linux-kernel - Re: [RFC PATCH v2 00/10] 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: <aYdbkEnAooEuWkae@1wt.eu>
Date: Sat, 7 Feb 2026 16:34:40 +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 00/10] nolibc: Add static-pie support

Hi Daniel,

On Wed, Feb 04, 2026 at 09:45:32PM +0900, Daniel Palmer wrote:
> v2:
> 
> - This is still RFC quality
> - I have gotten a few more archs to work (not crash in nolibc-test) so I have added them
>   to show the that the arch specific parts are pretty small.
> - This should now only add this extra code if NOLIBC_WANT_RELOC is defined, which happens
>   automatically if you compile with -fpie. Should address Willy's concern with the size
>   blowing up for even binaries that don't need this.

Oh yes that's a nice improvement indeed, thank you:

  $ size init-master init-dpalmer*
     text    data     bss     dec     hex filename
    22519      24   39424   61967    f20f init-master
    22562      24   39424   62010    f23a init-dpalmer
    22710      56   39424   62190    f2ee init-dpalmer-pie
    22816      24   39424   62264    f338 init-dpalmer-want-reloc

I think the 43 bytes increase on the _start_c part remains acceptable,
especially compared to the +300 before :-)

>   Size difference on ppc64 is massive, I guess PIC code is big there.
>   
>   static:
>   
>   $ file nolibc-test
> nolibc-test: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, Power ELF V1 ABI, version 1 (SYSV), statically linked, not stripped
> $ size nolibc-test
>    text    data     bss     dec     hex filename
>   59560    3240     104   62904    f5b8 nolibc-test
> 
>   static pie:
>   
>   $ file nolibc-test
> nolibc-test: ELF 64-bit MSB pie executable, 64-bit PowerPC or cisco 7500, Power ELF V1 ABI, version 1 (SYSV), static-pie linked, with debug_info, not stripped
>   $ size nolibc-test
>    text    data     bss     dec     hex filename
>   67801    3656     104   71561   11789 nolibc-test
>   
> - Each of the archs checks that the relocations they need (just the one at the moment) is defined
>   before defining the relocation defines. So this shouldn't break with older UAPI headers.

I confirm, I've built against 5.10 to 6.18 and it's OK, and if -fpie
is passed we get an error saying the arch doesn't support it.
 
> - I think maybe you might want to set NOLIBC_WANT_RELOC even if __pie__ is not defined,
>   maybe for testing? So I didn't make it _NOLIBC_WANT_RELOC.

It's possible, at least for developers/maintainers maybe. Above I used it
to compare the size increase caused by the changes.

> - I was worried some archs didn't work because calling the relocation functions was
>   causing things like accessing the stack canary before it was accessible. So I added
>   __inline__ to all of the relocation functions to force them to get inlined into _start_c().

If you absolutely need to forcefully inline, you should add
__attribute__((always_inline)) in addition to __inline__, as
it will override the default compiler setting based on the
optimization level. However the functions are short enough
that they were always inlined in my tests regardless of the
attribute.

>   This might be too much. checkpatch certainly hates it.

No big deal.

Thanks,
Willy