sandbox: a confidential run sealed on TDX hardware, its PCK checked to Intel's root #436

Merged
dcharlot merged 1 commit from feat/tdx-hardware-check into main 2026-10-22 09:27:04 -04:00
Owner

A confidential sandbox run sealed on TDX hardware, with the evidence committed so anyone can check it away from the guest. This is the TDX counterpart of #412 (SEV-SNP) and uses the PCK chain check from #415.

What is in it

  • sandbox/proof/hardware/2026-10-21-tdx/: the attestation, the challenge and Intel's SGX Root CA (intel-root.der, uploaded from our side, never fetched by the guest), plus a README with the run and the command that checks it.
  • examples/confidential_run_tdx.rs: on a TDX guest, takes a probe quote through configfs-tsm, gets the PCK from the quote's certification data checked to the pinned root, and seals an S6 run bound to the challenge.
  • examples/verify_run.rs now handles both TEE kinds. For SEV-SNP the VCEK is given. For TDX it takes the Intel root and gets the PCK from the quote's own chain, checked to that root, with the TDX baseline policy. A PCK the quote carries is never trusted on its own.

Checked on the build host, from the committed files alone

  • SEV-SNP evidence: verified; refused under another challenge; refused under none.
  • TDX evidence: verified (measurement c1ee9c16…0a5); refused under another challenge; refused under none.
  • Outcome tampered to Failed: refused with "report-data binding mismatch".
  • The SEV-SNP VCEK given as the Intel root: refused with "the chain ends in another root than the pinned one".
  • cargo clippy -p sandbox-runtime --examples --tests -D warnings is clean, and the sandbox-runtime tests pass (22).

🤖 Generated with Claude Code

A confidential sandbox run sealed on TDX hardware, with the evidence committed so anyone can check it away from the guest. This is the TDX counterpart of #412 (SEV-SNP) and uses the PCK chain check from #415. ## What is in it - `sandbox/proof/hardware/2026-10-21-tdx/`: the attestation, the challenge and Intel's SGX Root CA (`intel-root.der`, uploaded from our side, never fetched by the guest), plus a README with the run and the command that checks it. - `examples/confidential_run_tdx.rs`: on a TDX guest, takes a probe quote through configfs-tsm, gets the PCK from the quote's certification data checked to the pinned root, and seals an S6 run bound to the challenge. - `examples/verify_run.rs` now handles both TEE kinds. For SEV-SNP the VCEK is given. For TDX it takes the Intel root and gets the PCK from the quote's own chain, checked to that root, with the TDX baseline policy. A PCK the quote carries is never trusted on its own. ## Checked on the build host, from the committed files alone - SEV-SNP evidence: verified; refused under another challenge; refused under none. - TDX evidence: verified (measurement `c1ee9c16…0a5`); refused under another challenge; refused under none. - Outcome tampered to `Failed`: refused with "report-data binding mismatch". - The SEV-SNP VCEK given as the Intel root: refused with "the chain ends in another root than the pinned one". - `cargo clippy -p sandbox-runtime --examples --tests -D warnings` is clean, and the `sandbox-runtime` tests pass (22). 🤖 Generated with [Claude Code](https://claude.com/claude-code)
sandbox: a confidential run sealed on TDX hardware, its PCK checked to Intel's root
All checks were successful
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 6s
repository checks / lockfiles, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 41s
standards workspaces build + test / joule-ui-rs (joule-ui/joule-ui-rs, joule-ui-rs, linux) (pull_request) Successful in 1m14s
standards workspaces build + test / jcp-rs (jcp-conformance, jcp/jcp-rs, -p jcp-energy --features nvml, jcp-rs, linux) (pull_request) Successful in 1m39s
standards workspaces build + test / joulecontract-rs (joulecontract/joulecontract-rs, joulecontract-rs, linux-arm64, true) (pull_request) Successful in 1m8s
standards workspaces build + test / joule-code-rs (joule-code/joule-code-rs, joule-code-rs, linux-arm64, true) (pull_request) Successful in 3m53s
standards workspaces build + test / sandbox-rs (sandbox-conformance, sandbox/sandbox-rs, -p sandbox-tee --features amd-kds,intel-pcs, sandbox-rs, linux) (pull_request) Successful in 2m39s
standards workspaces build + test / proof-rs (proof-conformance, proof/proof-rs, proof-rs, linux, true) (pull_request) Successful in 3m54s
standards workspaces build + test / macOS energy backends (pull_request) Successful in 7m37s
standards workspaces build + test / jouledesk-rs (jouledesk/jouledesk-rs, jouledesk-rs, macos) (pull_request) Successful in 2m49s
5fd925ed16
The TDX path (#399) and its PCK chain check (#415) had only met quotes this
crate built itself. This runs the reference host inside a TDX guest and
records the result as evidence anyone can re-check offline.

sandbox-runtime examples:
- confidential_run_tdx, run inside the guest. It takes quotes through
  configfs-tsm and derives the PCK anchor from a probe quote's chain,
  checked to Intel's root, which the verifier's side supplies. It seals an
  S6 run against a challenge, then checks the attestation: verified against
  the challenge, refused against another and against none.
- verify_run now reads the evidence kind. For TDX its anchor argument is
  Intel's root, and the PCK is derived from the quote's chain checked to it.
  SEV-SNP is unchanged, and the 2026-10-21 SEV-SNP evidence still verifies.
- sandbox-runtime's dev-dependencies enable sandbox-tee's intel-pcs feature
  for these examples.

sandbox/proof/hardware/2026-10-21-tdx: the attestation (with the DCAP v4
quote), the challenge, Intel's published root certificate, and a README
saying what it shows and what it does not. The unit is a placeholder and
revocation lists were not consulted.

Checked on our side, away from the guest:
- The quote's chain is PCK Certificate, then PCK Platform CA, then Root CA,
  and its root is byte-identical to Intel's published root (SHA-256
  44:A0:19:6B:…:74:D3).
- verify_run on the build host verifies the run, and refuses another
  challenge and no challenge.
- An attestation with its outcome changed is refused (report-data binding
  mismatch).
- Another certificate given as the root yields no anchor.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Transaction-Science/open-standards!436
No description provided.