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] [thread-next>] [day] [month] [year] [list]

Message-Id: <DE7F6RR1NAKW.3DJYO44O73941@kernel.org>
Date: Thu, 13 Nov 2025 19:22:15 +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 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 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/