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, Oct 30, 2026 at 09:58:03AM +0000, Reshetova, Elena wrote:
> > > It can't defer the session. The TDX Module runs the whole SPDM
> > > session setup inside TDH.SPDM.CONNECT, and the host relays its DOE
> > > messages without interpreting them, so there is no defined point to
> > > stop after the certificates. The chains come back in the device info
> > > only once TDH.SPDM.CONNECT completes (TDX Connect ABI Reference Spec
> > > 2.1 v0.66, 4.2.20.1).
> > 
> > Yeah, its fine. TDX will have to do what Aneesh proposed for ARM, and
> > use use the Rust SPDM Driver to operate DOE prior to calling
> > TDH.SPDM.CONNECT. This will allow discovering what is in the slots and
> > passing that information to userspace.
> 
> I am somewhat confused by this. 
> 
> 1. You are saying that prior to establishing a
> secure SPDM session, you will use unsecure DOE mechanism to discover
> available cert chains. Here you have to take into account that anything you
> get at this step is not trusted. A malicious device could send you any cert
> chains from another legitimate device.

I poked at this with AI for a while.. While nothing about SPDM slots seems
particularly clean it can be made to work. It looks like 1.4 improves
things meaningfully.

> 2. Next, you will choose a cert slot to be used for SPDM authentication and
> secure session establishment (slot 0 initially in this patch) and allow
> everything to happen.

Yep

> Now, who guarantees that a cert chain that you saw
> at step 1 for the selected slot is the same that is going to be used
> in actual SPDM connection? Who is verifying/ensuring this?
> Kernel? Userspace? 

Not sure, it would make sense if the kernel can do some of this with
rustspdm, but there are alot of details here that I can't guess what
is best.

AI tells me there are a couple of reasonable ways to implement slot
selection and avoid downgrade attacks:

1) With 1.4 match GET_DIGESTS and MULTI_KEY_CONN_RSP=true
   1) Do via RustSPDM:
        GET_DIGESTS / DIGESTS
        GET_CERTIFICATE / CERTIFICATE
   2) Userspace selects slots
   3) TSM module does startup and also issues 'GET_DIGESTS' as part of
      the signed transcript
   4) Confirm that the digests from #1 match the digests from #2 in
      the TSM transcript.

2) Do slot selection and use CHALLENGE to prevent downgrade attacks.
   1) Do via RustSPDM:
        GET_DIGESTS / DIGESTS
        GET_CERTIFICATE / CERTIFICATE
        CHALLENGE / CHALLENGE_AUTH (using slot 0)
   3) Kernel RustSPDM can check that CHALENGE_AUTH is self consistent
   2) Supply the certificates to userspace
   3) Userspace choose a slot
   4) TSM does KEY_EXCHANGE
   5) Confirm the certificate of the selected slot signs the
      transcript from TSM
   6) Verifier confirms that the #1 transcript is acceptable

   I think this is weaker than #1, but not that much..

3) Do slot selection without CHALLENGE and then do it again after
   establishing the session to confirm nothing has changed.
   
   Requires TSM to be able to return slots after opening the session,
   CCA can't at least.

It may be we simply don't securely support multi-slot until 1.4 spec
support in TSMs. Per 1.2 can be flagged as less secure in the API or
something?

Jason