Jump to content
SUSE Linux Enterprise Server 15

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: February 01, 2019

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 will remain intact, like to 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 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 which are not under the control of the VMs' owners, since it can reduce the amount of trust VMs need to 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 technical 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:

<domainCapabilities>
   ...
   <features>
   ...
   <sev supported='yes'/>
   ...
   </sev>
   </features>
</domainCapabilities>

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.

Note
Note

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

Currently virtio-blk disks are not supported. SATA and virtio-scsi disks are supported and work as expected. 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>
    <os>
    <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>
    <nvram>/var/lib/libvirt/qemu/nvram/sles15-sev-guest_VARS.fd</nvram>
    <boot dev='hd'/>
    </os>
    <launchSecurity 1 type='sev'>
    <cbitpos>47</cbitpos> 2
    <reducedPhysBits>1</reducedPhysBits> 3
    <policy>0x0037</policy> 4
    </launchSecurity>
    <memtune>
    <hard_limit unit='KiB'>4718592</hard_limit> 
    ...
    </memtune>
    <devices>
    <disk type='file' device='disk'>
    <driver name='qemu' type='raw'/>
    <target dev='sda' bus='scsi'/>
    <source file='/vmimages/sev-guest-disk.raw'/>
    </disk>
    <controller type='scsi' model='virtio-scsi'>
    <driver iommu='on'/>
    </controller>
    <rng model='virtio'>
    <driver iommu='on'/>
    ...
    </rng>
    <memballoon model='virtio'>
    <driver iommu='on' /> 5
    ...
    </memballoon>
    <video>
    <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/>
    </video>
    ...
    </devices>
    ...
    </domain>

1

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

2

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.

3

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.

4

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 throughout its lifetime.

5

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

Bit(s)

Definition

0

If set, debugging of the guest is disallowed

1

If set, sharing keys with other guests is disallowed

2

If set, SEV-ES is required

3

If set, sending the guest to another platform is disallowed

4

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

5

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

6-15

Reserved

16-32

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. This includes not only the VM's RAM, but also ROM(s), pflash, and video memory. Using the example configuration, the memory regions needing to be locked total to 4352592 kB, which exceeds the default memlock limit. The memlock limit for a virtual machine process can be increased using the hard_limit subelement of memtune. The value 4352592 kB was determined using the following formula:

hard_limit = VM RAM + VM video memory + ROMs/ACPI tables

where:

    4096 kB (UEFI ROM)
   +  4096 kB (UEFI variable store)
   +   128 kB (PC ROM)
   +   128 kB (ISA BIOS) 
   +  2384 kB (ACPI tables)
   = 10832 kB (total of all ROMs/ACPI tables)

Although 10832 kB for ROMs and ACPI tables should be sufficient in most cases, we recommend adding a few hundred kilobytes of padding. ROM sizes have been known to change and adding some padding here will accommodate that. Using the virtual machine RAM and video memory values from the example configuration:

  4194304 kB (virtual machine RAM) 
   +   65536 kB (qlx RAM) 
   +   65536 kB (qlx video RAM) 
   +   16384 kB (qlx VGA memory)
   +   10832 kB (ROMs/ACPI tables)
   = 4352592 kB hard_limit

Calculating the memlock limit and setting it via hard_limit 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 and SUSE Linux Enterprise Server 15 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 shutdown and restarted on another host as normal.

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

  • virtio-blk disks are not supported. virtio-scsi and SATA disks are supported and work as expected.

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