Re: Can DT_RELR catch up glibc 2.35?

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 18/11/2021 20:27, Fangrui Song via Libc-alpha wrote:
> (For newly CCed Linux distro folks, sorry for hijacking you here. Scroll
> to the end for my request from you.)
> 
> The first message of the thread is
> https://sourceware.org/pipermail/libc-alpha/2021-November/133009.html
> and
> https://maskray.me/blog/2021-10-31-relative-relocations-and-relr#time-travel-compatibility
> provides context.
> )
> 
> On 2021-11-18, Florian Weimer wrote:
>> * Fangrui Song via Libc-alpha:
>>
>>> A synthesized versioned undefined dynamic symbol can indeed catch "time
>>> travel compatibility", but the mechanism would be the first time ld adds an option variant
>>> for a particular libc implementation (glibc) locking out all other
>>> implementations: --pack-dyn-relocs=relr-glibc or -z relr-glibc.
>>> Sigh, it is really not pretty.
>>
>> There are already other features that do not work with other libcs,
>> e.g. --audit, --filter, --auxiliary.  And --dynamic-linker tends to lock
>> out other libcs, too.  And it's a bit hard to argue against this given
>> that --pack-dyn-relocs=relr works the same way against upstream glibc.
> 
> --audit, --filter, and --auxiliary do not lock out other
> implementations. Solaris has DT_AUDIT, DT_FILTER, and DT_AUXILIARY.
> If a libc implementation desires, it can add the support.
> 
> --pack-dyn-relocs=relr-glibc or -z relr-glibc would be the first time an
> option name mentions glibc. (See below, it could be "relr-gnu", but still
> something not many users using ELFOSABI_GNU want).
> 
>> However, I happen to dislike the glibc-tied approach as well, and would
>> like to see an ELFOSABI bump, along with a kernel fix to make it stick
>> for main programs as well.
> 
> Thanks for disliking the glibc-tied approach :)
> 
> EI_ABIVERSION depends on EI_OSABI. We need to discuss
> ELFOSABI_NONE/ELFOSABI_GNU separately.
> 
> For ELFOSABI_GNU (alias: ELFOSABI_LINUX), the option name does not have
> to mention "glibc" and can probably use "relr-gnu".  However, It is
> still odd that a feature exists/works well and a "*-gnu" variant is
> added just because glibc uses a different development model.
> 
> I think Android bionic / musl may feel the change unnecessary but may
> not complain loudly because they just doesn't inspect EI_ABIVERSION.
> Well, musl doesn't support DT_RELR, but Rich can provide more
> authoritative opinion on EI_ABIVERSION bump from musl's point of view.

I think it is a fair assumption that for ELFOSABI_GNU DT_RELR to use a
newer value for EI_ABIVERSION.  Android also supports DT_REL/DT_ANDROID_RELR
even without a proper standard ABI definition, so I assume it won't really
care about EI_ABIVERSION/ELFOSABI_GNU bump.

And at least for glibc, EI_ABIVERSION was not really enforced because it
lacks full coverage (it fails when loader is not responsible to load
binary image).  Some architecture tries to leverage it (MIPS for instance),
but I think currently it is a best effort than a proper solution.

> 
> For ELFOSABI_NONE: many Linux executables don't use
> STB_GNU_UNIQUE/STT_GNU_IFUNC and therefore use ELFOSABI_NONE.  I think
> Solaris folks have ruled out the possibility to bump EI_OSABIVERSION.
> This is not something they/FreeBSD/etc need.> 
> In addition, to make EI_ABIVERSION check work. A distro needs to
> backport the change to many old glibc versions. I am not sure many
> distros want to do this.

Yes, it takes time and not all distributions will pick this support
readily.  However backporting EI_ABIVERSION/ELFOSABI_GNU proper check
should be easy.

> 
>>> We know many other libc implementations don't want to synthesize such a
>>> symbol.
>>
>> It's been used for other toolchain features before, that's where the
>> idea comes from.
> 
> E.g. __stack_chk_guard, _mcount from GCC/Clang instrumentation as
> a compiler-libc protocol.
> But this would be the first time the linker synthesizes an undefined symbol.

I also dislike this approach.

> 
>>> "If user is deploying a *opt-in* feature that requires proper dynamic
>>> loader support, I would expect they know the environment they are targeting."
>>>
>>> May I suggest that: if a glibc distro really worries that users deploy
>>> ld.lld --pack-dyn-relocs=relr on their new system and back port that to
>>> old systems, just remove DT_RELR support from your local glibc? Since
>>> ld.lld --pack-dyn-relocs=relr  doesn't work on your system with glibc
>>> 2.35, people wouldn't complain about not working on older versions.
>>
>> In a sense, isn't that what's happening?  Albeit on an upstream scale.
> 
> From my point of view, I want glibc based Linux distro to benefit from
> DT_RELR earlier. Blocking this on an upstream scale is not appealing.
> 
> CCed a bunch of Linux distro folks (Arch/Debian/Gentoo/Void).
> 
> * ld.lld is not a default linker on most Linux distros.
> * ld.lld --pack-dyn-relocs=relr is an opt-in feature.
> * --pack-dyn-relocs=relr is difficult to misuse because GNU ld doesn't support it.
> * binutils may get relr support one day, but may take several releases.
> * Nobody will switch the GCC/Clang default any time soon.
> * Coping the new executable to an old glibc system is unsupported.
> 
> By enabling DT_RELR in upstream glibc, the Linux distros will get the
> glibc feature with ZERO overhead in their downstream packaging.  Then, a
> user opting in ld.lld --pack-dyn-relocs=relr will have smaller
> executables.  When GNU ld finally gets the feature, the benefit will
> reach more users. So why not having the feature to make the future
> feature enablement smoother?

I tend to agree with your points, but I am still failing the see the trouble
to support different EI_ABIVERSION for ELFOSABI_GNU on lld (or any other
linker that intends to support DT_RELR for ELFOSABI_GNU).