linux-kernel - Re: [PATCH v2 1/2] rust: Update PCI binding safety comments and add inline compiler hint

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: <DBILHBVA0NKJ.3R2QIVE9QIMM3@kernel.org>
Date: Tue, 22 Jul 2025 14:49:33 +0200
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Benno Lossin" <lossin@...nel.org>
Cc: "Alice Ryhl" <aliceryhl@...gle.com>, "Alistair Popple"
 <apopple@...dia.com>, <rust-for-linux@...r.kernel.org>, "Bjorn Helgaas"
 <bhelgaas@...gle.com>, Krzysztof Wilczyński
 <kwilczynski@...nel.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>, "Andreas Hindborg" <a.hindborg@...nel.org>,
 "Trevor Gross" <tmgross@...ch.edu>, "Greg Kroah-Hartman"
 <gregkh@...uxfoundation.org>, "Rafael J. Wysocki" <rafael@...nel.org>,
 "John Hubbard" <jhubbard@...dia.com>, "Alexandre Courbot"
 <acourbot@...dia.com>, <linux-pci@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] rust: Update PCI binding safety comments and add
 inline compiler hint

On Tue Jul 22, 2025 at 2:08 PM CEST, Benno Lossin wrote:
> On Tue Jul 22, 2025 at 1:35 PM CEST, Alice Ryhl wrote:
>> On Tue, Jul 22, 2025 at 12:57 PM Benno Lossin <lossin@...nel.org> wrote:
>>>
>>> On Tue Jul 22, 2025 at 11:51 AM CEST, Danilo Krummrich wrote:
>>> > I think they're good, but we're pretty late in the cycle now. That should be
>>> > fine though, we can probably take them through the nova tree, or in the worst
>>> > case share a tag, if needed.
>>> >
>>> > Given that, it would probably be good to add the Guarantee section on as_raw(),
>>> > as proposed by Benno, right away.
>>> >
>>> > @Benno: Any proposal on what this section should say?
>>>
>>> At a minimum I'd say "The returned pointer is valid.", but that doesn't
>>> really say for what it's valid... AFAIK you're mostly using this pointer
>>> to pass it to the C side, in that case, how about:
>>>
>>>     /// # Guarantees
>>>     ///
>>>     /// The returned pointer is valid for reads and writes from the C side for as long as `self` exists.
>>>
>>> Maybe we need to change it a bit more, but let's just start with this.
>>>
>>> (If you're also using the pointer from Rust, then we need to make
>>> changes)
>>
>> Honestly I think this is a bit over the top. I wouldn't bother adding
>> a section like that to every single as_raw() method out there.
>
> Hmm. And then just assume that these kinds of functions return valid
> pointers? I get that this is annoying to put on every function...
>
> Another option would be to have a `Ptr<'a, T>` type that is a valid
> pointer, but doesn't allow writing/reading safely (you need to justify
> why it's not a data race). And for FFI there could be an `as_ptr`
> function.

I don't understand where's the difference between the two. For FFI calls we'd
also have to justify it's not a data race, no?

The only guarantee we take as granted from as_raw() is that it returns a raw
pointer to the wrapped FFI type in Self, i.e. it points to valid memory. Any
additional guarantees may come from the context where the pointer is used and
which specific fields it is used to access.