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 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:
> 
> Can you help me understand why we need to snoop the DOE messages? IIUC,
> the earlier proposal for 1.2 was to use Rust SPDM to perform the
> following:
> 
> GET_VERSION
> GET_CAPABILITIES
> NEGOTIATE_ALGORITHMS
> GET_DIGESTS
> GET_CERTIFICATE for all slots in the slot_mask returned by GET_DIGESTS
> CHALLENGE using the slot 0 key (At this point, we can also verify that
> we received the certificates for all slots supported by the device.)

At least I wasn't proposing exactly this.. CHALLENGE ideally has to be
connected to KEY_EXCHANGE, ie they use the same nonce or get digests
is hashed by the TSM or something to have the full value that 1.3
brings.

I've also been told that not many devices are implementing CHALLENGE,
so this may not be that useful to invest in..

But the main issue is we have to use the TSM to initiate
NEGOTIATE_ALGORITHMS because that defines what the contents of the
slots will be, and a rustspdm has to follow the TSM's selection.

So, any version of this flow would require capture as a building block
anyhow, and you have this awkward version where TSM does all the
negotiation then rustspdm injects its own messages according to the
TSM selected rules.

It is possible but very hard, so I think we should set it aside. This
is something to reach for if the vendors don't want to agree on FW
changes as part of the 1.3 upgrade to improve things.

> The host then select a slot and use it to establish the IDE connection?
> (For intel we can only select slot 0 here?)
> 
> What does snooping provide in this context?

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.

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

Finally, Intel actually seems to need Linux managed capture (Seriously
Intel, WTF?) as they don't have any other way to get the VCA, and
without the VCA the measurement signature cannot be checked. I hope
they still have time in their spec process to adopt the ARM approach.

The ultimate goal is to get *consistency*, especially a consistent
uAPI. The second long term goal is I want the guest and host to show
the same data out of the same uAPI for attestation. The guest should
not have an inferior view.. It will take some spec changes to get
there.

I've now gone through all the exiting choices all the TSMs have made
and here is what I'm thinking

1) The uAPI presents a transcript interface, every message and reply
   individually presented to userspace. Perfectly future extensible to
   include GET_DIGESTS with 1.3 and whatever else comes down the road.
   These are consistent spec defined message blobs 100% the same for
   every single SPDM implementation and TSM.
   The kernel will start with a partial transcript, but the API
   can carry a full one as we improve with no uAPI change.
   The guest will see partial transcript until/if vmm/guest changes
   are made

2) The uAPI presents the x509 certificate chains in a consistent spec
   defined way that userspace can hash back to GET_DIGESTS

3) The uAPI presents the signed measurement result and tdisp in
   a consistent spec defined way

4) We have the four step
      Start
      Get certificate
      Finish using slot
      Accept
   Flow I mentioned earlier

5) We start without complicated capture. ARM will collect VCA with its
   in built capture. AMD will do a measurement collection during
   'Finish' and extract VCA from its blob. Common code will transform
   both VCAs into a truncated transcript.

   Intel don't get a VCA at this point, so no signature verification.

7) We implement common direct capture and throw away the VCA code from
   the drivers. Intel can work. Every host driver has 100% perfect
   transcript.

8) We have a nice think and Linux sets a recommendation what the FW
   TSM interface should look like and try to badger the TSM FW spec
   authors into something more consistent than this mess as part of
   a 1.3 multikey update.

   If everyone can standardize on ARM-like TSM managed capture, with
   the proper breakdown and data inclusion then we can get 100%
   consistency without a complicated capture process in the kernel.

9) The VMM uses the above common interface to reconstruct the
   RHI/GHCI/AMD. That mess doesn't leak into the kernel on the host.
   I checked this and everyone but Intel is fine to construct their
   host/guest channel from the common interface.

   Ie fetch the x509 bundle and reform it into whatever was speced,
   then undo it and put it back into the x509 bundle for the guest
   attestation subsystem.

   Except for Intel all the guest defined digests can be calculated
   from the common spec messages. Well, maybe AMD has an issue, their
   spec is too vauge to tell exactly what bytes are digested.

IMHO ARM has the design that is closest to perfect, a few tweaks and
it would be excellent and support 1.3 multikey.

AMD's is weird but at least what they have for 1.2 can be made to
work. Will need to be rethought to get get 1.3 multi-key. Copy ARM.

Intel.. Is wrong IMHO. It is still unreleased, is it too much to hope
you could just copy more from ARM?
 1) No easy way to get the VCA, no easy way to do capture

 2) Wrong digests design for the guest. SPDM_DEVICE_ATTESTATION_INFO_T
    is a terrible idea since it is not grounded in any spec. The other
    two have multiple guest digests computed directly over spec
    defined objects.

 3) Even if you like SPDM_DEVICE_ATTESTATION_INFO_T it includes
    TDISP_CAPABILITIES for some bad reason. Nobody else even
    exports this info from their TSM or digests it. Thus Intel would
    need unique API for the VMM to even build
    SPDM_DEVICE_ATTESTATION_INFO_T. Not nice.

 4) How does future extension work? Oh you probably have to pass 
    SPDM_DEVICE_ATTESTATION_INFO_T as an opaque blob through to the
    VMM. Lovely, so only Intel needs a special Intel specific blob
    uAPI? Bah. This is a very bad idea.

 5) Several unnecessary collections during connection setup.

 6) Confusing/bad implementation of 'TSM selected nonce' and
    "recollection"

 7) Lack of an API to do evidence colllection for the host, the only
    provided API always changes the guest visible information.
    Not nice.

Jason