linux-kernel - Re: [PATCH 2/2] kbuild: userprogs: also inherit byte order and ABI from kernel

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] [day] [month] [year] [list]

Message-ID: <20250827224935.GB414199@ax162>
Date: Wed, 27 Aug 2025 15:49:35 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
Cc: Nicolas Schier <nicolas.schier@...ux.dev>, linux-kbuild@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Masahiro Yamada <masahiroy@...nel.org>
Subject: Re: [PATCH 2/2] kbuild: userprogs: also inherit byte order and ABI
 from kernel

Hi Thomas,

On Wed, Aug 27, 2025 at 08:31:00AM +0200, Thomas Weißschuh wrote:
> On Wed, Aug 13, 2025 at 07:43:41AM +0200, Thomas Weißschuh wrote:
...
> > diff --git a/Makefile b/Makefile
> > index d0f5262a9c0f3b4aa79a91c20cc149d034ffa0b7..7d40f84d5efde18ed3a2f4d8cf7a9b1ec3610ed4 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1137,8 +1137,8 @@ ifneq ($(CONFIG_ARCH_VMLINUX_NEEDS_RELOCS),)
> >  LDFLAGS_vmlinux	+= --emit-relocs --discard-none
> >  endif
> >  
> > -# Align the bit size of userspace programs with the kernel
> > -USERFLAGS_FROM_KERNEL := -m32 -m64 --target=%
> > +# Align the bit size, byte order and architecture of userspace programs with the kernel
> > +USERFLAGS_FROM_KERNEL := -m32 -m64 -mlittle-endian -mbig-endian -EL -EB --target=% -march=% -mabi=%
> >  KBUILD_USERCFLAGS  += $(filter $(USERFLAGS_FROM_KERNEL), $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS))
> >  KBUILD_USERLDFLAGS += $(filter $(USERFLAGS_FROM_KERNEL), $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS))
> 
> I looked some more at the breakage reported from -next [0].

Thanks for looking into this.

> For architectures with multiple possible byte orders or ABIs the toolchain
> might be able to build the kernel for all combinations but might not have a
> matching libc for them. Currently userprogs uses the default byteorder and
> ABI from the compiler, which will match the included libcs if there is any.
> However the resulting binary might not run on the built kernel.
> CC_CAN_LINK can be extended to generically handle different byte orders, as
> for those we have standard kconfig symbols. But handling ABIs would need to
> be architecture specific and a bit more complex.
> 
> We can't use KBUILD_*FLAGS for CC_CAN_LINK, as they are not yet set during
> the configuration stage.

Right, this was the biggest thing that I noticed, which would really
help us out...

> I see the following options:
> 
> * Add byte order and architecture-specific ABI handling to CC_CAN_LINK

How do you envision this? Different default lines for each combination?
Feels like that could get complicated quickly but this would probably be
the objectively most robust and "hands off" option.

> * Accept that userprogs might not be runnable on the built kernel

I do wonder how common running the userprogs are. Obviously you hit this
in testing but I am curious if others have reported this.

> * Let the user manually set CC_CAN_LINK to override the autodetection

I am not sure I like this one but maybe we could have a hidden
CC_MAY_LINK with something like the current CC_CAN_LINK then CC_CAN_LINK
could be turned into something like

    config CC_CAN_LINK
        bool "Toolchain can link userspace executables" if !COMPILE_TEST
        default CC_MAY_LINK

I am not surethat would actually help us here plus I still do not like
the idea of throwing this back to the user.

> * Add separate handling for runnable userprogs

What do you mean by this?

> * Use tools/include/nolibc/ for userprogs instead of the toolchain libc
>   (unlikely, but I wanted do mention the option)

This could be interesting to explore but I assume using a cross libc
could be desirable for some people depending on the testing?

Cheers,
Nathan