Re: [PATCH] elf: Add elf checks for main executable

[Florian Weimer <fweimer@redhat.com>]

* Fāng-ruì Sòng:

> On Tue, Dec 7, 2021 at 12:35 PM Adhemerval Zanella via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
>>
>>
>>
>> On 07/12/2021 12:45, Florian Weimer wrote:
>> > * Adhemerval Zanella:
>> >
>> >> It does, but only for specific configurations.  bintutils does have a
>> >> testcase for it, pr21375*, but not all configurations does bump because
>> >> they do not require ABS relocations (for instance, for n64 -mmicromips
>> >> --defsym hidn=1 does set the ABI version to 4).
>> >
>> > Should this tell us something at DT_RELR?  That binutils doesn't help us
>> > to prevent crashes for other features?
>>
>> I think it tell us that binutils support for DT_RELR or any other potential
>> abi disruptive feature will need a better ABI enforce for all Linux or
>> affected ABI.  It seems that binutils support are not really unified with
>> the multiples architectures and ABI.
>>
>> But I think it should be doable on linker side.
>
> For DT_RELR, you may see
> https://maskray.me/blog/2021-10-31-relative-relocations-and-relr#ei_abiversion
> Many Linux executables (STB_GNU_UNIQUE/STT_GNU_IFUNC are not used) use
> ELFOSABI_NONE and the linker does not and should not bump
> EI_ABIVERSION.

That radare2 command is really confusing.  It changes the ABI version to
16.  It does not change OSABI to GNU.

So I think we actually agree on the ld behavior, that the
OSABI/ABIVERSION is not really used by binutils today.

One question I meant to ask you: If the GNU toolchain uses any mechanism
for lockout of older glibc, would Google start building binaries using
that mechanism and patch their glibc forks that implement DT_RELR to be
able to load binaries with the lockout?

Thanks,
Florian