Failure in elf/tst-pie-address{, -static} on aarch64 with PAC/BTI release.

[Sam James]

Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> writes:

> On 15/01/25 19:42, Aurelien Jarno wrote:
>> Hi,
>> 
>> Commit e7b553272196 ("elf: Handle static PIE with non-zero load address
>> [BZ #31799]") added two news tests, elf/tst-pie-address and
>> elf/tst-pie-address-static. In my test builds for glibc 2.41, they fail
>> on aarch64 when PAC/BTI is enabled with the current HEAD.
>> elf/tst-pie-address fails with a SIGSEGV and elf/tst-pie-address-static
>> with a SIGILL.
>> 
>> This has been fixed by commit bce70034b112 ("elf: Check PDE load address
>> with non-empty text section") for the non-PAC/BTI case, but I still
>> observe the tests failures with PAC/BTI enabled in the compiler. This is
>> on a CPU which does not support PAC/BTI and which should interpret the
>> corresponding instructions as nop. I have tested building glibc with
>> both binutils 2.43.1 and 2.43.50.20250108 and both gcc 13.3.0 and gcc
>> 14.2.0.
>> 
>> This can be reproduced with (at least here) with:
>> 
>> CC="gcc -mbranch-protection=standard" CXX="g++ -mbranch-protection=standard" ../glibc/configure --prefix=/usr && make -j4 && make -j4 check
>> 
>> Any idea?
>
> I can reproduce it with binutils 2.43.1, but it seems a ld.bfd issue.
> Building with -Ttext-segment=0x0000000000400000 I see unusual PLT stubs
> being generated:
>
> $ objdump -D --section .plt elf/tst-pie-address
> [...]
> 0000000000401a40 <memcpy@plt>:
>   401a40:       90000010        adrp    x16, 401000 <__abi_tag+0xce0>
>   401a44:       f90000f1        str     x17, [x7]
>   401a48:       91000210        add     x16, x16, #0x0
>   401a4c:       d6000220        .inst   0xd6000220 ; undefined
>   401a50:       90000010        adrp    x16, 401000 <__abi_tag+0xce0>
>   401a54:       f90000f1        str     x17, [x7]
> [...]
>
> Where with same link command, but without -Ttext-segment=, it shows the
> expected stub instructions:
>
> $ objdump -D --section .plt elf/tst-pie-address-no-text-segment:
> [...]
> 0000000000001a40 <memcpy@plt>:
>     1a40:       f00000f0        adrp    x16, 20000 <memcpy@GLIBC_2.17>
>     1a44:       f9400211        ldr     x17, [x16]
>     1a48:       91000210        add     x16, x16, #0x0
>     1a4c:       d61f0220        br      x17
>
> Also, lld seems to generate correct binary (with its analogous --image-base
> option).

Can you file a binutils bug ASAP, given the release is planned soon
(branching on Sunday)? Thanks.