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 Fri, Nov 06, 2026 at 08:53:39AM -0700, Dave Jiang wrote:
> 
> 
> On 11/4/26 9:54 AM, Dave Jiang wrote:
> > 
> > 
> > On 11/4/26 6:41 AM, Jason Gunthorpe wrote:
> > <--snip-->
> > 
> >> Is there a PDF for TDX's SPDM flow someplace? I will try to draft a
> >> more complete document
> > 
> > TDX connect architecture spec
> > https://cdrdv2-public.intel.com/862706/Intel%20TDX%20Connect%20EAS%20354629%20004.pdf
> > 2.7.5 Figure 2.6
> > 
> > TDX connect TEE-IO device guide
> > https://cdrdv2-public.intel.com/861654/whitepaper-tee-io-device-guide-v0-7-0.pdf
> > Appendix B.1.1 Table B-1
> 
> I generated a diagram that hopefully better reflects Option A with TDX better than the current public documentations:
> 
> Option (a) on TDX, with the current TDX Connect ABI: slot 0 only, no TDX
> change. Numbers in the left margin point to the notes below.
> 
>   ---->   call                 <- - -   return
>   <---->  SPDM request and response in clear text, relayed by the host
>   <====>  the same, inside the SPDM session

It looks OK, thanks.

I have a few thoughts

1) I would very much like it if the core SPDM code in the kernel
   can snoop the DOE messages from the TSM. If we do this then the
   kernel can directly capture the full transcript:

> (4)  |                    |                       | GET_VERSION            |
>      |                    |                       |<---------------------->|
>      |                    |                       | GET_CAPABILITIES       |
>      |                    |                       |<---------------------->|
>      |                    |                       | NEGOTIATE_ALGORITHMS   |
>      |                    |                       |<---------------------->|
>      |                    |                       | GET_CERTIFICATE slot 0 |
>      |                    |                       |<---------------------->|
> (5)  |                    |                       | KEY_EXCHANGE slot 0    |

With perfect consistency on all vendors.

Further, it will also be able to capture the GET_CERTIFICATE during
the preamble so again we get greater consistency for everyone.

I'm very interested in this because it frees the uABI from any
variation in choices the TSM may have made. I have the full perfect
transcript in the kernel and I will ALWAYS present the same uABI to
userspace regardless what the TSM offers.

Like a whole bunch of TSM FW API just to do this:

> === Step 4: query certificates, query final transcript items ===============
>      |                    |                       |                        |
>      | query certificates |                       |                        |
>      |------------------->|                       |                        |
>      |                    |                       |                        |
>      | slot 0's chain     |                       |                        |
>      |<- - - - - - - - - -|                       |                        |
>      |                    |                       |                        |
>      | query transcript   |                       |                        |
>      |------------------->|                       |                        |
>      |                    |                       |                        |
> (6)  | device info        |                       |                        |
>      |<- - - - - - - - - -|                       |                        |
>      |                    |                       |                        |

Seems pointless to me, and could cause uABI variations I don't like.

What do you think? Am I off my rocker? At least AI says it looks OK
(always optimistic!). Undoing the chunking is annoying.

This is close to what ARM did with CCA, it seems very smart, but they
seem to have provided some help to the OS to locate the bytes in the
messages, but I assume with some work (and we have Rust SPDM) Linux
can decode them autonomously?

This would really slim down the TSM drivers since core code would
build up all the SPDM data and the drivers just need to do the
communicate loop and little else.

2) I do not like the idea to refetch certificates:

>      | nonce              |                       |                        |
>      |------------------->|                       |                        |
>      |                    |                       |                        |
> (7)  |                    | TDH.SPDM.MNG(nonce)   |                        |
>      |                    |---------------------->|                        |
>      |                    |                       |                        |
>      |                    |                       | GET_CERTIFICATE        |
>      |                    |                       |<======================>|
>      |                    |                       | GET_MEASUREMENTS       |
>      |                    |                       |<======================>|
>      |                    |                       |                        |
>      |                    | new device info       |                        |
>      |                    |<- - - - - - - - - - - |                        |
>      |                    |                       |                        |
>      | one-shot result    |                       |                        |
>      |<- - - - - - - - - -|                       |                        |

That's just asking for trouble. Our general security statement is the
kernel & TSM validates a signature over the certificates to verify
their authenticity in the HW. Re-fetching defeats the whole point of
this if the responder can supply something that differs from
GET_DIGESTS. If it can't differ then it was a waste of time since we
already have it.

Further it wrecks the point of the transcript and the 1.3 multikey
signed GET_DIGESTS.

If you *really* want to do certificate refresh it has to be a
dedicated operation, it has to be supported by the TSM, and it has to
get back another SIGNED GET_DIGESTS. All that would ideally have to be
dumped into the transcript again.

I feel it is alot of work and not valuable.

I generally feel a 2nd measurement is not a valuable activity in the
first place. There is one meaningful security measurement. At boot,
before DMA is allowed. It must be logged into a measurement register
and then after you turn on DMA the device can replace every byte of
software on the system. (hello ATS). Only the logged measurement can be
relied on for security, any post-DMA measurement can be fradulent.

It is OK for auditing, but not for security, so why would you even
look at the certificate chain for audit? For auditing you should check
that the PUBKEY is stable.

I think any device that can loose its private key while an SPDM
session is open (ie with live update or something) is fundamentally
broken. If it wants to do this it has to break the SPDM.

3) Obviously TDX and everyone else will need a 1.3 multi-key upgrade
   I think they all look the same. I would like us to settle on this
   API here and then we can describe what a perfect TSM would look
   like and people can go write their specs for it.

> Notes:
> (1) Creates the attestation endpoint only; no TSM call.
> (2) TDH.SPDM.CONNECT has no KEY_EXCHANGE slot input.
>     CERTIFICATE_SLOT_MASK, the only slot field in SPDM_CONFIG_INFO_T, is
>     the "Device certificate request slot mask" [ABI 3.3.2.2]: it picks
>     which chains to read, not the slot. So userspace can't enumerate
>     slots by repeating step 3.

Boo

> (3) TDH.SPDM.CREATE runs first. The kernel sets CERTIFICATE_SLOT_MASK to
>     0x01, so the TSM reads only slot 0's chain. It could also read slots
>     1-7 inside the session [GUIDE B.1.1, Table B-1], but no signature
>     would cover them: KEY_EXCHANGE hashes only the chain of the slot it
>     names [SPDM 10.18.1]. So (a) doesn't report them.

? this is confusing. KEY_EXCHANGE slot=0 includes the hash of the
certificate chain in slot 0. If the TSM doesn't even read that slot
during the premable it is impossible to validate the KEY_EXCHANGE.

What prupose is there for this configurable "the kernel sets
CERTIFICATE_SLOT_MASK to 0x01" ? If the kernel sets for slot 1 then
KEY_EXCHANGE must fail?

> (4) The host relays each message over DOE [ABI 3.3.3, 4.2.20]. No
>     GET_DIGESTS and no CHALLENGE [ARCH 2.7.5, Figure 2.6]. The guide's
>     session setup example also reads slot 0's chain before KEY_EXCHANGE
>     [GUIDE B.1.1, Table B-1].

Yes, you have to because it is necessary to do this:

> (5) The TSM verifies the KEY_EXCHANGE_RSP signature [SPDM para 630]. The
>     host trusts that check, so it keeps no KEY_EXCHANGE messages.

Yes, but if we do #1 above I would keep it anyhow and optionally give
it to the verifier. I agree it is fairly pointless, but it is really
cheap to do if you have #1 and simply capturing the *entire* signed
transcript is forward looking from an ABI design perspective.

It might even be useful if we want to use
GET_DIGEST/CHALLENGE/KEY_EXCHANGE as the sequence to support
multi-slot.

If people start adding more messages in later spec revs it simply
flows through with no ABI change as additional transcript meassages.

> (7) DEV_INFO_RECOLLECTION puts the caller's nonce in GET_MEASUREMENTS
>     [ABI 3.3.2.3], and the TSM reads the chains again
>     [GUIDE B.1.5, Table B-5]. The device signs the new measurement log,
>     nonce included [SPDM 10.12.3]. That signature is what protects the
>     new measurements. The verifier must check it with the leaf key of
>     slot 0, the slot KEY_EXCHANGE used, and must find its nonce in the
>     log to know the result is fresh. The kernel hands the result over
>     once and doesn't store it.

Yes, but in 1.2 there is only one private key so the slot doesn't
matter. There is no reason to re-read the chains. Kernel would throw
that information away, it already has a signed copy that it got at the
start.

Jason