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

[Alistair <alistair23@gmail.com>]

On 10/11/26 04:53, Jason Gunthorpe wrote:
> 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.

Jason just pointed out this thread, I've tried to pickup what the 
discussion is currently up to, hopefully I've understood it all.

It sounds like the current thinking is the TSM will issue all of the 
SPDM requests and be in control of the session. The kernel will forward 
those requests to the device and Rust SPDM in the kernel will be used to 
decode the responses.

The TSM will be in charge of slot selection, bank selection and 
algorithm support.

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

The current Rust SPM implementation has split out the message 
processing, so that should be somewhat easy to reuse. Basically (in 
Rust) you pass in the bytes of an SPDM response, specify what the reply 
is (CHALLENGE_RSP) and you get a nice destructed struct back (or an 
error if it's invalid). It's all called the Validator as it validates 
Untrusted data and returns an SPDM response.

One issue though, is that the Validator expects to be passed the SPDM 
Context struct. It uses this as part of the validation. For example the 
Validator will check the `context.version` negotiated to make sure it 
matches the response. Things like that. So some state is expected.

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

The Rust SPDM code is hopefully really close! I'm planning on sending v6 
today or tomorrow. The last remaining issue is just getting the Rust 
bindings all sorted. If there is a big push for it to be merged we might 
be able to speed things up.

Note it doesn't support MULTI_KEY or PQC yet though.

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

Yep, no length information. You have to decode the entire packet...

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

Maybe for PQC, but generally this doesn't seem to come up much with DOE. 
So for now it should be fine.

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

The kernel patches support 1.0 - 1.4, so that should be fine.

The issue will be the capabilities (like MULTI_KEY) that aren't 
supported, yet.

One other thing, the current Rust kernel code assumes it's issuing the 
requests, so if a responder uses a capability we don't support, that's 
an error. If the TSM is issuing the requests then we will want to be a 
little more graceful in handling capabilities. Not too hard, just 
something to do.

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

That's mostly what the current patches implement as well, so once merged 
you should get most of that working (see the above points)

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

That might require some changes, but I don't think is impossible.

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

Again, see above

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

I would argue that you would be better spending that effort on making 
changes to the Rust code and re-use that. That at least would make sure 
it can be adjusted to do what you want and would be more useful :)

Alistair

> 
> Jason