sandbox: TDX on the run path, through a pinned PCK #399
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/sandbox-tdx-run-path"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The run path sealed and verified SEV-SNP only:
TeeConfigheld a VCEK, and both sealing andverify_run_evidencecalledverify_snp.A soundness fix first
verify_tdxtook the PCK key from the quote's own certification data and checked the quoting-enclave report against it. So a quote consistent with itself, endorsed by a key its maker generated, verified. Now:verify_tdx(…, pck)takes the PCK key the verifier pinned: from Intel's PCS with its chain checked, just as a VCEK comes from AMD's KDS.a_quote_endorsed_by_its_own_pck_is_refused.TDX on the run path
TeeAnchor { SevSnp(vcek), Tdx(pck) }plus averify_reportdispatcher.TeeConfig.anchorreplacesvcek. Sealing refuses a provider and anchor of different kinds.verify_run_evidencetakes the verifier's anchor and refuses evidence of another kind.LocalTdxProvideris a software-grounded TDX provider for wiring (real ECDSA-P256,Grounding::Software).ConfigfsTsmProvideris no longer hard-coded to SEV-SNP:for_kind(kind)sets the kind;providerattribute names another platform (sev_guestortdx_guest).Verification (build host)
--locked), plus sandbox-tee with theamd-kdsfeature.-D warningsis clean on the touched crates.Not exercised: real TDX hardware. As on SEV-SNP, fetching the PCK certificate from Intel's PCS is the deployment's step.
🤖 Generated with Claude Code
The run path sealed and verified SEV-SNP only: TeeConfig held a VCEK and both seal and verify_run_evidence called verify_snp, so a TDX guest could not run a confidential unit. Wiring TDX in exposed a soundness gap first. verify_tdx took the PCK key from the quote's own certification data and checked the QE report against it, so any quote that was consistent with itself, endorsed by a key its maker generated, verified. sandbox-tee: - verify_tdx takes the PCK key the verifier pinned (from Intel's PCS, its chain checked, as a VCEK comes from AMD's KDS); the quote must carry that key, and the QE report is checked against it. - TeeAnchor { SevSnp(vcek), Tdx(pck) } and verify_report dispatch on it. - LocalTdxProvider: a software-grounded TDX provider (real ECDSA-P256, dev keys, Grounding::Software), the TDX counterpart of LocalSnpProvider; the test-only quote builder becomes the crate-visible local_quote. - ConfigfsTsmProvider is no longer hard-coded to SEV-SNP: for_kind(kind), and a report is refused when the kernel's `provider` attribute names another platform (tsm_provider_kind: sev_guest, tdx_guest). sandbox-runtime: - TeeConfig.anchor replaces TeeConfig.vcek. Sealing refuses a provider and anchor of different kinds, then verifies through verify_report. - verify_run_evidence takes the verifier's anchor and refuses evidence of another kind. sandbox-cli is updated to the anchor. SPEC §7.6: the anchor rule (a report is trusted through a key the verifier pins, never one it carries) and the TDX PCK rule. The §9 readiness row is updated. Tests: - A quote endorsed by its own PCK is refused. - A local TDX quote verifies against its PCK. - TSM provider names map to kinds. - A report of another platform kind is refused. - A confidential run on TDX is sealed and verified, and refused for another challenge, outcome, PCK or kind. - A provider and anchor of different kinds cannot seal. Mutation testing: 10 mutants; 9 killed, 1 equivalent (checking the QE report with the quote's PCK once it is pinned equal). Verified on the build host: sandbox-rs 427 tests (--locked), sandbox-tee with amd-kds, and every conformance class; clippy -D warnings clean on sandbox-tee, -runtime, -cli. Repo checks pass, including lockfiles. Co-Authored-By: Claude Opus 5.5 <[email protected]>