Re: [PATCH v4 00/22] lib: Rust implementation of SPDM

From: Alistair Francis

Date: Thu Oct 15 2026 - 00:19:31 EST


On Thu, Oct 15, 2026 at 1:16 AM Alexandre Courbot <acourbot@xxxxxxxxxx> wrote:
>
> Hi Alistair,
>
> On Mon Sep 28, 2026 at 10:11 AM JST, alistair23 wrote:
> > From: Alistair Francis <alistair.francis@xxxxxxx>
> >
> > Security Protocols and Data Models (SPDM) [1] is used for authentication,
> > attestation and key exchange. SPDM is generally used over a range of
> > transports, such as PCIe, MCTP/SMBus/I3C, ATA, SCSI, NVMe or TCP.
> >
> > From the kernels perspective SPDM is used to authenticate and attest devices.
> > In this threat model a device is considered untrusted until it can be verified
> > by the kernel and userspace using SPDM. As such SPDM data is untrusted data
> > that can be mallicious.
> >
> > The SPDM specification is also complex, with the 1.2.1 spec being almost 200
> > pages and the 1.3.0 spec being almost 250 pages long.
> >
> > As such we have the kernel parsing untrusted responses from a complex
> > specification, which sounds like a possible exploit vector. This is the type
> > of place where Rust excels!
> >
> > This series implements a SPDM requester in Rust.
>
> A few high-level comments/questions about this series:

Thanks for the review!

>
> - Have you tried building it with `CLIPPY=1` as per the checklist [1]? I
> am getting dozen of Clippy warnings about unused imports, unused
> constants, missing safety comments, and style issues. Series are
> expected to be Clippy-clean when submitted.

I have been, but apparently running

```
CLIPPY=1 LLVM=1 make -j32
```
doesn't trigger clippy while

```
LLVM=1 make CLIPPY=1 -j32
```

does. I have fixed the clippy issues

> - Most of the C parts have received more attention than the Rust ones so
> far, if they are meaningful on their own can they be merged separately
> so this series can focus on the Rust bits and the C FFI?

Not really unfortunately. A few could be pulled out and merged today,
but there isn't much movement there

> - I see many unsafe calls to C crypto functions in e.g. patch 17, these
> will need to have their own Rust wrapper so they can be called safely.

Yeah, the crypto calls all use unsafe as there aren't bindings written.

This came up at Kangrejos and I thought the takeaway that this was ok
as a starting point. My next step is to work on PQC and crypto
bindings, but I was hoping to split it out of this series, as it's
already long and touching a few subsystems.

>
> I am not familiar with SPDM yet so I cannot comment on the
> protocol-specific parts, but I'll try to perform a review on the Rust
> bits. For this revision it won't be exhaustive as there are a few
> critical things to fix before considering the rest.

Thanks. I have fixed up your comments and have a few fixes I have
found. I'll get a v5 out soon

Alistair

>
> [1] https://rust-for-linux.com/contributing#submit-checklist-addendum