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, Oct 29, 2026 at 09:56:26AM -0700, Dave Jiang wrote:
> 
> 
> On 10/28/26 8:26 AM, Aneesh Kumar K.V (Arm) wrote:
> > Declare certificate slot zero as the CCA link backend evidence
> > capability. Limit connect to PDEV creation and slot-zero identity
> > collection. Copy the chain into the PCI evidence cache before publishing
> > the CTLV device.
> > 
> > Complete public-key submission, secure-session setup and stream
> > connection through evidence_accept after userspace verifies the chain.
> > Keep the evidence snapshot separate from the RMM communication cache and
> > release it on context removal.
> > 
> > With AMD converted in the previous patch, CCA is the last link backend
> > that still establishes streams during connect. Now require
> > evidence_accept for every link backend and initialize newly connected
> > contexts without active streams. Reject link providers that omit the
> > callback, and remove the legacy connect-time session and IDE exception
> > from the API comments and documentation. Connect remains required at
> > this point; a later patch allows shared-discovery backends to omit it.
> 
> TDX Connect is another one. The TDX host link [1] sets up the SPDM
> session and then the IDE streams in its connect
> (tdx_tsm_link_connect(), patches 27 and 30).

Yeah, everyone tried to do it this way, but that is what is changing.

Do not call TDH.SPDM.CONNECT when processing the sysfs connect
operation. The sysfs operation only establishes what TSM driver is in
use.

You call TDH.SPDM.CONNECT triggered by attestation subsystem with the
slot id provided by userspace.

Don't get confused by the similar names :)

> It can't defer the session. The TDX Module runs the whole SPDM
> session setup inside TDH.SPDM.CONNECT, and the host relays its DOE
> messages without interpreting them, so there is no defined point to
> stop after the certificates. The chains come back in the device info
> only once TDH.SPDM.CONNECT completes (TDX Connect ABI Reference Spec
> 2.1 v0.66, 4.2.20.1).

Yeah, its fine. TDX will have to do what Aneesh proposed for ARM, and
use use the Rust SPDM Driver to operate DOE prior to calling
TDH.SPDM.CONNECT. This will allow discovering what is in the slots and
passing that information to userspace.

> For TDX, the chain can be checked after connect instead. A connected
> link doesn't make the device trusted by a guest. The guest still
> verifies the device before it accepts it. Could evidence_accept stay
> optional?

No, it is a key part of any crypto handshake, something in userspace
has to acknowledge the SPDM session is "Authenticated" before any use
of it progresses.

For these combined connect and IDE flows, "use" probably means
allowing a kernel driver to bind. Ideally once we connec the TSM there
will be no driver bound, and no driver can be bound until we accept
it.

This probably isn't *strictly* necessary since userspace can sequence
driver binding (assuming that doesn't get removed), more of a safety
sequencing.

For a guest it would mean you are allowed to go to RUN (or maybe it
implicitly goes to run?)

Jason