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

2026-10-21

Transaction Science

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

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

328d89b676

• View at this point in history

2026-10-21 16:25:26 -04:00