From: Dave Jiang <dave.jiang@intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>,
"Reshetova, Elena" <elena.reshetova@intel.com>
Cc: Xu Yilun <yilun.xu@linux.intel.com>,
"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
Jiri Pirko <jiri@resnulli.us>,
"Tian, Kevin" <kevin.tian@intel.com>,
Alexey Kardashevskiy <aik@amd.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Steven Price <steven.price@arm.com>,
Kiryl Shutsemau <kas@kernel.org>,
"Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Jonathan Cameron <jic23@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Ashish Kalra <ashish.kalra@amd.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
John Allen <john.allen@amd.com>, Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
"patches@lists.linux.dev" <patches@lists.linux.dev>
Subject: Re: [RFC PATCH v1 10/11] virt: coco: arm-cca-host: Publish slot zero and establish streams after acceptance
Date: Fri, 6 Nov 2026 08:53:39 -0700 [thread overview]
Message-ID: <e05a71df-3b20-45a3-bb46-fb1bdad164c8@intel.com> (raw)
In-Reply-To: <a3f95140-c49f-42fc-b92c-73c8cf98336d@intel.com>
On 11/4/26 9:54 AM, Dave Jiang wrote:
>
>
> On 11/4/26 6:41 AM, Jason Gunthorpe wrote:
> <--snip-->
>
>> Is there a PDF for TDX's SPDM flow someplace? I will try to draft a
>> more complete document
>
> TDX connect architecture spec
> https://cdrdv2-public.intel.com/862706/Intel%20TDX%20Connect%20EAS%20354629%20004.pdf
> 2.7.5 Figure 2.6
>
> TDX connect TEE-IO device guide
> https://cdrdv2-public.intel.com/861654/whitepaper-tee-io-device-guide-v0-7-0.pdf
> Appendix B.1.1 Table B-1
I generated a diagram that hopefully better reflects Option A with TDX better than the current public documentations:
Option (a) on TDX, with the current TDX Connect ABI: slot 0 only, no TDX
change. Numbers in the left margin point to the notes below.
----> call <- - - return
<----> SPDM request and response in clear text, relayed by the host
<====> the same, inside the SPDM session
Userspace Host kernel TDX Module Device
(systemd, (PCI/TSM, (TSM) (DSM)
verifier) tdx-host)
| | | |
=== sysfs connect ==========================================================
| | | |
(1) | connect | | |
|------------------->| | |
| | | |
=== Step 1: START CONNECT ==================================================
| | | |
| START CONNECT | | |
|------------------->| | |
| | | |
| 0 (no-op) | | |
|<- - - - - - - - - -| | |
| | | |
=== Step 2: query certificates, query VCA items ============================
| | | |
| query certificates | | |
|------------------->| | |
| | | |
| -EOPNOTSUPP | | |
|<- - - - - - - - - -| | |
| | | |
=== Step 3: FINISH CONNECT with slot S =====================================
| | | |
| FINISH CONNECT(S) | | |
|------------------->| | |
| | | |
| if S != 0: | | |
(2) | refused | | |
|<- - - - - - - - - -| | |
| | | |
| if S == 0: | | |
(3) | | TDH.SPDM.CONNECT | |
| |---------------------->| |
| | | |
(4) | | | GET_VERSION |
| | |<---------------------->|
| | | GET_CAPABILITIES |
| | |<---------------------->|
| | | NEGOTIATE_ALGORITHMS |
| | |<---------------------->|
| | | GET_CERTIFICATE slot 0 |
| | |<---------------------->|
(5) | | | KEY_EXCHANGE slot 0 |
| | |<---------------------->|
| | | FINISH |
| | |<======================>|
| | | GET_MEASUREMENTS |
| | |<======================>|
| | | GET_TDISP_VERSION |
| | |<======================>|
| | | GET_TDISP_CAPABILITIES |
| | |<======================>|
| | | |
(6) | | device info | |
| |<- - - - - - - - - - - | |
| | | |
| 0 | | |
|<- - - - - - - - - -| | |
| | | |
=== Step 4: query certificates, query final transcript items ===============
| | | |
| query certificates | | |
|------------------->| | |
| | | |
| slot 0's chain | | |
|<- - - - - - - - - -| | |
| | | |
| query transcript | | |
|------------------->| | |
| | | |
(6) | device info | | |
|<- - - - - - - - - -| | |
| | | |
.--- optional: fresh measurements for a caller's nonce ---------------.
| | | |
| nonce | | |
|------------------->| | |
| | | |
(7) | | TDH.SPDM.MNG(nonce) | |
| |---------------------->| |
| | | |
| | | GET_CERTIFICATE |
| | |<======================>|
| | | GET_MEASUREMENTS |
| | |<======================>|
| | | |
| | new device info | |
| |<- - - - - - - - - - - | |
| | | |
| one-shot result | | |
|<- - - - - - - - - -| | |
| | | |
'---------------------------------------------------------------------'
| | | |
=== Step 5: ACCEPT (host) ==================================================
| | | |
| ACCEPT | | |
|------------------->| | |
| | | |
(8) | | TDH.IDE.STREAM.* | |
| |---------------------->| |
| | | |
| | | IDE_KM key programming |
| | |<======================>|
Notes:
(1) Creates the attestation endpoint only; no TSM call.
(2) TDH.SPDM.CONNECT has no KEY_EXCHANGE slot input.
CERTIFICATE_SLOT_MASK, the only slot field in SPDM_CONFIG_INFO_T, is
the "Device certificate request slot mask" [ABI 3.3.2.2]: it picks
which chains to read, not the slot. So userspace can't enumerate
slots by repeating step 3.
(3) TDH.SPDM.CREATE runs first. The kernel sets CERTIFICATE_SLOT_MASK to
0x01, so the TSM reads only slot 0's chain. It could also read slots
1-7 inside the session [GUIDE B.1.1, Table B-1], but no signature
would cover them: KEY_EXCHANGE hashes only the chain of the slot it
names [SPDM 10.18.1]. So (a) doesn't report them.
(4) The host relays each message over DOE [ABI 3.3.3, 4.2.20]. No
GET_DIGESTS and no CHALLENGE [ARCH 2.7.5, Figure 2.6]. The guide's
session setup example also reads slot 0's chain before KEY_EXCHANGE
[GUIDE B.1.1, Table B-1].
(5) The TSM verifies the KEY_EXCHANGE_RSP signature [SPDM para 630]. The
host trusts that check, so it keeps no KEY_EXCHANGE messages.
(6) SPDM_DEVICE_ATTESTATION_INFO_T [ABI 3.3.2.4]: SPDM and TDISP
capabilities, TDISP version, the requested chains, and MEASUREMENT.
MEASUREMENT is the signed SPDM measurement log, Concatenate(VCA,
GET_MEASUREMENTS_REQUEST1, MEASUREMENTS_RESPONSE1, ...,
GET_MEASUREMENTS_REQUESTn, MEASUREMENTS_RESPONSEn) [SPDM 10.12.3].
The last MEASUREMENTS carries the signature. The TDX Module keeps
the info's digest. The kernel keeps the info as immutable startup
data.
(7) DEV_INFO_RECOLLECTION puts the caller's nonce in GET_MEASUREMENTS
[ABI 3.3.2.3], and the TSM reads the chains again
[GUIDE B.1.5, Table B-5]. The device signs the new measurement log,
nonce included [SPDM 10.12.3]. That signature is what protects the
new measurements. The verifier must check it with the leaf key of
slot 0, the slot KEY_EXCHANGE used, and must find its nonce in the
log to know the result is fresh. The kernel hands the result over
once and doesn't store it.
(8) TDH.IDE.STREAM.CREATE, then TDH.IDE.STREAM.KM. IDE setup moves from
connect to ACCEPT.
Sources:
[ABI] TDX Connect ABI Reference Specification 2.1 V0.66
https://cdrdv2.intel.com/v1/dl/getContent/858625
[ARCH] Intel TDX Connect Architecture Specification, 354629-003
https://cdrdv2.intel.com/v1/dl/getContent/773614
[GUIDE] Intel TDX Connect TEE-IO Device Guide, 354272-002
https://cdrdv2.intel.com/v1/dl/getContent/772642
[SPDM] DMTF DSP0274 1.4.1
next prev parent reply other threads:[~2026-11-06 15:53 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-28 15:26 [RFC PATCH v1 00/11] PCI/TSM: Add CTLV attestation Aneesh Kumar K.V (Arm)
2026-10-28 15:26 ` [RFC PATCH v1 01/11] attestation: Restrict inherited operations per instance Aneesh Kumar K.V (Arm)
2026-10-30 13:29 ` Jiri Pirko
2026-10-28 15:26 ` [RFC PATCH v1 02/11] attestation: Filter evidence objects " Aneesh Kumar K.V (Arm)
2026-10-30 13:44 ` Jiri Pirko
2026-10-31 6:24 ` Aneesh Kumar K.V
2026-11-02 19:14 ` Jiri Pirko
2026-10-28 15:26 ` [RFC PATCH v1 03/11] attestation: Enter secure operation when evidence is accepted Aneesh Kumar K.V (Arm)
2026-10-30 13:51 ` Jiri Pirko
2026-10-30 15:36 ` Jason Gunthorpe
2026-10-31 4:09 ` Aneesh Kumar K.V
2026-11-02 11:28 ` Jiri Pirko
2026-10-28 15:26 ` [RFC PATCH v1 04/11] attestation: Bind object selection to accepted evidence snapshots Aneesh Kumar K.V (Arm)
2026-10-28 15:26 ` [RFC PATCH v1 05/11] attestation: Make the evidence-get challenge attribute optional Aneesh Kumar K.V (Arm)
2026-10-28 15:26 ` [RFC PATCH v1 06/11] PCI/TSM: Describe the PCI attestation control family Aneesh Kumar K.V (Arm)
2026-10-30 14:01 ` Jiri Pirko
2026-10-30 15:43 ` Jason Gunthorpe
2026-11-02 12:45 ` Jiri Pirko
2026-11-03 15:45 ` Jason Gunthorpe
2026-11-04 9:21 ` Jiri Pirko
2026-11-04 14:00 ` Jason Gunthorpe
2026-10-31 4:05 ` Aneesh Kumar K.V
2026-11-02 11:50 ` Jiri Pirko
2026-11-03 15:35 ` Jason Gunthorpe
2026-10-31 4:22 ` Aneesh Kumar K.V
2026-11-02 11:30 ` Jiri Pirko
2026-11-03 15:39 ` Jason Gunthorpe
2026-10-28 15:26 ` [RFC PATCH v1 07/11] attestation: Add attestation helpers for PCI/TSM integration Aneesh Kumar K.V (Arm)
2026-10-28 15:26 ` [RFC PATCH v1 08/11] PCI/TSM: Bind CTLV attestation to connected and locked contexts Aneesh Kumar K.V (Arm)
2026-10-28 22:56 ` Dave Jiang
2026-10-29 5:30 ` Aneesh Kumar K.V
2026-10-29 12:41 ` Jason Gunthorpe
2026-10-30 14:04 ` Jiri Pirko
2026-10-30 14:08 ` Jiri Pirko
2026-10-30 15:39 ` Jason Gunthorpe
2026-11-02 12:11 ` Jiri Pirko
2026-11-03 15:41 ` Jason Gunthorpe
2026-10-28 15:26 ` [RFC PATCH v1 09/11] crypto/ccp: Defer SEV-TIO link setup until evidence acceptance Aneesh Kumar K.V (Arm)
2026-11-06 7:47 ` Alexey Kardashevskiy
2026-11-06 13:14 ` Aneesh Kumar K.V
2026-11-06 14:21 ` Jason Gunthorpe
2026-10-28 15:26 ` [RFC PATCH v1 10/11] virt: coco: arm-cca-host: Publish slot zero and establish streams after acceptance Aneesh Kumar K.V (Arm)
2026-10-29 16:56 ` Dave Jiang
2026-10-29 17:10 ` Jason Gunthorpe
2026-10-30 9:58 ` Reshetova, Elena
2026-10-30 13:15 ` Jason Gunthorpe
2026-10-31 3:47 ` Aneesh Kumar K.V
2026-11-02 10:11 ` Reshetova, Elena
2026-11-02 17:26 ` Jason Gunthorpe
2026-11-03 12:01 ` Reshetova, Elena
2026-11-03 15:16 ` Jason Gunthorpe
2026-11-04 8:03 ` Xu Yilun
2026-11-04 9:49 ` Reshetova, Elena
2026-11-04 13:41 ` Jason Gunthorpe
2026-11-04 16:54 ` Dave Jiang
2026-11-06 15:53 ` Dave Jiang [this message]
2026-11-06 19:30 ` Jason Gunthorpe
2026-11-06 22:39 ` Dave Jiang
2026-11-08 18:33 ` Jason Gunthorpe
2026-11-04 9:03 ` Reshetova, Elena
2026-11-04 13:48 ` Jason Gunthorpe
2026-11-06 8:24 ` Aneesh Kumar K.V
2026-11-06 12:49 ` Reshetova, Elena
2026-11-06 15:53 ` Aneesh Kumar K.V
2026-11-06 18:54 ` Jason Gunthorpe
2026-11-03 16:31 ` Aneesh Kumar K.V
2026-11-03 17:56 ` Jason Gunthorpe
2026-11-02 10:05 ` Reshetova, Elena
2026-11-02 10:22 ` Reshetova, Elena
2026-11-02 17:37 ` Jason Gunthorpe
2026-10-28 15:26 ` [RFC PATCH v1 11/11] virt: coco: arm-cca-guest: Refresh selected evidence against trusted digests Aneesh Kumar K.V (Arm)
2026-10-30 12:34 ` [RFC PATCH v1 00/11] PCI/TSM: Add CTLV attestation Xu Yilun
2026-10-30 15:32 ` Jason Gunthorpe
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=e05a71df-3b20-45a3-bb46-fb1bdad164c8@intel.com \
--to=dave.jiang@intel.com \
--cc=aik@amd.com \
--cc=aneesh.kumar@kernel.org \
--cc=ashish.kalra@amd.com \
--cc=bhelgaas@google.com \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=elena.reshetova@intel.com \
--cc=jgg@nvidia.com \
--cc=jic23@kernel.org \
--cc=jiri@resnulli.us \
--cc=john.allen@amd.com \
--cc=kas@kernel.org \
--cc=kevin.tian@intel.com \
--cc=linux-coco@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=patches@lists.linux.dev \
--cc=rick.p.edgecombe@intel.com \
--cc=steven.price@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=thomas.lendacky@amd.com \
--cc=will@kernel.org \
--cc=yilun.xu@linux.intel.com \
/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.