Re: [RFC v3 00/27] lib: Rust implementation of SPDM

[Alistair Francis]

On Thu, Apr 9, 2026 at 1:39 PM Alistair Francis <alistair23@xxxxxxxxx> wrote:
>
> On Thu, Feb 12, 2026 at 3:56 PM <dan.j.williams@xxxxxxxxx> wrote:
> >
> > alistair23@ wrote:
> > > From: Alistair Francis <alistair.francis@xxxxxxx>
> >
> > Hi Alistair, quite a bit to digest here and details to dig into. Before
> > getting into that, I will say that at a broad strokes level, no immune
> > response to the core proposal of depending on a Rust SPDM library and
> > forgoing a C SPDM library.
> >
> > Most of that allergy relief comes from how this organizes the C to
> > Rust interactions. The core SPDM implementation calls out to C for the
> > presentation layer (Netlink) or is invoked by sysfs. That makes it
> > amenable for sharing those presentation mechanics.
> >
> > Specifically, my primary concern is integration and refactoring
> > opportunities with the PCI TSM implementation [1]. The PCI TSM case
> > should use the same uABI transport for requesting + conveying device
> > certificate chain, SPDM transcript, and device measurements as PCI CMA.
> > Note that in the TSM case the SPDM implementation is in platform
> > firmware and will bypass this library. The TSM SPDM session is mutually
> > exclusive with the CMA SPDM session.
> >
> > [1]: http://lore.kernel.org/69339e215b09f_1e0210057@dwillia2-mobl4.notmuch
> >
> > > 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.
> > >
> > > This is very similar to Lukas' implementation [2]. This series includes patches
> > > and files from Lukas' C SPDM implementation, which isn't in mainline.
> > >
> > > This is a standalone series and doesn't depend on Lukas' implementation.
> >
> > So, I *am* allergic to how this series references Lukas' work by
> > pointing to random points in his personal git tree. I trust that was
> > done for RFC purposes, but it would have helped to call that out in the
> > changelog and set expectations about the ideal path to coordinate with
> > that work.
> >
> > > To help with maintaining compatibility it's designed in a way to match Lukas'
> > > design and the state struct stores the same information, although in a Rust
> > > struct instead of the original C one.
> > >
> > > This series exposes the data to userspace via netlink, with a single sysfs
> > > atrribute to allow reauthentication.
> > >
> > > All of the patches are included in the RFC, as it depends on some patches
> > > that aren't upstream yet.
> > >
> > > Now that Rust is no longer experimental I have picked this back up. If the
> > > community is generally on board with a Rust implementation I can work on
> > > sending a non-RFC version and push towards getting that merged.
> >
> > As long as this stays explicitly designed to minimize exposure to
> > "refactor across language boundary" events (as initially seems to be the
> > case), then it seems workable.
> >
> > > The entire tree can be seen here: https://github.com/alistair23/linux/tree/alistair/spdm-rust
> > >
> > > I'm testing the netlink data by running the following
> > >
> > > ```shell
> > > cargo run -- --qemu-server response
> > >
> > > qemu-system-x86_64 \
> > >   -nic none \
> > >   -object rng-random,filename=/dev/urandom,id=rng0 \
> > >   -device virtio-rng-pci,rng=rng0 \
> > >   -drive file=deploy/images/qemux86-64/core-image-pcie-qemux86-64.rootfs.ext4,if=virtio,format=raw \
> > >   -usb -device usb-tablet -usb -device usb-kbd \
> > >   -cpu Skylake-Client \
> > >   -machine q35,i8042=off \
> > >   -smp 4 -m 2G \
> > >   -drive file=blknvme,if=none,id=mynvme,format=raw \
> > >   -device nvme,drive=mynvme,serial=deadbeef,spdm_port=2323,spdm_trans=doe \
> > >   -snapshot \
> > >   -serial mon:stdio -serial null -nographic \
> > >   -kernel deploy/images/qemux86-64/bzImage \
> > >   -append 'root=/dev/vda rw  console=ttyS0 console=ttyS1 oprofile.timer=1 tsc=reliable no_timer_check rcupdate.rcu_expedited=1 swiotlb=0 '
> > >
> > > spdm_utils identify &
> > > sleep 1
> > > echo re > /sys/devices/pci0000:00/0000:00:03.0/authenticated
> >
> > So this is where it will collide with TSM that also emits an
> > authenticated attribute. See Documentation/ABI/testing/sysfs-bus-pci.
> >
> > The rough plan Lukas and I worked out is that switching between TSM and
> > CMA based authentication would use sysfs visibility to coordinate. I.e.
> > TSM to CMA conversion hides the TSM "authenticated" attribute and
> > unhides the CMA attribute of the same name.
>
> That seems straightforward and is already documented upstream as well,
> so that's pretty easy.
>
> >
> > The most significant unsolved point of contention between TSM and CMA is
> > the policy on when authentication is mandated and the driver probe
> > policy. The proposed model for enforcing device security for
> > Confidential Computing is make it completely amenable to userspace
> > policy. Draft details here [2] to be refreshed "soon" when I send out
> > the next version of that.
> >
> > [2]: http://lore.kernel.org/20250827035259.1356758-6-dan.j.williams@xxxxxxxxx
>
> CMA will eventually need to support some sort of drive probe policy as
> well, but that can wait until later and isn't going to be dealt with
> in this series.
>
> >
> > To be clear I am ok if there is an incremental option to have auto_cma
> > and/or auto_tsm that arranges for authentication or link encryption to
> > happen without asking. I take issue with auto_cma being the only hard
> > coded option.
>
> I have been working through all of the comments and discussions and I
> think I have addressed everything, except for this one.
>
> To summerise, is the high level issue is how do we know if we should
> use CMA or TSM?
>
> Do you have any more thoughts on this?

+ Dan's Kernel.org email

Alistair