linux-kernel - Re: [GIT PULL] RISC-V updates for v6.18-rc1

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: <CAHk-=wgYcOiFvsJzFb+HfB4n6Wj6zM5H5EghUMfpXSCzyQVSfA@mail.gmail.com>
Date: Tue, 30 Sep 2025 16:53:24 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Ben Dooks <ben.dooks@...ethink.co.uk>
Cc: Paul Walmsley <pjw@...nel.org>, linux-riscv@...ts.infradead.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] RISC-V updates for v6.18-rc1

On Tue, 30 Sept 2025 at 09:04, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Oh Christ. Is somebody seriously working on BE support in 2025?

Ok, I just googled this, and I am putting my foot down:

 WE ARE NOT PREEMPTIVELY SUPPORTING BIG-ENDIAN ON RISC-V

The documented "reasoning" for that craziness is too stupid for words,
but since riscv.org did put it in words, I'll just quote those words
here:

 "There are still applications where the way data is stored matters,
such as the protocols that move data across the Internet, which are
defined as big-endian. So when a little-endian system needs to inspect
or modify a network packet, it has to swap the big-endian values to
little-endian and back, a process that can take as many as 10-20
instructions on a RISC-V target which doesn’t implement the Zbb
extension"

In other words, it is suggesting that RISC-V add a big-endian mode due to

 (a) internet protocols - where byte swapping is not an issue

 (b) using "some RISC-V implementations don't do the existing Zbb
extension" as an excuse

This is plain insanity. First off, even if byte swapping was a real
cost for networking - it's not, the real costs tend to be all in
memory subsystems - just implement the damn Zbb extension.

Don't go "we're too incompetent to implement Zbb, so we're now asking
that EVERYBODY ELSE feel the pain of a much *worse* extension and
fragmenting RISC-V further".

I'm hoping this is some April fools joke, but that page is dated
"March 10, 2025". Close, but not close enough.

This is the kind of silly stuff that just makes RISC-V look bad.

Ben - I'm afraid that that page has "further reading" pointing to codethink.

I see some CONFIG_CPU_BIG_ENDIAN has already made it in, but this
needs to stop.

The mainline kernel is for mainline development. Not for random
experiments that make the world a worse place.

And yes, we're open source, and that very much means that anybody is
more than welcome to try to prove me wrong.

If it turns out that BE RISC-V becomes a real thing that is relevant
and actually finds a place in the RISC-V ecosystem, then _of_course_
we should support it at that point in the mainline kernel.

But I really do think that it actually makes RISC-V only worse, and
that we should *not* actively help the fragmentation.

             Linus