linux-kernel - Re: [PATCH 0/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: <20250815075527-ada0921a-d2ab-40b6-8882-3c84339f0582@linutronix.de>
Date: Fri, 15 Aug 2025 07:57:32 +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 0/2] kbuild: userprogs: also inherit byte order and ABI
 from kernel

On Thu, Aug 14, 2025 at 11:46:46AM -0700, Nathan Chancellor wrote:
> On Wed, Aug 13, 2025 at 07:43:39AM +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.
> > 
> > These patches where originally part of my series "kunit: Introduce UAPI
> > testing framework" [0], but that isn't going anywhere right now and the
> > patches are useful on their own.
> > 
> > [0] kunit: Introduce UAPI testing framework

[0] https://lore.kernel.org/lkml/20250717-kunit-kselftests-v5-0-442b711cde2e@linutronix.de/

> > ---
> > Thomas Weißschuh (2):
> >       kbuild: userprogs: avoid duplication of flags inherited from kernel
> >       kbuild: userprogs: also inherit byte order and ABI from kernel
> 
> Seems reasonable to me. Should I fast track this via kbuild-fixes or
> should I just apply it to kbuild-next? I am guessing you only noticed
> this in the context of developing [0] so it might not be a big issue in
> the wild?

kbuild-next should be fine.


Thomas