Jump to content
documentation.suse.com / AMD Secure Encrypted Virtualization (AMD-SEV) Guide
SUSE Linux Enterprise Server 15 SP3

AMD Secure Encrypted Virtualization (AMD-SEV) Guide

Publication Date: December 05, 2024

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 and how to enable and configure it. It also mentions some limitations and restrictions that the use of SEV causes as compared to non-encrypted virtualization.

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: An NVDIMM (non-volatile memory module) could be physically removed from a system and the data on it will remain intact, like that on a hard disk 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. 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.

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 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: No IDE support in Q35

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>
    <memoryBacking>
    <locked/>
    </memoryBacking>
    <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>0x0033</policy> 4
    </launchSecurity>
    <devices>
    <disk type='file' device='disk'>
    <driver iommu='on' name='qemu' type='raw'/>
    <target dev='vda' bus='virtio'/>
    <source file='/vmimages/sev-guest-disk.raw'/>
    </disk>
    <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 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. 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, see Virtualization Best Practices, Article “Virtualization Best Practices”, Section 4.1.1 “Configuring the VM Host Server and the VM Guest to use 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 be terminated.

5 SEV with KubeVirt

KubeVirt supports running SEV guests starting from the version 0.49.0. The functionality can be activated by enabling the WorkloadEncryptionSEV feature gate:

> kubectl edit kubevirt kubevirt -n kubevirt
[...]
spec:
  configuration:
    developerConfiguration:
      featureGates:
      - WorkloadEncryptionSEV
[...]

To run an SEV-encrypted guest, the virtual machine specification must include the entry sev: {} under the launchSecurity domain element. Additionally, you need to configure the firmware/bootloader parameters to use the efi option with the secureBoot flag set to disabled. The corresponding YAML snippet will look similar to the following:

[...]
spec:
  domain:
    firmware:
      bootloader:
        efi:
          secureBoot: false
    launchSecurity:
      sev: {}
[...]

6 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 shutdown 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.

7 More information