[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANiq72njeRLijF8Vt+Kgv_gCD6O4E67rH87bGOG6mZCs7wS+=g@mail.gmail.com>
Date: Tue, 15 Jul 2025 01:31:38 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Miguel Ojeda <ojeda@...nel.org>, Alexander Viro <viro@...iv.linux.org.uk>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Arnd Bergmann <arnd@...db.de>,
Andrew Morton <akpm@...ux-foundation.org>, Boqun Feng <boqun.feng@...il.com>,
Gary Guo <gary@...yguo.net>, Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>,
Trevor Gross <tmgross@...ch.edu>, Danilo Krummrich <dakr@...nel.org>, rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org, Christian Schrefl <chrisi.schrefl@...il.com>
Subject: Re: [PATCH v3] uaccess: rust: use newtype for user pointers
On Mon, Jun 16, 2025 at 3:46 PM Alice Ryhl <aliceryhl@...gle.com> wrote:
>
> Currently, Rust code uses a typedef for unsigned long to represent
> userspace addresses. This is unfortunate because it means that userspace
> addresses could accidentally be mixed up with other integers. To
> alleviate that, we introduce a new UserPtr struct that wraps a raw
> pointer to represent a userspace address. By using a struct, type
> checking enforces that userspace addresses cannot be mixed up with
> anything else.
>
> This is similar to the __user annotation in C that detects cases where
> user pointers are mixed with non-user pointers.
>
> Note that unlike __user pointers in C, this type is just a pointer
> without a target type. This means that it can't detect cases such as
> mixing up which struct this user pointer references. However, that is
> okay due to the way this is intended to be used - generally, you create
> a UserPtr in your ioctl callback from the provided usize *before*
> dispatching on which ioctl is in use, and then after dispatching on the
> ioctl you pass the UserPtr into a UserSliceReader or UserSliceWriter;
> selecting the target type does not happen until you have obtained the
> UserSliceReader/Writer.
>
> The UserPtr type is not marked with #[derive(Debug)], which means that
> it's not possible to print values of this type. This avoids ASLR
> leakage.
>
> The type is added to the prelude as it is a fairly fundamental type
> similar to c_int. The wrapping_add() method is renamed to
> wrapping_byte_add() for consistency with the method name found on raw
> pointers.
>
> Reviewed-by: Benno Lossin <lossin@...nel.org>
> Reviewed-by: Danilo Krummrich <dakr@...nel.org>
> Reviewed-by: Christian Schrefl <chrisi.schrefl@...il.com>
> Reviewed-by: Boqun Feng <boqun.feng@...il.com>
> Reviewed-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> Signed-off-by: Alice Ryhl <aliceryhl@...gle.com>
Applied to `rust-next` -- thanks everyone!
[ Reworded title. - Miguel ]
Cheers,
Miguel
Powered by blists - more mailing lists