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

[Jiri Pirko <jiri@resnulli.us>]

Sat, Oct 31, 2026 at 05:22:48AM +0100, aneesh.kumar@kernel.org wrote:
>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.

Okay. The aim of evidence-get is to do get fresh evidence upon each
call. I will document this more clearly.