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

[Florian Weimer <fweimer@redhat.com>]

* 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?

Sorry, I would have to see the patch.  But I generally appreciate
consistency.

Thanks,
Florian