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, Nov 13, 2026 at 02:24:59PM +0530, Aneesh Kumar K.V wrote:
> 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.

Yeah, I'm not so sure how useful it is, but if you ever want this,
then the uABI has to be structured like this. I don't see any reason
to forbid it, people have asked for it before, and it is easier uABI
to maintain long term than the alternatives.

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

IMHO ARM has it nearly right, and if you can do TSM directed capture
then you don't need kernel snooping. Kernel snooping has the drawback
that the kernel has to understand every message the TSM sends and
every option it negotiates. This is a troublesome coupling, so it
would be good to avoid it.

But breaking up a VCA blob has the same troublesome coupling as
snooping, so we need the TSM directed capture to work in a transcript
form, see blow.

Your diagram is basically what ARM does already, I don't see an issue
with ARM's implementation as-is for 1.2 support.

> |                                 | KEY_EXCHANGE_RSP                 |
> |                                 |<---------------------------------|
> |                                 | Verify response signature        |
> |                                 |                                  |
> | NEW: cache complete             |                                  |
> | KEY_EXCHANGE request and        |                                  |
> | KEY_EXCHANGE_RSP, with signature|                                  |

This is not the change I would suggest.

ARM has everything fine, the RmiDevCommExit tells the OS how to build
up the transcript.

The only issue is how the cache_object_id was layed out.

It should be a range of objects, one per transcript message. eg use
0x80 -> 0xff as
 0x80 - request #0
 0x81 - reply #0
 0x82 - request #1
 0x83 - reply #1
  ...

Then include every single message that is part of the signature. OS
reconstructs VCA from this. Trivial to include KEY_EXCHANGE in 1.2,
GET_DIGESTS in 1.3 and then whatever else 1.x brings down the
road. You have enough IDs to capture 64 transcript messages.

That ARM can capture encrypted messages this way is cool too, if that
becomes useful it can append to the transcript encrypted items as
well!

I imagine an ECN with a OS negotiated opt-in "Improved flow for 1.3"
that changes things like this, and below as a package.

> | NEW: request slot discovery     |                                  |
> |-------------------------------->| GET_DIGESTS / DIGESTS [secure]   |
> | Relay ciphertext                |<-------------------------------->|
> | Receive RMM-exported slot info  |                                  |
> |<--------------------------------|                                  |

Intel did this, IDK if we need to for RMM, at least not like this..

We really want the certificates to be loaded at the start before doing
key_exchange. That is when they are most useful.

So when we fix this for 1.3 the opt in should trigger a transcript'd
GET_DIGEST in plain text and certificate collection from all the slots
in plain text.

1.3 will sign GET_DIGESTS during KEY_EXCHANGE
1.2 RMM could issue CHALLENGE if the device supports it right before
    KEY_EXCHANGE and transcript it
1.2 RMM could issue GET_DIGESTS inside the session and fail if != to
    the plaintext

These approaches keep a consistent flow where we get the certificates
before doing KEY_EXCHANGE so we can set the slot.

The final 1.3 opt in change is to not use the slot passed to
RMI_PDEV_CREATE(), but instead change RMI_PDEV_SET_PUBKEY() to input
the slot, pubkey and certificate hash. Have a pause in the flow prior
to RMI_PDEV_SET_PUBKEY where userspace will read the certificates and
input the slot.

I view all of this as a new opt-in feature the OS can select to enable
all these new rules together. When the RMM supports it then we get a
more complete transcript, early slot selection, multikey, and early
visibility to all certificate chains.

In terms of change to RMM it is very minor.

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

As above, the TSM needs to issue these in plaintext because we need
the information to do slot selection before doing KEY_EXCHANGE. This
is essential for 1.3 multikey..

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

This only works for 1.2 where all leaf keys have the same PUBKEY. In
1.3 that's not true anymore, so this logic falls apart. You need to
sign the GET_DIGESTS and present all the slot opts to userspace so it
selects a strong key as the signing key for KEY_EXCHANGE.

It is why I don't see value in fixing 1.2 like this, it only works for
1.2 and we need to fix it again for 1.3. It is better to make 1.2 look
like the 1.3 flow.

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

IMHO, leave everything alone as is today. We can make it work well
enough as is.

Make a ECN for a 1.3 opt in broadly like the above that fits better
into how I sketched the kernel uAPI. Do this once we all agree to the
new uAPI. The kernel will always try to use this new mode if RMM
supports it and userspace gets a better 1.3 experiance.

There would a similar opt in change on the RHI side to transfer the
new object list.

Jason