328d89b676
All checks were successful
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 5s
repository checks / lockfiles, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 47s
standards workspaces build + test / jcp-rs (jcp-conformance, jcp/jcp-rs, -p jcp-energy --features nvml, jcp-rs, linux) (pull_request) Successful in 1m43s
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 / proof-rs (proof-conformance, proof/proof-rs, proof-rs, linux, true) (pull_request) Successful in 1m33s
standards workspaces build + test / sandbox-rs (sandbox-conformance, sandbox/sandbox-rs, sandbox-rs, linux) (pull_request) Successful in 2m47s
standards workspaces build + test / joulecontract-rs (joulecontract/joulecontract-rs, joulecontract-rs, linux-arm64, true) (pull_request) Successful in 1m57s
standards workspaces build + test / joule-code-rs (joule-code/joule-code-rs, joule-code-rs, linux-arm64, true) (pull_request) Successful in 4m59s
standards workspaces build + test / macOS energy backends (pull_request) Successful in 7m46s
standards workspaces build + test / jouledesk-rs (jouledesk/jouledesk-rs, jouledesk-rs, macos) (pull_request) Successful in 2m50s
The run binding of #392 had only met software-grounded reports. This runs the reference host inside an SEV-SNP guest and records the result as evidence anyone can re-check offline. sandbox-runtime examples: - confidential_run, run inside the guest. It takes reports through configfs-tsm and seals an S6 run against a challenge; the report_data is the run binding of SPEC §7.6. It then checks the attestation through the chip's VCEK: verified against the challenge, refused against another and against none. - verify_run: the third party's check, from the attestation, the challenge issued and the VCEK alone. sandbox/proof/hardware/2026-10-21-sev-snp: the attestation (with the 1184-byte v5 report), the challenge, the chip's VCEK and AMD's cert chain, and a README saying what it shows and what it does not. The unit is a placeholder, so this exercises the binding and verifier on silicon, not isolation. Checked on our side, away from the guest: - The VCEK was fetched from AMD's KDS by the chip id and TCB inside the report, and openssl verifies it to ARK-Milan. - 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"): the AMD signature covers the outcome through the binding. sandbox-tee: the version comment now says what the code does (v2 layout and later; a v5 report verified on hardware). Co-Authored-By: Claude Opus 5.5 <[email protected]>
56 lines
2.4 KiB
Markdown
56 lines
2.4 KiB
Markdown
# A confidential run on SEV-SNP hardware, 2026-10-21
|
|
|
|
The report-data binding of SPEC §7.6, exercised on genuine AMD silicon and
|
|
verified by a party other than the host.
|
|
|
|
## What ran
|
|
|
|
- **Platform:** a confidential VM with AMD SEV-SNP, on an AMD Milan processor
|
|
(`n2d-standard-2`, image `ubuntu-2404-noble-amd64-v20261016`). It was created
|
|
for the run and deleted after it.
|
|
- **Inside the guest:** the reference host
|
|
([`confidential_run`](../../../sandbox-rs/crates/sandbox-runtime/examples/confidential_run.rs)).
|
|
It took a report through `configfs-tsm` (the kernel named its provider
|
|
`sev_guest`) and sealed an S6 run. Its `report_data` is the run binding:
|
|
the unit, the receipt, the outcome, and a 32-byte challenge chosen by the
|
|
party that started the run ([`challenge.hex`](challenge.hex)).
|
|
- **The report:** version 5, 1184 bytes, signed with the chip's VCEK. It
|
|
travels in the attestation as `tee.report_hex`.
|
|
|
|
## What it shows
|
|
|
|
Verified away from the guest, from these files alone:
|
|
|
|
```text
|
|
cd ../../../sandbox-rs
|
|
cargo run -p sandbox-runtime --example verify_run -- \
|
|
../proof/hardware/2026-10-21-sev-snp/attestation.json \
|
|
"$(cat ../proof/hardware/2026-10-21-sev-snp/challenge.hex)" \
|
|
../proof/hardware/2026-10-21-sev-snp/vcek.der
|
|
```
|
|
|
|
- The report verifies through the VCEK. Its `report_data` is 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: the AMD signature covers
|
|
the outcome through the binding.
|
|
|
|
The VCEK ([`vcek.der`](vcek.der)) was fetched from AMD's KDS by the chip id and
|
|
reported TCB inside the report. It chains to AMD's root
|
|
([`cert_chain.pem`](cert_chain.pem): `SEV-Milan`, then `ARK-Milan`):
|
|
|
|
```text
|
|
openssl x509 -inform der -in vcek.der -out vcek.pem
|
|
openssl verify -CAfile <ARK-Milan> -untrusted <SEV-Milan> vcek.pem
|
|
```
|
|
|
|
The ARK's SHA-256 fingerprint is
|
|
`69:D0:63:B4:53:44:D2:6A:2E:94:E1:F4:21:0D:E4:9E:F5:55:30:82:87:D4:C1:74:44:5C:95:63:9A:54:0B:CD`.
|
|
Compare it with the one AMD publishes, not with this file.
|
|
|
|
## What it does not show
|
|
|
|
- The unit is a fixed placeholder. This exercises the binding and the verifier
|
|
on real hardware, not an executor's isolation of a workload.
|
|
- The receipt and Supervisor keys are fixed development keys. The trust here
|
|
rests on the hardware report, not on those signatures.
|