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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aYdfDv4jU4yqYI2h@1wt.eu>
Date: Sat, 7 Feb 2026 16:49:34 +0100
From: Willy Tarreau <w@....eu>
To: Daniel Palmer <daniel@...ngy.jp>
Cc: linux@...ssschuh.net, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2 03/10] tools/nolibc: Add basic ELF self-relocation
 support for static PIE

On Wed, Feb 04, 2026 at 09:45:35PM +0900, Daniel Palmer wrote:
> Currently nolibc programs cannot be compiled with -static-pie.
> Which is basically no shared libraries, no interpreter, but contain
> relocation information in the ELF to allow the program to be fixed
> up to run at the address that the kernel loaded it to.
> 
> There might be other use cases for static PIE but mine is for nommu.
> The ELF FDPIC loader can actually load normal ELFs is long as they
> can be relocated.
> 
> This very basic implementation does the following:
> 
> - Works out if we are PIE and need to be relocated. ELF type == ET_DYN
> - Works out if we are static PIE, have no interpreter, and need to
>   relocate ourselves.
> - Calculates the base address using the ELF program header address
>   given to us by the kernel and the size of the ELF header that
>   should be directly above.
> - Finds the ELF relocation data.
> - Calls an arch specific function to handle each of the relocations.
> 
> Note that from testing a lot of archs don't produce static PIE
> binaries with the -static-pie option and you need to compile with
> -pie -Wl,--no-dynamic-linker to get a static PIE binary.
> 
> Currently REL and RELA formats are supported.

So we're clearly past my knowledge of these things and will have to
trust you :-)

One thing however, please keep in mind that all your _relocate and
__relocate* functions will be visible from userland code and as such
should be prefixed with "_nolibc" (or even __nolibc) to prevent name
conflicts. It's a particular effort we have to do that is caused by
the lib's design consisting only in include files: nothing at all
is private.

Willy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ