Virtual Machine Privilege Levels

Virtual Machine Privilege Levels (VMPLs) represent a new optional feature within the SEV-SNP architecture, offering a means for a guest VM to partition its address space into four hierarchical levels. These levels serve as hardware-isolated abstraction layers, providing enhanced security controls and aiding in communication management with the hypervisor.

The VMPLs are arranged hierarchically, with VMPL0 being the highest privilege level and VMPL3 the least privileged. When enabled, each virtual CPU (vCPU) of a VM is assigned a specific VMPL. The Reverse Map Table (RMP) entry for each page of private guest memory is extended to include page access rights corresponding to each VMPL. These permissions are applied in conjunction with standard paging permissions. Essentially, individual guest pages can be marked as readable, writeable, supervisor-mode executable, or user-mode executable. Initially, when a page is validated by a guest, VMPL0 is granted full permissions for the page, while all other VMPLs are granted no permissions. However, the guest can choose to adjust these VMPL permissions using the new RMPADJUST instruction.

The RMPADJUST instruction allows a given VMPL to modify the permissions for a less privileged VMPL. For example, VMPL0 could grant read and write (but not execute) permissions on a page to VMPL1. This granting of permissions is limited to prevent a higher-level VMPL from granting more permissions than it currently possesses. The primary purpose of VMPLs is to set additional page permission checks, and they do not interfere with other x86 security features.

VMPLs

The RMP page permission checks occur during the RMP lookup at the end of a table-walk. These checks are restrictive, meaning that for a guest page to be writable, it must be marked as writable in the guest-managed page tables (associated with the active vCPU), the nested page tables managed by the hypervisor, and the RMP table managed by a higher privileged VMPL.

VMPLs resemble nested virtualization to some extent since a guest can have its own management layer running at a higher VMPL, controlling permissions on its other pages. This facilitates use cases such as securely virtualizing a security-enforcing hypervisor. In a bare-metal system, a standard hypervisor may be employed to enforce certain page permissions, such as making certain pages read-only or non-executable. SEV-SNP enables this same level of control and protection in a cloud environment. In such a scenario, VMPL0 inside the guest would enforce the required page permissions since the actual hypervisor in the cloud is considered untrusted.

VMPL0 #VC Emulation

VMPLs offer valuable applications beyond serving as an abstraction layer. For instance, in SEV-SNP, certain VMs might require a more restrictive environment, and therefore, they may choose to move APIC (Advanced Programmable Interrupt Controller) emulation within the guest's trust domain. To achieve this, VMPL0 can be utilized to perform trusted APIC emulation while the rest of the guest operates in lower VMPLs, remaining unaware of the emulation process.

Another use case for VMPL0 is acting as an intermediary for guest-to-hypervisor communications. In previous SEV and SEV-ES technologies, an enlightened guest OS was necessary to handle security features, such as setting the C-bit in page tables, managing #VC (VMM Communication) exceptions (in SEV-ES), and more. However, in SEV-SNP, these tasks can optionally be delegated to VMPL0.

In this approach, VMPL0 can configure which guest memory in another vCPU is private (C=1) versus shared (C=0) using a watermark called the Virtual Top of Memory (vTOM). Memory addresses below vTOM are automatically treated as private, while memory above vTOM is treated as shared. By using vTOM to distinguish memory in this manner, there is no need to modify the standard x86 page tables with C-bit markings, simplifying guest OS software.

Additionally, VMPL0 can handle #VC events that occur in another vCPU. An SEV-SNP VM can be configured such that when an intercepted instruction is executed in one vCPU (e.g., RDMSR - Read Model Specific Register), that vCPU exits, and VMPL0 is invoked. VMPL0 can then access the intercepted information directly from the encrypted save area of the original vCPU, execute any necessary hyper-calls, and emulate the instruction on behalf of the original vCPU. While not as efficient as a natively enlightened guest, this behavior enables VMPL0 to act as the bridge logic for running unenlightened (legacy) guest VMs. This capability has the potential to secure older workloads that may not easily upgrade to newer operating systems.

Overall, VMPLs extend the versatility of SEV-SNP, allowing for a range of security configurations and enabling new approaches for communication, isolation, and emulation within guest VMs.