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

[Jonathan Cameron]

On Mon, 9 Mar 2026 09:31:48 -0300
Jason Gunthorpe <jgg@xxxxxxxxxx> wrote:

> On Mon, Mar 09, 2026 at 11:39:41AM +0000, Jonathan Cameron wrote:
> 
> > Anyhow, all that really says is I'd like the internal consistency of
> > the SPDM session checking in now.  Leave checking we actually trust
> > the cert + measurements to user space (and all the stuff below
> > on recovery comes later).  
> 
> I think kernel doing internal consistency (non policy) checks is fine
> 
> We just need to be careful to construct things so it is compatible
> with an external verifier. Even in this bare SPDM mode we still want
> to hook it into external verification.
> 
> I don't know alot, but I understand this requires the nonce (?) to
> come from userspace? 

Going out of my area of expertise... So take the following with a pinch
of salt.

Yes to userspace provided nonce. My understanding is that can come
from the verifier that wants to ensure freshness.

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?

> 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?

>  - Kernel checks the signature against the public key and confirms the
>    CSPRNG and nonce are correct (only kernel can do this since the
>    CSPRNG must not leak out of the kernel)
>  - Kernel forwards the signature from the peer to userspace and
>    userspace re-checks the signature against the public key and
>    validates the nonce is the one it issued, and checks that the
>    public key is acceptable. Ignores the CSPRNG data.
>  - Presumably in a real TSM there will be a merkle tree signed by the
>    TSM's platform key that binds together all the TVM measurements and
>    the SPDM activity so the verifier can see a complete picture?
> 
>    ie that the verifier pushed nonce A authenticated SPDM session B
>    which is part of PCI device C that is part of TVM D.
> 
>    Should kernel be extending TPM PCRs or something in this bare SPDM
>    mode to provide something similar using the TPM to produce
>    platform evidence?
> 
> 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 ;)

Jonathan



> 
> Jason