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

[Adhemerval Zanella Netto]

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