A significant security flaw has been identified in AMD’s Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP), a technology integral to confidential computing environments utilized by leading cloud service providers such as AWS, Azure, and Google Cloud. This vulnerability, termed RMPocalypse, exploits weaknesses in the initialization process of the Reverse Map Table (RMP), a component designed to maintain memory integrity and prevent hypervisors from interfering with encrypted virtual machines (VMs).
Understanding the RMPocalypse Vulnerability
The RMP is a critical data structure within SEV-SNP, mapping host physical addresses to guest virtual addresses to thwart attacks like page swapping, which were prevalent in earlier versions like SEV and SEV-ES. Under normal circumstances, the RMP safeguards itself by restricting hypervisor access to its own pages. However, during the initialization phase, this self-protection mechanism is not yet operational, creating a window of opportunity for exploitation.
The Platform Security Processor (PSP), an ARM-based coprocessor, is responsible for setting up the RMP by establishing Trusted Memory Regions (TMRs) at the memory controller level and implementing locks on x86 cores to prevent unauthorized writes during this critical phase. Despite these measures, researchers Benedict Schlüter and Shweta Shinde from ETH Zurich discovered that these protective barriers are not entirely effective. They found that asynchronous operations allow x86 cores to generate dirty cache lines in RMP memory before full protection is in place. Once the TMRs are deactivated post-initialization, these stale cache entries are written to DRAM, leading to the corruption of the RMP with arbitrary values.
Experiments conducted on AMD’s EPYC processors—specifically models 9135 (Zen 5), 9124 (Zen 4), and 7313 (Zen 3)—confirmed that such overwrites can occur without triggering any faults. This issue is exacerbated in Zen 3 processors due to coherency challenges. Although the PSP’s source code suggests intended safeguards like cache flushes, gaps remain due to proprietary operating system components and the absence of Translation Lookaside Buffer (TLB) invalidations.
Potential Exploits Enabled by RMPocalypse
The corruption of the RMP through the RMPocalypse vulnerability enables attackers to fully compromise SEV-SNP VMs. By altering RMP-protected pages, firmware, context, guest-valid, and Virtual Machine Save Area (VMSA) states to be writable by the hypervisor, several critical exploits become possible:
1. Forging Attestation Reports: Attackers can replay benign context page ciphertexts to deceive guest VMs into trusting malicious VMs. This method bypasses integrity checks since context pages lack encryption integrity.
2. Enabling Debug Mode on Confidential VMs: By modifying a policy bit in the context page, attackers can activate debug mode on production confidential VMs. This grants hypervisors read and write access via SNPDEBUGDECRYPT/ENCRYPT APIs without detection, as attestation reports remain unchanged. Success rates for this exploit exceed 99.9% in under 15 milliseconds after multiple attempts.
3. VMSA State Replay: This technique resets confidential VM registers to previous states, compromising execution integrity and facilitating rollback attacks.
4. Arbitrary Code Injection: By manipulating SNPPAGEMOVE to swap tweak values, attackers can replay input/output channel payloads, such as network packets, into kernel code. This approach circumvents encryption tweaks and can be executed in approximately 5 milliseconds, including breaking Kernel Address Space Layout Randomization (KASLR).
These exploits effectively nullify SEV-SNP’s protections against untrusted hypervisors, exposing sensitive data—including artificial intelligence models and enterprise workloads—to potential exfiltration and tampering.
Mitigation Efforts and Recommendations
AMD has acknowledged the RMPocalypse vulnerability, designated as CVE-2025-0033, and is actively working on developing fixes. However, as of now, no patches have been released for the affected hardware. The vulnerability impacts AMD’s Zen 3, Zen 4, and Zen 5 processors, including EPYC server chips widely used in production environments.
To mitigate the risks associated with this vulnerability, researchers suggest several approaches:
– Aligning Protective Barriers at the Core Level: Implementing checks on caches before lifting TMRs can prevent unauthorized cache entries from corrupting the RMP.
– Enforcing Global Cache and TLB Flushes Post-RMP Setup: This measure ensures that any stale cache entries are cleared, reducing the risk of RMP corruption. However, Zen 3 processors may require additional invalidations due to domain incoherency issues.
– Implementing Firmware Checks on RMP Self-Protection: Introducing time-of-check to time-of-use (TOCTOU) detection mechanisms in firmware can help identify and prevent exploitation attempts, though this may introduce additional overhead.
As confidential computing continues to gain traction, the emergence of vulnerabilities like RMPocalypse underscores the need for robust security measures and continuous vigilance. Cloud tenants are advised to audit their service providers for updates and patches related to this vulnerability. Additionally, AMD’s partial open-sourcing of PSP firmware facilitates greater scrutiny but also highlights the inherent risks associated with proprietary components.
The RMPocalypse attack, which can be executed in under 234 milliseconds during the SNPINITEX phase, calls for a reevaluation of hardware-based trust models and emphasizes the importance of comprehensive security strategies in protecting sensitive data.
