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

["Fāng-ruì Sòng" <maskray@google.com>]

On 2021-12-08, Florian Weimer wrote:
>* 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.

I was out-of-town for ~10 days. So sorry that I did not reply in time.

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

Thanks. I clarified my wording and added
"For ELFOSABI_GNU (r2 -nwqc 'wx 03 @ 7'), changing EI_ABIVERSION to 4 or
above will observe the failure with ld.so mapped objects but not with kernel
mapped objects."

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

Agree that OSABI/ABIVERSION is not enforced in the linker.

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

For ChromeOS patched glibc, I can forward the question to ChromeOS
toolchain folks. Actually the code review is open to the public and you
can comment on
https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/3320511

I think their viewpoint is similar to the Gentoo developer:
https://sourceware.org/pipermail/libc-alpha/2021-November/133388.html
If a group chooses a non-default feature, they need to understand the
implications and they cannot blame the upstream if porting the binary to
old systems would crash.

If the question is: "if upstream glibc implements the diagnostic, will
ChromeOS port the patch to their glibc".  My reply is non-authoritative,
but if this has not been a problem for more than 3 years now, I do know
see large value backporting the feature to their older glibc release.

If the question is to Google internal systems, such a diagnostic would
have a low value as production systems try hard not to have the
mismatching version problem (which is probably common on Linux desktops).
I believe many corporate users will share similar viewpoint.
They may control their production systems in such a way that running
a new executable on an old glibc is either impossible, or can be detected
with other means, so a built-in glibc diagnostic is not that useful.

While I am replying with my corporate email address (because I subscribe
to this list with it), I also need to speak up for other customers I
support as my non-work-related community duty (Android, Fuchsia,
FreeBSD, etc). For Android and Fuchsia, they have the feature for ~3
years now, while I think (running on an old system) is explicitly
unsupported for them, having a ld.so diagnostic (well, they use their
own libc implementations) at this point is definitely nearly useless.
For *BSD, I have heard multiple people saying something in line with
"this is a Linux problem. They'd not add new knobs to the toolchain".