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

[Alexey Kardashevskiy <aik@amd.com>]

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

The attacker could steer the slot selection to less optimal, is that the attack?

The TSM has to pick a slot to sign GET_DIGESTS which we then want to use to pick a better slot and switch to that?

> This is also after the OS has
> told PSP what the slot is, so it can't even help do slot selection.

How is pausing going to help with the 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.

That's great, cannot agree more, but what was that recurring thing about not programming IDE keys before accepting the PF? Thanks,


> 
> Jason

-- 
Alexey