Page Validation

As mentioned earlier, each entry in the Reverse Map Table (RMP) contains information about the Guest Physical Address (GPA) at which a specific page of DRAM should be mapped. This ensures that each System Physical Address (SPA) can only be mapped to a single GPA at any given time. Conversely, allowing a single GPA to be mapped to multiple SPAs would compromise the integrity guarantee of SEV-SNP. Although nested page tables enforce the one-to-one GPA-to-SPA mapping, the hypervisor retains the ability to modify these tables at will. To ensure the desired integrity, SEV-SNP introduces the concept of Validation.

Within each RMP entry, there is a Validated bit that is automatically cleared to 0 by CPU hardware when a new RMP entry is created for a guest. Pages assigned to guests with the Validated bit cleared cannot be used by the hypervisor or as private guest pages since they are not yet validated. The guest can only use these pages after setting the Validated bit through a new CPU instruction called PVALIDATE. Only the guest has access to this instruction, and each guest VM can only validate its own memory.

Basic Page States

The process of adding a new page to a guest VM involves a two-step process, as shown in the figure above. First, the hypervisor assigns the page to the guest using the new RMPUPDATE instruction, which sets the page to the Guest-Invalid state. Second, the guest validates the page using the PVALIDATE instruction, transitioning it to the Guest-Valid state, where it becomes usable.

To achieve the desired integrity, the guest VM should never validate memory corresponding to the same GPA more than once. This can be accomplished in two ways: either the guest VM validates all of its memory at boot and refuses to validate additional memory except as part of hot-plug events, or the guest VM keeps track of validated memory locations and refuses to validate the same location twice. If the guest VM correctly validates its memory, it guarantees an injective mapping between GPAs and SPAs. The guest will validate each GPA only once, and the RMP table ensures that each SPA can only map to one GPA.

Page Re-mapping Attack

By correctly implementing page validation, re-mapping attacks like the one shown in figure above can be blocked. In this scenario, GPA A is initially mapped to SPA X, and the guest validates this translation through PVALIDATE, setting the Validated bit in the corresponding RMP entry. If the hypervisor maliciously attempts to remap A to a different SPA Y, it will create an RMP entry for SPA Y while attempting to map GPA A using the RMPUPDATE instruction. Subsequently, the hypervisor alters the nested page table (NPT) to re-map GPA A to Y. However, when the guest accesses Y, it encounters a #VC (VMM Communication) exception. This exception occurs because the Validated bit in the RMP entry corresponding to SPA Y is clear (since RMPUPDATE initially cleared it). Recognizing that it has already validated GPA A, the guest concludes that it should not be facing a validation error and realizes it is under attack, prompting it to take steps to protect itself, such as terminating or employing other defensive measures