linux-kernel - Re: [PATCH v2 1/4] rust: io: Add big-endian read and write functions

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: <DG7DUN9M4YIU.KNRN6FM1K687@garyguo.net>
Date: Thu, 05 Feb 2026 22:31:20 +0000
From: "Gary Guo" <gary@...yguo.net>
To: "Danilo Krummrich" <dakr@...nel.org>, "Daniel Almeida"
 <daniel.almeida@...labora.com>
Cc: "Gary Guo" <gary@...yguo.net>, "Link Mauve" <linkmauve@...kmauve.fr>,
 <rust-for-linux@...r.kernel.org>, "Madhavan Srinivasan"
 <maddy@...ux.ibm.com>, "Michael Ellerman" <mpe@...erman.id.au>, "Nicholas
 Piggin" <npiggin@...il.com>, "Christophe Leroy (CS GROUP)"
 <chleroy@...nel.org>, "Srinivas Kandagatla" <srini@...nel.org>, "Miguel
 Ojeda" <ojeda@...nel.org>, "Boqun Feng" <boqun@...nel.org>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>, "Benno Lossin"
 <lossin@...nel.org>, "Andreas Hindborg" <a.hindborg@...nel.org>, "Alice
 Ryhl" <aliceryhl@...gle.com>, "Trevor Gross" <tmgross@...ch.edu>, "Ard
 Biesheuvel" <ardb@...nel.org>, "Martin K. Petersen"
 <martin.petersen@...cle.com>, "Eric Biggers" <ebiggers@...gle.com>, "Greg
 Kroah-Hartman" <gregkh@...uxfoundation.org>, "Lyude Paul"
 <lyude@...hat.com>, "Asahi Lina" <lina+kernel@...hilina.net>, "Viresh
 Kumar" <viresh.kumar@...aro.org>, "Lorenzo Stoakes"
 <lorenzo.stoakes@...cle.com>, "Tamir Duberstein" <tamird@...nel.org>,
 "FUJITA Tomonori" <fujita.tomonori@...il.com>,
 <linuxppc-dev@...ts.ozlabs.org>, <linux-kernel@...r.kernel.org>,
 <officialTechflashYT@...il.com>, "Ash Logan" <ash@...quark.com>, "Roberto
 Van Eeden" <rw-r-r-0644@...tonmail.com>,
 Jonathan Neuschäfer <j.neuschaefer@....net>
Subject: Re: [PATCH v2 1/4] rust: io: Add big-endian read and write
 functions

On Thu Feb 5, 2026 at 7:05 PM GMT, Danilo Krummrich wrote:
> On Thu Feb 5, 2026 at 6:28 PM CET, Daniel Almeida wrote:
>>> On 5 Feb 2026, at 12:16, Gary Guo <gary@...yguo.net> wrote:
>>> I think we should have everything default to little endian, and have wrapper
>>> types that do big endian which require expicit construction, similar to
>>> RelaxedMmio in Alex's series.
>>
>> Ah yes, the RelaxedMmio pattern is definitely a good one. I agree that we
>> should head in this direction.
>
> I strongly disagree.
>
> This is a great pattern for relaxed ordering because:
>
>   (1) We need both strict and relaxed ordering.
>
>   (2) Relaxed ordering is rare, hence it doesn't hurt to write e.g.
>
> 	io.relaxed().write()
>
>   (3) If you by accident just write
>
> 	io.write()
>
>       i.e. forget to call relaxed() it s not a bug, nothing bad happens.
>
> Whereas for endianness it is a bad pattern because:
>
>   (1) Devices are either little-endian or big-endian. Hence, having to write
>
> 	io.big_endian().write()
>
>       is excessive, we always want big-endian for a big-endian device.

You don't need to always write this. You just need to do `big_endian()` once
when you obtain the io, and then keep using `BigEndian<Mmio>` instead of just
`Mmio`, and the rest of code is still `.write()`.

I proposed the wrapper type because majority of devices won't need BE support,
so adding complexity to Mmio itself is not ideal. It is also generic, so it can
work with any IO backends, so for example, you can have `BigEndian<Pio>` and
`BigEndian<Mmio>` and you don't need to duplicate your endianness support for
both backends.

>
>   (2) It is error prone, if you forget to call big_endian() first, it is a bug.

Moot point when `big_endian()` is only done once.

>
>   (3) It is unergonomic in combination with relaxed ordering.
>
> 	io.big_endian().relaxed().write()

This might be an issue, as `RelaxedMmio`, unless `BigEndian`, cannot be
implemented as wrapper that just reverse byteorder. Although I am not sure that
we even need that support, given that there's no be_relaxed functions on C side
anyway.

Best,
Gary

>
>       (Does the other way around work as well? :)
>
> It makes much more sense to define once when we request the I/O memory whether
> the device is litte-endian or big-endian.
>
> This could be done with different request functions, a const generic or a
> function argument, but it should be done at request time.