linux-kernel - Re: [PATCH v11 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: <7E4F0584-7C60-494A-9CE6-57840F3B7976@collabora.com>
Date: Mon, 27 Jan 2025 07:52:42 -0300
From: Daniel Almeida <daniel.almeida@...labora.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: Alice Ryhl <aliceryhl@...gle.com>,
 Abdiel Janulgue <abdiel.janulgue@...il.com>,
 rust-for-linux@...r.kernel.org,
 robin.murphy@....com,
 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 v11 2/3] rust: add dma coherent allocator abstraction.

> 
> Why do we consider the existing one unsafe?
> 
> Surely, it's not desirable that the contents of the buffer are modified by the
> HW unexpectedly, but is this a concern in terms of Rust safety requirements?
> 
> And if so, how does this go away with the proposed approach?
> 

Alice pointed out that if you hand out a &mut T, you must ensure exclusive access
to that memory location. So if you pass that address to some piece of hardware and
it writes it, that violates that expectation.

The solution was to simply not do that when the &mut T was alive, i.e. to ensure that
no hardware operation involving that memory was taking place while the slice was still
in use.

Some people then commented that they would use the abstraction for ring buffers, which 
would violate this assumption in perpetuity, as both producer and consumer would have
the range mapped at the same time. 

The solution was to revert back to pointers.

I think Boqun asked for the unsafe as_slice() function as a way to impose the safety check
on users, for the cases where it could be proved through other means that the reference
rules were upheld.