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 Wed, Nov 04, 2026 at 09:49:25AM +0000, Reshetova, Elena wrote:
> > > We will need some multi-step sequence from the uABI perspective:
> > >
> > > 1) CTLV command START CONNECT:
> > >     TSM does:
> > >      GET_VERSION / VERSION                          (VCA: Version)
> > >      GET_CAPABILITIES / CAPABILITIES                (VCA: Capabilities)
> > >      NEGOTIATE_ALGORITHMS / ALGORITHMS              (VCA: Algorithms)
> > >      GET_DIGESTS / DIGESTS
> > >
> 
> Why do you need a break here? Why not merge 1 and 2? 

Break gives the option for the OS to ask the TSM to transfer the
certificates it actually wants to speed up session startup. Eg if the
OS already has all the certificates cached then it doesn't need to
fetch any. Or if it only wants to use slot 0 then it only needs to
fetch slot 0.

> > > 2) CTLV commands:
> > >     query certificates. TSM will issue on demand:
> > >      GET_CERTIFICATE / CERTIFICATE                  (every slot in the slot mask, all chunks)
> > >     query VCA items

With the paus we can drive the certificate fetch from userspace, on
demand.

I view it as optional. The TSM's implementation choice is invisible to
userspace, but I'd like to gently encourage that we think about
session startup performance :)

> > > Then there are five implementations of this:
> > >  a) Today w/ 1.2 and current TDX/RMM/SEV specs:
> > >       #1 is a NOP
> > >       #2 is EOPNOTSUPP
> > >       #3 does the full flow from GET_VERSION -> FINISH
> > >          no GET_DIGESTS
> > >       #4 returns only the slot S certificate that was signed
> > >          during the transcript
> 
> Again, agree given the current limitations. 
> 
> > 
> > I see Elena's proposal [*] for current TDX:
> > 
> >   #1 Does the full flow from GET_VERSION -> FINISH
> >      no GET_DIGESTS
> >   #2 Returns only the slot S certificate that was signed during the
> >      transcript, this is my understanding, not specified by Elena.
> >   #3 If user selects slot0, pass; other slots, fail. Actually user can
> >      see only slot0.
> >   #4 Same as #2
> > 
> > Seems same to me, any preference? or do I understand correctly?

I think it is similar, but the main drawback is that userspace can no
longer detect that it is running option a. From userspace it looks
like option b with the device having only a single slot since this
makes #2 return certificates instead of EOPNOTSUPP.

Further, we completely loose the ability for userspace to specify a
slot at all since #3 would be the only function accepting a slot
number, but the session is already open.

Thus I think it is better to stick with the a above where all flows
consistently issue KEY_EXCHANGE in step #3. IMHO that consistency is
easier to reason about across all the options.

From a definitional perspective I would be very happy if the uAPI
specified precisely what part of the SPDM sequence is performed at
each step.

Again, if userspace detects it is in option a and really wants to do
slot selection it can run through iterations of step #3 to enumerate
the slots. I don't see we need the kernel to be involved in this, and
that is a strong reason why option a should be discoverable.

> > >   b) Improved 1.2 TSM:
> > >       #1 TSM can execute GET_DIGESTS and pause after
> > >       #2 Ideal TSM allows the OS to request each GET_CERTIFICATES command.
> > >          Less ideal is TSM pushes all GET_CERTIFICATES then pauses.
> 
> Why is it less ideal ? 

Only performance. It means every SPDM setup is forced to transfer
every certificate bundle even if we don't care or already have
it. That's all.

> > >       #3 TSM issues CHALLENGE and verifiers the signature.
> > >
> > >   c) 1.3 Multi-key flow:
> > >       #1/#2 is the same as b
> > >
> > >       #3 The function of CHALLENGE is absorbed in the updated
> > >          KEY_EXCHANGE which covers GET_DIGESTS when in multikey mode
> > > 	 No CHALLENGE issued
> > >
> > >   d) RustSPDM flow:
> > >       #1 becomes a RustSPDM session and includes CHALLENGE
> > >       #3 starts a new session
> > >       We have to solve the issue with ALGORITHMS mismatch somehow.
> > >       There is no verifiable binding of certificates visible to the
> > >       verifier
> 
> But why we need the RustSPDM flow now given that we agree we 
> should handle everything in single SPDM TSM session?

Right, I'm showing it for completness, I don't think we should
implement this. Maybe if someone strenuously objects to implement the
FW changes for mulit-slot/multi-key in their TSM they would do this.

My feeling is for now we should sketch out option a/b/c in detail,
everyone should confirm they can implement option a with current TSM
specs. Everyone should go back to their arch teams and reflect if they
agree to option c in future as some discoverable extension in their
FW.

Agree?

Is there a PDF for TDX's SPDM flow someplace? I will try to draft a
more complete document

Jason