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

[Jason Gunthorpe <jgg@nvidia.com>]

On Mon, Mar 09, 2026 at 03:33:39PM +0000, Jonathan Cameron wrote:

> I'm not sure exactly what our security model is in the native CMA case,
> so what software we can trust on the host. I.e. does the DH session actually
> need to be between the kernel and the peer?

Yes, absolutely a DH session is required in all cases, it is the only
way to generate a PCI encryption shared secret and exclude a MIM.

For native the verifer should be able to measure the running kernel
using the TPM, and then confirm the measured kernel and the peer have
established a MIM free PCIe encryption, and finally measure the peer
device.

For instance, imagine an enhanced version of "Network-Bound Disk
Encryption" where the storage key is not released unless the server
also validates PCI properties (physically encrypted with no MIM, right
devices, etc)

> > I suppose the flow is the usual crypto something
> > like
> >  - Kernel negotiates a DH session/CSPRNG with the peer, generates
> >    symmetric keys from the CSPRNG 
> >  - Kernel forwards a nonce challenge and peer signs it, somehow mixing in
> >    CSPRNG data to bind to the DH session
> 
> We have a small amount of context (8 bytes) that we can put anything as
> part of challenge/auth (alongside the nonce) It will part of the signed
> response. Would that work for something from with the CSPRNG,
> mixed so that you can't go from that context to the CSPRNG value?

I assume SPDM is doing this already somehow otherwise there is no way
to setup the PCI encryption keys. The fundamental purpose of the
signature is to exclude a MIM by signing something that proves there
is no MIM, and that is usually a value that both sides independently
pull out of the CSPRNG. If they derive the same value then they have
the same CSPRNG and DH tells us nobody else can have it. But there are
other approaches too..

> > Of course all of this should try to align with the way TSMs are
> > working so we have as uniform as possible uAPI for evidence transfer.
> > Though obviously a kernel SPDM has to be distinguisable from any other
> > TSM from a verifier POV.
> 
> Agreed. Very interesting to know what exactly is going in the TSM
> SPDM exchanges as hopefully that will reflect best practice. If we
> are really lucky they won't all do different things ;)

Yeah, and I don't really know the details, just have some general idea
how attestation and PCI link encryption should work in broad strokes.

But I know people who do, so if we can get a series that clearly lays
out the proposed kernel flow I can possibly get someone to compare
it..

The baseline I expect is a merkle tree signed by the root of trust
(TPM or platform TSM) that encompases everything down to the required
bits of the SPDM negotiation to prove no MIM.

Jason