Re: [RFC PATCH v1 00/11] PCI/TSM: Add CTLV attestation

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Oct 30, 2026 at 08:34:28PM +0800, Xu Yilun wrote:
> On Wed, Oct 28, 2026 at 08:56:07PM +0530, Aneesh Kumar K.V (Arm) wrote:
> > This series connects PCI/TSM to the common CTLV attestation interface.
> > Userspace can discover a device's evidence objects, retrieve them, and
> > accept the evidence before the kernel establishes a secure link or moves
> > a guest device into TDISP RUN. It replaces the PCI/TSM netlink evidence
> > interface while retaining connect, disconnect, lock and unlock in sysfs.
> > 
> > This series builds on the CTLV attestation series [1] and Arm CCA
> > device-assignment support. It covers PCI/TSM attestation through
> > certificate slot-zero.
> > 
> > The development tree is available at:
> > 
> >   https://gitlab.arm.com/linux-arm/linux-cca.git cca/topics/cca-da-attestation
> > 
> > That branch also includes the follow-up Rust SPDM certificate-slot
> > discovery work, generic attestation fixes, and CTLV tooling fixes.
> > 
> > [1] https://lore.kernel.org/all/20261015145053.3664509-1-jiri@resnulli.us
> > 
> > The host flow separates identity collection from session and IDE setup:
> > 
> >   sysfs connect
> >     -> collect and cache the certificate chain
> >   DEVICE_GET / EVIDENCE_GET
> >     -> discover available objects and retrieve the chain for verification
> 
> Is it possible that these two steps combined to one? They collect, cache
> the certificates, then hand over the cache to userspace when requested. Why
> not just use one user interface to collect and hand over the certificates?

Any caching needs a careful think.. We should be caching globally in
the attestation subsystem things like certificate chains so we can do
GET_DIGESTS and then skip the GET_CERTIFICATES if we already have it..

And if we are going to do this rustspdm + TSM stuff the certificate
caching should be shared between those components too.

Other stuff is not caching, it is storing immutable data about a
single SPDM session. Like the transcript.. This needs to be properly
lifetime bound to the session itself through a session generation.

> Could the flow be:
> 
> 1. DEVICE_GET/EVIDENCE_GET
> 	-> collect and retrieve the certificates via native SPDM
> 2. sysfs connect
> 	-> establish the *TSM-based* secure session and IDE streams
> 3. sysfs disconnect
> 	-> release the *TSM-based* streams and identity context
> 
> This way we don't even touch the existing host side TSM.

I don't think this is a great idea, ideally we should be seeing the
TSM world expand their APIs to support slot discovery properly and
securely. Injecting rustspdm to make up those gaps should be seen as a
temporary thing. Thus the uAPI presented should be uniform between and
old and new TSM..

There should also be some continuity, possibly in the kernel, to bind
the digests/certificates from the first phase through to the
authenticated phase to avoid downgrade attacks. See my reply to Elena
This is much harder to do if the tsm driver goes away in the middle of
the process.

Jason