From patchwork Wed Jan 24 11:20:21 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alice Ryhl X-Patchwork-Id: 13528936 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0C309C47DDF for ; Wed, 24 Jan 2024 11:20:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7D7A76B007E; Wed, 24 Jan 2024 06:20:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 75E906B0080; Wed, 24 Jan 2024 06:20:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D9266B0082; Wed, 24 Jan 2024 06:20:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 45D316B007E for ; Wed, 24 Jan 2024 06:20:52 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 045FFA2014 for ; Wed, 24 Jan 2024 11:20:51 +0000 (UTC) X-FDA: 81713962344.16.6AE7399 Received: from mail-lj1-f202.google.com (mail-lj1-f202.google.com [209.85.208.202]) by imf28.hostedemail.com (Postfix) with ESMTP id 12C4FC0003 for ; Wed, 24 Jan 2024 11:20:49 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=RxdJxtbf; spf=pass (imf28.hostedemail.com: domain of 3kPKwZQkKCG0LWTNPcjSWRZZRWP.NZXWTYfi-XXVgLNV.ZcR@flex--aliceryhl.bounces.google.com designates 209.85.208.202 as permitted sender) smtp.mailfrom=3kPKwZQkKCG0LWTNPcjSWRZZRWP.NZXWTYfi-XXVgLNV.ZcR@flex--aliceryhl.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706095250; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=sOlUnGTFxhN3Wh+HyLrepLimkn/9swyxf47U8+mQUyU=; b=w/T6X8h7tMG+PwORS7DYSnBp9x2QPdsO6NAsv8Z0IKAjtK/ZM2BIwMq0I2IaRpaRkdvPYh E7jQcPNFyzOyirWXRjAiWBbGSO2OoHPrXuwCK+hjwdRApt423lTyb8801pp6Z2ocB2ZyKO tQ6rVxcQEjl+dSENy4XUWnYZ1yMG5Ag= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706095250; a=rsa-sha256; cv=none; b=08Wz138BNyxWLr5pzidcjLW73wi7jn5peWA+ruhTRQIqjzl/YH7Lq6iKdBV1tV3T17sb5Q KINv4i05VVujrRrxHjwShiw7zRNtq7MuoV55+u50iL5u3awnKTGvSL3kj2KGkI/tL3xgXj bX9umq3L3bfY5Up9feWAFz5kltlph44= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=RxdJxtbf; spf=pass (imf28.hostedemail.com: domain of 3kPKwZQkKCG0LWTNPcjSWRZZRWP.NZXWTYfi-XXVgLNV.ZcR@flex--aliceryhl.bounces.google.com designates 209.85.208.202 as permitted sender) smtp.mailfrom=3kPKwZQkKCG0LWTNPcjSWRZZRWP.NZXWTYfi-XXVgLNV.ZcR@flex--aliceryhl.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-lj1-f202.google.com with SMTP id 38308e7fff4ca-2cf119d6c7aso9857301fa.1 for ; Wed, 24 Jan 2024 03:20:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1706095248; x=1706700048; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=sOlUnGTFxhN3Wh+HyLrepLimkn/9swyxf47U8+mQUyU=; b=RxdJxtbfWIkZp/0bUCkGhlnYK4yDpX4P2saVxsjHgXv7Bl6nK7xQIQIEuKUuocwuKA VMP1QeBmmPygY1hL+ue8RbV3Yv8hBNU+eWQPCP4NECEpVtHdwvoJsIgY/Y7JLSowvXxK hdvAQmK5a5qZvASJV8mNOPqsokjOQafS+oVmaO/M0xukvqQIK7DrZfIImc6k8Ld8HxU8 LRpWQ+FrbdYtIaYrA0ynZGVwdCbv7qz/DUZ0tIFGk0cS4xxEkPeeYSCrzqEQlDGDqzJ0 8sDEhJ0gj7NM9U6u9yJXCH0IpmamgKrZmeoCi+WEJtWS6R4+wD1xTmRR1WPAN5qUfiHr iu0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706095248; x=1706700048; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=sOlUnGTFxhN3Wh+HyLrepLimkn/9swyxf47U8+mQUyU=; b=k00GJmletVz6S2s+5NDyGxMYoO40dadUzHGNWORuJ/cv74C7OjEFDUpBmFqPKbhA2L TUqJPEcM8/MN3iMYedxSJlBKgHIwNJapIVVBAZAO81AHFI4jwdJlRyej6Setg8lw4Nni LKEnsB/37YdsBGBtksyFKP2nyJZxj0tQ2SWBDGUAlKk6pLn9PDY+q/vDbq2d5jYO9vEi vZ9rvwi66pPgELNHzWOc6582vJhpATV1Kmios7vvo0UrC8nLzqxHLCBoXrO8X2YPjHvc sKskejioZUXhp4SETBKJ5MOVGzRy99/imV1g1XIGTKgmor3/LzAl0YJWf7BCR2JkY8Z7 spbA== X-Gm-Message-State: AOJu0YwjfQN9/6SlBu7G+w4Jh69IqvZSrRtCjtzfeKa7gk+i33vh9Uqf QSIsOC6eKqyhmXx8w1cThW0bdhMW2ljC+I5YYPzIHu4lcQoFP2lPeuVxx2PTuklQ3IesO7GTPKi UdR+dN3D5KPC0yQ== X-Google-Smtp-Source: AGHT+IFUYMF+5aVolcJmSgvYFnzvo3J5rdE3577wOO1E14UnlXcw+yKrbQDZV1pCgDhSzd5JSUABWHV4PUCu0xY= X-Received: from aliceryhl2.c.googlers.com ([fda3:e722:ac3:cc00:68:949d:c0a8:572]) (user=aliceryhl job=sendgmr) by 2002:a05:651c:b10:b0:2cd:eb48:b13a with SMTP id b16-20020a05651c0b1000b002cdeb48b13amr2362ljr.0.1706095248056; Wed, 24 Jan 2024 03:20:48 -0800 (PST) Date: Wed, 24 Jan 2024 11:20:21 +0000 In-Reply-To: <20240124-alice-mm-v1-0-d1abcec83c44@google.com> Mime-Version: 1.0 References: <20240124-alice-mm-v1-0-d1abcec83c44@google.com> X-Developer-Key: i=aliceryhl@google.com; a=openpgp; fpr=49F6C1FAA74960F43A5B86A1EE7A392FDE96209F X-Developer-Signature: v=1; a=openpgp-sha256; l=12466; i=aliceryhl@google.com; h=from:subject:message-id; bh=bddQOIHpQkNTHq5sjTLF1voN+vRIKosROer1IBiKH5A=; b=owEBbQKS/ZANAwAKAQRYvu5YxjlGAcsmYgBlsPKIRQHGdOXUpFINztbIBSV3FRotWlg2iJOOs JAtY6uLI4CJAjMEAAEKAB0WIQSDkqKUTWQHCvFIvbIEWL7uWMY5RgUCZbDyiAAKCRAEWL7uWMY5 RoEfD/91wS6JPiDUWmveLCNNVfA6anIc+FlQsNYh5zlWLLaxe+paLhsR0TrGWOogLdJ0IEH0jMU IJsgpxyuIHJ2gU5Wv5XJ/6T652mp+neY7FLhbDy1AwyaDjOtyZe9YG+lleVY+cCb6JfpCjaxQ4P OAVNBrtDzv/q7RDe3hJBJmc/qi1UJW7CaM0N7AkAHqVopOdi0JV3NUvYYJhsPtOSaWVNdHjw3Rc /xkUIhvoMY7HUz4660SIcOVUBgPQ+N4jwsZlX04QD+FjKi0ZPRchMCJOf622yKI8c41wmdO3df1 JnbwGrCqZ+0OJkDowIjxUddGR/jm98odkcYtso9gCXCuW36zQv/E9Aqlbi0qg0G1oM1msuV2B7C JZPkTcmL26OQXZe4H3N1wZblu6NK8NJmtZz+3uBhALhRAKwr2lzNLRdmlfKwUU0uqIpFREk6hLZ jNQOzCCe1nDDxMaexOZbX8TNzih7O6/k928AQFtMyzzAZDPlUysnD+MosOPxFxdV5HM0lfpL/9W nz2hVF8znvzWDXkB9Rt2J2uVFdJLkH6FKbXEPXkM/aeRQQVE3QMZmVDvuNj6b1RliB551Mm/ljQ LHlblg1e2PzRKPE09USqjXaol+QbwGQO4Of/MO8jkDxLXA/xE0vBkCLIk0zXRcK6rzE3V6CKHR6 FOwnyPzNQkC5n6g== X-Mailer: b4 0.13-dev-26615 Message-ID: <20240124-alice-mm-v1-1-d1abcec83c44@google.com> Subject: [PATCH 1/3] rust: add userspace pointers From: Alice Ryhl To: Miguel Ojeda , Alex Gaynor , Wedson Almeida Filho , Boqun Feng , Gary Guo , " =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= " , Benno Lossin , Andreas Hindborg , Kees Cook , Al Viro , Andrew Morton Cc: Greg Kroah-Hartman , " =?utf-8?q?Arve_Hj?= =?utf-8?q?=C3=B8nnev=C3=A5g?= " , Todd Kjos , Martijn Coenen , Joel Fernandes , Carlos Llamas , Suren Baghdasaryan , Arnd Bergmann , linux-mm@kvack.org, linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, Alice Ryhl , Christian Brauner X-Rspamd-Queue-Id: 12C4FC0003 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: fud9idtqx5eto93r9x1mcq5pjna8ngi1 X-HE-Tag: 1706095249-738281 X-HE-Meta: U2FsdGVkX19zeVOrNkWSK7uwXcNodxU8iWyUYoUhi82vzTjuGC7CruBJCdzVjPwHz00jvvJsB1YOSj/q6o4xiENtykRW5aOLDbhUGWdcMwfboaldlM5q45F+fOkOvbyOnhDrjNFKhUk4/2FLqkwYnQ5Was/3cN7BZe+4VSViOdfoynyYa9CDBmT6o+mAIjzSNARKYWRHzQ4ktfXVjxoaz3m5UZwhgmPwF0wZdUgK9XKDQ9qCuFDe+yDsRdk8QedAVG81bJdJNNfmtYp68gAqV7u2bVMLzQatCYs4jt9MzKOhOqwLAKrsba58swNi2y/AJuU/0df5TrzPT5EnNDBc1f//9So+A6t/GOtQuXCgemt3tNuAGXCfFdAGlXTvj54Ypy2gLvCaVIQtwiGraEMHauxSuIsEdmpZi5uLvwClSNhycvvpbQ60TOAHfBKUuF3pNE5+7yKpRG/W/9a3WqNsRIvI1Y9dO6IhgwEsBPRDO73r22Ssp9GT0LuS5gexwtQvnIseu9BpMr0nIrFRVyAPuncPGZW0188bEMsT6MTR2m+NfTFUwJvaYNqoH4YXea/4CSooQmS4LbYoVG31SoX21MWYuML+JlvWwrj5x6MOrd4C3xBPrRep0c3v/DuDbGQukfXu59xEQVVMfvE2gbVTz/e0Z3HRZMp3NKi6v954vHRD++5uyCdG2+VRLh6qvlaHfkra7bKUSndinLENZGo6Ph1E02Wz3ZIsy0GbQmsulw+a4PYuOxlbRmnsdRmralbwqplHkFOBlEkBqSGgDmhtwKlpl3biTyV+6d6b/pkiYyRthHBJvZhM9ytBysNDhg+xocO3x8xybAo6h/wdN3c5dQeCMrs+GTTK+a+roDE3tTz45zfgQfrB5Lo4dAVclNs/OlUJj5Cz0/nHQvvl+JxPgiMcnWgtRpwUGEor5zSjKGZXTvRLPjVZIP/QEeYxrFkO74z4QJY2nRuVmvirNly MRYVIfWe h9kvawcfsVBpgUacdBNX6f+vmo7zwmyTol68Krws89wQsE6orbX6pp8ZLPIg2fmrpHrDEkwDpE3O09vV8tsjeMrW3U80m97HNgMswnsb6LGUFAHqztwdDA7V2npHKclsXYeH4haXjjNB+YlSoCvpaATWIpjZEcIHMfdZVVblUu37VId1RYxZ0tomWEMuHJllcsPcZxVc8WCSBwudoeT4usY+TvTlLIZ/CGQnZpdX0o8az/cYih2a0mq+WMKL3czN9q8tvJtCkB3RQ61lv07qoZ6Mva32mZWooaRly3ARxVRVRiRwiYHr7O0oFq1HSzHR+6NDaJng2hYt3kiNdf33IQmypZnpsiH0S7WNLsAqhw8SzcV6jl/ot+xQ5dhtJcpnafHes/2GhNuEQWzdDmy6nL2ii/wDwAagWN6qK+9BcR7mAGiG/xPjLQan2CZuGWaMsaZdJavBClAOttvcKIJRj3AFoDNJ57Sn7c43pFpWzJtHPnrazuL9PmJxYxuhh/ouGHG9N6RXUmEe8FGbokrlYeikjCQAVW9sfbB0GieHsxG4uB35SlH7AczhwBud2TLT1QerL4zmEee/kbP5NkafnonhPabSdVCyfxhB1O9F+JRv1o+OMd/G4VprqMCTpb6Losx8mr6UiG3nTDYBtZI4yjYIJ9C5B0UgINFo5hYgvnKKHJEnXR3EA0rQYG8c9UK5fbddI X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: From: Wedson Almeida Filho A pointer to an area in userspace memory, which can be either read-only or read-write. All methods on this struct are safe: invalid pointers 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, introducing the `MAX_USER_OP_LEN` constant, and various changes to the comments and documentation. Signed-off-by: Wedson Almeida Filho Co-developed-by: Alice Ryhl Signed-off-by: Alice Ryhl --- rust/helpers.c | 14 +++ rust/kernel/lib.rs | 1 + rust/kernel/user_ptr.rs | 222 ++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 237 insertions(+) diff --git a/rust/helpers.c b/rust/helpers.c index 70e59efd92bc..312b6fcb49d5 100644 --- a/rust/helpers.c +++ b/rust/helpers.c @@ -38,6 +38,20 @@ __noreturn void rust_helper_BUG(void) } EXPORT_SYMBOL_GPL(rust_helper_BUG); +unsigned long rust_helper_copy_from_user(void *to, const void __user *from, + unsigned long n) +{ + return copy_from_user(to, from, n); +} +EXPORT_SYMBOL_GPL(rust_helper_copy_from_user); + +unsigned long rust_helper_copy_to_user(void __user *to, const void *from, + unsigned long n) +{ + return copy_to_user(to, from, n); +} +EXPORT_SYMBOL_GPL(rust_helper_copy_to_user); + void rust_helper_mutex_lock(struct mutex *lock) { mutex_lock(lock); diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs index 7ac39874aeac..041233305fda 100644 --- a/rust/kernel/lib.rs +++ b/rust/kernel/lib.rs @@ -50,6 +50,7 @@ pub mod sync; pub mod task; pub mod types; +pub mod user_ptr; pub mod workqueue; #[doc(hidden)] diff --git a/rust/kernel/user_ptr.rs b/rust/kernel/user_ptr.rs new file mode 100644 index 000000000000..00aa26aa6a83 --- /dev/null +++ b/rust/kernel/user_ptr.rs @@ -0,0 +1,222 @@ +// SPDX-License-Identifier: GPL-2.0 + +//! User pointers. +//! +//! C header: [`include/linux/uaccess.h`](../../../../include/linux/uaccess.h) + +// Comparison with MAX_USER_OP_LEN triggers this lint on platforms +// where `c_ulong == usize`. +#![allow(clippy::absurd_extreme_comparisons)] + +use crate::{bindings, error::code::*, error::Result}; +use alloc::vec::Vec; +use core::ffi::{c_ulong, c_void}; + +/// The maximum length of a operation using `copy_[from|to]_user`. +/// +/// If a usize is not greater than this constant, then casting it to `c_ulong` +/// is guaranteed to be lossless. +const MAX_USER_OP_LEN: usize = c_ulong::MAX as usize; + +/// A pointer to an area in userspace memory, which can be either read-only or +/// read-write. +/// +/// All methods on this struct are safe: invalid pointers 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, e.g. using +/// [`clone_reader`]. +/// +/// 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). +/// +/// [`std::io`]: https://doc.rust-lang.org/std/io/index.html +/// [`clone_reader`]: UserSlicePtrReader::clone_reader +pub struct UserSlicePtr(*mut c_void, usize); + +impl UserSlicePtr { + /// Constructs a user slice from a raw pointer and a length in bytes. + /// + /// Callers must be careful to avoid time-of-check-time-of-use + /// (TOCTOU) issues. The simplest way is to create a single instance of + /// [`UserSlicePtr`] per user memory block as it reads each byte at + /// most once. + pub fn new(ptr: *mut c_void, length: usize) -> Self { + UserSlicePtr(ptr, length) + } + + /// Reads the entirety of the user slice. + /// + /// Returns `EFAULT` if the address does not currently point to + /// mapped, readable memory. + pub fn read_all(self) -> Result> { + self.reader().read_all() + } + + /// Constructs a [`UserSlicePtrReader`]. + pub fn reader(self) -> UserSlicePtrReader { + UserSlicePtrReader(self.0, self.1) + } + + /// Constructs a [`UserSlicePtrWriter`]. + pub fn writer(self) -> UserSlicePtrWriter { + UserSlicePtrWriter(self.0, self.1) + } + + /// Constructs both a [`UserSlicePtrReader`] and a [`UserSlicePtrWriter`]. + pub fn reader_writer(self) -> (UserSlicePtrReader, UserSlicePtrWriter) { + ( + UserSlicePtrReader(self.0, self.1), + UserSlicePtrWriter(self.0, self.1), + ) + } +} + +/// A reader for [`UserSlicePtr`]. +/// +/// Used to incrementally read from the user slice. +pub struct UserSlicePtrReader(*mut c_void, usize); + +impl UserSlicePtrReader { + /// Skip the provided number of bytes. + /// + /// Returns an error if skipping more than the length of the buffer. + pub fn skip(&mut self, num_skip: usize) -> Result { + // Update `self.1` first since that's the fallible one. + self.1 = self.1.checked_sub(num_skip).ok_or(EFAULT)?; + self.0 = self.0.wrapping_add(num_skip); + Ok(()) + } + + /// Create a reader that can access the same range of data. + /// + /// Reading from the clone does not advance the current reader. + /// + /// The caller should take care to not introduce TOCTOU issues. + pub fn clone_reader(&self) -> UserSlicePtrReader { + UserSlicePtrReader(self.0, self.1) + } + + /// Returns the number of bytes left to be read from this. + /// + /// Note that even reading less than this number of bytes may fail. + pub fn len(&self) -> usize { + self.1 + } + + /// Returns `true` if no data is available in the io buffer. + pub fn is_empty(&self) -> bool { + self.1 == 0 + } + + /// Reads raw data from the user slice into a raw kernel buffer. + /// + /// Fails with `EFAULT` if the read encounters a page fault. + /// + /// # Safety + /// + /// The `out` pointer must be valid for writing `len` bytes. + pub unsafe fn read_raw(&mut self, out: *mut u8, len: usize) -> Result { + if len > self.1 || len > MAX_USER_OP_LEN { + return Err(EFAULT); + } + // SAFETY: The caller promises that `out` is valid for writing `len` bytes. + let res = unsafe { bindings::copy_from_user(out.cast::(), self.0, len as c_ulong) }; + if res != 0 { + return Err(EFAULT); + } + // Since this is not a pointer to a valid object in our program, + // we cannot use `add`, which has C-style rules for defined + // behavior. + self.0 = self.0.wrapping_add(len); + self.1 -= len; + Ok(()) + } + + /// Reads all remaining data in the buffer into a vector. + /// + /// Fails with `EFAULT` if the read encounters a page fault. + pub fn read_all(&mut self) -> Result> { + let len = self.len(); + let mut data = Vec::::try_with_capacity(len)?; + + // SAFETY: The output buffer is valid for `len` bytes as we just allocated that much space. + unsafe { self.read_raw(data.as_mut_ptr(), len)? }; + + // SAFETY: Since the call to `read_raw` was successful, the first `len` bytes of the vector + // have been initialized. + unsafe { data.set_len(len) }; + Ok(data) + } +} + +/// A writer for [`UserSlicePtr`]. +/// +/// Used to incrementally write into the user slice. +pub struct UserSlicePtrWriter(*mut c_void, usize); + +impl UserSlicePtrWriter { + /// Returns the amount of space remaining in this buffer. + /// + /// Note that even writing less than this number of bytes may fail. + pub fn len(&self) -> usize { + self.1 + } + + /// Returns `true` if no more data can be written to this buffer. + pub fn is_empty(&self) -> bool { + self.1 == 0 + } + + /// Writes raw data to this user pointer from a raw kernel buffer. + /// + /// Fails with `EFAULT` if the write encounters a page fault. + /// + /// # Safety + /// + /// The `data` pointer must be valid for reading `len` bytes. + pub unsafe fn write_raw(&mut self, data: *const u8, len: usize) -> Result { + if len > self.1 || len > MAX_USER_OP_LEN { + return Err(EFAULT); + } + let res = unsafe { bindings::copy_to_user(self.0, data.cast::(), len as c_ulong) }; + if res != 0 { + return Err(EFAULT); + } + // Since this is not a pointer to a valid object in our program, + // we cannot use `add`, which has C-style rules for defined + // behavior. + self.0 = self.0.wrapping_add(len); + self.1 -= len; + Ok(()) + } + + /// Writes the provided slice to this user pointer. + /// + /// Fails with `EFAULT` if the write encounters a page fault. + pub fn write_slice(&mut self, data: &[u8]) -> Result { + let len = data.len(); + let ptr = data.as_ptr(); + // SAFETY: The pointer originates from a reference to a slice of length + // `len`, so the pointer is valid for reading `len` bytes. + unsafe { self.write_raw(ptr, len) } + } +}