From a88732428d42dd69a91a6a0a3ce723216c899f87 Mon Sep 17 00:00:00 2001 From: Imran Siddique Date: Tue, 18 Aug 2026 09:02:42 -0700 Subject: [PATCH] docs(testing): the TDX row covers the quote, not the TDREPORT (#370) This page exists to enforce one rule: no document describes cMCP as hardware-attested for a platform until a genuine quote from that platform has been verified end to end and the run is recorded here. The TDX row was at risk of being read wider than the run behind it. The recorded run verifies a DCAP v4 quote: attestation-key signature over header plus TD report body, the QE report binding, the PCK signature, and the PCK chain to the pinned Intel SGX Root CA. verify_tdx_measurement() also parses the 1024-byte TDREPORT_STRUCT from the TDX_CMD_GET_REPORT0 ioctl, which is a different artifact, and no real TDREPORT has ever been checked against it. That matters now because #371 found both TDREPORT field offsets wrong, MRTD read from inside REPORTMACSTRUCT.report_data and REPORTDATA read from the leading RESERVED block, and #527 corrected them against the published ABI. The correction is asserted against the ABI and against a property that needs no hardware to state, that a measurement must not move when only the nonce moves. Neither is a capture, and synthetic self-consistency is exactly what this page says is not validation. Nothing about the offsets being wrong for that long would have been visible to a reader of the table as it stood. Refs #370, #371, #527 Signed-off-by: Imran Siddique Co-Authored-By: Claude Opus 5 (1M context) --- docs/testing/hardware-validation.md | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/docs/testing/hardware-validation.md b/docs/testing/hardware-validation.md index 39c91f97..5f151acc 100644 --- a/docs/testing/hardware-validation.md +++ b/docs/testing/hardware-validation.md @@ -13,7 +13,7 @@ been verified end to end by `cmcp_verify`, and the run is recorded below. | Platform | Report parsing | Certificate chain | Report signature | Verified against real hardware evidence | |---|---|---|---|---| | AMD SEV-SNP (Azure CVM, vTPM-rooted) | Yes | Yes, to the real AMD ARK-Milan root | Yes | **Yes**, 2026-07-27, both from a stored capture and **live inside a running CVM** | -| Intel TDX (GCP C3, non-paravisor) | Yes | Yes, to the pinned Intel SGX Root CA | Yes | **Yes**, 2026-07-27, capture of 2026-07-21 | +| Intel TDX (GCP C3, non-paravisor) | Yes | Yes, to the pinned Intel SGX Root CA | Yes | **Yes**, 2026-07-27, capture of 2026-07-21. DCAP quote path only; the TDREPORT path is unvalidated, see below | | TPM 2.0 (Azure vTPM, Trusted Launch) | Yes | Not yet (`ek_cert_chain` stays unverified, see #431) | Yes | **Yes**, 2026-07-31. AK-signed quote verified end to end, tampered copies rejected; certificate chain still open | | NVIDIA GPU CC (H100/H200) | Not implemented | | | No | @@ -113,6 +113,18 @@ The capture directory holds `tdx_quote.bin`. Optional: `collateral/intel_root_ca to override the pinned root, and `report_data.hex` to assert the report_data binding. The quote is not committed: the PCK certificate identifies the CPU. +What this run does not cover: the TDREPORT path. `verify_tdx_measurement()` +parses the 1024-byte TDREPORT_STRUCT returned by the `TDX_CMD_GET_REPORT0` +ioctl, which is a different artifact from the DCAP quote captured here, and no +real TDREPORT has been checked against it. #371 found both of its field offsets +wrong -- `MRTD` read from inside `REPORTMACSTRUCT.report_data` and `REPORTDATA` +read from the leading RESERVED block -- and #527 corrected them against the +published Intel TDX Module ABI. The correction is asserted against the ABI and +against a property no hardware is needed to state (a measurement must not move +when only the nonce moves), which is not the same as a capture. The row above +covers quote verification; read it as covering measurement provenance only once +a TDREPORT capture appears here. + This run is what found the parser defect fixed alongside this page. Real DCAP v4 quotes nest the Quoting Enclave material under a type-6 `QE_REPORT_CERTIFICATION_DATA` header; the parser read the QE report six bytes