linux-kernel - Re: [RFC PATCH 0/9] nolibc: Add static-pie support

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: <aX-X_lI8HOeMmLSz@1wt.eu>
Date: Sun, 1 Feb 2026 19:14:22 +0100
From: Willy Tarreau <w@....eu>
To: Daniel Palmer <daniel@...ngy.jp>
Cc: linux@...ssschuh.net, kees@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/9] nolibc: Add static-pie support

On Sat, Jan 31, 2026 at 04:44:31PM +0900, Daniel Palmer wrote:
> For more background see:
> https://lore.kernel.org/lkml/20260116122812.2421621-1-daniel@thingy.jp/
> 
> Basically I am trying to run normal ELF binaries created with
> nolibc on nommu (m68k, 68000). To make this work without an external
> linker nolibc needs code to do the relocation.
> 
> The following is my attempt at doing this by hacking just enough
> together that static-pie binaries work on a few archs.
> The ones that work have a patch in this series.
> 
> Answers to questions you might have:
> Q: Don't we need to handle more relocation types?
> A: Maybe, everything exception sparc only had R_x_RELATIVE in
>    the nolibc test binary. sparc emits R_SPARC_NONE as well.
> 
> Q: Don't we need to make some sections writable for this to
>    work.
> A: Maybe, I tried to get most of the supported archs working.
>    The only one that had relocations on a non-writable section
>    was arm64 and I think I can fix it so it doesn't need that.
> 
> Q: Why can't you just pass -static-pie to gcc?
> A: Only x86 seemed to actually produce static PIE binaries doing
>    that. Everything else produced normal static ones. Maybe this
>    is a compiler version thing?
> 
> There are probably things I'm missing, things I have done totally
> wrong. Please feel free to grill me.

I'm noticing a significant size increase with this change, and I'm
not sure all of it is well justified:

  $ size nolibc-test-*
     text    data     bss     dec     hex filename
    43300     120     112   43532    aa0c nolibc-test-6.19-rc7
    44524     120     112   44756    aed4 nolibc-test-daniel
  
    => +1.2 kB

Even a trivial "return 0;" program:

  $ size ret0-*      
     text    data     bss     dec     hex filename
    309      24      24     357     165 ret0-6.19-rc7
    642      24      24     690     2b2 ret0-daniel

    => +333 B

The difference I'm seeing is here:

  $ diff -u ret0*size
  --- ret0-6.19-rc7.size  2026-02-01 19:04:33.918536545 +0100
  +++ ret0-daniel.size    2026-02-01 19:04:40.914761767 +0100
  @@ -16,4 +16,5 @@
   0000000000000011 W raise
   0000000000000012 W abort
   0000000000000023 W memmove
  -0000000000000098 W _start_c
  +0000000000000086 W __start_c
  +000000000000015f W _start_c

The delta is indeed 333 bytes.

Is there anything we could detect at build time to detect that we want to
go the heavy way ? Maybe we should only condition that code to __PIE__ ?
There's nothing critical, it's really about having an open discussion on
this, because we're trying to keep the minimal binaries small, and here
we're just doubling the size of the smallest ones all the time.

Thanks!
Willy