Re: [PATCH 1/1] aarch64:fix aarch64_tlsdesc conflict handling

[Szabolcs Nagy <szabolcs dot nagy at arm dot com>]

On 06/11/15 16:09, Mark Hatle wrote:
> On 11/6/15 9:56 AM, Szabolcs Nagy wrote:
> > On 06/11/15 06:59, Maninder Singh wrote:
> > > This patch fixes aarch64_tlsdesc conflict handling in
> > > .gnu.conflict section. This patch is added to support prelink
> > > on aarch64 architecture.
> > > http://git.yoctoproject.org/cgit/cgit.cgi/prelink-cross/commit
> > > /?h=cross_prelink_aarch64&id=2e83ded69171d87b76bcffaeffbd2cdb532663de
> > >
> > > Signed-off-by: Vaneet Narang <v.narang@samsung.com>
> > > Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
> > > ---
> > >    sysdeps/aarch64/dl-machine.h |   17 ++++++++++++++---
> > >    1 files changed, 14 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/sysdeps/aarch64/dl-machine.h b/sysdeps/aarch64/dl-machine.h
> > > index 217e179..70c112d 100644
> > > --- a/sysdeps/aarch64/dl-machine.h
> > > +++ b/sysdeps/aarch64/dl-machine.h
> > > @@ -290,9 +290,20 @@ elf_machine_rela (struct link_map *map, const ElfW(Rela) *reloc,
> > >    #ifndef RTLD_BOOTSTRAP
> > >    	    if (! sym)
> > >    	      {
> > > -		td->arg = (void*)reloc->r_addend;
> > > -		td->entry = _dl_tlsdesc_undefweak;
> > > -	      }
> > > +			ElfW(Rela) * conflict_start = NULL;
> > > +			ElfW(Rela) * conflict_end = NULL;
> > > +			if ( l->l_info [ADDRIDX (DT_GNU_CONFLICT)])
> > > +		      {
> > > +				conflict_start = (ElfW(Rela) *) map->l_info [ADDRIDX (DT_GNU_CONFLICT)]->d_un.d_ptr;
> > > +				conflict_end = conflict_start +
> > > +								map->l_info [VALIDX (DT_GNU_CONFLICTSZ)]->d_un.d_val;
> > > +		      }
> > > +			td->arg = (void*)reloc->r_addend;
> > > +			if(conflict_start <= reloc && conflict_end >= reloc)
> > > +				td->entry = _dl_tlsdesc_return;
> > > +			else
> > > +				td->entry = _dl_tlsdesc_undefweak;
> >
> > this code could be better organised.
> > (to have minimal impact on the non-prelinked case, e.g by
> > leaving the original code alone and moving all the new
> > special casing behind one if that checks for DT_GNU_CONFLICT.)
> >
> > isn't it possible to just pass a dummy sym in
> > _dl_resolve_conflicts so we don't need any special
> > target specific code?
> >
> > is x86_64 tlsdesc also broken with prelinking?
>
> As far as I am ware the tlsdesc on x86_64 is working properly.  The current set
> of prelink tests pass.  I've not verified that that specific issue is tested for
> however.  (Current tests are in the 'testsuite' directory and run via 'make
> check'.  These tests recently exposed a problem between ld.so in glibc 2.22 and
> the prelink interface BZ # 19178.  This interface problem affected all
> i*86/x86_64 and arm/aarch64 systems.)

i see failures with CC='gcc -mtls-dialect=gnu2'

11 of 43 tests failed
(3 tests were not run)

but i'm not sure if my setup is correct.

> > who uses prelinking and why? (it has various issues
> > including defeating security measures..)
>
> Anyone who has memory usage requirements (low memory available) or load time
> performance requirements can benefit from the prelinker.
>
> The prelinker does not 'defeat' security measures.  If your design needs to use
> ASLR, then the prelinker is not for you.  (I won't debate the merits of ASLR,
> other then to say it has tradeoffs which need to be decided on by the platform
> integrator and it's not always the right answer.)
>
> When prelinking a small embedded system, it's fairly typical to see 1/2 MB or
> more in additional usable memory available after the system boot.  This is due

you seem to care about memory usage but use glibc..

(i thought ppl in that domain use busybox, possibly static
linked, and don't go near glibc).

i personally still don't see the prelink hack justified,
but since glibc supports it, it should be fixed if something
is broken.

> to fewer COW pages for the core system services such as sysvinit or systemd,
> udev, etc.  In addition the load time of the components is reduced (as shown by
> LD_DEBUG=statistics.)  These figures vary by system configuration (process
> choice) and number of running services of course.
>
> On a high end system with lots of memory and few load time speed requirements,
> prelinker may not provide the benefits justifying it's use -- but on embedded
> systems where performance and memory usage are often key software requirements
> the prelinker can make the difference between a CPU core being adequate for the
> task -- or a product doomed to failure.
>
> > > +	      }
> > >    	    else
> > >    #endif
> > >    	      {