sandbox: a confidential run sealed on SEV-SNP hardware, verified by a third party #412

Merged

dcharlot merged 1 commit from feat/sandbox-hardware-check into main 2026-10-21 23:05:31 -04:00

Conversation 0 Commits 1 Files changed 9 +231 -2

dcharlot commented 2026-10-21 16:26:03 -04:00

Owner

Copy link

The run binding of #392 (SPEC §7.6) had only met software-grounded reports. This PR runs the reference host inside an SEV-SNP guest and records the result as evidence anyone can re-check offline.

What ran

• Platform: a confidential VM on AMD Milan (n2d-standard-2, Ubuntu 24.04), created for the run and deleted after it.
• Inside the guest: examples/confidential_run.
  • It took reports through configfs-tsm (provider sev_guest).
  • It sealed an S6 run whose report_data is the run binding: unit, receipt, outcome, and a 32-byte challenge from the party that started the run.
• The report: version 5, 1184 bytes, signed with the chip's VCEK. It travels in the attestation.

Checked on our side, away from the guest

• The key. The VCEK was fetched from AMD's KDS by the chip id and TCB inside the report. openssl verifies it to ARK-Milan, and its fingerprint is in the README.
• The run. examples/verify_run, run on the build host from the attestation, the challenge and the VCEK alone:
  • verifies the run;
  • refuses it for another challenge, and without one.
• Tampering. An attestation with its outcome changed is refused ("report-data binding mismatch"): the AMD signature covers the outcome through the binding.

The evidence lives in sandbox/proof/hardware/2026-10-21-sev-snp/: the attestation, the challenge, the VCEK, the cert chain, and a README that also says what this does not show. The unit is a placeholder, so this tests the binding and verifier on silicon, not an executor's isolation.

The sandbox-tee version comment is corrected: the verifier models the v2 layout and later, and a v5 report verified on hardware.

Verification

• The examples build with --locked, and verify_run passes on the rebased tree.
• Clippy -D warnings is clean on the examples.
• Repo checks pass, including lockfiles.

🤖 Generated with Claude Code

The run binding of #392 (SPEC §7.6) had only met software-grounded reports. This PR runs the reference host inside an **SEV-SNP guest** and records the result as evidence anyone can re-check offline. ## What ran - **Platform:** a confidential VM on AMD Milan (`n2d-standard-2`, Ubuntu 24.04), created for the run and deleted after it. - **Inside the guest:** `examples/confidential_run`. - It took reports through `configfs-tsm` (provider `sev_guest`). - It sealed an S6 run whose `report_data` is the run binding: unit, receipt, outcome, and a 32-byte challenge from the party that started the run. - **The report:** version 5, 1184 bytes, signed with the chip's VCEK. It travels in the attestation. ## Checked on our side, away from the guest - **The key.** The VCEK was fetched from AMD's KDS by the chip id and TCB inside the report. `openssl` verifies it to **ARK-Milan**, and its fingerprint is in the README. - **The run.** `examples/verify_run`, run on the build host from the attestation, the challenge and the VCEK alone: - **verifies** the run; - **refuses** it for another challenge, and without one. - **Tampering.** An attestation with its outcome changed is **refused** ("report-data binding mismatch"): the AMD signature covers the outcome through the binding. The evidence lives in `sandbox/proof/hardware/2026-10-21-sev-snp/`: the attestation, the challenge, the VCEK, the cert chain, and a README that also says what this does **not** show. The unit is a placeholder, so this tests the binding and verifier on silicon, not an executor's isolation. The sandbox-tee version comment is corrected: the verifier models the v2 layout and later, and a v5 report verified on hardware. ## Verification - The examples build with `--locked`, and `verify_run` passes on the rebased tree. - Clippy `-D warnings` is clean on the examples. - Repo checks pass, including lockfiles. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 1 commit 2026-10-21 16:26:03 -04:00

sandbox: a confidential run sealed on SEV-SNP hardware, verified by a third party ... 328d89b676

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]>

dcharlot merged commit 6e05089fb3 into main 2026-10-21 23:05:31 -04:00

dcharlot referenced this pull request from a commit 2026-10-21 23:05:32 -04:00

Merge pull request 'sandbox: a confidential run sealed on SEV-SNP hardware, verified by a third party' (#412) from feat/sandbox-hardware-check into main

dcharlot referenced this pull request 2026-10-22 06:53:44 -04:00

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

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

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!412

No description provided.