All of lore.kernel.org
 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: 49+ 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

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 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.