AMD SEV-SNP

SEV-SNP encrypts the entire contents of a virtual machine's memory using an AES-128 engine integrated into the AMD system-on-a-chip (SoC). Each VM is assigned a unique encryption key managed by the AMD Secure Processor (AMD-SP) , ensuring that data remains encrypted even when resident in DRAM. This prevents the hypervisor or a rogue administrator with physical access from reading plaintext VM memory.

• Key Isolation: Encryption keys are never accessible to the host OS or hypervisor.
• Transparent Operation: Encryption and decryption occur inline during memory accesses with minimal performance impact.

SEV-SNP introduces the Reverse Map Table (RMP) , a hardware-enforced data structure that tracks page ownership and prevents malicious remapping. The RMP guarantees that a guest VM's physical memory page can only be mapped at the correct guest physical address, neutralizing data replay and memory aliasing attacks that previously exploited SEV-ES.

• Page Validation: The VM must explicitly accept a page before it becomes usable, preventing the hypervisor from injecting unvalidated data.
• Immutable Ownership: Once a page is assigned to a VM, the hypervisor cannot alter its mapping without triggering a fault.

SEV-SNP provides a robust attestation mechanism that allows a remote party to cryptographically verify the identity and integrity of the VM before provisioning secrets. The AMD Secure Processor generates a signed attestation report containing the VM's launch digest—a hash of the initial guest firmware, kernel, and configuration.

• VMPL-based Signing: The report is signed by a Versioned Chip Endorsement Key (VCEK) , binding the attestation to a specific processor.
• Guest-Requested Reports: The VM itself can request an attestation report at any time, enabling ongoing trust verification.

SEV-SNP extends the register state protection introduced in SEV-ES by adding hardware safeguards against malicious interrupt injection. The architecture restricts the injection of interrupts and exceptions to only those vectors explicitly allowed by the guest VM, preventing the hypervisor from manipulating the guest's control flow through crafted interrupt sequences.

• Restricted Injection: The hypervisor can only inject a predefined subset of interrupt vectors.
• Event Injection Validation: The hardware validates the event type and vector against the guest's configuration before delivery.

SEV-SNP introduces VMPLs, an architectural feature that allows a single guest VM to run code at multiple privilege levels within the confidential boundary. This enables the guest to isolate sensitive operations—such as attestation report generation or key management—from the bulk of the guest OS, creating a secure enclave-like abstraction within the VM itself.

• In-Guest Isolation: VMPL0 can run a minimal security monitor, while VMPL1 runs the main OS kernel.
• Secure Services: Enables confidential computing patterns where a small, trusted service component is shielded from a larger, potentially compromised guest.

The Secure Nested Paging (SNP) table is a hardware-managed second-level address translation structure that enforces the memory integrity guarantees. Unlike a traditional hypervisor-managed nested page table, the SNP table is validated and locked by the AMD Secure Processor, ensuring that the hypervisor cannot create unauthorized mappings or redirect guest memory accesses to malicious pages.

• Hardware-Enforced Mapping: The RMP and SNP tables work in concert to validate every memory access.
• Page State Tracking: The hardware tracks whether a page is private to the VM, shared with the hypervisor, or in a transitional state.

The cryptographic process by which an AMD SEV-SNP platform proves its identity, integrity, and security posture to a remote relying party before that party provisions secrets or trusts the VM's outputs.

• SEV-SNP uses an AMD-rooted certificate chain to sign attestation reports
• Reports include the launch digest (measurement of initial VM state)
• Verifiers can confirm firmware version, platform TCB status, and guest policy
• Essential for establishing trust before injecting decryption keys or sensitive data

Intel's competing VM-level Trusted Execution Environment that, like AMD SEV-SNP, protects entire virtual machines from the hypervisor. Both technologies enable lift-and-shift confidential computing without application code modification.

• Intel TDX uses multi-key total memory encryption and integrity protection
• SEV-SNP and TDX share architectural goals but differ in implementation details
• Both support remote attestation and encrypted live migration
• Choosing between them often depends on existing hardware vendor relationships

A full virtual machine instance running inside a hardware-backed TEE like AMD SEV-SNP. The hypervisor manages CPU scheduling and memory allocation but cannot read or modify VM memory contents.

• Entire VM memory space is encrypted with AES-128-XEX
• SEV-SNP adds Reverse Map Table integrity protection to prevent remapping attacks
• Guest owner can verify VM state via attestation before booting
• Enables migration of legacy workloads into confidential environments without refactoring

The set of all hardware, firmware, and software components critical to a system's security. A vulnerability in any TCB component can compromise the entire system's security guarantees.

• AMD SEV-SNP minimizes the TCB by excluding the hypervisor from the trust boundary
• The TCB includes the AMD Secure Processor, SEV firmware, and the guest VM itself
• AMD reports TCB version in attestation reports for verifiable patch status
• Reducing TCB size is a primary goal of confidential computing architectures

A non-invasive attack that exploits physical information leakage—such as timing, power consumption, cache access patterns, or electromagnetic emissions—to extract secrets from a theoretically secure environment.

• SEV-SNP includes mitigations against certain speculative execution attacks
• Page table side-channels are addressed through restricted injection and validation
• No hardware TEE is immune; defense-in-depth strategies remain essential
• Ongoing research examines microarchitectural side-channels specific to SEV implementations