AMD SEV-SNP offers confidential computing in form of confidential VMs, such that the untrusted hypervisor cannot tamper with its confidentiality and integrity. SEV-SNP, the latest addition, ensures integrity via the Reverse Map Table (RMP) that stops the hypervisor from tampering guest page mappings. AMD uses RMP entries to protect the rest of the RMP, thus causing a Catch-22 during the RMP setup phase. To address this, SEV-SNP relies on AMD's Platform Security Processor (PSP), that resides next to the x86 cores executing SEV-SNP VMs, to perform the RMP initialization. During initialization, only PSP should be able to alter the RMP memory. All other memory accesses must be fenced, especially from the x86 cores. We present RMPocalypse, a novel attack that shows a critical gap in the security of RMP initialization, wherein the x86 cores maliciously control parts of the initial RMP state. Our analysis shows that the vulnerability arises due to the complex, but insufficient, interplay of multiple hardware components and distributed access controls. To show the impact of our finding, we exploit this gap to break confidentiality and integrity guarantees of SEV-SNP. We demonstrate RMPocalypse by enabling debug on production-mode CVMs, faking attestation, VMSA state replay, and code injection.

Confidential computing needs hardware support that stops privileged software from learning secrets of a guest virtual machine. AMD offers such hardware support in the form of SEV-SNP to create confidential virtual machines, such that hardware encrypts all the VM memory. Specifically, SEV-SNP uses the XEX encryption mode with address-dependent tweak values such that the same plaintext at different memory addresses yields different ciphertexts.

AMD SEV-SNP offers VM-level trusted execution environments (TEEs) to protect the confidentiality and integrity for sensitive cloud workloads from untrusted hypervisor controlled by the cloud provider. AMD introduced a new exception, #VC, to facilitate the communication between the VM and the untrusted hypervisor. We present WeSee attack, where the hypervisor injects malicious #VC into a victim VM’s CPU to compromise the security guarantees of AMD SEV-SNP. Specifically, WeSee injects interrupt number 29, which delivers a #VC exception to the VM who then executes the corresponding handler that performs data and register copies between the VM and the hypervisor. WeSee shows that using well-crafted #VC injections, the attacker can induce arbitrary behavior in the VM. Our case-studies demonstrate that WeSee can leak sensitive VM information (kTLS keys for NGINX), corrupt kernel data (firewall rules), and inject arbitrary code (launch a root shell from the kernel space).