SUSE open-sources Secure VM Service Module for Confidential Computing

Today SUSE open-sources its implementation of a Secure Virtual Machine Service Module (SVSM), which will enhance the security of confidential virtual machines (CVMs). The COCONUT-SVSM will allow CVMs to securely store data in a trusted environment and emulate TPM devices on AMD EPYC Generation 3 and later. Written in the Rust programming language it features special isolation capabilities. It is dual-licensed under the Apache-2.0 and MIT licenses. With open-sourcing the project we invite the community to participate in its future development.

What is Confidential Computing

The very short answer is: Confidential Computing encrypts data during processing. In recent years CPU vendors have started to integrate features which allow to setup isolated and trusted execution environments that are inaccessible to the rest of the system. The SVSM builds on AMD Secure Virtual Machine with Secure Nested Paging (AMD SEV-SNP). With this extension the virtual machine runs with encrypted memory and register state, so that its content is not visible outside of the CVMs context.

Why a Secure VM Service Module

Confidential Computing is especially important in environments where the hypervisor is controlled by someone else and thus not fully trusted. Since all peripheral devices of a CVM are controlled by the hypervisor, these devices are not fully trusted too. For most devices like disks and network cards the CVM can protect itself from malformed or malicious input. But there are also devices, like the TPM, which contain security sensitive state that must not be visible to the hypervisor.

The SVSM allows to move the emulated TPM device from the hypervisor into the trusted CVM context. The TPM state is secure and the CVM can use it for attestation and storing encryption keys.

Getting and Installing the Code

The code for the COCONUT-SVSM is available on GitHub and split into several repositories:

• The SVSM source code is hosted at https://github.com/coconut-svsm/svsm.
  This repository contains an INSTALL.md file with detailed installation instructions.
• Linux kernel branches for svsm-host and svsm-guest support are at
  https://github.com/coconut-svsm/linux
• The QEMU svsm branch needed to run the SVSM is at
  https://github.com/coconut-svsm/qemu
• EDK2 firmware changes to support an SVSM are at
  https://github.com/coconut-svsm/edk2

Design Highlights

The SVSM code base has a rich set of features to build on. It contains around 8000 lines of Rust code and puts a strong emphasis on isolation. PerCPU page-tables isolate the mappings of data structures between the cores of a running system. The memory allocator uses buddy and slab algorithms and presents itself to the Rust runtime via the GlobalAlloc trait. With a global allocator the SVSM can use parts of the Rust library which rely on memory allocations, like vec and strings. But also other data structures and smart pointers like Box, Rc and Arc are available to use.

For robustness it includes a locking library with a spin-lock and read-write lock implementation. With fixups the SVSM can recover from exceptions that happen during request processing and return an error code to the operating system.

Last but not least there are also debugging features included, like the ability to collect and print the call-stack. The panic!() macro currently uses them to print a back-trace, but they can also help to debug locking issues.

Future of the COCONUT-SVSM

The released code base is far from being complete. It can boot a Linux image in a CVM with multiple vCPUs assigned. It does not include a TPM emulation yet, but we will add this as one of the very next steps. To implement this, the SVSM will get the ability to run separate modules at ring 3 within the SVSM context. This will isolate the modules from the core SVSM kernel and makes it easy to extend.

With a persistency layer modules like the TPM will be able to securely save and restore their state across reboots and shutdowns. Live migration support is also planned. The SVSM will be able to transfer the running guest operating system to another SVSM running on a remote machine. This requires a secure channel between the source and destination SVSM as well as help from the hypervisor for tracking dirty pages.

Ultimately we want to move more device emulation parts from the hypervisor into the CVM context to enable running almost unenlightened operating systems with AMD SEV-SNP protection.

Acknowledgments

The COCONUT-SVSM project would not have been possible without the close relationship to AMD. AMD provided the Linux kernel and OVMF modifications to complete the SVSM host and guest stack. Many thanks for the work and our continuous cooperation!