Encrypted CPU Registers

The first version of AMD SEV had a problem that allowed the hypervisor to read the registers of a confidential VM whenever a VMEXIT occurred. As in AMD-V, since SEV is only an extension of it, when a VMEXIT occurs, control of the VM is returned to the hypervisor for management purposes. In addition, in order to recover the state of the guest, the current guest state, entry and exit controls must be saved. Previously, the guest state was stored unencrypted in hypervisor memory, allowing the hypervisor to modify the current instruction pointer to skip security checks or read the registers. For example, the registers could contain secrets currently being used by the guest. To solve this problem, all guest state and input controls are stored in the hypervisor's memory in an encrypted, integrity and replay-secured form.

However, there are some benign cases, such as device emulation, where the hypervisor needs to access and modify the guest state. The SEV architecture distinguishes between Automatic Exits (AE) and Non-Automatic Exits (NAE) of the VM through the VMEXIT command. AE's do not require the hypervisor to read any state, so all state is stored in encrypted form. On the other hand, NAEs require the hypervisor to read or write to the guest state. To handle NAEs safely, a new exception #VC (VMM Communication Exception) is introduced whenever NAEs occur and is handled by the guest VM. This exception is thrown by the CPU in response to an event that requires hypervisor emulation. Now, when the exception is handled by the guest VM, it decides which registers to expose to the hypervisor by writing them to a structure called the Guest Hypervisor Communication Block (GHCB). The GHCB resides in shared memory and is encrypted with the hypervisor's key. Only after the exception is handled does a VMEXIT occur, all state is saved encrypted with the VM's key, and the hypervisor can handle emulation by accessing the GHCB. After the hypervisor completes the emulation, the VM resumes within the exception handler, inspects the GHCB, and verifies the changes before applying them to it's state. Thus, this feature allows the guest VM to safely reject malicious behavior from the hypervisor. It's up to the VM to protect itself and its interfaces.