linux-kernel - aarch64 binaries using nolibc segfault before reaching the entry point

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <5d49767a-fbdc-fbe7-5fb2-d99ece3168cb@redhat.com>
Date:   Wed, 13 Sep 2023 20:44:59 +0200 (CEST)
From:   Sebastian Ott <sebott@...hat.com>
To:     Mark Brown <broonie@...nel.org>, Willy Tarreau <w@....eu>,
        Thomas Weißschuh <linux@...ssschuh.net>
cc:     linux-kernel@...r.kernel.org
Subject: aarch64 binaries using nolibc segfault before reaching the entry
 point

Hi,

the tpidr2 selftest on an arm box segfaults before reaching the entry point.
I have no clue what is to blame for this or how to debug it but for a
statically linked binary there shouldn't be much stuff going on besides the
elf loader?

I can reproduce this with a program using an empty main function. Also checked
for other nolibc users - same result for init.c from rcutorture.

tools/testing/selftests/arm64/fp/za-fork is working though - the only
difference I could spot here is that it is linked together with another object
file. I also looked at the elf headers but didn't find anything obvious (but
I'm a bit out of my comfort zone here..)

After playing around with linker options I found that using -static-pie
lets the binaries run successful.

[root@arm abi]# cat test.c
int main(void)
{
         return 1;
}
[root@arm abi]# gcc -Os -static -Wall -lgcc -nostdlib -ffreestanding  -include ../../../../include/nolibc/nolibc.h  test.c
[root@arm abi]# ./a.out 
Segmentation fault
[root@arm abi]# gcc -Os -static -Wall -lgcc -nostdlib -ffreestanding -static-pie -include ../../../../include/nolibc/nolibc.h  test.c
[root@arm abi]# ./a.out 
[root@arm abi]#

All on aarch64 running fedora37 + upstream kernel. Any hints on what could
be borken here or how to actually fix it?

Sebastian