From: "Alexandre Courbot" <acourbot@nvidia.com>
To: <alistair23@gmail.com>
Cc: <lukas@wunner.de>, <linux-cxl@vger.kernel.org>,
<akpm@linux-foundation.org>, <Jonathan.Cameron@huawei.com>,
<rust-for-linux@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<jic23@kernel.org>, <bhelgaas@google.com>,
<alistair@alistair23.me>, <djbw@kernel.org>,
<linux-pci@vger.kernel.org>, <wilfred.mallawa@wdc.com>,
<a.hindborg@kernel.org>, <gregkh@linuxfoundation.org>,
<alex.gaynor@gmail.com>, <aliceryhl@google.com>,
<benno.lossin@proton.me>, <boqun.feng@gmail.com>,
<bjorn3_gh@protonmail.com>, <tmgross@umich.edu>,
<gary@garyguo.net>, <ojeda@kernel.org>,
"Alistair Francis" <alistair.francis@wdc.com>
Subject: Re: [PATCH v4 03/22] rust: create basic untrusted data API
Date: Thu, 15 Oct 2026 00:17:00 +0900 [thread overview]
Message-ID: <DM4NSU7XQTV4.2ZUEKRQAI9CXK@nvidia.com> (raw)
In-Reply-To: <20260928011123.450800-4-alistair.francis@wdc.com>
On Mon Sep 28, 2026 at 10:11 AM JST, alistair23 wrote:
<...>
> +/// Untrusted data of type `T`.
> +///
> +/// Data coming from userspace is considered untrusted and should be marked by this type.
> +///
> +/// The particular meaning of [`Untrusted<T>`] depends heavily on the type `T`. For example,
> +/// `&Untrusted<[u8]>` is a reference to an untrusted slice. But the length is not considered
> +/// untrusted, as it would otherwise violate normal Rust rules. For this reason, one can easily
> +/// convert that reference to `&[Untrusted<u8>]`. Another such example is `Untrusted<KVec<T>>`, it
> +/// derefs to `[Untrusted<T>]`. Raw bytes however do not behave in this way, `Untrusted<u8>` is
> +/// totally opaque.
> +///
> +/// # Usage in API Design
> +///
> +/// The exact location where to put [`Untrusted`] depends on the kind of API. When asking for an
> +/// untrusted input value, or buffer to write to, always move the [`Untrusted`] wrapper as far
> +/// inwards as possible:
> +///
> +/// ```ignore
> +/// // use this
> +/// pub fn read_from_userspace(buf: &mut [Untrusted<u8>]) { todo!() }
> +///
> +/// // and not this
> +/// pub fn read_from_userspace(buf: &mut Untrusted<[u8]>) { todo!() }
> +/// ```
> +///
> +/// The reason for this is that `&mut Untrusted<[u8]>` can beconverted into `&mut [Untrusted<u8>]`
nit: missing space: "can be converted"
> +/// very easily, but the converse is not possible.
> +///
> +/// For the same reason, when returning untrusted data by-value, one should move the [`Untrusted`]
> +/// wrapper as far outward as possible:
> +///
> +/// ```ignore
> +/// // use this
> +/// pub fn read_all_from_userspace() -> Untrusted<KVec<u8>> { todo!() }
> +///
> +/// // and not this
> +/// pub fn read_all_from_userspace() -> KVec<Untrusted<u8>> { todo!() }
> +/// ```
> +///
> +/// Here too the reason is that `KVec<Untrusted<u8>>` is more restrictive compared to
> +/// `Untrusted<KVec<u8>>`.
> +#[repr(transparent)]
> +pub struct Untrusted<T: ?Sized>(T);
> +
> +impl<T: ?Sized> Untrusted<T> {
> + /// Marks the given value as untrusted.
> + ///
> + /// # Examples
> + ///
> + /// ```
> + /// use kernel::validate::Untrusted;
> + ///
> + /// # mod bindings { pub(crate) unsafe fn read_foo_info() -> [u8; 4] { todo!() } };
> + /// fn read_foo_info() -> Untrusted<[u8; 4]> {
> + /// // SAFETY: just an FFI call without preconditions.
> + /// Untrusted::new(unsafe { bindings::read_foo_info() })
> + /// }
> + /// ```
> + #[inline]
> + pub fn new(value: T) -> Self
> + where
> + T: Sized,
> + {
> + Self(value)
> + }
This constructor is probably useful (although it should probably be a
`From<T>` implementation?), but is also moves `value`, which might
perform a copy on the stack that we will want to avoid if `T` is big.
So in addition to it, can we define constructors that work on references:
pub fn from_ref(r: &T) -> &Self;
pub fn from_mut(r: &mut T) -> &mut Self;
So we can pass around data to be validated without performing a copy.
While we are at it, we can also add slice variants:
pub const fn from_slice(s: &[T]) -> &[Self];
pub const fn from_mut_slice(s: &mut [T]) -> &mut [Self];
They will also be useful for the `Deref` implementations below.
> +}
> +
> +impl<T> Deref for Untrusted<[T]> {
> + type Target = [Untrusted<T>];
> +
> + #[inline]
> + fn deref(&self) -> &Self::Target {
> + // SAFETY: `Untrusted<T>` transparently wraps `T`.
> + unsafe { cast_slice(&self.0) }
With `from_slice` above this can become:
Untrusted::from_slice(&self.0)
> + }
> +}
> +
> +impl<T> DerefMut for Untrusted<[T]> {
> + #[inline]
> + fn deref_mut(&mut self) -> &mut Self::Target {
> + // SAFETY: `Untrusted<T>` transparently wraps `T`.
> + unsafe { cast_slice_mut(&mut self.0) }
And this becomes:
Untrusted::from_mut_slice(&mut self.0)
> + }
> +}
> +
> +impl<T, A: Allocator> Deref for Untrusted<Vec<T, A>> {
> + type Target = [Untrusted<T>];
> +
> + #[inline]
> + fn deref(&self) -> &Self::Target {
> + // SAFETY: `Untrusted<T>` transparently wraps `T`.
> + unsafe { cast_slice(self.0.as_slice()) }
> + }
> +}
> +
> +impl<T, A: Allocator> DerefMut for Untrusted<Vec<T, A>> {
> + #[inline]
> + fn deref_mut(&mut self) -> &mut Self::Target {
> + // SAFETY: `Untrusted<T>` transparently wraps `T`.
> + unsafe { cast_slice_mut(self.0.as_mut_slice()) }
> + }
> +}
These can also be implemented identically to the ones above.
next prev parent reply other threads:[~2026-10-14 15:17 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 1:11 [PATCH v4 00/22] lib: Rust implementation of SPDM alistair23
2026-09-28 1:11 ` [PATCH v4 01/22] virt: coco: change tsm_register() to use a const struct alistair23
2026-09-28 1:11 ` [PATCH v4 02/22] rust: transmute: add `cast_slice[_mut]` functions alistair23
2026-10-14 15:16 ` Alexandre Courbot
2026-09-28 1:11 ` [PATCH v4 03/22] rust: create basic untrusted data API alistair23
2026-10-14 15:17 ` Alexandre Courbot [this message]
2026-09-28 1:11 ` [PATCH v4 04/22] rust: validate: add `Validate` trait alistair23
2026-09-28 1:11 ` [PATCH v4 05/22] X.509: Make certificate parser public alistair23
2026-09-28 1:11 ` [PATCH v4 06/22] X.509: Parse Subject Alternative Name in certificates alistair23
2026-09-28 1:11 ` [PATCH v4 07/22] X.509: Move certificate length retrieval into new helper alistair23
2026-09-28 1:11 ` [PATCH v4 08/22] rust: add bindings for hash.h alistair23
2026-09-28 1:11 ` [PATCH v4 09/22] rust: error: impl From<FromBytesWithNulError> for Kernel Error alistair23
2026-09-28 1:11 ` [PATCH v4 10/22] lib: rspdm: Initial commit of Rust SPDM alistair23
2026-10-14 15:17 ` Alexandre Courbot
2026-09-28 1:11 ` [PATCH v4 11/22] PCI/TSM: Rename pf0 to host alistair23
2026-09-28 1:11 ` [PATCH v4 12/22] PCI/TSM: Support connecting to PCIe CMA devices alistair23
2026-09-28 1:11 ` [PATCH v4 13/22] PCI/CMA: Add a PCI TSM CMA driver using SPDM alistair23
2026-09-28 1:11 ` [PATCH v4 14/22] PCI/CMA: Validate Subject Alternative Name in certificates alistair23
2026-09-28 1:11 ` [PATCH v4 15/22] lib: rspdm: Support SPDM get_version alistair23
2026-09-28 1:11 ` [PATCH v4 16/22] lib: rspdm: Support SPDM get_capabilities alistair23
2026-09-28 1:11 ` [PATCH v4 17/22] lib: rspdm: Support SPDM negotiate_algorithms alistair23
2026-09-28 1:11 ` [PATCH v4 18/22] lib: rspdm: Support SPDM get_digests alistair23
2026-09-28 1:31 ` [PATCH v4 19/22] lib: rspdm: Support SPDM get_certificate alistair23
2026-09-28 1:31 ` [PATCH v4 20/22] lib: rspdm: Support SPDM certificate validation alistair23
2026-09-28 1:31 ` [PATCH v4 21/22] rust: allow extracting the buffer from a CString alistair23
2026-09-28 1:31 ` [PATCH v4 22/22] lib: rspdm: Support SPDM challenge alistair23
2026-10-14 15:16 ` [PATCH v4 00/22] lib: Rust implementation of SPDM Alexandre Courbot
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=DM4NSU7XQTV4.2ZUEKRQAI9CXK@nvidia.com \
--to=acourbot@nvidia.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=a.hindborg@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=alistair.francis@wdc.com \
--cc=alistair23@gmail.com \
--cc=alistair@alistair23.me \
--cc=benno.lossin@proton.me \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=djbw@kernel.org \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=jic23@kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
--cc=wilfred.mallawa@wdc.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox