Jump to content

AMD Secure Encrypted Virtualization (AMD-SEV) Guide

AMD's Secure Encrypted Virtualization (SEV) allows the memory of virtual machines to be encrypted. This is a new feature for Linux's built-in Kernel-based Virtual Machine (KVM) hypervisor. The intention is to increase system security, especially when using persistent memory.

This document aims to provide a basic understanding of how SEV works, how to enable and configure it, and some of the limitations and restrictions that its use causes as compared to non-encrypted virtualization.

Publication Date: December 03, 2021

1 Introducing SEV

Encryption of computer data stored on disk is a widely-deployed feature. However, data in RAM is stored in the clear. This can leave that data vulnerable to software or hardware probing by intruders into the host system. New persistent-memory technology makes this problem more acute, since an NVDIMM (non-volatile memory module) could be physically removed from a system and the data on it would remain intact, like that on a hard drive or SSD. Without encryption, any stored information—such as sensitive data, passwords, or secret keys—could easily be compromised.

AMD's SEV (Secure Encrypted Virtualization) is a technology to protect Linux KVM virtual machines by transparently encrypting the memory of each VM with a unique key. SEV can also calculate a signature of the memory's contents, which can be sent to the VM's owner as an attestation that the memory was encrypted correctly by the firmware. SEV is especially relevant to cloud computing environments, where VMs are hosted on remote servers that are not under the control of the VMs' owners, since this can reduce the amount of trust VMs can place in the hypervisor and administrator of their host system.

In SUSE Linux Enterprise 12 SP4 and above, and a forthcoming maintenance release of SUSE Linux Enterprise 15, the kernel, QEMU, and libvirt support the creation and management of VMs using SEV. Currently, the technology is only available as a technology preview, but it will be fully supported in future versions of SUSE Linux Enterprise.

2 VM Host Requirements

The VM host hardware must support AMD's SEV technology. To detect if the host hardware supports SEV, check that the sev attribute is present in the capabilities of libvirt and that its value is set appropriately:

   <sev supported='yes'/>

Additionally, ensure that the kvm_amd kernel module has the sev parameter enabled:

/sys/module/kvm_amd/parameters/sev = 1

3 VM Requirements

The VM must be the modern Q35 machine type and must use UEFI firmware.


The Q35 machine type does not have an IDE controller and does not support IDE disks.

All virtio devices need to be configured with the iommu='on' attribute in their <driver> configuration. In addition, all memory regions used by the VM must be locked for Direct Memory Access (DMA) and to prevent swapping.

4 VM Configuration

Example 1: Sample Configuration File

As an example, an SEV-encrypted VM configured with 4 GB of memory would contain the following XML configuration:

<domain type='kvm'>
    <memory unit='KiB'>4194304</memory>
    <currentMemory unit='KiB'>4194304</currentMemory>
    <type arch='x86_64' machine='pc-q35-2.11'>hvm</type>
    <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x86_64-ms-4m-code.bin</loader>
    <boot dev='hd'/>
    <launchSecurity 1 type='sev'>
    <cbitpos>47</cbitpos> 2
    <reducedPhysBits>1</reducedPhysBits> 3
    <policy>0x0033</policy> 4
    <disk type='file' device='disk'>
    <driver iommu='on' name='qemu' type='raw'/>
    <target dev='vda' bus='virtio'/>
    <source file='/vmimages/sev-guest-disk.raw'/>
    <rng model='virtio'>
    <driver iommu='on'/>
    <memballoon model='virtio'>
    <driver iommu='on' /> 5
    <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/>


The launchSecurity type='sev' element and its contents enable encryption of the contents of the VM's memory.


When memory encryption is enabled, one of the physical address bits (also known as the "C-bit") is used to mark if a memory page is protected. The required cbitpos element provides the location of the C-bit in a guest page table entry. For example, the value 47 indicates that bit position 47 in a page table entry will determine whether that page is encrypted or not. The C-bit number is read from the host's CPUID and is thus hardware-dependent. The value of cbitpos is hypervisor-dependent, and can be obtained through the sev element in the capabilities of the domain.


When memory encryption is enabled, we lose certain bits of the physical address space. The required reducedPhysBits element provides this physical address bit reduction. Similarly to cbitpos, the value of reducedPhysBits is processor-family-dependent and can be obtained through the sev element in the domain capabilities.


The required policy element provides the guest policy, which must be maintained by the SEV firmware. This policy is enforced by the firmware, and restricts what configuration and operational commands can be performed on the VM by the hypervisor. The guest policy provided when starting the VM is bound to that VM and cannot be changed during its lifetime.


In addition to the launchSecurity settings, SEV-encrypted VMs must have the iommu='on' attribute set in each virtio device. This attribute is required in order to enable DMA APIs for the device within QEMU.

The guest policy is four unsigned bytes with the following definition:

Table 1: Guest Policy Definitions




If set, debugging of the guest is disallowed


If set, sharing keys with other guests is disallowed


If set, SEV-ES is required


If set, sending the guest to another platform is disallowed


If set, the guest must not be transmitted to another platform that is not in the domain


If set, the guest must not be transmitted to another platform that is not SEV-capable




The guest must not be transmitted to another platform with a lower firmware version

The optional dhCert element provides the guest owner's base64-encoded Diffie-Hellman (DH) key. The key is used to negotiate a master secret key between the SEV firmware and guest owner. This master secret key is then used to establish a trusted channel between the SEV firmware and guest owner.

The optional session element provides the guest owner's base64-encoded session blob, as defined in the SEV API specification. See the LAUNCH_START section of the SEV specification for the session blob format.

SEV-encrypted VMs must also have all of their memory regions locked to allow DMA and prevent swapping. Explicit locking of memory must be specified using the locked subelement of memoryBacking. Explicit memory locking can be avoided by configuring the virtual machine to use hugepages. For more information on using hugepages with VMs, refer to the Virtualization Best Practices Guide, Chapter "Configuring the VM Host Server and the VM Guest to use Huge Pages": https://www.suse.com/documentation/sles-15/book_quickstarts/data/sec_vt_best_hostlevel.html#sec_vt_best_mem_huge_pages.

Whilst the overhead incurred is no different to that required for non-SEV VMs, it is much more important to get the hard limit right when pinning memory. If the limit is too low, the VM will get killed.

5 Current Limitations

  • The guest operating system running inside an SEV-encrypted VM must contain SEV support. Currently, SUSE Linux Enterprise Server 12 SP4, SUSE Linux Enterprise Server 15, and SUSE Linux Enterprise Server 15 SP1 provide this.

  • Any operations that involve saving and restoring the memory and state of an instance are currently not supported. This means that SEV-encrypted VMs cannot be resumed from snapshots, and live migration is not possible. Encrypted VMs can be shut down and restarted on another host as normal.

  • SEV-encrypted VMs cannot contain directly accessible host devices (that is, PCI passthrough).

These limitations will be removed in the future as the hardware, firmware, and various layers of software receive new features.

6 For More Information

Print this page