linux-kernel - Re: [PATCH v12 2/3] rust: add dma coherent allocator abstraction.

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: <Z8stJXrDtA5tZB40@cassiopeiae>
Date: Fri, 7 Mar 2025 18:30:13 +0100
From: Danilo Krummrich <dakr@...nel.org>
To: Jason Gunthorpe <jgg@...dia.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Abdiel Janulgue <abdiel.janulgue@...il.com>, aliceryhl@...gle.com,
	robin.murphy@....com, daniel.almeida@...labora.com,
	rust-for-linux@...r.kernel.org, Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <benno.lossin@...ton.me>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Trevor Gross <tmgross@...ch.edu>,
	Valentin Obst <kernel@...entinobst.de>,
	open list <linux-kernel@...r.kernel.org>,
	Christoph Hellwig <hch@....de>,
	Marek Szyprowski <m.szyprowski@...sung.com>, airlied@...hat.com,
	"open list:DMA MAPPING HELPERS" <iommu@...ts.linux.dev>
Subject: Re: [PATCH v12 2/3] rust: add dma coherent allocator abstraction.

On Fri, Mar 07, 2025 at 10:38:21AM -0400, Jason Gunthorpe wrote:
> 
> This Rust direction is radically transforming how the driver lifecycle model
> of the kernel works

I already explained in other threads that the Rust abstractions follow the device
/ driver model. There is no "radical change" to it. Since I assume you still
refer to the Devres aspect of it, please find another explanation in [1].

But please also show in detail where you see the "radical change" of the driver
model, maybe there's some misunderstanding?

> with almost no review from any kernel experts.

Do you question Greg being an expert on the driver model? Who do you think
applied the patches after month of discussions on the mailing list and at
conferences?

> Certainly I object to it. I think others will too if they understood
> what was going on here.

Again, this stuff was on the corresponding mailing lists for month; I haven't
seen such objections.

I'm absolutely willing to address yours though. And I'm happy to be questioned
on this stuff by you and in general.

But please start doing so in a constructive way, i.e. if you find issues help
solving them instead of just trying to blame people. If you think there is no
issue, but still think another approach would be better, please send patches.

> Write a position paper in Documentation/ on how you imagine lifecycle
> will work with Rust driver bindings

Rust abstractions follow the driver model, just like the C code does.

What - and please provide details - should this position paper describe?
The driver model itself, implementation details of the Rust abstractions or
something else?

> and get some acks from experienced people??

Again, this stuff was on the list for month, I can't force people to review it.

Do you have a list of those experienced people? Maybe you can get them to
revisit things and contribute improvements?

However, let me also say that experienced people *did* review it and work on it.

---

[1] Devres - C vs. Rust
-----------------------

Starting with C, let's pick the following two functions.

	pcim_iomap()
	pcim_request_region()

Those two are called from probe() and the pointer returned from pcim_iomap() is
stored in some driver specific structure, which, depending on the subsystem and
driver, may out-live driver unbind.

If the driver is unbound the following functions are called automatically after
remove() from the corresponding devres callbacks.

	pci_iounmap()
	pci_release_region()

The pointer in the driver specific structure (if still existent) becomes
invalid.

In Rust the lifecycle of the I/O memory mapping and the resource region are
bound to a structure called pci::Bar.

Creating a new pci::Bar calls pci_iomap() and pci_request_region(). Dropping the
object calls pci_iounmap() and pci_release_region(). The pointer to the memory
mapping is embedded in the pci::Bar object.

The driver model prescribes that device resources must be released when the
driver is unbound. Hence, we can't hand out a raw pci::Bar object to driver,
because the object lifetime could be extended across the "driver is unbound"
boundary.

This is why we only ever give out the pci::Bar object in a Devres container,
i.e. Devres<pci::Bar>.

Devres puts the pci::Bar in a Revocable and sets up the devres callback. Once
the devres callback is called the embedded pci::Bar is dropped, which calls
pci_iounmap() and pci_release_region().

Subsequently, the access to the pci::Bar for the owner of the Devres<pci::Bar>
object is revoked, since the pointer to the memory mapping within the pci::Bar
just became invalid.

The latter is the only additional step the Rust abstraction does, in order to
not leave drivers with an invalid pointer. However, this additional safety
aspect is *not* a change of the driver model itself.