In an ordinary VM, the hypervisor can read the guest’s memory.\nAMD SEV, Secure Encrypted\nVirtualization, encrypts that memory with a per-VM key the hypervisor does\nnot receive. SEV-ES extends the protection to saved CPU register state.
\nSEV-SNP, Secure Nested Paging, adds checks on memory ownership and mappings\nto prevent a malicious hypervisor from substituting or remapping private\npages. This protects the guest from the host; it doesn’t make software\ninside the guest trustworthy or prevent the host from stopping the VM.
\nSNP lets the guest request a report signed by the AMD secure processor,\nproviding evidence of the VM’s launch state and configuration. It contains\nthe launch measurement, guest policy, platform security versions and 64\nbytes of caller-supplied REPORT_DATA.
Before the VM starts, the host loads its starting software into memory.\nThis includes the guest’s boot firmware: the startup software that initializes\nthe VM’s boot environment and hands control to the operating system’s\nbootloader. On Google Cloud,\nthat’s Google-managed UEFI firmware\nbased on Open Virtual Machine Firmware (OVMF).
\nThe starting software can also include\nCoconut SVSM, a separate program that\nhosts services such as a virtual TPM. The UEFI firmware still boots the OS;\nSVSM provides services that need protection from the OS itself.
\nAMD’s SNP firmware runs on the secure processor. The host starts a launch\nwith SNP_LAUNCH_START, then supplies the starting image in chunks called\nmemory pages through\nSNP_LAUNCH_UPDATE.\nFor each normal code or data page, the firmware hashes the bytes it installs,\ntheir guest-memory address, page type and permissions, together with the\nprevious hash. AMD’s firmware maintains this running hash in protected\nstate; the host cannot supply a replacement value.
SNP_LAUNCH_FINISH closes the launch. The final SHA-384 hash is the\nlaunch measurement, a fingerprint of that initial image, including\nSVSM when present. Later, the firmware\ncopies this stored value into the report.\nIt stays fixed as the VM runs.
When performing remote attestation,\na Verifier compares it with the expected fingerprint for the starting\nsoftware and launch configuration it trusts. Google publishes\nsigned launch endorsements\ncontaining those expected measurements for its firmware. Changing the\nfirmware bytes changes the fingerprint. Marking those pages as unmeasured\nskips hashing their contents, but changes the page type included in the hash.\nEither way, the result differs from the expected fingerprint, so the\nVerifier can reject the attestation.
\nThe kernel and applications that the firmware loads afterwards are not\nautomatically covered by this fingerprint.
\nLinux exposes the SNP guest interface\nat /dev/sev-guest. An application sends the SNP_GET_REPORT ioctl, and\nthe driver handles the protected exchange with AMD SNP firmware.
Alongside the report data, the request supplies a VM privilege level, or\nVMPL: 0 through 3, with 0 most privileged. These levels matter because\nLinux isn’t always the most privileged software inside the VM. Coconut\nSVSM, for example, can use that separation to host a virtual TPM whose\nkeys are isolated from the guest kernel. Being root in Linux doesn’t put\nyou at VMPL0. Use the VMPL supported by your guest.
\nHere’s the request in Zig (0.17.0), using the layouts from Linux’s guest\nAPI. fd is an open /dev/sev-guest descriptor inside an x86-64 Linux SNP\nguest:
const std = @import("std");\nconst linux = std.os.linux;\n\nconst ReportRequest = extern struct {\n user_data: [64]u8,\n vmpl: u32,\n reserved: [28]u8 = @splat(0),\n};\n\nconst GuestRequest = extern struct {\n msg_version: u8 = 1,\n padding: [7]u8 = @splat(0),\n req_data: u64,\n resp_data: u64,\n exitinfo2: u64 = 0,\n};\n\npub fn fetchReport(fd: i32, challenge: [64]u8, vmpl: u32) ![1184]u8 {\n var request: ReportRequest = .{ .user_data = challenge, .vmpl = vmpl };\n var response: [4000]u8 = @splat(0);\n var call: GuestRequest = .{\n .req_data = @intFromPtr(&request),\n .resp_data = @intFromPtr(&response),\n };\n\n const SNP_GET_REPORT = 0xc0205300;\n const result = linux.ioctl(fd, SNP_GET_REPORT, @intFromPtr(&call));\n if (linux.errno(result) != .SUCCESS or call.exitinfo2 != 0) {\n return error.ReportRequestFailed;\n }\n\n const status = std.mem.readInt(u32, response[0..4], .little);\n const size = std.mem.readInt(u32, response[4..8], .little);\n if (status != 0 or size != 1184) return error.InvalidResponse;\n\n // The report follows the 32-byte firmware response header.\n return response[32..][0..1184].*;\n}Pass a fresh 64-byte challenge from the verifier and the guest’s VMPL.\nThe challenge comes back in REPORT_DATA, so the verifier can reject an\nold report. The result is a raw report; its signature and policy still\nneed checking.
I packaged the retrieval, report parsing and verification in\nzig-sev-guest, so callers\ndon’t have to work with these buffers directly.
\nCoconut SVSM and\nMicrosoft’s OpenHCL\nhave different designs, but both run privileged services such as a vTPM\ninside the confidential VM. On SNP, AMD hardware encrypts that memory—including\nthe TPM’s private keys—with a per-VM key managed by the secure processor.\nThe guest kernel runs at a less privileged VMPL than SVSM or OpenHCL.\nSNP’s page permissions block it from reading the pages holding the vTPM’s\nprivate keys.
\nThe guest can ask AMD to sign a report containing a hash of any public key.\nThat does not prove the key belongs to the protected vTPM. SVSM and OpenHCL\nbuild the request using the public keys of the TPM they host. The\napplication therefore obtains this report through them.
\nThree request paths, all backed by SNP firmware.
\nIn zig-sev-guest, I use OpenSSL to verify the signing certificate’s chain\nagainst the embedded AMD roots and check the report’s ECDSA P-384 signature.\nThe certificate’s security versions, and chip identity where present, must\nalso match the report.
\nPolicy validation then compares the report with the expected launch\nmeasurement, REPORT_DATA, VMPL and minimum platform security versions.\nDebugging, SMT and migration are rejected unless explicitly allowed.
verify.andValidate performs both steps on the same report. The caller\nsupplies the expected values, including the fresh challenge, and checks any\nvTPM-specific claims and quotes separately.