Re: [RFC PATCH v1 10/11] virt: coco: arm-cca-host: Publish slot zero and establish streams after acceptance

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Nov 10, 2026 at 04:32:34PM +1100, Alexey Kardashevskiy wrote:
> > My AI predicts 1000-2000 lines of code very careful spec derived code
> > just to remove this padding. Such a big spec mistake.
> 
> Out of curiosity - why that many? There is only a handful of SPDM
> messages and secure SPDM has the size in the header.

It sounds like there are alot of options. Since nothing is sized in
the message you have to parse the negotiated algorithms and spec
version to figure out how big each crypto field is and manually sum
everything up.

IDK I thought it was alot too, but it is just an estimate.

> > 1) I think this removes alot of code from the TSM drivers. All this
> >     stuff they have to go back and get the data after the fact, or the
> >     thing that is almost like this in RMM, goes away. The TSM drivers
> >     are very slim, just run their communicate loops.
> 
> It is already like this pretty much, is not it? Well, on AMD.

Not quite, AMD doesn't have any way to return the session transcript
to userspace, and it hides VCA under it's get measurements thing. It
only looks simple because these issues haven't been addressed.

In terms of presenting a consistent uAPI for SPDM AMD is the furthest
away from the rest and probably the best reason to do this design
since it would bring it into alignment.

> > 2) Clear uniform path to 1.3, stop after GET_DIGESTS, let userspace
> >     inspect the certificates, continue with the slot. Again drivers can
> >     be super simple, just need to pause at the right point in the
> >     sequence.
> 
> 
> The AMD PSP calls SPDM_DIGESTS first, then SPDM_CERTIFICATE (just
> like the PCIe spec depicts). May be stop at SPDM_KEY_EXCHANGE_RSP?

That's wasteful too, GET_DIGESTS before KEY_EXCHANGE isn't signed so
it can't really be used for anything. This is also after the OS has
told PSP what the slot is, so it can't even help do slot selection.
 
> > 3) The data collected and presented to userspace is perfectly uniform
> >     governed only by the SPDM specification. There is a clear path to
> >     adopt newer versions in the kernel with in-kernel SPDM that
> >     instantly with nearly no-code works with all the TSM drivers.
> > 4) This is about half of in-kernel SPDM, the receive buffer
> >     reassembly, certificate chain reassembly, x509, padding stripping.
> >     Each a complicated topic on its own. We always imagined having
> >     in-kernel SPDM, so I view this as effectively free code - contigent
> >     on organizing the in-kernel SPDM implementation in a properly
> >     modular way.
> > 5) Without AI this looks actually fairly scary. I can see why people
> >     wanted to avoid it with different schemes to have the TSM do some
> >     of the work. Yet we planned to do it anyhow for in-kernel SPDM so..
> > 6) With AI this is probably a weeks work I suppose to really expertly
> >     polish and make excellent tests.
> > 7) There is clear overlap with Alistair's work, I don't have a sense
> >     right now how close some of the parts in that series are to fitting
> >     this shape.
> 
> You want the above just to prevent IDE keys from being programmed
> into the device before accepting the device in the host os, or there
> is more to it?

I want a consistent uAPI that is 100% the same for all four
implementations. I do not want ARM to show the VCA before measurements
in a transcript and AMD to hide the VCA in an AMD specific measurement
blob - for example.

I want a uAPI where the user cannot tell the difference between the
four backends. When they operate the same PCIe device they all give
exactly the same uAPI experiance.

Jason