[Bug dynamic-link/23293] aarch64: getauxval is broken when run as ld.so ./exe and ld.so adjusts argv on the stack

["fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=23293

--- Comment #5 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Szabolcs Nagy from comment #4)
> (In reply to Florian Weimer from comment #3)
> > (In reply to Michael Hudson-Doyle from comment #2)
> > > I've just run into this because it causes a glibc test failure when
> > > libnss-systemd is enabled
> > > (https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1869364).
> > > 
> > > Would a fix be for _dl_start_user to update _dl_auxv in the same way it
> > > updates _dl_argv? Or is that just naive (start up code confuses me!)
> > 
> > I think this should work. There does not seems to be anything that stores
> > the address if auxv entries, only values read from the vector.
> 
> it may work, but i think _dl_start_user stack handling should
> not be updated, it should be removed: the logic is backwards:
> 
> most targets have fragile asm for the rtld start code to shuffle
> around entries on the stack, but such shuffling can be done in c
> in the generic code (e.g. in dl_main).
> 
> this would also fix the (imo security) bug that the protection
> of dl data is not consistent across targets (DL_ARGV_NOT_RELRO).
> 
> and all this mess is for saving a few cycles on targets where
> you don't need to do the shuffling. i think the generic code
> should work for all targets and those who wish to optimize
> add some hacks (e.g. ifdef out the shuffling), not the other
> way around.
> 
> i didnt get the chance to clean this up yet, so it's not fixed.

That sounds of course very reasonable. As long as very manipulate the arguments
as arrays, the C code should be very portable. An assembler stub will still be
needed, but it will be much smaller.

I also think we should move the assembler code out of dl-machine.h while we are
at it. We can start out with an empty dl-start.S file, and gradually move ports
to follow the powerpc32 example.

-- 
You are receiving this mail because:
You are on the CC list for the bug.