Re: [PATCH v6 3/5] Add GLIBC_ABI_DT_RELR for DT_RELR support

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

On 30/03/2022 11:41, H.J. Lu wrote:
> On Wed, Mar 30, 2022 at 7:18 AM Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>>
>>
>>
>> On 29/03/2022 19:29, H.J. Lu wrote:
>>> On Tue, Mar 29, 2022 at 9:52 AM Adhemerval Zanella
>>> <adhemerval.zanella@linaro.org> wrote:
>>>>
>>>>
>>>>
>>>> On 10/03/2022 17:03, H.J. Lu via Libc-alpha wrote:
>>>>> The EI_ABIVERSION field of the ELF header in executables and shared
>>>>> libraries can be bumped to indicate the minimum ABI requirement on the
>>>>> dynamic linker.  However, EI_ABIVERSION in executables isn't checked by
>>>>> the Linux kernel ELF loader nor the existing dynamic linker.  Executables
>>>>> will crash mysteriously if the dynamic linker doesn't support the ABI
>>>>> features required by the EI_ABIVERSION field.  The dynamic linker should
>>>>> be changed to check EI_ABIVERSION in executables.
>>>>>
>>>>> Add a glibc version, GLIBC_ABI_DT_RELR, to indicate DT_RELR support so
>>>>> that the existing dynamic linkers will issue an error on executables with
>>>>> GLIBC_ABI_DT_RELR dependency.  Issue an error if there is a DT_RELR entry
>>>>> without GLIBC_ABI_DT_RELR dependency nor GLIBC_PRIVATE definition.
>>>>>
>>>>> Support __placeholder_only_for_empty_version_map as the placeholder symbol
>>>>> used only for empty version map to generate GLIBC_ABI_DT_RELR without any
>>>>> symbols.
>>>>
>>>> I think it only make sense to add the GLIBC_ABI_DT_RELR if the ABI actually
>>>> supports DT_RELR, otherwise if the ABI start to support old glibcs might
>>>> wrongly assumes DT_RELR and fails with undefined behavior at runtime
>>>> (which this patch essentially tries to avoid).
>>>
>>> The DT_RELR set enables DT_RELR in glibc for all targets.
>> If I understood correctly, if we add GLIBC_ABI_DT_RELR on 2.36 but only enable
>> it on some architecture on 2.37 and try to run a binary with DT_RELR enabled
>> on glibc 2.36, _dl_check_map_versions won't accuse a failure and it will
>> eventually only fail at runtime (since relocation won't be applied).  My
>> understanding we are trying to avoid such failures.
> 
> My patch set enables DT_RELR and GLIBC_ABI_DT_RELR on glibc 2.36
> for all, regardless of binutils version.   There is no per-arch
> behavior.    Only
> DT_RELR run-time tests are enabled for linkers with -z pack-relative-relocs.

But it still does not fail when the architecture does not actually implement
RELR even when static linker does:

$ clang --target=aarch64-linux-gnu -fuse-ld=lld -Wl,-z,pack-relative-relocs -fpie -o test -pie test.c
$ aarch64-glibc-linux-gnu-readelf -S test | grep relr\.dyn
  [ 9] .relr.dyn         RELR             0000000000000528  00000528
$ ./elf/ld.so --library-path . ./test
$

I would expect that even when binary adds GLIBC_ABI_DT_RELR, if dynamic linker
does not have DT_RELR it would fail early.