linux-kernel - Re: [PATCH v7 7/7] rust: enable `clippy::ref_as

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: <D8REA6VW7QFS.Y5195VX38USO@proton.me>
Date: Thu, 27 Mar 2025 22:17:13 +0000
From: Benno Lossin <benno.lossin@...ton.me>
To: 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>, Alice Ryhl <aliceryhl@...gle.com>, 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>, Abdiel Janulgue <abdiel.janulgue@...il.com>, Daniel Almeida <daniel.almeida@...labora.com>, Robin Murphy <robin.murphy@....com>, Maarten Lankhorst
	<maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, FUJITA Tomonori <fujita.tomonori@...il.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, dri-devel@...ts.freedesktop.org, netdev@...r.kernel.org
Subject: Re: [PATCH v7 7/7] rust: enable `clippy::ref_as_ptr` lint

On Thu Mar 27, 2025 at 8:44 PM CET, Tamir Duberstein wrote:
> On Thu, Mar 27, 2025 at 10:15 AM Tamir Duberstein <tamird@...il.com> wrote:
>> On Wed, Mar 26, 2025 at 6:15 PM Benno Lossin <benno.lossin@...ton.me> wrote:
>> > On Wed Mar 26, 2025 at 11:09 PM CET, Tamir Duberstein wrote:
>> > > On Wed, Mar 26, 2025 at 5:09 PM Benno Lossin <benno.lossin@...ton.me> wrote:
>> > >> On Wed Mar 26, 2025 at 8:06 PM CET, Tamir Duberstein wrote:
>> > >> > On Wed, Mar 26, 2025 at 1:36 PM Benno Lossin <benno.lossin@...ton.me> wrote:
>> > >> >> On Wed Mar 26, 2025 at 5:57 PM CET, Tamir Duberstein wrote:
>> > >> >> >
>> > >> >> > Yeah, we should do this - but again: not relevant in this discussion.
>> > >> >>
>> > >> >> I think it's pretty relevant.
>> > >> >
>> > >> > It's not relevant because we're no longer talking about transmuting
>> > >> > pointer to pointer. The two options are:
>> > >> > 1. transmute reference to reference.
>> > >> > 2. coerce reference to pointer, `as` cast pointer to pointer (triggers
>> > >> > `ptr_as_ptr`), reborrow pointer to reference.
>> > >> >
>> > >> > If anyone can help me understand why (2) is better than (1), I'd
>> > >> > certainly appreciate it.
>> > >>
>> > >> I am very confident that (2) is correct. With (1) I'm not sure (see
>> > >> above), so that's why I mentioned it.
>> > >
>> > > Can you help me understand why you're confident about (2) but not (1)?
>> >
>> > My explanation from above explains why I'm not confident about (1):
>> >
>> >     For ptr-to-int transmutes, I know that they will probably remove
>> >     provenance, hence I am a bit cautious about using them for ptr-to-ptr or
>> >     ref-to-ref.
>> >
>> > The reason I'm confident about (2) is that that is the canonical way to
>> > cast the type of a reference pointing to an `!Sized` value.
>>
>> Do you have a citation, other than the transmute doc?

Not that I am aware of anything.

> Turns out this appeases clippy:
>
> diff --git a/rust/kernel/uaccess.rs b/rust/kernel/uaccess.rs
> index 80a9782b1c6e..7a6fc78fc314 100644
> --- a/rust/kernel/uaccess.rs
> +++ b/rust/kernel/uaccess.rs
> @@ -240,9 +240,10 @@ pub fn read_raw(&mut self, out: &mut
> [MaybeUninit<u8>]) -> Result {
>      /// Fails with [`EFAULT`] if the read happens on a bad address,
> or if the read goes out of
>      /// bounds of this [`UserSliceReader`]. This call may modify
> `out` even if it returns an error.
>      pub fn read_slice(&mut self, out: &mut [u8]) -> Result {
> +        let out: *mut [u8] = out;
>          // SAFETY: The types are compatible and `read_raw` doesn't
> write uninitialized bytes to
>          // `out`.
> -        let out = unsafe { &mut *(out as *mut [u8] as *mut
> [MaybeUninit<u8>]) };
> +        let out = unsafe { &mut *(out as *mut [MaybeUninit<u8>]) };
>          self.read_raw(out)
>      }

Seems like your email client auto-wrapped that :(

> Benno, would that work for you? Same in str.rs, of course.

For this specific case, I do have a `cast_slice_mut` function I
mentioned in the other thread, but that is still stuck in the untrusted
data series, I hope that it's ready tomorrow or maybe next week. I'd
prefer if we use that (since its implementation also doesn't use `as`
casts :). But if you can't wait, then the above is fine.

---
Cheers,
Benno