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

[Jonathan Cameron]

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

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

Ah. I was missing what you wanted with the DH part. For some reason wasn't
thinking about IDE (maybe because this patch set doesn't get you there for
native). Though as I understand it some of the native usecases for CMA aren't
using link encryption (different security model from CoCo).

Yes, if you want to avoid MIM you need to bring up IDE etc - the basic fact
that both ends can still talk to each other after enabling it given they have
to have the same keys and those went over the secure channel, is part of the
security around that. I think you can attest before that point and rely on
the link 'failing' if there was a man in the middle. The verifier would
want the evidence IDE was up before giving you any secrets.

Whether anyone actually implements root ports via standard DOE flows or
everyone does this a custom way at the host is an open question.
There are various mix and match situations where the Coco / TSM flows
mean we have an encrypted channel, but we are doing our own native
attestation (to a different DOE, say on a VF).  Anyhow, others on this thread
have more info (I think) on the corner cases of how this is going to be
used than I do.

The secure channel establishment and key exchange comes later in the SPDM
flow than this patch set currently covers. This bit just gets you to the
point where you know you are ultimately talking to right device - you don't
know there isn't a MIM at this point.

Next up is KEY_EXCHANGE / KEY_EXCHANGE_RSP / FINISH / FINISH_RSP that will
exchange the public ephemeral keys and ultimately get us a secure channel.
Then we then switch to secured-CMA which is the PCIe spec and is basically the
format for wrapping up the session IDs etc + the encrypted channel.
Lukas' github has the next few bits required, but not sure he's all the
way there yet?

That then gets used for key exchange messages related to IDE via the PCI
spec defined IDE_KM protocol. (which is fairly simple compared to the other
steps - only about 8 pages :)).

So we may need to get a bit further before we can do the attestation
flow that would be equivalent to what CoCo needs.  I'm thinking
we may need one more set of measurements to verify both ends think
IDE is up.

For now the host will know it didn't bring up IDE.

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

For SPDM it's this or pre shared key stuff which requires some out of
band way path. So probably ignore that.

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

Agreed, that's my basic undestanding as well and likewise, can get
some appropriate folk to check it out once we have the full thing described.

Jonathan

> 
> Jason
>