| Filename | Latest commit message | Latest commit date |
|---|---|---|
5fd925ed16
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
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]> |
||
| .. | ||
| attestation.json | ||
| challenge.hex | ||
| intel-root.der | ||
| README.md | ||
A confidential run on TDX hardware, 2026-10-21
The report-data binding of SPEC §7.6 on genuine Intel silicon, with the PCK anchor derived from the quote's own certificate chain checked to Intel's root, and the run verified by a party other than the host.
What ran
- Platform: a confidential VM with Intel TDX (
c3-standard-4, kernel7.0.0-1014-gcp), created for the run and deleted after it. - Inside the guest: the reference host
(
confidential_run_tdx).- It took quotes through
configfs-tsm(providertdx_guest). - It derived the anchor from a probe quote's PCK chain, checked to Intel's root, which the verifier's side uploaded rather than the guest fetching it.
- It sealed an S6 run whose
report_databinds the unit, the receipt, the outcome and a 32-byte challenge (challenge.hex).
- It took quotes through
- The quote: DCAP version 4, TEE type
0x81. The interface returns it in an 8000-byte buffer, 4935 bytes of quote followed by padding. It travels in the attestation astee.report_hex.
The quote's certification data carries three certificates:
CN=Intel SGX PCK Certificate issued by CN=Intel SGX PCK Platform CA
CN=Intel SGX PCK Platform CA issued by CN=Intel SGX Root CA
CN=Intel SGX Root CA self-signed
The root it carries is byte-identical to Intel's published root
(intel-root.der), whose SHA-256 fingerprint is
44:A0:19:6B:2B:99:F8:89:B8:E1:49:E9:5B:80:7A:35:0E:74:24:96:43:99:E8:85:A7:CB:B8:CC:FA:B6:74:D3.
Compare it with the one Intel publishes, not with this file.
What it shows
Verified away from the guest, from these files alone:
cd ../../../sandbox-rs
cargo run -p sandbox-runtime --example verify_run -- \
../proof/hardware/2026-10-21-tdx/attestation.json \
"$(cat ../proof/hardware/2026-10-21-tdx/challenge.hex)" \
../proof/hardware/2026-10-21-tdx/intel-root.der
- The quote's PCK chain checks to Intel's root (
sandbox-tee::intel_pcs), and the quote verifies through that PCK: the quote signature, the QE report's endorsement of the attestation key, and the PCK's signature over the QE report. - Its
report_datais the binding of this attestation's unit, receipt and outcome, and of the challenge issued. It is refused for any other challenge, and without one. - An attestation whose outcome is changed is refused.
- Given another certificate in place of Intel's root, no anchor is derived.
What it does not show
- The unit is a fixed placeholder. This exercises the binding, the chain check and the verifier on real hardware, not an executor's isolation of a workload.
- Revocation was not consulted: Intel publishes CRLs for the PCK CAs, and checking them is the deployment's step.
- The receipt and Supervisor keys are fixed development keys. The trust here rests on the quote, not on those signatures.