↓ Skip to main content
Le Site de François
  1. Index/

SEV-SNP (AMD Secure Encrypted Virtualization – Secure Nested Paging)

Security Confidential-Computing Hardware Attestation Virtualization Amd

SEV-SNP is AMD’s third-generation confidential computing technology for EPYC processors, and the generation in production use across major cloud providers (AWS, Google Cloud) and Linux distributions today. It builds on two predecessors: SEV (2016), which encrypted each VM’s memory with a per-VM AES key managed by the AMD Secure Processor, and SEV-ES (2017), which additionally encrypted CPU register state on VM exit to prevent the hypervisor from reading guest execution state. SEV-SNP’s defining addition is memory integrity: using Secure Nested Paging, the firmware enforces that if a guest can read an encrypted memory location, the value returned must be exactly what the guest last wrote there — closing the replay, remap, and memory aliasing attacks that made earlier generations insufficient for a fully untrusted hypervisor threat model.

The trust boundary is enforced by the AMD Secure Processor (ASP), an on-die ARM Cortex-A5 running AMD firmware that owns key management and launch policy. At guest launch, the ASP measures the initial memory contents and binds a guest policy — a bitmask controlling whether debugging, SMT, or migration are permitted — that neither the guest nor the hypervisor can alter afterwards. The result is a launch measurement that uniquely identifies the initial state of the TD. For remote attestation, the guest can request a signed attestation report from the ASP containing that measurement along with current firmware version and platform identity, signed with an AMD-rooted key chain. A relying party can verify this report against AMD’s Key Distribution Service (KDS) to confirm the guest is running on genuine AMD hardware with a specific, unmodified software stack, before sending it secrets.

Compared to TDX, the architectural approach differs: TDX uses a CPU-measured module in SEAM mode as an intermediary, while SEV-SNP places trust in the AMD Secure Processor firmware running entirely on-die. Both achieve a similar confidential computing threat model — a guest protected from a fully compromised hypervisor and host — and both are supported by the CNCF Confidential Containers and Linux kernel stacks. On Linux, SEV-SNP guests pair naturally with UKI-based measured boot and systemd-cryptenroll for secret injection at launch time.

Related

TDX (Intel Trust Domain Extensions)

Security Confidential-Computing Hardware Attestation Virtualization
Intel Trust Domain Extensions (TDX) is a confidential computing technology built into Intel CPUs that allows entire virtual machines — called Trust Domains (TDs) — to run with hardware-enforced isolation from the host hypervisor, VMM, and any other software on the platform, including privileged system software with administrative access. Unlike SGX, which protects small application-level enclaves, TDX operates at the VM level, making it suitable for lifting existing workloads into a confidential environment without significant code changes.

TCB (Trusted Computing Base)

Security Confidential-Computing Virtualization Attestation Linux
The Trusted Computing Base (TCB) is everything you must trust for your security guarantees to hold: CPU and firmware, the host kernel, the hypervisor, the container runtime, the kubelet, identity and secrets infrastructure, and any management plane that can change workload configuration. If any component in the TCB is buggy, misconfigured, or controlled by an adversary, the whole security argument fails — regardless of how well the application itself is written. The classic design principle is TCB minimisation: keep this set as small as possible, because every added component is another place where a flaw can void your policy. “Trusted” here does not mean “trustworthy in practice”; it means “assumed correct by the security model.”

TEE (Trusted Execution Environment)

Security Confidential-Computing Hardware Attestation Tee
A Trusted Execution Environment (TEE) is a hardware-enforced isolated execution context whose confidentiality and integrity are protected by the CPU itself, rather than by software policy. The defining property of a TEE is that its guarantees hold against an adversary with full control of the software stack outside it — the hypervisor, the host operating system, the BIOS firmware, and even a user with physical access to the machine — because the enforcement is implemented in silicon and cannot be overridden by software. Code and data inside a TEE are encrypted in DRAM using a key held within the CPU’s memory controller or on-die security processor, CPU register state is isolated from the host at context switch boundaries, and memory integrity protection prevents the host from replaying, remapping, or aliasing TEE memory pages. The threat model TEEs are designed against is therefore the infrastructure provider: a cloud operator, a data centre staff member, or a co-tenant who controls the hypervisor layer — the party that traditional virtualisation, namespaces, and access control cannot protect against because they depend on a trusted host kernel.