A close look at RMP entry caching and its security implications in SEV-SNP

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).