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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJ-ks9kD++_T_3my1Etam9PRJHHZvdM=zbkWgbxW3oybwMTw9w@mail.gmail.com>
Date: Wed, 19 Mar 2025 14:23:07 -0400
From: Tamir Duberstein <tamird@...il.com>
To: Benno Lossin <benno.lossin@...ton.me>
Cc: Alice Ryhl <aliceryhl@...gle.com>, 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 Wed, Mar 19, 2025 at 10:42 AM Benno Lossin <benno.lossin@...ton.me> wrote:
>
> On Wed Mar 19, 2025 at 3:14 PM CET, Tamir Duberstein wrote:
> > On Wed, Mar 19, 2025 at 8:21 AM Alice Ryhl <aliceryhl@...gle.com> wrote:
> >> On Wed, Mar 19, 2025 at 12:23:44AM +0000, Benno Lossin wrote:
> >> > 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:
> >> > >> @@ -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 :)
> >>
> >> We're doing that to the fullest extent possible already. We only convert
> >> them to pointers when calling C FFI functions that take user pointers as
> >> a raw pointer.
> >>
> >> Alice
> >
> > Personally, I agree with Benno that `as` conversions are a misfeature
> > in the language.
> >
> > I think this patch and the ensuing discussion is making perfect the
> > enemy of good, so I'd prefer to drop it and revisit when the
> > ergonomics have improved.
>
> I don't think that we need to rush on the rest of the patch series.
> Boqun's suggestion is very good and I'm not sure which ergonomics need
> to be improved here.

The improved ergonomics arrive in Rust 1.79. See Boqun's reply that
explains we need to keep all the stubs until then.

Regarding landing the rest of the series - you said it yourself: "it's
only going to get more painful in the long run to change this". The
nature of lints is that the longer you don't enable them, the likelier
you are to have a higher hill to climb later.