From: Alistair Francis <alistair23@gmail.com>
To: Dirk Behme <dirk.behme@de.bosch.com>
Cc: alistair@alistair23.me, linux-kernel@vger.kernel.org,
lukas@wunner.de, Jonathan.Cameron@huawei.com,
bhelgaas@google.com, rust-for-linux@vger.kernel.org,
akpm@linux-foundation.org, linux-cxl@vger.kernel.org,
djbw@kernel.org, linux-pci@vger.kernel.org,
alex.gaynor@gmail.com, wilfred.mallawa@wdc.com,
gary@garyguo.net, bjorn3_gh@protonmail.com,
benno.lossin@proton.me, aliceryhl@google.com,
boqun.feng@gmail.com, a.hindborg@kernel.org, tmgross@umich.edu,
ojeda@kernel.org, Simona Vetter <simona.vetter@ffwll.ch>
Subject: Re: [PATCH 01/18] rust: add untrusted data abstraction
Date: Fri, 15 May 2026 15:49:45 +1000 [thread overview]
Message-ID: <CAKmqyKO+Pzj_z_r_tmVCuTt4gacrF9M74WknciGCbHGyBn5L=A@mail.gmail.com> (raw)
In-Reply-To: <73b1ecdf-8754-4c17-88af-671246a6787d@de.bosch.com>
On Fri, May 8, 2026 at 3:18 PM Dirk Behme <dirk.behme@de.bosch.com> wrote:
>
> Hi Alistair,
>
> On 08.05.2026 05:16, alistair23@gmail.com wrote:
> > From: Benno Lossin <benno.lossin@proton.me>
> >
> > When reading data from userspace, hardware or other external untrusted
> > sources, the data must be validated before it is used for logic within
> > the kernel. This abstraction provides a generic newtype wrapper
> > `Untrusted`; it prevents direct access to the inner type. The only way
> > to use the underlying data is to call `.validate()` on such a value.
> >
> > Doing so utilizes the new `Validate` trait that is responsible for all
> > of the validation logic. This trait gives access to the inner value of
> > `Untrusted` by means of another newtype wrapper `Unvalidated`. In
> > contrast to `Untrusted`, `Unvalidated` allows direct access and
> > additionally provides several helper functions for slices.
> >
> > Having these two different newtype wrappers is an idea from Simona
> > Vetter. It has several benefits: it fully prevents safe access to the
> > underlying value of `Untrusted` without going through the `Validate`
> > API. Additionally, it allows one to grep for validation logic by simply
> > looking for `Unvalidated<`.
> >
> > Any API that reads data from an untrusted source should return
> > `Untrusted<T>` where `T` is the type of the underlying untrusted data.
> > This generic allows other abstractions to return their custom type
> > wrapped by `Untrusted`, signaling to the caller that the data must be
> > validated before use. This allows those abstractions to be used both in
> > a trusted and untrusted manner, increasing their generality.
> > Additionally, using the arbitrary self types feature, APIs can be
> > designed to explicitly read untrusted data:
> >
> > impl MyCustomDataSource {
> > pub fn read(self: &Untrusted<Self>) -> &Untrusted<[u8]>;
> > }
> >
> > Cc: Simona Vetter <simona.vetter@ffwll.ch>
> > Signed-off-by: Benno Lossin <benno.lossin@proton.me>
> > Message-ID: <20240925205244.873020-2-benno.lossin@proton.me>
>
>
> Today, randomly, I was about to ask Benno if there are any plans to
> continue with his great untrusted work. Just to find that you are
> carrying this forward. Many thanks!
>
> While trying to figure out some history of this patch, it looks to me
> that the version you are using is Benno's v2:
>
> https://lore.kernel.org/rust-for-linux/20240925205244.873020-2-benno.lossin@proton.me/
>
> ?
>
> While the latest version from Benno I found is a v4:
>
> https://lore.kernel.org/rust-for-linux/20250814124424.516191-3-lossin@kernel.org/
>
> Is there any reason not to use that?
Nope, there isn't, I just didn't know it existed. I have updated to
using the v4 submission
>
> While at this, do you have any plan to add the `Validate` trait as well?
>
> https://lore.kernel.org/rust-for-linux/20250814124424.516191-4-lossin@kernel.org/
I am using the `Validate` trait, so yes :) I have pulled in patched 1,
2 and 3 from the v4 series.
>
> Thanks
>
> Dirk
>
> P.S.: Carrying this patch forward, please check if it needs an update
> regarding new "rules". E.g. it looks to me that there should be an
> update regarding the vertical style for imports?
>
> https://docs.kernel.org/rust/coding-guidelines.html#imports
Thanks, I have fixed that up.
Alistair
next prev parent reply other threads:[~2026-05-15 5:50 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-08 3:16 [PATCH 00/18] lib: Rust implementation of SPDM alistair23
2026-05-08 3:16 ` [PATCH 01/18] rust: add untrusted data abstraction alistair23
2026-05-08 3:52 ` sashiko-bot
2026-05-08 5:17 ` Dirk Behme
2026-05-15 5:49 ` Alistair Francis [this message]
2026-05-08 3:16 ` [PATCH 02/18] X.509: Make certificate parser public alistair23
2026-05-08 3:45 ` sashiko-bot
2026-05-14 7:22 ` Lukas Wunner
2026-05-08 3:16 ` [PATCH 03/18] X.509: Parse Subject Alternative Name in certificates alistair23
2026-05-08 3:16 ` [PATCH 04/18] X.509: Move certificate length retrieval into new helper alistair23
2026-05-08 3:39 ` sashiko-bot
2026-05-14 6:59 ` Lukas Wunner
2026-05-08 3:16 ` [PATCH 05/18] rust: add bindings for hash.h alistair23
2026-05-08 3:43 ` sashiko-bot
2026-05-08 3:16 ` [PATCH 06/18] rust: error: impl From<FromBytesWithNulError> for Kernel Error alistair23
2026-05-08 3:51 ` sashiko-bot
2026-05-08 3:16 ` [PATCH 07/18] lib: rspdm: Initial commit of Rust SPDM alistair23
2026-05-08 3:41 ` sashiko-bot
2026-05-08 3:17 ` [PATCH 08/18] PCI/TSM: Support connecting to PCIe CMA devices alistair23
2026-05-20 5:56 ` Alistair Francis
2026-06-18 2:04 ` Alistair Francis
2026-06-18 22:51 ` Dan Williams (nvidia)
2026-05-08 3:17 ` [PATCH 09/18] PCI/CMA: Add a PCI TSM CMA driver using SPDM alistair23
2026-05-08 5:02 ` sashiko-bot
2026-05-08 3:17 ` [PATCH 10/18] PCI/CMA: Validate Subject Alternative Name in certificates alistair23
2026-05-08 3:58 ` sashiko-bot
2026-05-14 2:45 ` Alistair Francis
2026-05-14 13:14 ` Lukas Wunner
2026-05-08 3:17 ` [PATCH 11/18] lib: rspdm: Support SPDM get_version alistair23
2026-05-08 3:50 ` sashiko-bot
2026-05-08 3:17 ` [PATCH 12/18] lib: rspdm: Support SPDM get_capabilities alistair23
2026-05-08 4:05 ` sashiko-bot
2026-05-08 3:17 ` [PATCH 13/18] lib: rspdm: Support SPDM negotiate_algorithms alistair23
2026-05-08 4:05 ` sashiko-bot
2026-05-08 3:17 ` [PATCH 14/18] lib: rspdm: Support SPDM get_digests alistair23
2026-05-08 4:06 ` sashiko-bot
2026-05-08 3:17 ` [PATCH 15/18] lib: rspdm: Support SPDM get_certificate alistair23
2026-05-08 4:23 ` sashiko-bot
2026-05-08 3:17 ` [PATCH 16/18] lib: rspdm: Support SPDM certificate validation alistair23
2026-05-08 4:25 ` sashiko-bot
2026-05-08 3:17 ` [PATCH 17/18] rust: allow extracting the buffer from a CString alistair23
2026-05-08 3:17 ` [PATCH 18/18] lib: rspdm: Support SPDM challenge alistair23
2026-05-08 4:19 ` sashiko-bot
2026-05-17 8:09 ` Dirk Behme
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='CAKmqyKO+Pzj_z_r_tmVCuTt4gacrF9M74WknciGCbHGyBn5L=A@mail.gmail.com' \
--to=alistair23@gmail.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@alistair23.me \
--cc=benno.lossin@proton.me \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dirk.behme@de.bosch.com \
--cc=djbw@kernel.org \
--cc=gary@garyguo.net \
--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=simona.vetter@ffwll.ch \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).