linux-kernel - Re: [PATCH] powerpc: Implement ARCH_HAS_CC_CAN

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: <20260105095007-f78459cc-248a-4926-940b-bc41e58251f5@linutronix.de>
Date: Mon, 5 Jan 2026 10:01:29 +0100
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Segher Boessenkool <segher@...nel.crashing.org>, 
	"Christophe Leroy (CS GROUP)" <chleroy@...nel.org>
Cc: Madhavan Srinivasan <maddy@...ux.ibm.com>, 
	Michael Ellerman <mpe@...erman.id.au>, Nicholas Piggin <npiggin@...il.com>, 
	linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] powerpc: Implement ARCH_HAS_CC_CAN_LINK

Hi!

On Sat, Jan 03, 2026 at 08:06:42AM -0600, Segher Boessenkool wrote:
> On Sat, Jan 03, 2026 at 11:39:12AM +0100, Christophe Leroy (CS GROUP) wrote:
> > Le 30/12/2025 à 08:06, Thomas Weißschuh a écrit :
> > > The generic CC_CAN_LINK detection does not handle different byte orders.
> > > This may lead to userprogs which are not actually runnable on the target
> > > kernel.
> > 
> > Isn't the kernel supposed to handle any userland endianess ? Macro
> > SET_ENDIAN() is there for that as far as I understand.

To be honest I have no idea how switching endianess in the middle of an
application is supposed to work with C applications. Suddenly all of the
UAPI needs different a different byte order, for which I see no support
in the kernel.

A big-endian kernel still does not seem to load a little-endian userspace
executable and instead fails with ENOEXEC. This is the issue I am trying
to address.

> Yes, the kernel does not get much data out of data structures in memory
> in the first place :-)

Except for all of the UAPI :-/

> > And if you want to be complete, I think you should also check whether the
> > ELF ABI is v1 or v2.
> 
> ELFv2 is version 1 of ELF, as wel as version 1 of its particular ABI.
> It is just a cutesy name.  The thing now called "ELFv1" was called
> "PowerOpen", or simply "PowerPC 64-bit ELF", or one of a hundred other
> names :-)
> 
> All of the ABIs we use with PowerPC (in trunk, anyway) work with either
> endianness (well, you need a userland built for it of course, and maybe
> AIX and/or Darwin have not actually been designed to work with wrong-
> endian as well).
> 
> But powerpc-{elf,linux} and powerpcle-{elf,linux} work equivalently
> well, and so do both BE and LE versions of ELFv2 (yes, BE of that exists
> just as well, and some distros even ship it!)

> powerpc64-linux and powerpc64le-linux use different ABIs though (BE
> ELFv1 and LE ELFv2, resp.)

But these are all toolchain considerations, which are fine.
I am trying to make sure that userprogs are actually *runnable* on the
kernel they are being built together with.


Thomas