All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Benno Lossin" <lossin@kernel.org>
To: <sashiko-reviews@lists.linux.dev>, <alistair23@gmail.com>,
	<linux-pci@vger.kernel.org>, <linux-cxl@vger.kernel.org>
Cc: <ojeda@kernel.org>, <gary@garyguo.net>
Subject: Re: [PATCH v5 02/23] rust: create basic untrusted data API
Date: Tue, 27 Oct 2026 13:17:03 +0000	[thread overview]
Message-ID: <DMFNE2OD18PH.27J64IS0GAJLF@kernel.org> (raw)
In-Reply-To: <sashiko-outbox-186123@kernel.org>

On Tue Oct 27, 2026 at 5:34 AM GMT, sashiko-bot wrote:
>> +impl<T> Untrusted<T> {
>> +    /// Marks the data behind the given reference as untrusted.
>> +    ///
>> +    /// Unlike [`Untrusted::new`], this does not require moving the value.
>> +    #[inline]
>> +    pub const fn from_ref(value: &T) -> &Self {
>> +        // SAFETY: `Untrusted<T>` transparently wraps `T`. The cast
>> +        // does not introduce interior mutability, as `Untrusted<T>`
>> +        // has interior mutability if and only if `T` has.
>> +        unsafe { &*from_ref(value).cast::<Self>() }
>> +    }
>> +
>> +    /// Marks the data behind the given mutable reference as untrusted.
>> +    ///
>> +    /// Unlike [`Untrusted::new`], this does not require moving the value.
>> +    #[inline]
>> +    pub const fn from_mut(value: &mut T) -> &mut Self {
>> +        // SAFETY: Same reasoning as `from_ref()`.
>> +        unsafe { &mut *from_mut(value).cast::<Self>() }
>> +    }
>> +
>> +    /// Marks the given slice of data as untrusted.
>> +    #[inline]
>> +    pub const fn from_slice(value: &[T]) -> &[Self] {
>> +        // SAFETY: `Untrusted<T>` transparently wraps `T`. The cast
>> +        // does not introduce interior mutability either, as `Untrusted<T>`
>> +        // has interior mutability if and only if `T` has.
>> +        unsafe { slice::from_raw_parts(value.as_ptr().cast::<Self>(), value.len()) }
>> +    }
>> +
>> +    /// Marks the given mutable slice of data as untrusted.
>> +    #[inline]
>> +    pub const fn from_mut_slice(value: &mut [T]) -> &mut [Self] {
>> +        // SAFETY: Same reasoning as `from_slice()`.
>> +        unsafe { slice::from_raw_parts_mut(value.as_mut_ptr().cast::<Self>(), value.len()) }
>> +    }
>> +}
>
> [Severity: Medium]
> Do public Untrusted::from_mut() and Untrusted::from_mut_slice() allow safe
> code to bypass the opacity guarantee of Untrusted<T>?
>
> Because mutable references are invariant in T, converting &mut T into
> &mut Untrusted<T> (or &mut [T] into &mut [Untrusted<T>]) allows callers to
> write unvalidated Untrusted<T> values directly into a plain, trusted T or [T]
> variable without validation:
>
>     let mut trusted: u8 = 0;
>     *Untrusted::from_mut(&mut trusted) = untrusted_byte;
>
> Similarly, a caller with a plain mutable slice buf: &mut [u8] can pass
> Untrusted::from_mut_slice(buf) to a function expecting &mut [Untrusted<u8>]
> (such as the read_from_userspace(buf: &mut [Untrusted<u8>]) pattern shown in
> the documentation) and then read the unvalidated bytes directly from buf
> after the call returns.
>
> Since DerefMut on Untrusted<[T]> and Untrusted<Vec<T, A>> only converts an
> already-untrusted container into &mut [Untrusted<T>], should from_mut_slice()
> be private and from_mut() be removed or kept private?

this is correct. we should remove `from_mut_slice`. but we can provide
`Vec::from_trusted: fn(Vec<T>) -> Vec<Untrusted<T>>`.

best,
Benno

  reply	other threads:[~2026-10-27 13:17 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-27  5:25 [PATCH v5 00/23] lib: Rust implementation of SPDM alistair23
2026-10-27  5:25 ` [PATCH v5 01/23] virt: coco: change tsm_register() to use a const struct alistair23
2026-10-27  5:32   ` sashiko-bot
2026-10-27  5:25 ` [PATCH v5 02/23] rust: create basic untrusted data API alistair23
2026-10-27  5:34   ` sashiko-bot
2026-10-27 13:17     ` Benno Lossin [this message]
2026-10-27  5:25 ` [PATCH v5 03/23] rust: validate: add `Validate` trait alistair23
2026-10-27  5:33   ` sashiko-bot
2026-10-27  5:25 ` [PATCH v5 04/23] X.509: Make certificate parser public alistair23
2026-10-27  5:33   ` sashiko-bot
2026-10-27  5:25 ` [PATCH v5 05/23] X.509: Parse Subject Alternative Name in certificates alistair23
2026-10-27  5:32   ` sashiko-bot
2026-10-27  5:25 ` [PATCH v5 06/23] X.509: Move certificate length retrieval into new helper alistair23
2026-10-27  5:32   ` sashiko-bot
2026-10-27  5:25 ` [PATCH v5 07/23] rust: add bindings for hash.h alistair23
2026-10-27  5:34   ` sashiko-bot
2026-10-27  5:25 ` [PATCH v5 08/23] rust: device: Expose Device from_raw() publically alistair23
2026-10-27  5:34   ` sashiko-bot
2026-10-27  5:25 ` [PATCH v5 09/23] lib: rspdm: Initial commit of Rust SPDM alistair23
2026-10-27  5:42   ` sashiko-bot
2026-10-27  5:25 ` [PATCH v5 10/23] PCI/TSM: Rename pf0 to host alistair23
2026-10-27  5:33   ` sashiko-bot
2026-10-27  5:25 ` [PATCH v5 11/23] PCI/TSM: Support connecting to PCIe CMA devices alistair23
2026-10-27  5:50   ` sashiko-bot
2026-10-27  5:25 ` [PATCH v5 12/23] PCI/CMA: Add a PCI TSM CMA driver using SPDM alistair23
2026-10-27  5:46   ` sashiko-bot
2026-10-27  5:25 ` [PATCH v5 13/23] PCI/CMA: Validate Subject Alternative Name in certificates alistair23
2026-10-27  5:37   ` sashiko-bot
2026-10-27  5:25 ` [PATCH v5 14/23] lib: rspdm: Support SPDM get_version alistair23
2026-10-27  5:41   ` sashiko-bot
2026-10-27  5:25 ` [PATCH v5 15/23] lib: rspdm: Support SPDM get_capabilities alistair23
2026-10-27  5:36   ` sashiko-bot
2026-10-27  5:25 ` [PATCH v5 16/23] rust: kernel: Add crypto hash bindings alistair23
2026-10-27  5:41   ` sashiko-bot
2026-10-27  5:25 ` [PATCH v5 17/23] lib: rspdm: Support SPDM negotiate_algorithms alistair23
2026-10-27  5:43   ` sashiko-bot
2026-10-27  5:25 ` [PATCH v5 18/23] lib: rspdm: Support SPDM get_digests alistair23
2026-10-27  5:38   ` sashiko-bot
2026-10-27  5:25 ` [PATCH v5 19/23] lib: rspdm: Support SPDM get_certificate alistair23
2026-10-27  5:35   ` sashiko-bot
2026-10-27  5:25 ` [PATCH v5 20/23] rust: public_key: Add crypto public key bindings alistair23
2026-10-27  5:41   ` sashiko-bot
2026-10-27  5:25 ` [PATCH v5 21/23] rust: x509: Add X509 certificate bindings alistair23
2026-10-27  5:45   ` sashiko-bot
2026-10-27  5:25 ` [PATCH v5 22/23] lib: rspdm: Support SPDM certificate validation alistair23
2026-10-27  5:38   ` sashiko-bot
2026-10-27  5:25 ` [PATCH v5 23/23] lib: rspdm: Support SPDM challenge alistair23
2026-10-27  5:43   ` sashiko-bot

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=DMFNE2OD18PH.27J64IS0GAJLF@kernel.org \
    --to=lossin@kernel.org \
    --cc=alistair23@gmail.com \
    --cc=gary@garyguo.net \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=ojeda@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.