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

[Jason Gunthorpe <jgg@nvidia.com>]

On Mon, Mar 09, 2026 at 06:00:54PM +0000, Jonathan Cameron wrote:
> On Mon, 9 Mar 2026 12:59:09 -0300
> Jason Gunthorpe <jgg@nvidia.com> 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).

Yeah, there are models where you could collect evidence and not have
any IDE setup where you have greater trust in physical security.

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

No.. With DH systems something can sit in the middle and
encrypt/decrypt and you can't detect that unless you sign something
derived from the DH the other side can validate.

> Whether anyone actually implements root ports via standard DOE flows or
> everyone does this a custom way at the host is an open question.

I'm expecting Linux will be able to setup Link IDE, either through a
platform TSM as you say, or through someone plugging in the IDE
registers into some Linux drivers.. I certainly don't want to close
that door by bad uAPI design.

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

Hmm, like I said I don't really know the flow, but something has to
bind the DH into the evidence for it to be useful, if that comes after
(seems backwards, but OK) then as long as the evidence reporting and
controlling uAPI is happy with all these different flows OK..

Jason