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 Thu, Nov 12, 2026 at 03:07:43PM +0530, Aneesh Kumar K.V wrote:
>> > Like a whole bunch of TSM FW API just to do this:

 [ ... 38 lines skipped ... ] 

>
> Capturing the transcript makes everything 100% perfectly consistent
> for everyone. Userspace sees *the transcript* as defined by SPDM not
> some mangled, truncated or processed version that the TSM decides to
> provide.
>
> Userspace gets to see KEY_EXCHANGE which means the verifier can prove
> the certificate binding, this is the ONLY way to let the verifier do
> this proof if it wants.
>

To clarify, is this only needed if the verifier wants to perform an
independent verification? The RMM already verifies KEY_EXCHANGE_RSP, and
we trust the RMM.

>
> Further with capture we have a nice primitive to pause and do slot
> selection before going to KEY_EXCHANGE. If we know the kernel has
> capture then the ideal FW design for 1.3 multikey is much simpler and
> clearer (more like ARM).
>
> Also, ARM decided to do capture already, but directed by the TSM.  I
> think it is the right and best idea, they just made the implementation
> too narrowly specific. eg it doesn't split up VCA, it doesn't capture
> 100% of everything to get KEY_EXCHANGE, etc. Trivial to fix while
> upgrading to support 1.3
>

So, not everyone needs DOE snooping? Architectures without a
firmware-directed capture mechanism can use DOE snooping to collect the
required data on the host. Would the flow for SPDM 1.2 look like the
following?

Host                              RMM                              Device
|                                 |                                  |
| RMI_PDEV_CREATE(slot 0)         |                                  |
|-------------------------------->|                                  |
|                                 |                                  |
| RMI_PDEV_COMMUNICATE loop       |                                  |
|-------------------------------->|                                  |
|                                 | GET_VERSION / VERSION            |
|                                 |<-------------------------------->|
|                                 | GET_CAPABILITIES / CAPABILITIES  |
|                                 |<-------------------------------->|
|                                 | NEGOTIATE_ALGORITHMS / ALGORITHMS|
|                                 |<-------------------------------->|
| Cache VCA exported by RMM       |                                  |
|<--------------------------------|                                  |
|                                 |                                  |
|                                 | GET_CERTIFICATE(slot 0) /        |
|                                 | CERTIFICATE response chunks      |
|                                 |<-------------------------------->|
| Cache chain exported by RMM     |                                  |
|<--------------------------------|                                  |
|                                 |                                  |
|                         PDEV_NEEDS_KEY                             |
|                                 |                                  |
| Extract slot 0's leaf key       |                                  |
| RMI_PDEV_SET_PUBKEY(key 0)      |                                  |
|-------------------------------->|                                  |
|                                 |                                  |
| RMI_PDEV_COMMUNICATE loop       | KEY_EXCHANGE(slot 0)             |
|-------------------------------->|--------------------------------->|
|                                 | KEY_EXCHANGE_RSP                 |
|                                 |<---------------------------------|
|                                 | Verify response signature        |
|                                 |                                  |
| NEW: cache complete             |                                  |
| KEY_EXCHANGE request and        |                                  |
| KEY_EXCHANGE_RSP, with signature|                                  |
|<--------------------------------|                                  |
|                                 |                                  |
|                                 | FINISH / FINISH_RSP              |
| Relay                           |<-------------------------------->|
|                                 |                                  |
|                         PDEV_READY                                 |
|                                 |                                  |
| NEW: request slot discovery     |                                  |
|-------------------------------->| GET_DIGESTS / DIGESTS [secure]   |
| Relay ciphertext                |<-------------------------------->|
| Receive RMM-exported slot info  |                                  |
|<--------------------------------|                                  |
|                                 |                                  |
| NEW: request certificate slot 1 |                                  |
|-------------------------------->| GET_CERTIFICATE / CERTIFICATE    |
| Relay ciphertext                | [secure session]                 |
|                                 |<-------------------------------->|
| Cache RMM-exported chain 1      | Retain reference chain digest    |
|<--------------------------------|                                  |
|                                 |                                  |

That is, we can use the existing RMI_PDEV_COMMUNICATE-based host caching
to obtain this data, while issuing GET_DIGESTS and GET_CERTIFICATE for
the selected slot over the secure session established by the RMM? (these
blobs will be returned from RMM with req_send = 0 and req_cache = 1)

If GET_DIGESTS and GET_CERTIFICATE(selected slot) are issued after the
secure session is established, DOE snooping cannot capture their
plaintext responses. I am therefore still unclear how the DOE snooping
design handles this data.

In the end, the host has the certificate chain for slot 0, which was
used to establish the secure SPDM session, and the certificate chain for
the selected slot, which was fetched over that trusted session. The RMM
also returns the chain digests. The host can compare the leaf keys for
slot 0 and the selected slot, and can be sure that it received all
supported slots because the slot information was obtained over the
secure SPDM session.

If the verifier wants to independently verify the session in addition to
the verification already performed by the RMM, it can do so because it
has the VCA, the slot 0 certificate chain, and the
KEY_EXCHANGE/KEY_EXCHANGE_RSP transcript. This independent verification
is optional?

BTW, this proposal does require RMM changes. I have also omitted SPDM
1.3 multi-key support from this diagram because it will be easier to
follow once the SPDM 1.2 flow is clear.

-aneesh