Re: Can DT_RELR catch up glibc 2.35?

[Fangrui Song <maskray@google.com>]

(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.

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.

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

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