linux-kernel - Re: [PATCH] samples: rust: fix endianness issue in rust_driver

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: <DE7FHUVN5QE0.3ECM9JKXUNWFW@kernel.org>
Date: Thu, 13 Nov 2025 19:36:43 +1100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Miguel Ojeda" <miguel.ojeda.sandonis@...il.com>, "Marko Turk"
 <mt@...koturk.info>
Cc: "Dirk Behme" <dirk.behme@...bosch.com>, <bhelgaas@...gle.com>,
 <kwilczynski@...nel.org>, <linux-pci@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>, <rust-for-linux@...r.kernel.org>
Subject: Re: [PATCH] samples: rust: fix endianness issue in rust_driver_pci

On Thu Nov 13, 2025 at 7:22 PM AEDT, Danilo Krummrich wrote:
> On Wed Nov 12, 2025 at 8:56 PM AEDT, Miguel Ojeda wrote:
>> I guess we could potentially consider something like returning a
>> wrapper to force us to explicitly pick either LE or BE to prevent
>> things like this.
>
> In general, the I/O backend (e.g. MMIO, I2C, etc.) is supposed to take care
> of endianness.
>
> In the case of MMIO we (currently) always assume that the device is
> little-endian; this is also what the C functions used to implement the MMIO
> backend (e.g. readl()) assume, i.e. they always convert from little-endian to
> CPU endianness.

I.e. if we'd support a big-endian architecture in Rust

	u32::from_le(bar.read32())

would be a bug.

> I don't think we should do anything else; the cases where we need to deal with
> big-endian devices for MMIO should be extremely rare -- rare enough that there
> aren't even corresponding *_be() implementations for all architectures.
>
> Given that, I think the proper fix is to drop the existing u32::from_le() call
> (that ended up in the sample driver by accident) and properly document the
> little-endian assumption of the MMIO backend.
>
> (Currently, this simply is the Io structure, but there is a patch series [1]
> from Zhi splitting things up, so we can start supporting arbitrary I/O
> backends.)
>
> @Marko: Two separate patches for this would be very welcome. :)
>
> [1] https://lore.kernel.org/all/20251110204119.18351-1-zhiw@nvidia.com/