[PATCH v3 1/2] aarch64: Use generic argv adjustment in ld.so [BZ #23293]

[Szabolcs Nagy]

The 05/03/2022 13:53, Florian Weimer via Libc-alpha wrote:
> * Szabolcs Nagy via Libc-alpha:
> 
> > When an executable is invoked as
> >
> >   ./ld.so [ld.so-args] ./exe [exe-args]
> >
> > then the argv is adujusted in ld.so before calling the entry point of
> > the executable so ld.so args are not visible to it.  On most targets
> > this requires moving argv, env and auxv on the stack to ensure correct
> > stack alignment at the entry point.  This had several issues:
> >
> > - The code for this adjustment on the stack is written in asm as part
> >   of the target specific ld.so _start code which is hard to maintain.
> >
> > - The adjustment is done after _dl_start returns, where it's too late
> >   to update GLRO(dl_auxv), as it is already readonly, so it points to
> >   memory that was clobbered by the adjustment. This is bug 23293.
> >
> > - _environ is also wrong in ld.so after the adjustment, but it is
> >   likely not used after _dl_start returns so this is not user visible.
> >
> > - _dl_argv was updated, but for this it was moved out of relro, which
> >   changes security properties across targets unnecessarily.
> >
> > This patch introduces a generic _dl_start_args_adjust function that
> > handles the argument adjustments after ld.so processed its own args
> > and before relro protection is applied.  It sets _dl_skip_args to 0 so
> > the existing adjustment in asm is not invoked.  Each target has to
> > opt-in to use this new adjustment since some targets don't need it.
> > Once all targets are updated, _dl_argv declaration can be simplified.
> >
> > A new _dl_start_argptr was introduced because the original sp is not
> > passed to dl_main which now has to do the adjustments.
> >
> > --
> > v2:
> > - use p != NULL, and a_type != AT_NULL
> > - remove the confusing paragraph from the commit message.
> 
> Looks good to me.
> 
> Reviewed-by: Florian Weimer <fweimer@redhat.com>

thanks, meanwhile i started working on v4.

that always does the new adjustment (even on targets that don't
require it) since ld.so invocation does not have to be optimal
but it's better to have consistent behaviour.

then the bug is fixed everywhere (not just opt-in).

is that an acceptable approach?