linux-kernel - Re: [PATCH] mips: Use generic endianness macros instead of MIPS-specific ones

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: <alpine.DEB.2.21.2511100050330.25436@angie.orcam.me.uk>
Date: Mon, 10 Nov 2025 01:34:19 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Nathan Chancellor <nathan@...nel.org>
cc: Jens Reidel <adrian@...nlining.org>, 
    Thomas Bogendoerfer <tsbogend@...ha.franken.de>, 
    Nick Desaulniers <nick.desaulniers+lkml@...il.com>, 
    Bill Wendling <morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>, 
    linux-mips@...r.kernel.org, linux-kernel@...r.kernel.org, 
    bpf@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [PATCH] mips: Use generic endianness macros instead of MIPS-specific
 ones

On Sun, 9 Nov 2025, Nathan Chancellor wrote:

> > Compiling bpf_skel for mips currently fails because clang --target=bpf
> > is invoked and the source files include byteorder.h, which uses the
> > MIPS-specific macros to determine the endianness, rather than the generic
> > __LITTLE_ENDIAN__ / __BIG_ENDIAN__. Fix this by using the generic
> > macros, which are also defined when targeting bpf. This is already done
> > similarly for powerpc.
> > 
> > Signed-off-by: Jens Reidel <adrian@...nlining.org>
> 
> As far as I can tell, this should be fine since clang defines these
> macros in the generic case since [1] and I assume GCC does as well but
> if there is a risk of this being a problem for userspace, these could be
> added in addition to __MIPSEB__ / __MIPSEL__.

 How was the change verified?

 Certainly GCC defines neither __BIG_ENDIAN__ nor __LITTLE_ENDIAN__, not 
at least for the MIPS target.  Either the current macros need to stay as 
they are, or the generic __BYTE_ORDER__ macro can be used instead if so 
desired, which is target-agnostic and well-documented.  Preferably with 
the #else clause retained.

 Why is a MIPS header used with another target anyway?  It seems like a 
bug elsewhere.  If it's not a bug indeed, for whatever odd reason, then a 
proper rationale needs to be given in the change description.

 Also please don't review changes based on assumptions, "I assume GCC 
does[...]" means that you just don't know (and it's trivial to check).

 NB the __BYTE_ORDER__ macro has only been there as from GCC 4.6 back in 
2010, while this header dates back to 1995 when it was necessary to use 
target macros.  Since our current GCC requirement is 5.1 it will be fine 
to use this macro instead.  But as I say a proper rationale is required.

  Maciej