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

[Jason Gunthorpe <jgg@nvidia.com>]

On Mon, Nov 02, 2026 at 01:45:19PM +0100, Jiri Pirko wrote:
> Fri, Oct 30, 2026 at 04:43:53PM +0100, jgg@nvidia.com wrote:
> >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?
> 
> Yes. For SPDM-capable PCIe endpoints, this is the mapping I figured out
> with LLM, using the existing RMM 2.0-bet3 interface:

Lets talk about this in this thread:

https://lore.kernel.org/all/20261103151643.GI274202@nvidia.com/

> sysfs connect (PCI/TSM and kernel SPDM requester):
>   Perform preliminary negotiation and GET_DIGESTS/GET_CERTIFICATE.
>   Retain the discovery snapshot and destroy the temporary requester.
>   Do not create the endpoint PDEV yet.

If we want to do what I called option a, with user space repeat, then
we need a CTLV command to start the flow, not sysfs.

I have been thinking sysfs should only create the attestation end
point and not do any RMM operations
 
> SPDM_GET (attestation provider):
>   Return the retained discovery information and connection state.
>   There is no corresponding RMI discovery command.

> EVIDENCE_GET(CERT_CHAIN, blob-instance=N):
>   Return the retained DER certificate chain for slot N.

I think these two are my #2
 
> SPDM_AUTHENTICATE(device-generation, slot):
>   Validate the generation and selected slot.
>   RMI_PDEV_CREATE(id_index=slot)

Maybe PDEV_CREATE is in my #1?

>   RMI_PDEV_COMMUNICATE until PDEV_NEEDS_KEY
>     -> RMM performs fresh negotiation and retrieves the selected chain
>     -> CCA host driver relays requests over DOE and caches the chain
>   Compare its DER certificates with the selected discovery identity.
>     -> reject a mismatch before supplying the key
>   Extract the leaf key; RMI_PDEV_SET_PUBKEY -> PDEV_HAS_KEY
>   RMI_PDEV_COMMUNICATE until PDEV_READY

This is my #3

>   Prepare the root-port PDEV to READY and configure PCI IDE resources.
>   RMI_PDEV_STREAM_CONNECT
>   RMI_PDEV_COMMUNICATE on both PDEVs, honoring STREAM_WAIT
>   RMI_PDEV_STREAM_COMPLETE
>   Enable the endpoint IDE stream.
>   Only then publish authenticated state and the new device-generation.

Oh is IDE under the control of the OS for RMM? I hadn't read that far
ahead. Then it should be done as part of the "ACCEPT" step #5

ie the same place we would do RUN

Jason