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 02, 2026 at 10:22:16AM +0000, Reshetova, Elena wrote:

> We can also simplify this further by not using GET_DIEGESTS but
> assuming TSM can return the cert chain for selected slot back to
> kernel/userspace in a trusted way. TDX does it by returning
> the cert chain (actually for all slots if asked, but it is redundant here)
> on successful SPDM.CONNECT and there is a trusted TDX Module
> provided digest covering this info.  
> 
> So, option 1 becomes like:
> 
> 1) With 1.4 match GET_DIGESTS and MULTI_KEY_CONN_RSP=true
>     1) Do via RustSPDM:
>          GET_CERTIFICATE / CERTIFICATE
>    2) Userspace selects slots
>    2a) Calculate a digest for the selected slot
>     3) TSM module does startup 
>   4) Extract cert chain (or only its digest) from info provided by TSM.
> Verify  that the digest from #2a match the digest calculated based on trusted info provided by TSM. 

See my larger email, I don't think this is how SPDM is intended to be
used, you should have a GET_DIGESTS that is covered by a signature and
included in a transcript..

I see only three options:
1) Use a single slot, so KEY_EXCHANGE includes a hash of the single
   slot cert chain
2) Use GET_DIGESTS/CHALLENGE on 1.2 followed by KEY_EXCHANGE.
   Maybe use the same nonce for both signatures so it can't be stale.
3) Use the new multi-key flow on 1.3 which already includes
   GET_DIGESTS in the transcript hashed by KEY_EXCHANGE

These all achieve the same end goal as what the 1.3 spec did, you end
up with a transcript signed by KEY_EXCHANGE that identifies all the
legal certificates.

IMHO there is no reason to deviate from this, so the uAPI should be
designed around it.

Thus I don't think TDX should fake this with a second GET_CERTIFICATES
pass inside the established session and try to skip the signed
digests..

Jason