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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250827075334-3332c08d-66f3-427d-b0b2-4460e779f261@linutronix.de>
Date: Wed, 27 Aug 2025 08:31:00 +0200
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Nathan Chancellor <nathan@...nel.org>, 
	Nicolas Schier <nicolas.schier@...ux.dev>
Cc: 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!

On Wed, Aug 13, 2025 at 07:43:41AM +0200, Thomas Weißschuh wrote:
> Make sure the byte order and ABI of the userprogs matches the one of the
> kernel, similar to how the bit size is handled.
> Otherwise the userprogs may not be executable.
> This happens for example on powerpc little endian, or riscv32.
> 
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
> Reviewed-by: Nicolas Schier <n.schier@....de>
> Acked-by: Masahiro Yamada <masahiroy@...nel.org>
> 
> ---
> Difference to original series:
> * Also handle -EL/-EB for MIPS
> ---
>  Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> 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].
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.

I see the following options:

* Add byte order and architecture-specific ABI handling to CC_CAN_LINK
* Accept that userprogs might not be runnable on the built kernel
* Let the user manually set CC_CAN_LINK to override the autodetection
* Add separate handling for runnable userprogs
* Use tools/include/nolibc/ for userprogs instead of the toolchain libc
  (unlikely, but I wanted do mention the option)


Thomas

[0] https://lore.kernel.org/lkml/20250818140143.61b8c466@canb.auug.org.au/