Reverse Map Table
Last updated
Was this helpful?
Last updated
Was this helpful?
As mentioned earlier, SEV-SNP relies on a novel data structure known as the Reverse Map Table (RMP) to enforce various integrity guarantees. The RMP is a system-wide data structure that contains an entry for each 4k page of DRAM available for VM usage. Its primary purpose is to track the ownership of each memory page, which can belong to the hypervisor, a specific VM, or the AMD-SP. To maintain memory security, write access is restricted to only the owner of a particular page. The RMP is integrated with standard x86 page tables to control memory restrictions and page access rights.
In the native mode (non-VM), virtual addresses are translated into physical addresses using standard x86 page tables. Once this translation is complete, the resulting physical address is used to index the RMP. The RMP entry is then read and checked. If the entry indicates that the page is owned by the hypervisor, the checks pass, and a new Translation Lookaside Buffer (TLB) entry is created. However, if the page is not hypervisor-owned, the table-walk faults (#PF), and the access is denied.
In an SEV-SNP VM, the RMP check is more intricate. The virtual address undergoes translation to a Guest Physical Address (GPA) through AMD-V 2-level paging. The GPA is then further translated to a System Physical Address (SPA), which is used to index the RMP. The entry in the RMP is inspected to confirm that the page is owned by the specific guest, mapped at the particular GPA, and contains the expected mapping information. If any of these checks fail, an exception is raised, and the access is denied.
Not all memory accesses require an RMP check. For instance, read accesses from the hypervisor or non-SEV-SNP guests are exempted since data confidentiality is already protected through AES memory encryption. However, all write accesses, regardless of the mode, necessitate an RMP check. This includes standard memory writes and A/D-bit updates during page table walks. The results of RMP checks are cached in the CPU TLB and related structures to improve efficiency.
Due to the critical role of the RMP in enforcing memory access control, it is not directly writable by software. Special CPU instructions are available to enable manipulation of RMP entries, allowing the hypervisor to assign pages to specific guests or reclaim them. When necessary, hardware automatically performs TLB invalidations to ensure that all processors in the system receive updated RMP entry information, maintaining memory security across all cores.