linux-kernel - Re: [PATCH v6 RESEND 4/7] rust: io: factor common I/O helpers into Io trait

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: <DEC4TSQBTESW.28F17X9GHCIU7@kernel.org>
Date: Wed, 19 Nov 2025 10:18:27 +1300
From: "Danilo Krummrich" <dakr@...nel.org>
To: "John Hubbard" <jhubbard@...dia.com>
Cc: "Alice Ryhl" <aliceryhl@...gle.com>, "Zhi Wang" <zhiw@...dia.com>,
 <rust-for-linux@...r.kernel.org>, <linux-pci@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>, <bhelgaas@...gle.com>,
 <kwilczynski@...nel.org>, <ojeda@...nel.org>, <alex.gaynor@...il.com>,
 <boqun.feng@...il.com>, <gary@...yguo.net>, <bjorn3_gh@...tonmail.com>,
 <lossin@...nel.org>, <a.hindborg@...nel.org>, <tmgross@...ch.edu>,
 <markus.probst@...teo.de>, <helgaas@...nel.org>, <cjia@...dia.com>,
 <smitra@...dia.com>, <ankita@...dia.com>, <aniketa@...dia.com>,
 <kwankhede@...dia.com>, <targupta@...dia.com>, <acourbot@...dia.com>,
 <joelagnelf@...dia.com>, <zhiwang@...nel.org>
Subject: Re: [PATCH v6 RESEND 4/7] rust: io: factor common I/O helpers into
 Io trait

On Tue Nov 18, 2025 at 11:44 AM NZDT, John Hubbard wrote:
> IO is generally something that can fail, so this whole idea of infallible
> IO is making me uneasy.
>
> I understand that we're trying to wrap it up into a bound device, but
> bound devices are all about whether or not the driver lifetime is OK,
> not so much about IO.

That is correct, device context states are about driver lifetime. However, it is
at least related, see below.

> For PCIe, it is still possible for the device to fall off of the bus, and 
> in that case you'll usually see 0xFFFF_FFFF returned from PCIe reads. The
> Open RM driver has sprinkled around checks for this value (not fun, I
> know), and Danilo hinted elsewhere that bound-ness requires not getting
> these, so maybe that suffices. But it means that Rust will be "interesting"
> here, because falling off the bus means that there will be a time window in
> which the IO is, in fact, fallible.

The PCI configuration space accessors indeed check a flag that is set when the
device falls off the bus. However, it is not sufficient, since you still have a
period of time when the device fell off the bus where the flag isn't set yet and
the I/O accessor may still be used concurrently.

(If you look at C drivers you will note that almost none of the drivers actually
check the return value of the configuration space accessors; needless to say
MMIO ones don't even have the flag.)

Because of that, there is not a point in making all the I/O accessors fallible,
because you'd have to deal with false negatives anyways, i.e. check the read
value for plausibility, because the device could already be gone, while the flag
is not set yet.

Additionally, when the device fell off the bus the driver core will unbind the
driver, so the period where fallability would serve at least some purpose would
be very short anyways.

Instead, drivers have to be designed to be robust enough to deal with broken
data read from the bus.

> Other IO subsystems can also get IO errors, too.
>
> I wonder if we should just provide IoFallible? (It could check for the
> 0xFFFF_FFFF case, for example, which is helpful to simplify the caller.)

For some registers this could be an expected value, plus a device can fall off
the bus during a read was well, leaving you with broken data.

I don't think trying to make all I/O operations fallible is the way to go, it's
just unreliable to detect in the generic layer. Instead, drivers should perform
a plausibility check on the read values (which they have to do anyways).