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: <20251006191314.GA2706650@ax162>
Date: Mon, 6 Oct 2025 12:13:14 -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 Thu, Oct 02, 2025 at 03:23:08PM +0200, Thomas Weißschuh wrote:
> I investigated this some more and didn't really like the end result. The
> problem is that $(m32-flag) and $(m64-flag) will expand to nothing if the
> compiler does not support -m32/-m64. So for architectures which use
> different flags the current logic will just ignore the bitness. One way
> around this would be a mapping from -m32/-m64 to architecture-specific
> flags inside cc-can-link.sh, similar to what I already did before for
> the mapping of -mlittle-endian to -EL on MIPS. But we'll end up with a
> bunch of architecture-specific details hidden away in a non-generic
> shellscript. And the interactions are very non-obvious and brittle.
> Then I'd rather have the architecture-specific bits openly in proper
> architecture code.
> 
> See my current proposal, using x86 as example below. It will require
> code for each architecture, but there are not that many of them.
> And the configuration matrix for each architecture only contains a
> relative small set of actually supported configurations.
> Unfortunately I don't see a generic way to deduplicate the flag values
> between ARCH_CC_CAN_LINK ARCH_USERPROGS_CFLAGS. Each architecture can
> use a macro if they so prefer.
> 
> When the "interesting" architectures are done we can also slim down the
> generic implementation to not use any special arguments and that would
> be enough for the simple architectures.
> 
> For the future I would like to introduce CC_CAN_LINK_STATIC again.
> With the scheme from below this would mean to duplicate all the kconfig
> symbols for each architecture again. One way around would be to change
> ARCH_CC_CAN_LINK from bool to string. And then let cc-can-link.sh test
> for both static and dynamic linking in one go and return either
> "dynamic,static", "dynamic" or "static" which then can be mapped to
> CC_CAN_LINK and CC_CAN_LINK_STATIC by generic logic.
> 
> What do you think?

Yeah this seems like a reasonable direction to start heading. I would
much prefer a little more verbosity for the sake of robustness and
maintainability going forward, especially since these are static flags
per architecture (i.e., once they are initially set, they should not
change).

> diff --git a/Makefile b/Makefile
> index d37dca7850b3..17123948a4fa 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1135,7 +1135,15 @@ LDFLAGS_vmlinux	+= --emit-relocs --discard-none
>  endif
>  
>  # Align the bit size of userspace programs with the kernel
> -USERFLAGS_FROM_KERNEL := -m32 -m64 --target=%
> +USERFLAGS_FROM_KERNEL := --target=%
> +
> +ifdef CONFIG_ARCH_USERPROGS_CFLAGS
> +KBUILD_USERCFLAGS += $(CONFIG_ARCH_USERPROGS_CFLAGS)
> +KBUILD_USERLDFLAGS += $(CONFIG_ARCH_USERPROGS_CFLAGS)
> +else
> +USERFLAGS_FROM_KERNEL += -m32 -m64
> +endif
> +
>  KBUILD_USERCFLAGS  += $(filter $(USERFLAGS_FROM_KERNEL), $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS))
>  KBUILD_USERLDFLAGS += $(filter $(USERFLAGS_FROM_KERNEL), $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS))
>  
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 75f3de70df51..162c71c117bc 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -332,6 +332,17 @@ config X86
>  	select SCHED_SMT			if SMP
>  	select ARCH_SUPPORTS_SCHED_CLUSTER	if SMP
>  	select ARCH_SUPPORTS_SCHED_MC		if SMP
> +	select ARCH_HAS_CC_CAN_LINK
> +
> +config ARCH_CC_CAN_LINK
> +	bool
> +	default $(cc_can_link_user,-m64) if 64BIT
> +	default $(cc_can_link_user,-m32) if !64BIT
> +
> +config ARCH_USERPROGS_CFLAGS
> +	string
> +	default "-m64" if 64BIT
> +	default "-m32" if !64BIT
>  
>  config INSTRUCTION_DECODER
>  	def_bool y
> diff --git a/init/Kconfig b/init/Kconfig
> index f3b13463ec26..5ca2f3289020 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -82,8 +82,13 @@ config RUSTC_LLVM_VERSION
>  	int
>  	default $(rustc-llvm-version)
>  
> +# Might be removed when all architectures are migrated
> +config ARCH_HAS_CC_CAN_LINK
> +	bool
> +
>  config CC_CAN_LINK
>  	bool
> +	default ARCH_CC_CAN_LINK if ARCH_HAS_CC_CAN_LINK
>  	default $(success,$(srctree)/scripts/cc-can-link.sh $(CC) $(CLANG_FLAGS) $(USERCFLAGS) $(USERLDFLAGS) $(m64-flag)) if 64BIT
>  	default $(success,$(srctree)/scripts/cc-can-link.sh $(CC) $(CLANG_FLAGS) $(USERCFLAGS) $(USERLDFLAGS) $(m32-flag))
>  
> diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
> index 33193ca6e803..0c8dbfbce415 100644
> --- a/scripts/Kconfig.include
> +++ b/scripts/Kconfig.include
> @@ -75,3 +75,6 @@ rustc-llvm-version := $(shell,$(srctree)/scripts/rustc-llvm-version.sh $(RUSTC))
>  # If you are testing for unstable features, consider testing RUSTC_VERSION
>  # instead, as features may have different completeness while available.
>  rustc-option = $(success,trap "rm -rf .tmp_$$" EXIT; mkdir .tmp_$$; $(RUSTC) $(1) --crate-type=rlib /dev/null --out-dir=.tmp_$$ -o .tmp_$$/tmp.rlib)
> +
> +# Test whether the compiler can link userspace applications
> +cc_can_link_user = $(success,$(srctree)/scripts/cc-can-link.sh $(CC) $(CLANG_FLAGS) $(USERCFLAGS) $(USERLDFLAGS) $(1))