Key Takeaways
- A report signed by the CPU, on your challenge. In a Confidential CPU VM (AMD EPYC with AMD SEV-SNP, no GPU), one script asks the AMD secure processor for an attestation report that carries 64 bytes you chose on your own machine.
- The check that counts runs on your machine. You fetch AMD's certificate chain from AMD, check its root against AMD's fingerprint and verify the report with snpguest 0.11.0. On 27 October 2026 every check passed on our published run, in about three seconds.
- It proves less than the word confidential suggests. The launch measurement is compared with no reference image, the VMPL field is only the level the tool requested, and a run you did not start cannot show you that its challenge was fresh.
A confidential VM is worth something only if you can check it without trusting whoever runs the host. On AMD EPYC with SEV-SNP, that check is an attestation report: a structure signed by the AMD secure processor of the chip, which carries 64 bytes of your choice. This tutorial gets one from a VoltageGPU Confidential CPU VM, tier cpu-small-amd, and verifies it on your own machine, with AMD's chain fetched from AMD and AMD's root pinned.
Every output below comes from 27 October 2026. The report we publish was made at 13:13 UTC in a cpu-small-amd VM, on a challenge sent from outside the VM. Its files are in a public folder, byte for byte. The checks on the reader's side ran again on 27 October 2026 at 14:42 UTC, with the current version of our script, on Ubuntu 24.04 under WSL2, in fresh directories, and their output is pasted as printed.
The published run, file by file
The archive the script wrote in the VM at 13:13 UTC, unpacked and served as is. SHA256SUMS was computed in the VM. The README says what the files show and what they do not.
What an SEV-SNP attestation report is
On these VMs, the memory of the guest is encrypted with a key managed by the AMD secure processor, which is built into the processor. When software inside the guest asks for it, the secure processor fills in a report about that guest and signs it. The fields used in this tutorial:
- REPORT_DATA: 64 bytes chosen by whoever asks for the report. With a fresh random challenge there, the report cannot have been made in advance.
- Measurement: a hash, computed by the secure processor, of what was loaded into the guest at launch.
- Guest policy: rules fixed at launch, among them whether debugging is allowed.
- VMPL: a privilege level written in the request (more on it in Step 3).
- TCB versions and chip ID: the firmware and microcode versions of the platform, and the identity of the chip.
The report is signed with the chip's VCEK, a key tied to that chip and to its TCB versions. AMD's key server (kdsintf.amd.com) hands out the VCEK certificate, signed by AMD's SEV signing key for the processor family (ASK), itself signed by AMD's root key (ARK). snpguest, an open-source tool of the VirTEE project, asks for reports, fetches these certificates and checks the chain.
Step 1: on your machine, get snpguest and choose a challenge
You need a Linux machine on x86_64 with curl, openssl and python3, and access to GitHub and to AMD's key server. snpguest 0.11.0 is one binary; check its SHA-256 before you run it. It is the same pin as in our script:
curl -fsSLO https://github.com/virtee/snpguest/releases/download/v0.11.0/snpguest echo "51b4d3eafd4f5a68bc3b2dc2fb858253b37790ea691b927266bde5ebfdc2a9a8 snpguest" | sha256sum -c - chmod +x snpguest && mkdir -p tools && mv snpguest tools/ && export PATH="$PWD/tools:$PATH" snpguest --version
snpguest: OK snpguest 0.11.0
Then choose the challenge, still on your machine: 64 random bytes, written as 128 hex characters.
CHALLENGE=$(python3 -c 'import secrets;print(secrets.token_hex(64))')
The challenge of the run we publish is in challenge.txt:
1e39192213a1e44de865230919285f6b1e04500c38b1fd5c2a9849e402ba080574d2572331a287222b82b5afbe737f805efbcc91508d4710cc37407b90f04019
Step 2: deploy a cpu-small-amd VM and run the script in it
Deploy a cpu-small-amd VM from the deploy page or through the API. Once the VM is ready, GET /api/volt/pods returns its ssh_command, and the deploy response of the API lists the commands below. From your machine:
curl -sSO https://voltagegpu.com/blog/two-proofs/evidence/snp-proof-in-the-vm.sh ssh -p <port> ubuntu@<ip> "CHALLENGE=$CHALLENGE bash -s" < snp-proof-in-the-vm.sh scp -P <port> ubuntu@<ip>:/tmp/snp-proof.tgz .
Read snp-proof-in-the-vm.sh before you pipe it into a VM. It stops if the challenge is not 64 bytes of hex. Inside the VM, according to its code:
- It prints what the kernel says about memory encryption, and the SEV guest device.
- It downloads snpguest 0.11.0 from GitHub and stops if the SHA-256 is not the pinned one.
- It asks the secure processor for a report whose REPORT_DATA is your challenge, at the VMPL level it names with
--vmpl: 0 by default, or the level you put inSNP_VMPL=beforebash -s. If VMPL 0 is refused, it says so and asks again at VMPL 1. - It checks that REPORT_DATA is your challenge, that the policy forbids debugging, and that the VMPL field is the level it requested.
- It fetches the ARK, ASK and VCEK from AMD's key server, checks the ARK against the AMD roots pinned in the script, and runs snpguest's chain check.
- It packs the report, its decoded text, the challenge, the check and the certificates, with a
SHA256SUMSfile, into/tmp/snp-proof.tgz.
This version has not run in a VM yet, as its header says. On 27 October 2026 we ran the previous version at 12:49 UTC, with another challenge. That version did not name the level, so snpguest 0.11.0 requested its default, VMPL 1. Its console, from the first line the script prints:
== environment 6.8.0-110-generic kvm [ 2.846464] Memory Encryption Features active: AMD SEV SEV-ES SEV-SNP [ 5.005714] sev-guest sev-guest: Initialized SEV guest driver (using vmpck_id 0) crw------- 1 root root 10, 262 Oct 27 12:49 /dev/sev-guest == snpguest 0.11.0, pinned by SHA-256 snpguest: OK snpguest 0.11.0 == 1. attestation report bound to your challenge Version: 4 Debug Allowed: false VMPL: 1 REPORT_DATA = CHALLENGE: OK == 2. AMD certificates (ARK, ASK, VCEK) from the AMD key server -rw-rw-r-- 1 ubuntu ubuntu 2277 Oct 27 12:50 certs/ark.pem -rw-rw-r-- 1 ubuntu ubuntu 2325 Oct 27 12:50 certs/ask.pem -rw-rw-r-- 1 ubuntu ubuntu 1887 Oct 27 12:50 certs/vcek.pem == 3. chain check INSIDE the VM (the one that counts is done outside) The AMD ARK was self-signed! The AMD ASK was signed by the AMD ARK! The VCEK was signed by the AMD ASK! Reported TCB Boot Loader from certificate matches the attestation report. Reported TCB TEE from certificate matches the attestation report. Reported TCB SNP from certificate matches the attestation report. Reported TCB Microcode from certificate matches the attestation report. VEK signed the Attestation Report! == archive ready: /tmp/snp-proof.tgz
The current version prints the requested level in the header of step 1, then a policy line such as report policy: debug not allowed, VMPL 0 as requested: OK after the REPORT_DATA line, a line such as ARK matches the AMD Milan root: OK after the list of certificates, and a last line that sends you to the check on your own machine.
The first lines come from the guest kernel: AMD SEV, SEV-ES and SEV-SNP memory encryption active, the SEV guest driver loaded, /dev/sev-guest present. The VM prints them itself, so they prove nothing on their own, and neither do the checks made inside the VM: a fake VM could print the same lines and pack certificates it made. What counts is the report, checked on your machine.
Step 3: read the report
The first lines of report.txt, the report of our published run as snpguest display report decoded it in the VM:
Attestation Report: Version: 4 Guest SVN: 0 Guest Policy (0x30000): ABI Major: 0 ABI Minor: 0 SMT Allowed: true Migrate MA: false Debug Allowed: false Single Socket: false CXL Allowed: false AEX 256 XTS: false RAPL Allowed: false Ciphertext hiding: false Page Swap Disable: false Family ID: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Image ID: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 VMPL: 1
Two of these lines matter for what follows.
Debug Allowed: false. The guest policy is fixed when the VM is launched, and the report carries it. AMD's firmware has debug commands that let the hypervisor decrypt or encrypt the memory of a guest; they return an error when the guest policy does not allow debugging (the Linux KVM documentation describes them for SEV). Debugging is bit 19 of the policy. Here the policy is 0x30000, so that bit is 0.
VMPL: 1. This is the level the tool requested, not a reading of where your guest runs. The script that made this report left the level to snpguest 0.11.0, which asks for VMPL 1 unless you pass --vmpl (its source), and the firmware accepts a requested level only if it is "greater than or equal to the current VMPL and at most three", as the virtee/sev library documents the field. So the report shows that the request came from VMPL 0 or 1. The guest kernel points to VMPL 0: its SEV driver uses VMPCK0, the communication key of VMPL 0 (using vmpck_id 0 in the console above), and the upstream Linux 6.8 kernel, the series this guest runs, supports SEV-SNP guests at VMPL 0 only. That is consistent with a guest at VMPL 0, with no SVSM below it. We have not confirmed it yet with a report requested at VMPL 0. For that reason the current script requests VMPL 0 by default.
Further down, the report data and the measurement:
Report Data: 1E 39 19 22 13 A1 E4 4D E8 65 23 09 19 28 5F 6B 1E 04 50 0C 38 B1 FD 5C 2A 98 49 E4 02 BA 08 05 74 D2 57 23 31 A2 87 22 2B 82 B5 AF BE 73 7F 80 5E FB CC 91 50 8D 47 10 CC 37 40 7B 90 F0 40 19 Measurement: 67 68 26 E9 02 52 47 99 A0 67 F7 C4 3B 3A B0 10 1D CE 73 A2 50 6D 41 43 6D D2 F8 47 2F A2 08 08 1F 11 F9 E6 5C A5 D2 43 97 85 73 2A 0B FD 83 39
The 64 bytes of Report Data are the challenge, in capitals: 1E 39 19 22 is 1e391922, and so on to 40 19. The measurement is 48 bytes; the limits section says what it does and does not cover.
Step 4: check it on your machine, with AMD's chain
This is the step that counts. The archive comes from the VM, so its certificates prove nothing: a fake VM could pack a root it made itself. The lines below fetch AMD's chain and the VCEK from AMD into a new directory, check that the root is AMD's, then verify the report with those certificates only. For your own VM, run them after the scp of Step 2, in the same shell; they expect a report requested at VMPL 0, the default of the current script:
D=$(mktemp -d) && tar xzf snp-proof.tgz -C "$D" && (cd "$D" && sha256sum -c SHA256SUMS) CHALLENGE=$CHALLENGE bash snp-proof-in-the-vm.sh --check-report-data "$D/report.bin" bash snp-proof-in-the-vm.sh --check-report-policy "$D/report.bin" A=$(mktemp -d) && (cd "$D" && snpguest fetch ca pem "$A" -r report.bin && snpguest fetch vcek pem "$A" report.bin) bash snp-proof-in-the-vm.sh --check-ark "$A/ark.pem" (cd "$D" && snpguest verify certs "$A" && snpguest verify attestation "$A" report.bin) # --check-report-policy expects VMPL 0, the level the script requests by default; if the run in the VM said it asked again at VMPL 1, add 1 as the last argument
The run we publish was made by the previous version of the script, which requested VMPL 1. To re-check it, download its files and give 1 as the last argument of --check-report-policy; its challenge is the one in challenge.txt:
BASE=https://voltagegpu.com/blog/two-proofs/evidence curl -fsSO "$BASE/snp-proof-in-the-vm.sh" D=$(mktemp -d) && for f in SHA256SUMS report.bin report.txt challenge.txt verify.txt certs/ark.pem certs/ask.pem certs/vcek.pem; do curl -fsS --create-dirs -o "$D/$f" "$BASE/snp-2026-10-27/$f"; done && (cd "$D" && sha256sum -c SHA256SUMS) CHALLENGE=$(cat "$D/challenge.txt") CHALLENGE=$CHALLENGE bash snp-proof-in-the-vm.sh --check-report-data "$D/report.bin" bash snp-proof-in-the-vm.sh --check-report-policy "$D/report.bin" 1 A=$(mktemp -d) && (cd "$D" && snpguest fetch ca pem "$A" -r report.bin && snpguest fetch vcek pem "$A" report.bin) bash snp-proof-in-the-vm.sh --check-ark "$A/ark.pem" (cd "$D" && snpguest verify certs "$A" && snpguest verify attestation "$A" report.bin)
Run on 27 October 2026 at 14:42 UTC with the current script, on Ubuntu 24.04 under WSL2, in a fresh directory. The files were read from a local copy of this site served at the same path, because this page was not online yet:
report.bin: OK report.txt: OK challenge.txt: OK verify.txt: OK certs/ark.pem: OK certs/ask.pem: OK certs/vcek.pem: OK REPORT_DATA = CHALLENGE: OK report policy: debug not allowed, VMPL 1 as requested: OK ARK matches the AMD Milan root: OK The AMD ARK was self-signed! The AMD ASK was signed by the AMD ARK! The VCEK was signed by the AMD ASK! Reported TCB Boot Loader from certificate matches the attestation report. Reported TCB TEE from certificate matches the attestation report. Reported TCB SNP from certificate matches the attestation report. Reported TCB Microcode from certificate matches the attestation report. VEK signed the Attestation Report!
The lines for your own VM ran too, exactly as printed, on the archive of the 13:13 UTC run (14:44 UTC, current script). They printed the same lines except the policy check, which, without the 1, printed report VMPL is 1, expected 0 (the level requested), as it should for a report requested at VMPL 1. A first try at 14:42 UTC, a few seconds after the run above, got an error from AMD's key server on the VCEK: Unable to fetch VCEK from URL: 429, too many requests. If that happens to you, wait a minute and run the line again.
Line by line:
sha256sum -c: the seven files are the ones the script listed in the VM. It shows that the transfer did not change them, not who made them.REPORT_DATA = CHALLENGE: OK: the 64 bytes at offset 0x50 ofreport.binare the challenge.report policy: debug not allowed, VMPL 1 as requested: OK: bit 19 of the guest policy is 0, and the VMPL field is the level given as last argument (1 for this run; 0 when you give none).- The two
snpguest fetchcommands print nothing when they work.fetch cawith-r report.binreads the processor family from the report and downloads that family's ARK and ASK;fetch vcekdownloads the VCEK for the chip ID and the TCB versions written in the report. ARK matches the AMD Milan root: OK: the SHA-256 of the root certificate is69d063b4…0bcd, the Milan root pinned in the script, as AMD's key server served it on 27 October 2026. Without this line, the chain check below would also pass with a root made by anyone, since a made-up root is self-signed too.snpguest verify certs: the ARK signs itself, the ASK is signed by the ARK, the VCEK by the ASK.snpguest verify attestation: the four TCB versions in the VCEK certificate are those of the report, and the signature of the report checks out with the VCEK's key. VEK is snpguest's name for the signing key;report.txtsayssigning key: vcek.
Make it fail
Three checks ran right after, at 14:42:20 UTC: a random challenge that is not the one in the report, the policy check without the level this report was requested at, and the ASK passed where the root is expected.
CHALLENGE=$(python3 -c 'import secrets;print(secrets.token_hex(64))') bash snp-proof-in-the-vm.sh --check-report-data "$D/report.bin"; echo "exit $?" bash snp-proof-in-the-vm.sh --check-report-policy "$D/report.bin"; echo "exit $?" bash snp-proof-in-the-vm.sh --check-ark "$A/ask.pem"; echo "exit $?"
REPORT_DATA does not match CHALLENGE report: 1e39192213a1e44de865230919285f6b1e04500c38b1fd5c2a9849e402ba080574d2572331a287222b82b5afbe737f805efbcc91508d4710cc37407b90f04019 challenge: c699f7c3bac3fe07356cf128607d38418fcf925b4823aefb62553aed4209e5db76d7edf3cd7c08f3457261e67c972b56170c6cf078391b6088d0e8f8f408df62 exit 3 report VMPL is 1, expected 0 (the level requested) exit 5 ARK is not one of the AMD roots (Milan, Genoa, Turin): 67d303bd3905fd38db8b20e0793699870e7fa612eaad5dec358293fd8c0bac1b exit 6
Exit code 3: REPORT_DATA does not match. Exit code 5: the VMPL field is not the level given (0 when you give none, while this report was requested at VMPL 1). Exit code 6: the certificate is not one of the AMD roots pinned in the script (Milan, Genoa, Turin). The script also stops with code 4 if the policy allows debugging, with 2 on a malformed challenge or level, and, in the VM, with 7 if the report is refused at every level it tried.
The VCEK you fetch is not the file in the archive
AMD's key server answered our machine with another VCEK certificate than the one in the archive: other validity dates, so other bytes. The key inside is the same, and the ARK and ASK are the same bytes:
for c in ark ask vcek; do cmp -s "$A/$c.pem" "$D/certs/$c.pem" && echo "$c.pem: same bytes as in the archive" || echo "$c.pem: different bytes"; done openssl x509 -in "$A/vcek.pem" -noout -startdate openssl x509 -in "$D/certs/vcek.pem" -noout -startdate for f in "$A/vcek.pem" "$D/certs/vcek.pem"; do openssl x509 -in "$f" -noout -pubkey | sha256sum; done
ark.pem: same bytes as in the archive ask.pem: same bytes as in the archive vcek.pem: different bytes notBefore=Oct 26 15:44:40 2026 GMT notBefore=Oct 26 13:13:17 2026 GMT ede274a881b87091f70ac6cb43dd71baae689de31f4d3815430ea4156588cb4f - ede274a881b87091f70ac6cb43dd71baae689de31f4d3815430ea4156588cb4f -
So do not compare your VCEK with the checksum in the archive: verify the report with the VCEK you fetched, as in Step 4. The different bytes also show that the check used a certificate that came from AMD, not from the archive.
What this proves, and what it does not
Shown by the published run (report of 27 October 2026, 13:13 UTC):
- The report is signed by the VCEK of an AMD chip, certified by AMD's Milan chain as AMD's key server served it to our machine, with the root checked against AMD's fingerprint.
- It carries our challenge in REPORT_DATA, and the TCB versions that AMD certified for that chip.
- The guest was launched with a policy that forbids debugging.
If you generate the challenge yourself just before the run, the same checks also show that the report was made after that moment, inside an SEV-SNP guest on a genuine AMD chip.
Not shown:
- Which image runs. The measurement (
676826e9…in our report) is not compared with any reference value: we publish none, and no key vouches for the image (ID Key DigestandAuthor Key Digestare zeros inreport.txt). The report shows a genuine SEV-SNP guest on an AMD chip, not which software it runs. In the first VM of this tier we inspected that day, the kernel command line began withBOOT_IMAGE=/vmlinuz-6.8.0-110-generic, which GRUB adds when it loads a kernel from the disk: such a kernel, and the disk, come after launch and are outside the measurement anyway. The measurement was the same in the three reports we took that day, two of them unpublished; record yours and compare it on your next VMs. - At which VMPL your guest runs. The VMPL field of the report is the level the tool requested: 1 in our run, the default of snpguest 0.11.0 that the previous script relied on (Step 3). The guest kernel uses VMPCK0, which is consistent with VMPL 0 and no SVSM, but we have not confirmed it yet with a report requested at VMPL 0.
- When our challenge was chosen. Nothing in the published files shows it. For a run you did not start, only a challenge you generate yourself, just before the run, shows that the report is fresh.
- That the guest that signed is the machine you log into. Nothing ties the report to your SSH session. A host that controls the network could pass your challenge to another SEV-SNP guest and return its report. Tying the two needs, for example, the SSH host key of the guest in REPORT_DATA; the script does not do that.
- That the firmware is current. The checks match the TCB versions of the report with those of the VCEK certificate. They do not compare them with the latest versions AMD has published, and we have not done that comparison.
- Protection against physical access. AMD considers physical access outside the published threat model of SEV-SNP; see our article on DDRop.
- Anything about the disk. SEV-SNP encrypts the memory of the guest. We make no disk encryption claim for this tier.
- That the text files are the unedited output of a run. The report is signed by the chip's key, and you can check that.
report.txt,verify.txtandSHA256SUMSare not signed.
If you rent one from us
The VM above is our Confidential CPU tier cpu-small-amd: AMD EPYC with AMD SEV-SNP, no GPU, an Ubuntu 24.04 image, SSH as ubuntu with sudo, billed per second with one hour prepaid at launch. The larger tiers (cpu-medium-amd, cpu-large-amd, cpu-xlarge-amd) use the same script; we have run it on cpu-small-amd only.
Live price and stock of each tier: /confidential-cpu, or the confidentialCpu array of the public price feed.
For a GPU in a confidential VM, the Confidential VM tiers run on Intel TDX, with an attestation you also generate and verify yourself; for the quote check, see Verify an Intel TDX Quote From Any Cloud.