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

[dan.j.williams]

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.

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

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.