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?
>

I was considering evidence-get to return the evidence generated by
evidence-refresh. Without an explicit refresh, evidence-get would return
the previously fetched evidence. There is no particular reason for this
two-step approach; evidence-get could always fetch fresh evidence,
making evidence-refresh redundant.

-aneesh