From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
To: Jiri Pirko <jiri@resnulli.us>
Cc: linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-api@vger.kernel.org, x86@kernel.org, kvm@vger.kernel.org,
linux-doc@vger.kernel.org, jgg@ziepe.ca, david.quigley@intel.com,
lukas@wunner.de, ksinyuk@kernel.org, rodrigo.vivi@intel.com,
cedric.xing@intel.com, sameo@meta.com, drdeeglaze@gmail.com,
James.Bottomley@hansenpartnership.com, aik@amd.com,
jpiotrowski@nvidia.com, qinkun@google.com, pgonda@google.com,
jic23@kernel.org, alistair.francis@wdc.com, ankita@nvidia.com,
suzuki.poulose@arm.com, kas@kernel.org,
rick.p.edgecombe@intel.com, elena.reshetova@intel.com,
dave.hansen@linux.intel.com,
sathyanarayanan.kuppuswamy@linux.intel.com, peter.fang@intel.com
Subject: Re: [PATCH RFC 00/20] attestation: Add a common subsystem and TDX support
Date: Fri, 23 Oct 2026 13:34:53 +0530 [thread overview]
Message-ID: <yq5av76sj10a.fsf@kernel.org> (raw)
In-Reply-To: <atooh7uO2RauUTfY@FV6GYCPJ69>
Jiri Pirko <jiri@resnulli.us> writes:
> Thu, Oct 22, 2026 at 12:30:47PM +0200, aneesh.kumar@kernel.org wrote:
>>Jiri Pirko <jiri@resnulli.us> writes:
>>
>>> From: Jiri Pirko <jiri@nvidia.com>
>>>
[ ... 67 lines skipped ... ]
>>>
>>
>>I am using this to understand what the IDE setup flow would look like,
>>but it is unclear whether the connect flow belongs in an attestation
>>framework. I understand the desire to pass the certificate slot number
>>as part of connect, and sysfs is probably not a suitable interface for
>>that. However, is CTLV the interface we want to use for connect?
>
> I was thinking about this and "connect" really does not belong in the
> attestation CTLV (same applies to "lock"). I was thinking about some
> parallel PCITSM CTLV instance, but that does not really click as well.
>
> Currently I'm thinking we can maintain existing "connect" in sysfs and
> extend it with "lock" sysfs knob for Realm side. Both would create
> ctlv-attestation-spdm instance. The same spdm instance may be created
> for other non-PCI-backed device.
>
> The proposed host flow is:
>
> sysfs connect: select tsmN and prepare the connection
> -> negotiate SPDM and discover certificates
> -> register ctlv-attestation-spdm instance in DISCOVERED state
>
> SPDM_GET
> -> populated certificate slots and digests
>
> EVIDENCE_GET(CERT_CHAIN, blob-instance=slot) /*optional*/
> -> retrieve candidate certificate chain for appraisal
>
> SPDM_AUTHENTICATE(device-generation, spdm-slot=selected_slot)
> -> authenticate the selected chain
> -> complete backend-required session and IDE setup
>
> sysfs disconnect
> -> remove the attestation instance
> -> destroy the native connection
>
> The slot is therefore selected after discovery, rather than supplied to
> connect. The attestation instance represents the prepared connection; it
> does not exist beforehand as a controller for a disconnected PCI function.
>
CCA currently takes the device identity index during pdev_create. I am
investigating how to retrieve the certificate chains for all slots. For
now, I have implemented the sequence below.
echo tsm0 > /sys/bus/pci/devices/$DEVICE/tsm/connect
./ctlvctl/ctlvctl --spec-dir=./specs/ exec ctlv0 device-get
# device-get, 1 fragment, generation 0
device.generation 0
device.caps
cap.evidence
cap.min-challenge-length 0
cap.max-challenge-length 0
cap.max-total-output-length 369098752
cap.evidence-flags evidence-accept
cap.object
cap.blob-class cert-chain
cap.blob-instance 0
cap.format spdm-cert-chain
cap.representation raw
cap.representation tcb-digest
cap.hash-algo 4
cap.hash-algo 5
cap.hash-algo 6
cap.max-length 16777216
device.info
pci.name 0000:02:00.0
I think we can use evidence-refresh to select the blob-instance for the
desired slot once the CCA specification supports that.
./ctlvctl/ctlvctl --spec-dir=./specs/ exec ctlv0 state-get
# state-get, 1 fragment, generation 0
pci.generation 0
pci.connected 1
pci.locked 0
pci.accepted 0
pci.tsm-id 0
pci.dsm 0000:02:00.0
device is marked connected, but IDE is not setup as indicated by pci.accepted = 0
./ctlvctl/ctlvctl --spec-dir=./specs/ exec ctlv0 evidence-get --json '{
"evidence.challenge": "hex:", "evidence.object": [{
"evidence.blob-class": "cert-chain", "evidence.format":
"spdm-cert-chain", "evidence.blob-instance": 0,
"evidence.representation": "raw", "evidence.data": { "file":
"/tmp/cert0.bin", "data-buf-size": 16777216 } }] }'
# evidence-get, 1 fragment, generation 0
device.generation 0
evidence.generation 1
evidence.object-length 1632
I added the file: attribute to verify the evidence blob's contents. ie,
we can do:
# file cert0.bin
cert0.bin: Certificate, Version=3
./ctlvctl/ctlvctl --spec-dir=./specs/ exec ctlv0 evidence-accept device.generation=0 evidence.generation=1
# acknowledged
./ctlvctl/ctlvctl --spec-dir=./specs/ exec ctlv0 state-get
# state-get, 1 fragment, generation 0
pci.generation 0
pci.connected 1
pci.locked 0
pci.accepted 1
pci.tsm-id 0
pci.dsm 0000:02:00.0
I am wondering why we need 'devsec-run' ops. Isn't that already the result of
'evidence-accept'?
-aneesh
prev parent reply other threads:[~2026-10-23 8:05 UTC|newest]
Thread overview: 122+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 14:50 [PATCH RFC 00/20] attestation: Add a common subsystem and TDX support Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 01/20] ctlv: Add the schema language and generator Jiri Pirko
2026-10-15 14:58 ` sashiko-bot
2026-10-20 22:31 ` Jonathan Cameron
2026-10-21 13:23 ` Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 02/20] ctlv: Add the UAPI wire format and family API Jiri Pirko
2026-10-19 23:29 ` Jason Gunthorpe
2026-10-20 12:26 ` Jiri Pirko
2026-10-20 23:00 ` Jonathan Cameron
2026-10-20 23:39 ` Jonathan Cameron
2026-10-21 13:54 ` Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 03/20] ctlv: Add the root family specification and generated files Jiri Pirko
2026-10-19 23:29 ` Jason Gunthorpe
2026-10-20 12:28 ` Jiri Pirko
2026-10-20 12:55 ` Jason Gunthorpe
2026-10-20 14:07 ` Jiri Pirko
2026-10-20 23:30 ` Jonathan Cameron
2026-10-21 16:25 ` Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 04/20] Documentation: ctlv: Add userspace ABI Jiri Pirko
2026-10-19 23:29 ` Jason Gunthorpe
2026-10-20 14:06 ` Jiri Pirko
2026-10-21 0:11 ` Jonathan Cameron
2026-10-22 9:01 ` Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 05/20] ctlv: Prepare message input handling Jiri Pirko
2026-10-15 15:06 ` sashiko-bot
2026-10-21 0:43 ` Jonathan Cameron
2026-10-22 8:27 ` Jiri Pirko
2026-10-22 18:39 ` Jason Gunthorpe
2026-10-15 14:50 ` [PATCH RFC 06/20] ctlv: Prepare blob descriptor validation Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 07/20] ctlv: Prepare schema validation Jiri Pirko
2026-10-15 15:14 ` sashiko-bot
2026-10-15 14:50 ` [PATCH RFC 08/20] ctlv: Prepare message output handling Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 09/20] ctlv: Prepare VA blob handling Jiri Pirko
2026-10-15 15:14 ` sashiko-bot
2026-10-15 14:50 ` [PATCH RFC 10/20] ctlv: Prepare event queue support Jiri Pirko
2026-10-15 15:22 ` sashiko-bot
2026-10-21 1:12 ` Jonathan Cameron
2026-10-22 9:04 ` Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 11/20] ctlv: Prepare runtime introspection Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 12/20] ctlv: Add device and operation dispatch Jiri Pirko
2026-10-15 15:28 ` sashiko-bot
2026-10-21 1:25 ` Jonathan Cameron
2026-10-22 9:05 ` Jiri Pirko
2026-10-22 18:43 ` Jason Gunthorpe
2026-10-15 14:50 ` [PATCH RFC 13/20] Documentation: ctlv: Describe how to write a family Jiri Pirko
2026-10-15 15:20 ` sashiko-bot
2026-10-19 23:29 ` Jason Gunthorpe
2026-10-21 14:23 ` Jiri Pirko
2026-10-21 14:49 ` Jason Gunthorpe
2026-10-21 16:24 ` Jiri Pirko
2026-10-21 16:48 ` Jason Gunthorpe
2026-10-22 8:22 ` Jiri Pirko
2026-10-22 19:21 ` Jason Gunthorpe
2026-10-15 14:50 ` [PATCH RFC 14/20] attestation: Add the base family specification and generated files Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 15/20] attestation: Prepare provider and instance core Jiri Pirko
2026-10-15 15:30 ` sashiko-bot
2026-10-19 23:29 ` Jason Gunthorpe
2026-10-21 13:04 ` Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 16/20] attestation: Prepare measurement register journal Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 17/20] attestation: Add CTLV operation handling Jiri Pirko
2026-10-15 15:33 ` sashiko-bot
2026-10-15 14:50 ` [PATCH RFC 18/20] tdx-guest: Expose the native attestation service API Jiri Pirko
2026-10-15 15:40 ` sashiko-bot
2026-10-15 14:50 ` [PATCH RFC 19/20] attestation: Add the TDX family specification and generated files Jiri Pirko
2026-10-15 14:50 ` [PATCH RFC 20/20] attestation: Add the TDX family implementation Jiri Pirko
2026-10-15 15:40 ` sashiko-bot
2026-10-22 22:07 ` Edgecombe, Rick P
2026-10-16 23:43 ` [PATCH RFC 00/20] attestation: Add a common subsystem and TDX support Jason Gunthorpe
2026-10-17 18:16 ` Dionna Glaze
2026-10-17 19:06 ` Jarkko Sakkinen
2026-10-17 19:08 ` Jarkko Sakkinen
2026-10-17 19:22 ` Jarkko Sakkinen
2026-10-17 20:55 ` Jason Gunthorpe
2026-10-17 21:14 ` Jarkko Sakkinen
2026-10-17 20:34 ` Jason Gunthorpe
2026-10-17 20:55 ` Jarkko Sakkinen
2026-10-17 23:10 ` Jason Gunthorpe
2026-10-18 23:53 ` Dionna Glaze
2026-10-19 12:08 ` Jiri Pirko
2026-10-19 16:10 ` Dionna Glaze
2026-10-19 22:56 ` Jason Gunthorpe
2026-10-21 8:33 ` Jiri Pirko
2026-10-21 14:12 ` Mimi Zohar
2026-10-21 14:35 ` Jason Gunthorpe
2026-10-21 19:05 ` Mimi Zohar
2026-10-22 10:54 ` Jiri Pirko
2026-10-22 11:24 ` Mimi Zohar
2026-10-22 18:51 ` Jason Gunthorpe
2026-10-22 19:19 ` Jarkko Sakkinen
2026-10-22 19:23 ` Jason Gunthorpe
2026-10-22 19:40 ` Jarkko Sakkinen
2026-10-22 19:40 ` James Bottomley
2026-10-22 12:26 ` James Bottomley
2026-10-22 13:11 ` Jason Gunthorpe
2026-10-22 14:07 ` James Bottomley
2026-10-22 19:19 ` Jason Gunthorpe
2026-10-22 19:37 ` Mimi Zohar
2026-10-22 19:45 ` Jason Gunthorpe
2026-10-22 19:52 ` James Bottomley
2026-10-22 20:43 ` Mimi Zohar
2026-10-20 9:26 ` Jiri Pirko
2026-10-20 13:45 ` Mimi Zohar
2026-10-20 14:06 ` Jason Gunthorpe
2026-10-20 15:22 ` Mimi Zohar
2026-10-20 16:11 ` Yeoreum Yun
2026-10-20 16:52 ` Jason Gunthorpe
2026-10-21 12:23 ` Mimi Zohar
2026-10-21 13:18 ` Jarkko Sakkinen
2026-10-21 13:50 ` Yeoreum Yun
2026-10-21 13:51 ` Jason Gunthorpe
2026-10-21 14:31 ` Mimi Zohar
2026-10-21 14:39 ` Jason Gunthorpe
2026-10-21 12:48 ` James Bottomley
2026-10-21 13:55 ` Jason Gunthorpe
2026-10-19 12:40 ` Jarkko Sakkinen
2026-10-19 23:11 ` Jason Gunthorpe
2026-10-20 12:49 ` James Bottomley
2026-10-20 13:13 ` Jason Gunthorpe
2026-10-22 10:30 ` Aneesh Kumar K.V
2026-10-22 15:38 ` Jiri Pirko
2026-10-22 16:42 ` Jason Gunthorpe
2026-10-23 8:04 ` Aneesh Kumar K.V [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=yq5av76sj10a.fsf@kernel.org \
--to=aneesh.kumar@kernel.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=aik@amd.com \
--cc=alistair.francis@wdc.com \
--cc=ankita@nvidia.com \
--cc=cedric.xing@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=david.quigley@intel.com \
--cc=drdeeglaze@gmail.com \
--cc=elena.reshetova@intel.com \
--cc=jgg@ziepe.ca \
--cc=jic23@kernel.org \
--cc=jiri@resnulli.us \
--cc=jpiotrowski@nvidia.com \
--cc=kas@kernel.org \
--cc=ksinyuk@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=peter.fang@intel.com \
--cc=pgonda@google.com \
--cc=qinkun@google.com \
--cc=rick.p.edgecombe@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=sameo@meta.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=suzuki.poulose@arm.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.