How to enhance VM Security with AMD SEV-SNP on SLES 15-SP6

Share
Share

Looking to enhance the security of your virtual machines? As announced last week, SUSE Linux Enterprise Server 15-SP6 now supports AMD SEV-SNP, a technology that isolates virtual machines from the host system and other VMs. This guide will walk through the steps to enable and use AMD SEV-SNP on your AMD EPYC server with SUSE Linux Enterprise Server 15-SP6.

Supported Hardware

In order to run AMD SEV-SNP virtual machines a system with an AMD EPYC Generation 3 or newer is required. The BIOS of the machine must provide the necessary options to enable support for confidential computing.

Enabling Confidential Compute Module

Support for AMD SEV-SNP is available as a Technology Preview in SUSE Linux Enterprise Server 15-SP6. As such it is not part of the default installation or repositories.

The packages are shipped via the Confidential Compute Module, which must be enabled at system installation time or later via the SUSEConnect command line tool.

To check whether the module is already enabled, type

# suseconnect -l

This will print a list of available modules together with their activation status and commands to enable not-yet activated ones.

For the (inactive) confidential compute module there is an entry like this:

Confidential Computing Technical Preview Module 15 SP6 x86_64
Activate with: suseconnect -p sle-module-confidential-computing/15.6/x86_64

The module can be enabled with the command from the message above:

# suseconnect -p sle-module-confidential-computing/15.6/x86_64
Registering system to SUSE Customer Center
Updating system details on https://scc.suse.com ...
Activating sle-module-confidential-computing 15.6 x86_64 ...
-> Adding service to system ...
-> Installing release package ...
Successfully registered system

After this command has completed the confidential compute module is enabled and packages can be installed.

Installing Packages and Setting up the Base System

The confidential compute module provides replacement packages supporting AMD SEV-SNP. To ensure a maximum of compatibility these packages are based on the code streams from SUSE Linux Enterprise Server.

Four components need to be replaced:

  • The Linux kernel
  • QEMU Virtual Machine Monitor
  • OVMF Virtual Machine Firmware
  • LibVirt framework

With the following command the replacement packages are installed:

# zypper in --from SLE-Module-Confidential-Computing-15-SP6-Pool --from SLE-Module-Confidential-Computing-15-SP6-Updates qemu libvirt kernel-coco ovmf qemu-ovmf-x86_64

When some of the packages are already installed from the main repositories, additional parameters to the zypper command are needed:

# zypper in --allow-vendor-change --oldpackage --allow-downgrade --from SLE-Module-Confidential-Computing-15-SP6-Pool --from SLE-Module-Confidential-Computing-15-SP6-Updates qemu libvirt kernel-coco ovmf qemu-ovmf-x86_64

These commands will install the virtualization packages with confidential computing support on the system. To prevent the packages being replaced from the main repository, they need to be locked as well:

# zypper addlock qemu libvirt kernel-coco ovmf qemu-ovmf-x86_64

After that the system needs to be set up with a configuration change to make the AMD SEV-SNP feature ready to use. The IOMMU on the host side must be configured in non-passthrough mode. This is required to prevent peripheral devices from writing to memory which belongs to an encrypted guest and destroy its data integrity.

The default IOMMU configuration in SUSE Linux Enterprise Server is passthrough mode. It can be disabled by changing the /etc/default/grub file. In that file, add iommu=nopt to the GRUB_CMDLINE_LINUX_DEFAULT variable. After making the changes, the bootloader configuration needs to be updated by running this command:

# update-bootloader

The system is now ready to be restarted with the confidential computing kernel. It is not selected as the default kernel in the bootloader, so make sure to select it at the boot menu.

Verifying Setup

To check that the system has started with the new kernel, look at the output of uname -r:

# uname -r
6.4.0-150616.coco15sp6-coco

The kernel version printed must contain the coco tag. When this kernel is running, the initialization result of the AMD Secure Processor needs to be checked in the kernel log:

# dmesg | grep -i ccp
[   10.103166] ccp 0000:42:00.1: enabling device (0000 -> 0002)
[   10.114951] ccp 0000:42:00.1: no command queues available
[   10.127137] ccp 0000:42:00.1: sev enabled
[   10.133152] ccp 0000:42:00.1: psp enabled
[   10.240817] ccp 0000:42:00.1: SEV firmware update successful
[   11.128307] ccp 0000:42:00.1: SEV API:1.55 build:8
[   11.135057] ccp 0000:42:00.1: SEV-SNP API:1.55 build:8

The message about the SEV-SNP API version indicates the successful initialization of the AMD Secure Processor. Sometimes it happens that these messages do not appear in the kernel log. In this case the BIOS settings or the IOMMU configuration are often the root-cause.

Launching an AMD SEV-SNP Virtual Machine

With the confidential computing kernel booted and the AMD Security Processor initialized the system is ready to run AMD SEV-SNP protected virtual machines with the LibVirt framework.

LibVirt has several ways of setting up new virtual machines, this guide will use a prepared disk image and the Virt-Manager frontend tool. Connect Virt-Manager to the AMD EPYC host and start creating a new virtual machine. This will lead you through a four-step dialog. In the fourth step, make sure to select “Customize configuration before install”:

After clicking on “Finish” the virtual machine configuration window appears. Select the XML Tab:

This lets you edit the XML configuration of the virtual machine used by the LibVirt backend. To protect the virtual machine with AMD SEV-SNP, first set the correct firmware by modifying the <os> section like this:

<os>
    <type arch="x86_64" machine="pc-q35-8.2">hvm</type>
    <loader readonly="yes" type="rom">/usr/share/qemu/ovmf-x86_64-sev.bin</loader>
    <boot dev="hd"/>
</os>

The <loader> line sets the firmware to the SEV version of OVMF.

The next step is adding a <launchSecurity> section. For AMD SEV-SNP, the section looks like this:

<launchSecurity type="sev-snp">
    <policy>0x00030000</policy>
</launchSecurity>

Apply the changes and go back to the Details tab, select CPUs in the left-hand list, and set the CPU type to host-model:

Apply this change as well and click “Begin Installation”. This will start the virtual machine and install it according to your settings. After this process is complete, the virtual machine boots up and the AMD SEV-SNP protection can be verified.

Verifying the AMD SEV-SNP Virtual Machine

From the appearance of the virtual machine one can not tell whether it runs in a confidential computing environment or not. But there are several ways to verify that from within the virtual machine.

The easiest way is to check the kernel log:

# dmesg | grep -i sev-snp
[     1.986186] Memory Encryption Features active: AMD SEV SEV-ES SEV-SNP

This SEV-SNP feature appearing in the kernel log among the active memory encryption features shows that the feature is active for the virtual machine.

There are also cryptographically secure ways to prove the security of the AMD SEV-SNP environment. This will be covered in detail in another article.

Outlook

The guide in this post showed how to set up a virtual machine protected by AMD SEV-SNP with SUSE Linux Enterprise Server 15-SP6 on an AMD EPYC host machine.

The next parts of this blog series will explore how to deploy complex workloads in a confidential virtual machine and how to get a cryptographic proof for the correctness of the confidential setup.

Share
(Visited 1 times, 1 visits today)
Avatar photo
285 views
Joerg Roedel Jörg is leading the Confidential Computing efforts at SUSE and is working with AMD on enabling SEV and related technologies. In this role he implemented major parts of the AMD SEV-ES guest support in the Linux kernel and brought it upstream into kernel 5.10. He is also active in the Linux kernel community as the maintainer for the IOMMU subsystem and a contributor to other areas like KVM or the X86 architecture.