From: Boqun Feng <boqun.feng@gmail.com>
To: Alice Ryhl <aliceryhl@google.com>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Arnd Bergmann" <arnd@arndb.de>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] uaccess: rust: use newtype for user pointers
Date: Tue, 27 May 2025 08:20:00 -0700 [thread overview]
Message-ID: <6835d823.050a0220.93bd2.dbfe@mx.google.com> (raw)
In-Reply-To: <20250527-userptr-newtype-v2-1-a789d266f6b0@google.com>
On Tue, May 27, 2025 at 01:53:12PM +0000, Alice Ryhl wrote:
> In C code we use sparse with the __user annotation to detect cases where
> a user pointer is mixed up with other things. To replicate that, we
> introduce a new struct UserPtr that serves the same purpose using the
> newtype pattern.
>
> 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.
>
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
A question below:
> ---
> This is based on top of the strncpy_from_user for Rust patch.
> ---
> Changes in v2:
> - Change usize to raw pointer.
> - Make field private.
> - Rename wrapping_add to wrapping_byte_add.
> - Add to prelude.
> - Rebase on v4 of strncpy_from_user
> - Link to v1: https://lore.kernel.org/r/20250506-userptr-newtype-v1-1-a0f6f8ce9fc5@google.com
> ---
> rust/kernel/prelude.rs | 2 ++
> rust/kernel/uaccess.rs | 68 +++++++++++++++++++++++++++++++++-------
> samples/rust/rust_misc_device.rs | 2 ++
> 3 files changed, 60 insertions(+), 12 deletions(-)
>
> diff --git a/rust/kernel/prelude.rs b/rust/kernel/prelude.rs
> index baa774a351ceeb995a2a647f78a27b408d9f3834..081af5bc07b0bcefb1da16e5a81fc611b3178aea 100644
> --- a/rust/kernel/prelude.rs
> +++ b/rust/kernel/prelude.rs
> @@ -41,3 +41,5 @@
> pub use super::init::InPlaceInit;
>
> pub use super::current;
> +
> +pub use super::uaccess::UserPtr;
> diff --git a/rust/kernel/uaccess.rs b/rust/kernel/uaccess.rs
> index e6534b52a1920254d61f8349426d4cdb38286089..02e0561eb1c6f4d813a4ab13a124bfac2d2a5c75 100644
> --- a/rust/kernel/uaccess.rs
> +++ b/rust/kernel/uaccess.rs
> @@ -14,8 +14,48 @@
> };
> use core::mem::{size_of, MaybeUninit};
>
> -/// The type used for userspace addresses.
> -pub type UserPtr = usize;
> +/// A pointer into userspace.
> +///
> +/// This is the Rust equivalent to C pointers tagged with `__user`.
> +#[repr(transparent)]
> +#[derive(Copy, Clone)]
> +pub struct UserPtr(*mut c_void);
> +
> +impl UserPtr {
> + /// Create a `UserPtr` from an integer representing the userspace address.
> + pub fn from_addr(addr: usize) -> Self {
> + Self(addr as *mut c_void)
> + }
> +
> + /// Create a `UserPtr` from a pointer representing the userspace address.
> + pub fn from_ptr(addr: *mut c_void) -> Self {
> + Self(addr)
> + }
> +
> + /// Cast this userspace pointer to a raw const void pointer.
> + ///
> + /// It is up to the caller to use the returned pointer correctly.
> + #[inline]
> + pub fn as_const_ptr(self) -> *const c_void {
> + self.0
> + }
> +
> + /// Cast this userspace pointer to a raw mutable void pointer.
> + ///
> + /// It is up to the caller to use the returned pointer correctly.
> + #[inline]
> + pub fn as_mut_ptr(self) -> *mut c_void {
> + self.0
> + }
> +
why are these two inline but the rest not?
Regards,
Boqun
> + /// Increment this user pointer by `add` bytes.
> + ///
> + /// This addition is wrapping, so wrapping around the address space does not result in a panic
> + /// even if `CONFIG_RUST_OVERFLOW_CHECKS` is enabled.
> + pub fn wrapping_byte_add(self, add: usize) -> UserPtr {
> + UserPtr(self.0.wrapping_add(add))
> + }
> +}
>
[...]
next prev parent reply other threads:[~2025-05-27 15:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-27 13:53 [PATCH v2] uaccess: rust: use newtype for user pointers Alice Ryhl
2025-05-27 14:42 ` Greg Kroah-Hartman
2025-05-27 15:20 ` Boqun Feng [this message]
2025-05-27 15:22 ` Alice Ryhl
2025-05-27 19:03 ` Christian Schrefl
2025-05-27 19:09 ` Alice Ryhl
2025-05-27 22:12 ` Al Viro
2025-05-27 23:13 ` Boqun Feng
2025-05-28 10:48 ` Alice Ryhl
2025-05-28 15:38 ` Benno Lossin
2025-05-28 16:02 ` Boqun Feng
2025-05-28 10:47 ` Alice Ryhl
2025-05-28 17:45 ` Al Viro
2025-05-28 20:01 ` Al Viro
2025-05-28 20:35 ` Benno Lossin
2025-05-28 10:52 ` Danilo Krummrich
2025-05-28 16:55 ` Benno Lossin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6835d823.050a0220.93bd2.dbfe@mx.google.com \
--to=boqun.feng@gmail.com \
--cc=a.hindborg@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=aliceryhl@google.com \
--cc=arnd@arndb.de \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.