Received-SPF: pass (google.com: domain of linux-kernel+bounces-148675-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Wed, 17 Apr 2024 15:28:02 +0100
From: Gary Guo <gary@garyguo.net>
To: Alice Ryhl <aliceryhl@google.com>
Cc: Miguel Ojeda <ojeda@kernel.org>, Matthew Wilcox <willy@infradead.org>,
 Al Viro <viro@zeniv.linux.org.uk>, Andrew Morton
 <akpm@linux-foundation.org>, Kees Cook <keescook@chromium.org>, Alex Gaynor
 <alex.gaynor@gmail.com>, Wedson Almeida Filho <wedsonaf@gmail.com>, Boqun
 Feng <boqun.feng@gmail.com>, "=?UTF-8?B?QmrDtnJu?= Roy Baron"
 <bjorn3_gh@protonmail.com>, Benno Lossin <benno.lossin@proton.me>, Andreas
 Hindborg <a.hindborg@samsung.com>, Greg Kroah-Hartman
 <gregkh@linuxfoundation.org>, "Arve =?UTF-8?B?SGrDuG5uZXbDpWc=?="
 <arve@android.com>, Todd Kjos <tkjos@android.com>, Martijn Coenen
 <maco@android.com>, Joel Fernandes <joel@joelfernandes.org>, Carlos Llamas
 <cmllamas@google.com>, Suren Baghdasaryan <surenb@google.com>, Arnd
 Bergmann <arnd@arndb.de>, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
 rust-for-linux@vger.kernel.org, Christian Brauner <brauner@kernel.org>
Subject: Re: [PATCH v5 1/4] rust: uaccess: add userspace pointers
Message-ID: <20240417152802.6b7a7384@eugeo>
In-Reply-To: <20240415-alice-mm-v5-1-6f55e4d8ef51@google.com>
References: <20240415-alice-mm-v5-0-6f55e4d8ef51@google.com>
	<20240415-alice-mm-v5-1-6f55e4d8ef51@google.com>
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?2cpmFHx78YYL78BKC7gf3KbBoEF895mCXVOt30eG7j8zvxgIAY8kZzp/CfVP?=
 =?us-ascii?Q?eE/v/38PQoAS1MBydVhZ7B551QtpLnTteYqQ8bIUJ39ebj5rR338fgGFiKu2?=
 =?us-ascii?Q?h689MVWolWyEiaptnJz+5czdEfooaCL175DJ5QLrtqtKCyXLzLBqpaF2Y/AB?=
 =?us-ascii?Q?1iVipjmwzwFAgtYxg0N5vN8Xw1OHdo7rV5wdU+VqrXJwxIj/TcgGL7jytZf3?=
 =?us-ascii?Q?VAKUGeBHt1wI7BkpAEdXKEBT3ACRru9B3x4xxDIaDSAmUWTO+GCSC9TOKIAv?=
 =?us-ascii?Q?Ai7fYy3w+QUDbIBZXlEnQpAO4chgeZ33WLbi4aPkiz0Ra4Za0iOhnO9yBifh?=
 =?us-ascii?Q?+tzzBKOn84wWa799Ium7XT6by7K1YMd+VmoSL/ZxjJGTttNrGCnJiLQaMsJL?=
 =?us-ascii?Q?/IaSoLlWM4pd4FsQPSGsyQ8hkIPnvQuvdLdFUS3m/OJ6czX/D9faJZLrKcKT?=
 =?us-ascii?Q?o+QBLaToHfFaDcXbbXGGVFwm/ZJj78VDjDsNYU26Kb/g7j13Pka3843uUjr1?=
 =?us-ascii?Q?pdHAccxqf26GL3Gjye9L30HAqDHM5OnkWaV59AXY5lANys6b8iC8BV7k2yZo?=
 =?us-ascii?Q?VPh68wBx3l261JVLTgmOx00qQI0Z1ODBaLFL5aGiihT+3xvBNdaos/jkufOJ?=
 =?us-ascii?Q?FAKk6E9k8uukZyS1sE9EzFtpJupmZSIhH5K2lxKNqvhCWm81LynCB8GIJhC7?=
 =?us-ascii?Q?OZvXd/pnU9PtVWP6JMaeGNuNweAbXdkyAtsvsrNj06vorGoXSJ9jIYwxR9Fv?=
 =?us-ascii?Q?vgO/X5ZsXjl0fYcdoH+sS99K7Xmo1hh7Ap6XFMbD6cCeyrMfXuLor2IJVnal?=
 =?us-ascii?Q?F6Wr1JUWvq1nDEXj3XuLzwiEmnfATXw2QEeztliw7HwNjXQ6uTIbjWiXas/k?=
 =?us-ascii?Q?jczYv/6JKt4dxxa9Szz2eGXvxtK5iqyvE/mvRaL3bookh6VixIvVIwd2npyH?=
 =?us-ascii?Q?2+gcdvQrbXIcSU0dlR//J2q7qodEIjJb8XH/fthjP5+m9x7vLSFI6Pez9QnZ?=
 =?us-ascii?Q?KOQpkf6g1x8czs0Kqfo78A+23mOUo+4JQmyR/CwZ3YpMEYLpwc4hD9ruuYFZ?=
 =?us-ascii?Q?FfXf2ycAUK7W6hlXDnFPc0AMa15WaBBl7DVam1+lDwf6GL62bPKwjFavzz0M?=
 =?us-ascii?Q?00NFP5FKIJJn5V0Ue3uoQFKLxw3gtiEwKrZvqreRQ2m+VdZjU8hp3/m63Se8?=
 =?us-ascii?Q?RVOsZ6tOWkoHNPutR2+ZIZ9gv6gvNw1V/Wr2iamt9tY0R3I11+NUguxgOQb4?=
 =?us-ascii?Q?eSxfJTYsdmitVBi3K9jVvH201YD3ION/t2vRdmxtJmb4UtAS0NTwIRyoe199?=
 =?us-ascii?Q?0xd5v8+v2Pr/E7mj91gcOQuOT1YuK5fRSJS02SMymGRwSX3PIvASB8SoVBG9?=
 =?us-ascii?Q?ZyrUnQSL8eQyNXbaRUNT2LnoIXBrrolq2eoguNEuZjFARnLH1k0b2cDEfH8/?=
 =?us-ascii?Q?VfA3FnjfsTx2gA/e/4lBVk0appFVHnIDgIDq9Ncc9lwu+yRrl0MRefSeRoYs?=
 =?us-ascii?Q?1F3vZDT77Gf4j7NXginVwcL7FJTgMyx2dM39lAaIthsv0qLnUi9QtertdYB4?=
 =?us-ascii?Q?7LvpbmnHq7zHr/wGQArExjNc3UtlSrVJ0hsNTXwm?=
X-OriginatorOrg: garyguo.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 186b6d43-0464-4a33-7434-08dc5eea9829
X-MS-Exchange-CrossTenant-AuthSource: LO2P265MB5183.GBRP265.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Apr 2024 14:28:04.9565
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: bbc898ad-b10f-4e10-8552-d9377b823d45
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: K9FqaBId04hA0Cit0UsWXUVy3f5Kbbr3oJJkWVRBTQ8VzU3b0l1YkWCV1+PERfGxMl5boWaHqvIuSxoZCLxfWg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO0P265MB6244

On Mon, 15 Apr 2024 07:13:53 +0000
Alice Ryhl <aliceryhl@google.com> wrote:

> From: Wedson Almeida Filho <wedsonaf@gmail.com>
> 
> A pointer to an area in userspace memory, which can be either read-only
> or read-write.
> 
> All methods on this struct are safe: attempting to read or write on bad
> addresses (either out of the bound of the slice or unmapped addresses)
> will return `EFAULT`. Concurrent access, *including data races to/from
> userspace memory*, is permitted, because fundamentally another userspace
> thread/process could always be modifying memory at the same time (in the
> same way that userspace Rust's `std::io` permits data races with the
> contents of files on disk). In the presence of a race, the exact byte
> values read/written are unspecified but the operation is well-defined.
> Kernelspace code should validate its copy of data after completing a
> read, and not expect that multiple reads of the same address will return
> the same value.
> 
> These APIs are designed to make it difficult to accidentally write
> TOCTOU bugs. Every time you read from a memory location, the pointer is
> advanced by the length so that you cannot use that reader to read the
> same memory location twice. Preventing double-fetches avoids TOCTOU
> bugs. This is accomplished by taking `self` by value to prevent
> obtaining multiple readers on a given `UserSlicePtr`, and the readers
> only permitting forward reads. If double-fetching a memory location is
> necessary for some reason, then that is done by creating multiple
> readers to the same memory location.
> 
> Constructing a `UserSlicePtr` performs no checks on the provided
> address and length, it can safely be constructed inside a kernel thread
> with no current userspace process. Reads and writes wrap the kernel APIs
> `copy_from_user` and `copy_to_user`, which check the memory map of the
> current process and enforce that the address range is within the user
> range (no additional calls to `access_ok` are needed).
> 
> This code is based on something that was originally written by Wedson on
> the old rust branch. It was modified by Alice by removing the
> `IoBufferReader` and `IoBufferWriter` traits, and various other changes.
> 
> Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com>
> Co-developed-by: Alice Ryhl <aliceryhl@google.com>
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
>  rust/helpers.c         |  14 +++
>  rust/kernel/lib.rs     |   1 +
>  rust/kernel/uaccess.rs | 304 +++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 319 insertions(+)
> 
> diff --git a/rust/kernel/uaccess.rs b/rust/kernel/uaccess.rs

> +/// [`std::io`]: https://doc.rust-lang.org/std/io/index.html
> +/// [`clone_reader`]: UserSliceReader::clone_reader
> +pub struct UserSlice {
> +    ptr: *mut c_void,
> +    length: usize,
> +}

How useful is the `c_void` in the struct and new signature? They tend
to not be very useful in Rust. Given that provenance doesn't matter
for userspace pointers, could this be `usize` simply?

I think `*mut u8` or `*mut ()` makes more sense than `*mut c_void` for
Rust code even if we don't want to use `usize`.

---

Some thinking aloud and brainstorming bits about the API.

I wonder if it make sense to have `User<[u8]>` instead of `UserSlice`?
The `User` type can be defined like this:

```rust
struct User<T: ?Sized> {
   ptr: *mut T,
}
```

and this allows arbitrary T as long as it's POD. So we could have
`User<[u8]>`, `User<u32>`, `User<PodStruct>`. I imagine the
`User<[u8]>` would be the general usage and the latter ones can be
especially helpful if you are trying to implement ioctl and need to
copy fixed size data structs from userspace.

Best,
Gary