Re: [PATCH RFC 00/20] attestation: Add a common subsystem and TDX support

[Jason Gunthorpe <jgg@ziepe.ca>]

On Fri, Oct 23, 2026 at 08:58:35PM +0530, Aneesh Kumar K.V wrote:
> Jason Gunthorpe <jgg@ziepe.ca> writes:
> 
> > On Fri, Oct 23, 2026 at 01:34:53PM +0530, Aneesh Kumar K.V wrote:
> >
> >> CCA currently takes the device identity index during pdev_create. I am
> >> investigating how to retrieve the certificate chains for all slots. For
> >> now, I have implemented the sequence below.
> >
> > Yeah, I think the consensus at LPC was this may be a gap in CCA.
> 
> I checked with Alexey, and if I understand him correctly, TIO also needs
> to establish eight separate connections to retrieve the certificate
> chains.

Lovely!

> For now, I am trying Jiri's suggestion: use Rust SPDM to fetch the
> certificate chain and return it via evidence-get. evidence-accept then
> does pdev-create with the specified slot number and compares the
> evidence data returned by the RMM with the value cached by Rust SPDM. If
> they match, it uses the cached value for set_pub_key. This seems to be
> working. (FVP only supports slot 0, hence only one blob-instance)

That's a pretty good idea, and works for every arch! Maybe that is
the best long term direction.

IDK about all this "Caching" stuff, I'm not sure I love the name
"Cache" to refer to the security important reference certificate
bundles. It should have a stronger name to reflect how critical it is
in the entire security design of SPDM. You select the certificates
once and everything following must match that or something bad has
happened. It is effectively a key part of the channel binding.

But yes, RMM is sort of backwards here, the slot number should come
with information about the certificates, but I think this is fine to
have RMM fetch them again and then we just confirm everything matches
the kernel's target. If we don't do a get prior to connecting then the
kernel would just adopt the RMM's result as the target certificate
chain for the slot?

It certainly seems like it should be all sketched out and the uAPI
confirmed. Given the state of things I don't see an issue with a slot
0 only initial configuration (ie EOPNOTSUPP the certificate gets) so
long as the long term resolution is clear.

Which is an interesting question for Jiri on CTLV, one of the things
we have in RDMA is runtime schema pruning. Based on runtime device
capabilities parts of the schema can be disabled. Can we get there
with CTLV too? Then introspection could return if the underlying
implementation supports some of this stuff..

Jason