linux-kernel - Re: 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 for Android: free password hash cracker in your pocket

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

Message-ID: <11356b6c-3f26-411c-a2ce-9cae9dfd3ea5@sirena.org.uk>
Date:   Wed, 13 Sep 2023 20:17:01 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Sebastian Ott <sebott@...hat.com>
Cc:     Willy Tarreau <w@....eu>,
        Thomas Weißschuh <linux@...ssschuh.net>,
        linux-kernel@...r.kernel.org
Subject: Re: aarch64 binaries using nolibc segfault before reaching the entry
 point

On Wed, Sep 13, 2023 at 08:44:59PM +0200, Sebastian Ott wrote:

> 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 did notice this on some systems but didn't manage to reproduce it
interactively and hence debug it yet :/

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

...

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

That suggests that there's some randomisation of the executable location
going on which is triggering the issue...  TBH it seems sensible to take
a patch that enables that for now, it's clearly better to get the tests
running more reliably even if we don't fully understand the issue.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)