linux-kernel - Re: [RFC PATCH v2 02/10] tools/nolibc: crt: Split _start

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: <aYdeDWCCeDjYerin@1wt.eu>
Date: Sat, 7 Feb 2026 16:45:17 +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 02/10] tools/nolibc: crt: Split _start_c() into
 stack-only and normal parts

On Wed, Feb 04, 2026 at 09:45:34PM +0900, Daniel Palmer wrote:
> To prepare for nolibc programs being able to relocate themselves
> we need to split _start_c() into two parts:
> 
> - One part that only uses the stack so there are no accesses via
>   the GOT etc that isn't setup yet. Note that on m68k at least
>   this also means forcing the stackprotector off because accessing
>   the stack protector canary is done via the GOT.
> 
> - Another part that is called after we have done relocation so it
>   is safe to access global variables etc that might use the GOT etc.
> 
> Signed-off-by: Daniel Palmer <daniel@...ngy.jp>
> ---
>  tools/include/nolibc/compiler.h |  6 ++++
>  tools/include/nolibc/crt.h      | 57 ++++++++++++++++++---------------
>  2 files changed, 38 insertions(+), 25 deletions(-)
> 
> diff --git a/tools/include/nolibc/compiler.h b/tools/include/nolibc/compiler.h
> index 87090bbc53e0..3f403e54e4f4 100644
> --- a/tools/include/nolibc/compiler.h
> +++ b/tools/include/nolibc/compiler.h
> @@ -47,4 +47,10 @@
>  #  define __nolibc_fallthrough do { } while (0)
>  #endif /* __nolibc_has_attribute(fallthrough) */
>  
> +#if __nolibc_has_feature(undefined_behavior_sanitizer)
> +#  define __no_sanitize __attribute__((no_sanitize("function")))
> +#else
> +#  define __no_sanitize
> +#endif

I'm starting to feel uncomfortable with the addition of new __no_foo
stuff, which doesn't have the "nolibc" prefix, risking to conflict with
userland code. I think we'll have to go through a cleanup patch at some
point for __no_sanitize and __no_stack_protector.

So probably in order to reduce the technical debt it would be nice to
to prepend __nolibc in front of this new internal macro. Maybe this part
of the patch should be a separate cleanup patch by the way, as future
patches might depend on it.

Willy