AMD SEV / SEV-ES - missing nested page table protection: MULTI-TENANT ISOLATION: SEV and SEV-ES do not protect

Impact

MULTI-TENANT ISOLATION: SEV and SEV-ES do not protect the nested page tables, so a malicious hypervisor can remap the guest's physical address space underneath it. The SEVurity and SEVerity research chains turned this into arbitrary code execution inside the encrypted guest: because encryption is keyed by physical address and the host controls the mapping, the host can move ciphertext blocks around to assemble instructions of its choosing inside the victim VM. The guest's memory is encrypted and the attacker still gets code execution in it.

Who can reach it

Requires a malicious administrator who has compromised the hypervisor. Affects SEV and SEV-ES; SEV-SNP's reverse-map table is the architectural answer to exactly this.

What to do

**Not fixable on SEV or SEV-ES** - the missing protection is architectural, which is why AMD built SEV-SNP with the RMP. The remediation is a platform migration: run confidential workloads on SEV-SNP-capable EPYC (Milan 7003 and later) with SNP actually enabled, not on SEV or SEV-ES. If you are running SEV or SEV-ES today and telling customers their VMs are protected from you, that claim does not hold. Requires new hardware or at minimum a firmware/BIOS enablement pass plus reconfiguring your VMM to launch SNP guests.

References