Software Implications

Hypervisor

While SEV still relies on the hypervisor for various virtual machine functions, such as device emulation and scheduling, it significantly reduces the hypervisor's role in ensuring security. A guest operating with SEV enabled can protect itself by designating memory pages as private when they should not be shared beyond the virtual machine.

During runtime, the hypervisor communicates with the AMD-SP (AMD Secure Processor) to coordinate the management of memory encryption keys. This communication occurs through the AMD-SP driver and involves tasks like informing the AMD-SP when a VM is about to be executed, allowing the AMD-SP to load the appropriate encryption key into the AES-128 encryption engine. The hypervisor also interacts with the AMD-SP to establish secure mechanisms for guest attestation, migration, and other operations.

Despite having control over the ASID (Address Space Identifier) used to execute a VM and selecting the encryption key, this is not a security concern because a loaded encryption key is meaningless unless the guest was already encrypted with that key. If an incorrect key is loaded or the wrong ASID is used for a guest, the first instruction fetch of that guest will fail as memory will be decrypted with the wrong key, leading to the execution of invalid data and likely causing a fault.

Guest

An OS running in an SEV-enabled guest must be aware of this new hardware feature and configure its page tables accordingly. Similar to the SME full memory encryption mode, most DRAM addresses are configured to have the C-bit (bit 47) set to 1.

One essential consideration for an SEV-enabled guest is that the SEV hardware does not allow DMA (Direct Memory Access) into guest encrypted memory due to security reasons. All DMA, whether from actual hardware or a hypervisor emulated device, must occur to shared guest memory. Consequently, the guest OS can either allocate memory pages for DMA as shared (C-bit clear) or copy data to/from a special buffer (known as a "bounce buffer") for DMA purposes. Some operating systems already support bounce buffers, such as the swiotlb functionality in Linux.

Lastly, SEV supports multi-core guests, and data can be shared among these cores with no additional performance penalty. The hypervisor simply needs to use the same ASID for all virtual CPU instances of a particular guest.