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

[Aneesh Kumar K.V <aneesh.kumar@kernel.org>]

Jiri Pirko <jiri@resnulli.us> writes:

> Wed, Oct 28, 2026 at 04:26:13PM +0100, aneesh.kumar@kernel.org wrote:
>
>
> [..]
>
>
>>diff --git a/Documentation/ctlv/specs/ctlv-attestation-pci.yaml b/Documentation/ctlv/specs/ctlv-attestation-pci.yaml
>>new file mode 100644
>>index 000000000000..edb35cede0c2
>>--- /dev/null
>>+++ b/Documentation/ctlv/specs/ctlv-attestation-pci.yaml
>>@@ -0,0 +1,79 @@
>>+# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
>>+%YAML 1.2
>>+---
>>+family:
>>+  name: ctlv-attestation-pci
>>+  inherits: ctlv-attestation
>>+  pre-init: true
>>+
>>+attr-groups:
>>+  - name: pci
>>+    attrs:
>>+      - name: name
>>+        type: string
>>+        min-length: 1
>>+        max-length: 31
>>+      - name: generation
>>+        type: uint
>>+        max: 4294967295
>>+      - name: tsm-id
>>+        type: uint
>>+        max: 2147483647
>>+      - name: connected
>>+        type: uint
>>+        max: 1
>>+      - name: locked
>>+        type: uint
>>+        max: 1
>>+      - name: accepted
>>+        type: uint
>>+        max: 1
>>+      - name: dsm
>>+        type: string
>>+        min-length: 1
>>+        max-length: 31
>>+
>>+      - name: object
>>+        enum: evidence-blob-class
>>+      - name: challenge
>>+        type: binary
>>+        min-length: 32
>>+        max-length: 32
>>+
>>+attr-sets:
>>+  - name: device-info
>>+    attrs: pci.name
>>+  - name: change-reply
>>+    attrs: pci.generation
>>+  - name: state-reply
>>+    attrs:
>>+      - pci.generation
>>+      - pci.connected
>>+      - pci.locked
>>+      - pci.accepted
>>+    optional-attrs:
>>+      - pci.tsm-id
>>+      - pci.dsm
>>+
>>+  - name: refresh-request
>>+    attrs:
>>+      - pci.generation
>>+      - pci.object
>>+    optional-attrs:
>>+      - pci.challenge
>>+
>>+ops:
>>+  - name: state-get
>>+    type: action
>>+    fd-access: read
>>+    reply:
>>+      attrs: state-reply
>>+  - name: evidence-refresh
>
> I'm missing why exactly you need this op. Can't you do whatever is
> needed in the provider evidence_get implementation? Why it needs to be 2
> step.
>
> Also, why do you think this is provider-specific op?
>
>
>
>>+    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.
>
> 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.
>
> That discovery view is not present in the posted schema; STATE_GET does
> not provide it.
>
> Would this split work here? It would also allow non-PCI SPDM adapters to
> share the contract. I understand that multi-slot discovery is deferred,
> but a slot-zero implementation could still use this family and operation
> layout.
>

The only point that remains unclear to me is the distinction between
EVIDENCE_ACCEPT and SPDM_AUTHENTICATE. Also, would EVIDENCE_GET retrieve
fresh evidence on every call? If so, we do not need evidence-refresh.

-aneesh