A Close Look at RMP Entry Caching and Its Security Implications in SEV-SNP
Name
3768725.3768727.pdf
Size
895.19 KB
Format
Adobe PDF
Checksum (MD5)
6ef20a463fc9c291f208170ea3d150e1
Author(s)
Bagia, Alexis
Ulitzsch, Vincent
Trujillo, Dani?l
Li, Mengyuan
Yan, Mengjia
Seifert, Jean-Pierre
Date Issued
October 18, 2025
Publisher
ACM|Hardware and Architectural Support for Security and Privacy 2025
Citation
Alexis Bagia, Vincent Quentin Ulitzsch, Daniël Trujillo, Mengyuan Li, Mengjia Yan, and Jean-Pierre Seifert. 2025. A Close Look at RMP Entry Caching and Its Security Implications in SEV-SNP. In Proceedings of the 14th International Workshop on Hardware and Architectural Support for Security and Privacy (HASP '25). Association for Computing Machinery, New York, NY, USA, 10–18.
Version
Final published version
Abstract
AMD’s Secure Encrypted Virtualization (SEV) technology is a pivotal component in AMD server processors that boosts cloud computing security. It achieves this by offering transparent memory encryption and managing keys for protecting virtual machines (VMs),
independently of the hypervisor’s trustworthiness. The latest iteration, SEV-Secure Nested Paging (SEV-SNP), introduces memory
integrity protection through a data structure called the Reverse
Map Table (RMP), which maps system physical addresses to guest
physical addresses and tracks ownership of physical pages.
The RMP is maintained in a dedicated region in DRAM. As every memory write triggers a check against an RMP entry, caching
RMP entries is crucial to alleviating the RMP’s performance impact. However, caching may create new security challenges, as it
can introduce new microarchitectural side-channels. In addition,
maintaining cache coherence is crucial for the RMP’s security guarantees. However, so far, neither the details of the RMP’s caching
behavior nor its security implications have been explored. This
paper aims to fill this gap by conducting a systematic study of the
RMP’s caching behavior. Through reverse engineering, we identify
that the RMP is not only cached in the TLB, but also in the L1D
and L2 data cache. Interestingly, this caching depends on the access
type on Zen 5. We also uncover the mechanisms by which cache
coherence across the TLB is enforced. We find that each update to
the RMP table triggers a global TLB flush across all cores. Finally,
we present several potential security implications and demonstrate
that an attacker can exploit RMP’s caching to leak physical address
information. A user process can leak 6 bits of the Physical Frame
Number (PFN) of its pages via the L1D cache within 2.5 µs per page,
with success rates of 97 % (Zen 4) and 99 % (Zen 3 and Zen 5).
MIT Department
Massachusetts Institute of Technology. Department of Electrical Engineering and Computer Science
Terms of Use
Creative Commons Attribution
Persistent DSpace Link
DOI of Published Version
https://doi.org/10.1145/3768725.3768727
