linux-kernel - Re: [PATCH 2/5] ARM: uapi: Stop leaking CONFIG_CPU_ENDIAN

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: <20251230152519-1f7ea27a-10de-4d0c-9dd0-04eb0588d733@linutronix.de>
Date: Tue, 30 Dec 2025 15:33:39 +0100
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Arnd Bergmann <arnd@...db.de>
Cc: Vineet Gupta <vgupta@...nel.org>, Russell King <linux@...linux.org.uk>, 
	Dinh Nguyen <dinguyen@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, 
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>, 
	linux-snps-arc@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 2/5] ARM: uapi: Stop leaking CONFIG_CPU_ENDIAN_BE8
 reference to userspace

On Tue, Dec 30, 2025 at 03:20:10PM +0100, Arnd Bergmann wrote:
> On Tue, Dec 30, 2025, at 08:10, Thomas Weißschuh wrote:
> > UAPI headers are not supposed to leak references to kconfig symbols.
> > These won't be set when building userspace. Hide the kconfig reference
> > behind 'if defined(__KERNEL__)', so it will be stripped by
> > headers_install.sh, the same way other kconfig references in this file
> > are handled. The result for userspace will be the same, but the
> > exception in headers_install.sh can also be removed.
> >
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
> 
> According to codesearch.debian.net, there are no actual users of
> this definition outside of the kernel, and there really shouldn't
> be either.
> 
> It should be both safe and correct to open-code PSR_ENDSTATE
> in the two file where it is used as
> 
>  if (IS_ENABLED(CONFIG_CPU_ENDIAN_BE8))
>         regs->ARM_cpsr |= PSR_E_BIT
> 
> and then remove the definition from the header. Alternatively
> it could be moved into the non-uapi header, or you can have
> an #ifdef around both of them.

These alternatives work for me, too. I went with the current aproach as
it matches what the rest of the file is doing and it won't break users.

I'll do the open-coding as proposed above.


Thomas