SEV is an extension to the AMD-V architecture which supports running encrypted virtual machine (VMs) under the control of KVM. Encrypted VMs have their pages (code and data) secured such that only the guest itself has access to the unencrypted version. Each encrypted VM is associated with a unique encryption key; if the guest data is accessed from a different entity using a different key, then the encrypted guest's data will be incorrectly decrypted into unintelligible plaintext.
SEV support has been accepted in upstream projects. This repository provides scripts to build various components to enable SEV support until the distros include the newer versions.
Kata Containers is an OpenStack project designed to leverage hardware virtualization technology to provide maximum isolation for container workloads in cloud environments. On AMD systems, SEV can be applied to further protect the confidentiality of container workloads from the host and other tenant containers.
To enable SEV support with Kata Containers, the following component versions are required:
| Project | Version |
|---|---|
| kernel | >= 4.17 |
| qemu | >= 3.0 |
| ovmf | >= commit (75b7aa9528bd 2018-07-06 ) |
NOTE: SEV support is not available in SeaBIOS. Guests must use OVMF.
The Prepare Host OS section contains instructions for satisfying these dependencies.
The packaged versions of the Linux kernel, qemu, and OVMF in Ubuntu 18.04 do not yet support SEV, so it is necessary to build them from source.
The build.sh script in the distros/ubuntu-18.04 directory will build and install SEV-capable versions of the host kernel, qemu, and OVMF:
NOTE: build.sh will use 'sudo' as necessary to gain privileges to install files, so build.sh should be run as a normal user.
$ cd distros/ubuntu-18.04
$ ./build.sh
Once the kernel has been installed, reboot and choose the SEV kernel:
$ sudo reboot
At this point, the host is ready to act as a SEV-capable hypervisor. For more information about running SEV guests, see README.md in the master branch.
Once the host is running an SEV-capable kernel, execute build-kata.sh in distros/ubuntu-18.04 to build, install, and configure the Kata Containers system along with the latest version of Docker CE:
NOTE: build-kata.sh will use 'sudo' as necessary to gain privileges to install files, so build-kata.sh should be run as a normal user.
$ cd distros/ubuntu-18.04
$ ./build-kata.sh
At this point, docker is installed and configured to use the SEV-capable kata-runtime as the default runtime for containers. In addition, kata-runtime is configured to use SEV for all containers by default.
Use the following command to launch a busybox container protected by SEV:
$ sudo docker run -it busybox sh
To verify that SEV is active in the guest, look for messages in the kernel logs containing "SEV":
# dmesg | grep SEV
[ 0.001000] AMD Secure Encrypted Virtualization (SEV) active
[ 0.219196] SEV is active and system is using DMA bounce buffers
Linux Kernel Memory Encryption Documentation (RST)
Linux Kernel Memory Encryption Documentation (TXT)
Qemu Memory Encryption Documentation
-
How do I know if my hypervisor supports the SEV feature?
a) When using libvirt >= 4.15, run the following command as root:
# virsh domcapabilitiesIf the hypervisor supports the SEV feature, then the sev tag will be present.
See Libvirt DomainCapabilities feature for additional information.
b) Use the QMP 'query-sev-capabilities' command to check for SEV support. If SEV is supported, then the command will return the full SEV capabilities (which includes the host PDH, cert-chain, cbitpos and reduced-phys-bits).
See QMP doc for details on how to interact with QMP shell.
-
How do I know if SEV is enabled in the guest?
a) Check the kernel log buffer for the following message:
# dmesg | grep -i sev AMD Secure Encrypted Virtualization (SEV) activeb) MSR 0xc0010131 (MSR_AMD64_SEV) can be used to determine if SEV is active:
# rdmsr -a 0xc0010131Bit[0]: 0 = SEV is not active 1 = SEV is active
-
Can I use virt-manager to launch SEV guests?
virt-manager uses libvirt to manage VMs. SEV support has been added in libvirt, but virt-manager does not use the newly introduced LaunchSecurity tags yet. Hence, we will not able to launch SEV guests through virt-manager.
If your system is using libvirt >= 4.15, then you can manually edit the xml file to use LaunchSecurity to enable SEV support in the guest.
-
virtio-blk devices fail with an out-of-dma-buffer error!
To support the multiqueue mode, virtio-blk drivers inside the guest allocate a large number of DMA buffers. SEV guests use SWIOTLB for DMA buffer allocation/mapping, hence the kernel exhausts the SWIOTLB pool quickly and triggers the out-of-memory error. In those cases, consider increasing the SWIOTLB pool size , or use a virtio-scsi device.
NOTE: If the device containing the container rootfs image is changed from virtio-blk to virtio-scsi, then the kernel_params variable in /etc/kata-containers/configuration.toml must be updated with root=/dev/sda1 (instead of /dev/vda1). Otherwise, the container will appear to hang during startup.
The root device can be changed from the command line using sed:
sudo sed -i -e "s/vda1/sda1/g" /etc/kata-containers/configuration.toml
-
How do I increase the SWIOTLB limit?
When SEV is enabled, all DMA operations inside the guest must be performed on shared (i.e. unencrypted) memory. The Linux kernel uses SWIOTLB bounce buffers to meet this requirement. A guest panic will occur if the kernel exhausts the SWIOTLB pool. The Linux kernel defaults to a 64MB SWIOTLB pool. It is recommended to increase the SWIOTLB pool size to 512MB. The SWIOTLB pool size can be increased in the guest by appending the "swiotlb=" parameter to the Linux kernel command line in the configuration.toml file.
Append the "swiotlb=" parameter to the kernel_params variable in /etc/kata-containers/configuration.toml:
kernel_params = " ... swiotlb=262144"Alternatively, this can be done from the command line using sed:
sudo sed -i -e "s/^kernel_params = \"\(.*\)\"/kernel_params = \"\1 swiotlb=262144\"/g" /etc/kata-containers/configuration.toml