Thread (43 messages) 43 messages, 6 authors, 38m ago

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

flat view

From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
Date: 2026-10-31 04:22:59
Also in: linux-patches

Jiri Pirko [off-list ref] writes:
Wed, Oct 28, 2026 at 04:26:13PM +0100, aneesh.kumar@kernel.org wrote:


[..]

quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help