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: <aOFy0ZwUKoBC32MY@levanger>
Date: Sat, 4 Oct 2025 21:17:37 +0200
From: Nicolas Schier <nsc@...nel.org>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
Cc: Nathan Chancellor <nathan@...nel.org>, 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 Thu, Oct 02, 2025 at 03:23:08PM +0200, Thomas Weißschuh wrote:
> Hi Nicolas and Nathan,
> 
> On Wed, Sep 03, 2025 at 03:31:31PM -0700, Nathan Chancellor wrote:
> > On Mon, Sep 01, 2025 at 11:51:03AM +0200, Thomas Weißschuh wrote:
> > > 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.
> > 
> > Nicolas might feel differently but this does not seem terrible to me,
> > especially with a macro to wrap the common logic, which is where I felt
> > like things could get unwieldy. Feel free to send an RFC if it is not
> > too much work.
> 
> 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.

yes, thanks for trying and the verbose feedback.  I think you're right,
it's better to not hide the architecture-specific details.

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

Thanks for all the effort, your proposal sounds good to me and I think
it is a good way forward.

Please call out if you want active support.

Kind regards,
Nicolas