VoltageGPU evidence: AMD SEV-SNP attestation report of a Confidential CPU VM (cpu-small-amd)
Captured 2026-10-27 13:13 UTC inside a VoltageGPU Confidential CPU VM, tier cpu-small-amd
(AMD EPYC, AMD SEV-SNP, no GPU), by snp-proof-in-the-vm.sh, on a 64-byte challenge sent
from outside the VM.
Tutorial: https://voltagegpu.com/blog/verify-amd-sev-snp-attestation-confidential-cpu
Script:   https://voltagegpu.com/blog/two-proofs/evidence/snp-proof-in-the-vm.sh

Files
  All files but this README are the content of the archive /tmp/snp-proof.tgz that the script
  wrote in the VM, byte for byte. SHA256SUMS was computed in the VM and does not cover README.txt.
  report.bin      the attestation report, 1184 bytes, version 4; REPORT_DATA is the challenge
  report.txt      the same report decoded in the VM by snpguest 0.11.0 (display report)
  challenge.txt   the challenge: 64 bytes written as 128 hex characters
  verify.txt      snpguest verify certs and verify attestation, run in the VM
  certs/          ark.pem, ask.pem, vcek.pem, as the VM fetched them from AMD's key server
  SHA256SUMS      SHA-256 of the seven files above

Check it on your own machine
  The archive comes from the VM, so do not trust the certificates above. Fetch AMD's chain and
  the VCEK from AMD (kdsintf.amd.com) into a new directory, check that the root is one of the
  AMD roots pinned in the script, then verify report.bin with those certificates. The commands,
  and their output on 2026-10-27, are in the tutorial. The script has three offline modes for
  it: --check-report-data, --check-report-policy and --check-ark. This report was requested at
  VMPL 1 by the previous version of the script, which left the level to snpguest 0.11.0: give 1
  as the last argument of --check-report-policy (the current script expects 0 by default).

What it shows
  A report signed by the VCEK of an AMD chip whose certificate chains to AMD's Milan root
  (ARK, SHA-256 69d063b45344d26a2e94e1f4210de49ef555308287d4c174445c95639a540bcd), carrying
  this challenge, for a guest launched with a policy that forbids debugging (0x30000).

What it does not show
  - Which image runs: the launch measurement is compared with no reference value.
  - At which VMPL the guest runs: VMPL 1 is the level snpguest 0.11.0 requests by default, and the
    script that made this report did not name another; the firmware accepts a level equal to or
    higher than the requester's, so the request came from VMPL 0 or 1. The guest kernel uses
    VMPCK0 ("using vmpck_id 0"), consistent with VMPL 0 and no SVSM; not yet confirmed with a
    report requested at VMPL 0.
  - When the challenge was chosen: for a run you did not start, only a challenge you generate
    yourself shows that a report is fresh.
  - That the guest that signed is the machine reached over SSH: nothing in the report binds them.
  - That the TCB versions are the latest AMD has published: not compared.