Page States
Last updated
Was this helpful?
Last updated
Was this helpful?
As illustrated, the Reverse Map Table (RMP) in SEV-SNP plays a crucial role in tracking the state of each memory page, governing its permissible uses, the entities authorized to read or write it, and potential state transitions. The various page states determine the level of access and control granted to different entities. For instance:
Hypervisor state: Pages in this state can be read and written by the hypervisor or SEV-SNP VMs accessing the memory with C=0 (shared pages).
Guest-Valid state: Pages in this state can be read and written by SEV-SNP VMs but are protected from being written by the hypervisor.
Guest-Invalid state: Pages in this state are yet to be validated by the guest, and access to them is restricted.
The SEV-SNP architecture defines a total of eight main page states, as listed in Table 3. Page state transitions are depicted in figure above and can occur through three mechanisms: the new CPU RMPUPDATE instruction (red), the new PVALIDATE instruction (blue), or via the VM management API in the AMD-SP (green).
Similar to previous SEV technologies, SEV-SNP incorporates a VM management API in the AMD-SP. The hypervisor employs this interface to facilitate VM lifecycle tasks and page management. To maintain security, any pages that the AMD-SP will manipulate must first be placed into special states called Immutable states before initiating the necessary API call. Pages in the Immutable states are protected from being written by any software on the CPU (hypervisor or guest) and cannot have their RMP entry modified by any entity other than the AMD-SP. After processing a page in one of these Immutable states, the AMD-SP can transition it to a different state as dictated by the specific API call.
One such example of Immutable pages is 'Metadata' pages. These pages are writable only by the AMD-SP and serve to store metadata entries associated with guest pages that have been swapped to disk. When a page is swapped to disk, the AMD-SP creates a metadata entry containing an authentication tag (from AES-GCM) and relevant data from the page's RMP entry, such as the GPA where it was located. As the Metadata page itself is not writable by the hypervisor, the integrity of this information is guaranteed. When a page is swapped back into memory, the AMD-SP verifies that the contents remain unchanged and ensures that the page is reintegrated into the guest address space at the same location as before. Metadata pages themselves can also be swapped to disk in a similar manner, enabling the entire guest to be saved to disk if needed.