Re: [RFC PATCH v1 06/11] PCI/TSM: Describe the PCI attestation control family

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Oct 30, 2026 at 03:01:29PM +0100, Jiri Pirko wrote:
> Wed, Oct 28, 2026 at 04:26:13PM +0100, aneesh.kumar@kernel.org wrote:
> >+    type: action
> >+    fd-access: read-write
> >+    availability: dynamic
> >+    optional: true
> >+    request:
> >+      attrs: refresh-request
> >+    reply:
> >+      attrs: change-reply
> 
> This differs from what I had in mind: a transport-neutral
> ctlv-attestation-spdm family with SPDM_GET and SPDM_AUTHENTICATE.

Yes, we should try very hard to keep all the SPDM stuff as transport
neutral as possible.

> SPDM_GET would report discovery BaseHash, discovered slots and their
> certificate digests, authentication state, and the effective
> authentication slot. SPDM_AUTHENTICATE would take device-generation and
> the selected slot. EVIDENCE_GET would retrieve CERT_CHAIN with
> blob-instance=slot without selecting the authentication slot.

Do you have a mapping to ARM RMM operations already you can share with
Aneesh?

Like I said in the other email I imagine a pre-discovery phase to
learn the slot number (with rustspdm), a connecting phase using the
slot number, then a post connect authentication to inspect the
certificate chain and evidence.

The certificate chain should be available at the first phase and the
subsequent stages should not allow it to change, ideally..

Jason