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

Message-ID: <20250828083747-e819430a-986f-4f71-bbc8-e402e339c9a2@linutronix.de>
Date: Mon, 1 Sep 2025 11:51:03 +0200
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Nathan Chancellor <nathan@...nel.org>
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

On Wed, Aug 27, 2025 at 03:49:35PM -0700, Nathan Chancellor wrote:
> 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))

(...)

> > 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?

Exactly. The normal cases can be handled generically. For example the kconfig
below works for architectures which only differ in byte order and 32bit/64bit,
which are most of them. MIPS should require more logic.
Also I'm ignoring x32, as it is never the kernel's native ABI.

 config CC_CAN_LINK
        bool
+       default $(cc_can_link_user,$(m64-flag) -mlittle-endian) if 64BIT && CPU_LITTLE_ENDIAN
+       default $(cc_can_link_user,$(m64-flag) -mbig-endian) if 64BIT && CPU_BIG_ENDIAN
        default $(cc_can_link_user,$(m64-flag)) if 64BIT
+       default $(cc_can_link_user,$(m32-flag) -mlittle-endian) if CPU_LITTLE_ENDIAN
+       default $(cc_can_link_user,$(m32-flag) -mbig-endian) if CPU_BIG_ENDIAN
        default $(cc_can_link_user,$(m32-flag))


> Feels like that could get complicated quickly but this would probably be
> the objectively most robust and "hands off" option.

Agreed.

> > * 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.

I'm not aware of any reports. Usage of userprogs seems to be fairly low in
general, judging by the issues I ran into which nobody reported or fixed
before. One of the original reasons for the introduction of userprogs were
usermode drivers. These indeed required execution. But the whole framework
was removed recently, although it might come back at some point.

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

(...)

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

Agreed. My personal preference would be my proposal from above.

> > * Add separate handling for runnable userprogs
> 
> What do you mean by this?

I see two possibilities.
* New kconfig and FLAGS mirroring the existing ones to build runnable
  userprogs.
* Introspection of the userprog executable ELF to see if it can run on the
  current kernel configuration.

> > * 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?

Yes, probably. Although the test code in samples/ should interact directly with
the kernel, without much involvement from libc.


Thomas