Linux PCI subsystem development
 help / color / mirror / Atom feed
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.

  parent reply	other threads:[~2026-10-14 15:17 UTC|newest]

Thread overview: 50+ 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:41   ` sashiko-bot
2026-09-28  1:11 ` [PATCH v4 02/22] rust: transmute: add `cast_slice[_mut]` functions alistair23
2026-09-28  1:35   ` sashiko-bot
2026-10-14 15:16   ` Alexandre Courbot
2026-09-28  1:11 ` [PATCH v4 03/22] rust: create basic untrusted data API alistair23
2026-09-28  1:41   ` sashiko-bot
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:41   ` sashiko-bot
2026-09-28  1:11 ` [PATCH v4 05/22] X.509: Make certificate parser public alistair23
2026-09-28  1:39   ` sashiko-bot
2026-09-28  1:11 ` [PATCH v4 06/22] X.509: Parse Subject Alternative Name in certificates alistair23
2026-09-28  1:39   ` sashiko-bot
2026-09-28  1:11 ` [PATCH v4 07/22] X.509: Move certificate length retrieval into new helper alistair23
2026-09-28  1:36   ` sashiko-bot
2026-09-28  1:11 ` [PATCH v4 08/22] rust: add bindings for hash.h alistair23
2026-09-28  1:43   ` sashiko-bot
2026-09-28  1:11 ` [PATCH v4 09/22] rust: error: impl From<FromBytesWithNulError> for Kernel Error alistair23
2026-09-28  1:36   ` sashiko-bot
2026-09-28  1:11 ` [PATCH v4 10/22] lib: rspdm: Initial commit of Rust SPDM alistair23
2026-09-28  1:45   ` sashiko-bot
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:41   ` sashiko-bot
2026-09-28  1:11 ` [PATCH v4 12/22] PCI/TSM: Support connecting to PCIe CMA devices alistair23
2026-09-28  1:43   ` sashiko-bot
2026-09-28  1:11 ` [PATCH v4 13/22] PCI/CMA: Add a PCI TSM CMA driver using SPDM alistair23
2026-09-28  1:43   ` sashiko-bot
2026-09-28  1:11 ` [PATCH v4 14/22] PCI/CMA: Validate Subject Alternative Name in certificates alistair23
2026-09-28  1:44   ` sashiko-bot
2026-09-28  1:11 ` [PATCH v4 15/22] lib: rspdm: Support SPDM get_version alistair23
2026-09-28  1:39   ` sashiko-bot
2026-09-28  1:11 ` [PATCH v4 16/22] lib: rspdm: Support SPDM get_capabilities alistair23
2026-09-28  1:41   ` sashiko-bot
2026-09-28  1:11 ` [PATCH v4 17/22] lib: rspdm: Support SPDM negotiate_algorithms alistair23
2026-09-28  1:45   ` sashiko-bot
2026-09-28  1:11 ` [PATCH v4 18/22] lib: rspdm: Support SPDM get_digests alistair23
2026-09-28  1:45   ` sashiko-bot
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:47     ` sashiko-bot
2026-09-28  1:31   ` [PATCH v4 21/22] rust: allow extracting the buffer from a CString alistair23
2026-09-28  1:41     ` sashiko-bot
2026-09-28  1:31   ` [PATCH v4 22/22] lib: rspdm: Support SPDM challenge alistair23
2026-09-28  1:46     ` sashiko-bot
2026-09-28  1:43   ` [PATCH v4 19/22] lib: rspdm: Support SPDM get_certificate sashiko-bot
2026-10-14 15:16 ` [PATCH v4 00/22] lib: Rust implementation of SPDM Alexandre Courbot
2026-10-14 20:54 ` Alice Ryhl

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