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

[Aneesh Kumar K.V <aneesh.kumar@kernel.org>]

"Reshetova, Elena" <elena.reshetova@intel.com> writes:

>> Jason Gunthorpe <jgg@nvidia.com> writes:
>> 
>> > On Tue, Nov 03, 2026 at 12:01:43PM +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
>> >
>> > 2) CTLV commands:
>> >     query certificates. TSM will issue on demand:
>> >      GET_CERTIFICATE / CERTIFICATE                  (every slot in the slot mask, all
>> chunks)
>> >     query VCA items
>> >
>> > 3) CTLV commands:
>> >    FINISH CONNECT with slot:
>> >     TSM for 1.2 does:
>> >      CHALLENGE(slot 0, fresh nonce) / CHALLENGE_AUTH
>> >      KEY_EXCHANGE(slot S) / KEY_EXCHANGE_RSP       (clear text)
>> >      FINISH / FINISH_RSP                           (in session, opaque to host)
>> >     Or for 1.3 multi-key does:
>> >      KEY_EXCHANGE(slot S) / KEY_EXCHANGE_RSP       (now includes DIGESTS
>> and CERTIFICATE)
>> >      FINISH / FINISH_RSP                           (in session, opaque to host)
>> >
>> 
>> 
>> Does this split require us to guarantee that no GET_VERSION can be
>> issued in between? 
>
> Yes, in my opinion TSM must enforce it because as you said, GET_VERSION
> resets everything.
>

How can TSM enforce this? Another subsystem could issue GET_VERSION
through the DOE mailbox. IIUC, TSM would only detect a transcript
mismatch when KEY_EXCHANGE_RSP validation fails. Is that correct?

>
>> Another GET_VERSION in the same requester context
>> between START CONNECT and FINISH CONNECT would reset the responder's
>> negotiated state and transcript, right?
>> 
>> If so, can we avoid this split and always use RustSPDM, with or without
>> multi-key support?
>> 
>> Something like:
>> Kc: public key used to verify CHALLENGE_AUTH from slot C.
>> Ks: public key selected for session establishment by user using slot S.
>> C and S may be different slots.
>> 
>> Host / RustSPDM:
>>     VCA -> GET_DIGESTS -> fetch certificate chains
>>     CHALLENGE(C) -> retain the messages and CHALLENGE_AUTH signature
>>     Stop communicating with the device.
>
> GET_DIGESTS only gets you digests, you still need GET_CERTIFICATES
> to actually fetch certs.
>

yes that is correct.

>
>> 
>> Host / userspace:
>>     Examine the discovery results.
>>     Select slot S and validate its certificate chain/key Ks.
>> 
>> Host -> RMM/firmware:
>>         Supply:
>>           - C and Kc, S and Ks
>>           - Algorithms
>> 
>>     Fresh GET_VERSION -> CAPABILITIES -> ALGORITHMS
>
> How do you propose to deal with the fact that here TSM
> may agree with a device on different params than rustSPDM
> above?
>

I suppose we would need to pass all of those parameters for the host ->
RMM/firmware interaction. I had assumed that the algorithms were the only
negotiated parameters needed for SPDM session establishment. Would validating
Kc and Ks require passing additional details from the RustSPDM exchange to the
firmware?

>
>
>>     GET_DIGESTS immediately after VCA
>>     GET_CERTIFICATE(C), GET_CERTIFICATE(S)
>>     Check that Kc is the leaf public key in chain C. // Can the slot number change
>> by now ?
>
> In addition to VCA influencing the content of the slots, 
> a device could have a FW upgrade in between rustSPDM
> step and this step and this could change the content of
> the slots. 
> But if you fully verify the actual cert chain and key itself
> you can reject such cases. So your way is also doable with
> additional checks, but I am worried about the problem to 
> agree on the same VCA.
>

My main question is whether we should avoid splitting the context and
relying on the host not to disrupt the sequence. I wonder whether that
would be a poor API design and whether we can avoid it. Is that a goal
we should pursue?

-aneesh