Summary

Confidential computing allows customers to off-load their computation to the cloud without having to trust the cloud provider. One of the approaches to enable confidential computing is by anchoring the trust in the hardware. AMD’s SEV-SNP, one such hardware mechanism, supports confidential computing by creating confidential virtual machines. With RMPocalypse, we demonstrate an attack on all AMD processors that support SEV-SNP (Zen 3/4/5) and compromise all confidential computing guarantees. Reverse Map Table, in short RMP, is one of the main protection mechanisms in SEV-SNP to stop the hypervisor from accessing the confidential virtual machines. In RMPocalypse, we exploit AMD’s incomplete protections that allow us to perform a single memory write to the RMP, thus breaking SEV-SNP.

What is AMD SEV-SNP?

Secure Encrypted Virtualization-Secure Nested Paging, SEV-SNP for short, is AMD’s latest hardware extension to support confidential computing.

What is RMP?

SEV-SNP uses a data structure called Reverse Map Table (RMP) to store security metadata for all DRAM pages in the system. Since RMP can be large in size, it is stored in the DRAM. Now you might ask, who protects the RMP? Well, the RMP! Easier said than done, as this design choice by AMD creates a chicken-and-egg problem. The main challenge lies in the initialization, when the RMP is being set up in the DRAM, there has to be an orthogonal mechanism in place to make sure this is done correctly. Only after a successful initialization can the RMP protect itself (and of course the confidential VMs). AMD has an elegant solution to this problem. They use a security co-processor called the PSP to initialize the RMP. During initialization, platform protection mechanisms configured by the PSP protect the RMP.

What went wrong?

RMPocalypse shows that AMD’s platform protection mechanisms are not complete, thus leaving a small window of opportunity for the attacker to maliciously overwrite the RMP on initialization. Due to the design of the RMP, a single overwrite of 8 bytes within the RMP causes the entire RMP to become subsequently compromised. With a compromised RMP, all integrity guarantees of SEV-SNP become void. RMPocalypse case studies show that an attacker-controlled RMP not only voids the integrity but also results in a full breach of confidentiality.

What can an attacker do with this vulnerability?

We showcase RMPocalypse primitives by forging attestation values, enabling debug, reading and writing arbitrary encrypted CVM memory, and replaying the CVM register state.

Attack Overview

AMD performs an initialization step when the hypervisor wants to enable SEV-SNP on the platform. Setting up the RMP is one of the critical steps in this initialization. Thus, during initialization, AMD blocks all the memory accesses to the memory region that holds the RMP data structure. In particular, AMD uses so-called Trusted Memory Regions (TMRs) to block any access from untrusted components (e.g., x86 cores).

In our analysis of the RMP initialization, we observed that the malicious hypervisor running on the x86 cores can still create dirty cachelines pointing to DRAM. As the TMR barrier only stops the memory access at the memory controller level, it cannot stop cache pollution. Note that this in itself does not compromise SEV-SNP yet, since the RMP is still intact in memory at this point and if the attacker tries to flush the entry, the TMR will block it. It is after the initialization, when AMD lifts the TMR barrier, when we can perform the flush, and the write goes through to the DRAM!

In summary, we identify the root-cause as the misalignment of different memory protection mechanisms on the platform.

High level overview of the RMPocalypse attack during SEV-SNP initialization

Figure (a) shows the main components of our attack with x86 cores and caches connected to the DRAM over an interconnect. During SEV-SNP init, as shown in (b), a malicious hypervisor creates dirty cachelines pointing to RMP memory. Then it lets the PSP setup the RMP per usual and waits for the acknowledgement that the initialization is complete. In particular, after writing to the RMP range the PSP notifies the platform to switch from the TMR protection mechanism and start enforcing SEV-SNP semantics. Concretely, this means that the TMR access checks are lifted and the core starts enforcing RMP checks on memory accesses. However, these RMP checks occur before the memory write gets written to cache. Thus, all data within the cache is assumed to be valid and already complies with the current security semantics. This leaves us with a time window during RMP initialization, where the x86 cores can flush the previously created dirty cacheline entries. They are neither subject to access control checks based on the TMR nor the RMP, thus bypassing both protection mechanisms. As depicted in (c), the malicious hypervisor can use the primitive to get arbitrary unchecked writes to RMP memory.

Attack Complexity

We perform the above RMP corruption during the SEV initialization. RMPocalypse is deterministic since our malicious write always goes through. Next, with our choice of corrupting the root RMP entry with this write, we can tamper with all RMP entries in the system and the logic state they belong to. Our paper explains the detailed analysis of the RMP states. But in short, the RMP write-protects a critical metadata page for CVMs. This page holds security sensitive information, such as debug-enable bit and the attestation hash. With the RMP checks practically disabled, we show how to corrupt these metadata pages to enable debug mode and bypass attestation. With each of these primitives, we can arbitrarily tamper with the execution of the confidential VMs and exfiltrate all secrets with 100% success rate.

RMPocalypse