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 Mon, Nov 09, 2026 at 10:37:14AM -0700, Dave Jiang wrote:

> One thing on TDX is that TDH.SPDM.CONNECT also runs a
> GET_MEASUREMENTS of its own during the connect, and the kernel
> doesn't choose its nonce. The kernel wouldn't hand that one to
> userspace. Measurements only come out through the two flows, with a
> user nonce.

Why? Seems like another wasted operation..

> That works for TDX. tdx-host's relay is one function today. It takes
> the module's request from a page shared with the module and calls
> pci_tsm_doe_transfer(), so att_spdm_doe_exchange() drops in there.

Yeah, it looks like it works for everyone.

I sketched out this library, and it is basically half or more of the
in-kernel SPDM in just a different form. Basically all the reply
message processing and de-framing abstracted into something a little
different.

So in terms of *net* code needed it seems like very little

But it brings forward "rust spdm" or something in a new form as a
pre-condition to do the TSMs. Which is annoying for sure.

> I tried a quick version of the capture in a test hack with the TDX
> Module It rebuilt the VCA, slot 0's chain and
> KEY_EXCHANGE/KEY_EXCHANGE_RSP from the relayed messages, and the
> kernel's own check of the KEY_EXCHANGE_RSP signature passed. Agreed
> it's more of a debugging aid. Two things I encountered:

So you (AI'd?) something basic up to do the captures and showed that
indeed the right data comes through and the general notion is OK?

That's great, it matches what all the analysis points to. I could find
no blocking issue on this idea.

> - The DOE payloads carry dword padding, so the capture has to trim
>   each message to its SPDM length before hashing. KEY_EXCHANGE was
>   160 bytes as a DOE payload and 158 as an SPDM message.

Yeah, I couldn't belive it when my AI pointed to this. Nobody thought
to preserve an actual length so any SPDM over DOE implementation needs
to be very, very painfully calculate a length from the message content
and algorith negotiation.

My AI predicts 1000-2000 lines of code very careful spec derived code
just to remove this padding. Such a big spec mistake.

> - The chain hash in the KEY_EXCHANGE_RSP transcript is over the
>   whole SPDM chain structure (length, reserved, root hash,
>   certificates), not just the DER certificates. That's how the
>   device and the TDX Module compute it.

Definitely, it would need to capture the certificate stuff in just the
right way.

The optional chunking features are a bit tricky, but I don't think a
1.2 only implementation needs them. They seem necesary for future
post-quantum.

This also formalizes the version locking: the TSM FW cannot use a SPDM
version that the kernel does not understand. I think this was already
basically true, trying to do the 1.3 multi-slot flow is not going to
work out with out kernel support to move the additional data. Maybe
nobody noticed, but with this scheme it would be really formal.

In practice this means all the TSMs will need the kernel to tell it
what SPDM versions it can go up to.

So I'm a little bit stuck here. Some thoughts:

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

I will look more closely at Alistair's series to see how close it is
already.

But, I am strongly tempted to make a draft placeholder in C with AI as
a way to get alignment and try it out. Something we can throw out if a
Rust version comes along.

Jason