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>]

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? 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.

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
    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 ?
    // Do we need rust spdm challenge auth response here? 

Is it possible to validate Kc and Ks in the step above?

-aneesh