linux-kernel - Re: [PATCH v5 6/6] rust: use strict provenance APIs

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: <D8JTC30W0NF6.17SR73Y9I99ZT@proton.me>
Date: Wed, 19 Mar 2025 00:23:44 +0000
From: Benno Lossin <benno.lossin@...ton.me>
To: Alice Ryhl <aliceryhl@...gle.com>, Tamir Duberstein <tamird@...il.com>
Cc: Masahiro Yamada <masahiroy@...nel.org>, Nathan Chancellor <nathan@...nel.org>, Nicolas Schier <nicolas@...sle.eu>, 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>, Danilo Krummrich <dakr@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "Rafael J. Wysocki" <rafael@...nel.org>, Brendan Higgins <brendan.higgins@...ux.dev>, David Gow <davidgow@...gle.com>, Rae Moar <rmoar@...gle.com>, Bjorn Helgaas <bhelgaas@...gle.com>, Luis Chamberlain <mcgrof@...nel.org>, Russ Weight <russ.weight@...ux.dev>, Rob Herring <robh@...nel.org>, Saravana Kannan <saravanak@...gle.com>, linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org, linux-kselftest@...r.kernel.org, kunit-dev@...glegroups.com, linux-pci@...r.kernel.org,
	linux-block@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v5 6/6] rust: use strict provenance APIs

On Tue Mar 18, 2025 at 1:29 PM CET, Alice Ryhl wrote:
> On Mon, Mar 17, 2025 at 10:23:56AM -0400, Tamir Duberstein wrote:
>> Throughout the tree, use the strict provenance APIs stabilized in Rust
>> 1.84.0[1]. Retain backwards-compatibility by introducing forwarding
>> functions at the `kernel` crate root along with polyfills for rustc <
>> 1.84.0.
>> 
>> Use `#[allow(clippy::incompatible_msrv)]` to avoid warnings on rustc <
>> 1.84.0 as our MSRV is 1.78.0.
>> 
>> In the `kernel` crate, enable the strict provenance lints on rustc >=
>> 1.84.0; do this in `lib.rs` rather than `Makefile` to avoid introducing
>> compiler flags that are dependent on the rustc version in use.
>> 
>> Link: https://blog.rust-lang.org/2025/01/09/Rust-1.84.0.html#strict-provenance-apis [1]
>> Suggested-by: Benno Lossin <benno.lossin@...ton.me>
>> Link: https://lore.kernel.org/all/D8EIXDMRXMJP.36TFCGWZBRS3Y@proton.me/
>> Signed-off-by: Tamir Duberstein <tamird@...il.com>
>
> I'm not convinced that the pros of this change outweigh the cons. I
> think this is going to be too confusing for the C developers who look at
> this code.

1) I think we should eliminate all possible `as` conversions. They are
   non-descriptive (since they can do may *very* different things) and
   ptr2int conversions are part of that.
2) At some point we will have to move to the provenance API, since
   that's what Rust chose to do. I don't think that doing it at a later
   point is doing anyone a favor.
3) I don't understand the argument that this is confusing to C devs.
   They are just normal functions that are well-documented (and if
   that's not the case, we can just improve them upstream). And
   functions are much easier to learn about than `as` casts (those are
   IMO much more difficult to figure out than then strict provenance
   functions).

Thus I think we should keep this patch (with Boqun's improvement).

>> diff --git a/rust/kernel/uaccess.rs b/rust/kernel/uaccess.rs
>> index 719b0a48ff55..96393bcf6bd7 100644
>> --- a/rust/kernel/uaccess.rs
>> +++ b/rust/kernel/uaccess.rs
>> @@ -226,7 +226,9 @@ pub fn read_raw(&mut self, out: &mut [MaybeUninit<u8>]) -> Result {
>>          }
>>          // SAFETY: `out_ptr` points into a mutable slice of length `len`, so we may write
>>          // that many bytes to it.
>> -        let res = unsafe { bindings::copy_from_user(out_ptr, self.ptr as *const c_void, len) };
>> +        let res = unsafe {
>> +            bindings::copy_from_user(out_ptr, crate::with_exposed_provenance(self.ptr), len)
>> +        };
>>          if res != 0 {
>>              return Err(EFAULT);
>>          }
>> @@ -264,7 +266,7 @@ pub fn read<T: FromBytes>(&mut self) -> Result<T> {
>>          let res = unsafe {
>>              bindings::_copy_from_user(
>>                  out.as_mut_ptr().cast::<c_void>(),
>> -                self.ptr as *const c_void,
>> +                crate::with_exposed_provenance(self.ptr),
>>                  len,
>>              )
>>          };
>
> That's especially true for cases like this. These are userspace pointers
> that are never dereferenced. It's not useful to care about provenance
> here.

I agree for this case, but I think we shouldn't be using raw pointers
for this to begin with. I'd think that a newtype wrapping `usize` is a
much better fit. It can then also back the `IoRaw` type. AFAIU user
space pointers don't have provenance, right? (if they do, then we should
use this API :)

---
Cheers,
Benno