Changes/ConfidentialVirtHostAMDSEVSNP

Confidential Virtualization Host with AMD SEV-SNP

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary

This enables Fedora virtualization hosts to launch confidential virtual machines using AMD's SEV-SNP technology. Confidential virtualization prevents admins with root shell access, or a compromised host software stack, from accessing memory of any running guest. SEV-SNP is an evolution of previously provided SEV and SEV-ES technologies providing stronger protection and unlocking new features such as a secure virtual TPM.

Owner

• Name: Daniel P. Berrangé
• Email: berrange@redhat.com

Current status

• Targeted release: Fedora Linux 41
• Last updated: 2024-05-16
• [Announced]
• [<will be assigned by the Wrangler> Discussion thread]
• FESCo issue: <will be assigned by the Wrangler>
• Tracker bug: <will be assigned by the Wrangler>
• Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

Fedora has provided support for launching confidential virtual machines using KVM on x86_64 hosts for several years, using the SEV and SEV-ES technologies available from AMD CPUs. These technologies have a number of design limitations, however, that make them less secure than is desired, and prevent exposure of desirable features such as secure TPMs. The SEV-SNP technology is a significant design enhancement and architectural change to addresses the key gaps, increasing security and unlocking more powerful use cases for confidential virtual machines.

With SEV/SEV-ES, attestation of the launched VM has to be initiated from the host, which means for a guest owner to attest their VM, they need to rely on API services exposed by the virtualization management stack which will vary across applications. With SEV-SNP, guest owners can initiated attestation from within guest context, providing a standard mechanism across any environment running SEV-SNP.

The SEV-SNP technology also unlocks the ability to have a paravisor run in guest context, which is a miniature OS that runs at a higher privilege level (VMPL 0) than the guest firmware / OS (VMPL 3). The paravisor, specifically the Coconut SVSM implementation, is able to expose trusted services to the guest, which remain inaccessible to the host. This makes it possible to provide a secure virtual TPM for confidential guests, thus allowing guest OS software to be better secured than is the case with normal virtual TPMs running in host OS context.

Benefit to Fedora

Confidential guests running under a Fedora SEV-SNP enabled KVM host will be able to:

• Self initiate an VM attestation to prove integrity of their running guest machine. This guarantees their guest is running on AMD hardware with SEV-SNP setup in a given configuration, running a particular build for EDK2 firmware
• Measure all aspects of the guest machine boot process into PCRs in a securely hosted virtual TPM
• Protected against various known weaknesses of the traditional SEV and SEV-ES technologies

Scope

• Proposal owners:

1. Ensure kernel packages built in Fedora have SEV-SNP feature integrated and enabled. Currently targeted for 6.10 upstream release, with possibility of slip to 6.11.
2. Ensure QEMU packages built in Fedora have SEV-SNP feature integrated and enabled. Currently targeted at 9.1.0 upstream release
3. Ensure libvirt packages built in Fedora have SEV-SNP feature integrated. Targeted to release immediately following merge into QEMU git HEAD
4. Ensure EDK2 packages built in Fedora have a EFI binary built suitable for use with SEV-SNP guests with SVSM paravisor.
5. Add new Cococnut SVSM package, to provide paravisor for SEV-SNP guests
6. Add new IGVM package, to enable bundling of Coconut SVSM and EDK2 firmware into one launch binary
7. Ensure that an IGVM binary is built containing paired EDK2 and SVSM binaries.
8. Ensure that virt-install is able to launch an SEV-SNP guest with SVSM and EDK2

• Other developers:

1. Kernel maintainers: responsible for building new kernel that includes SEV-SNP feature. This should not involve anything notable beyond their normal procedure of rebasing to new upstream kernel releases when they occur, enabling newly introduced KConfig features that are relevant.

• Release engineering: N/a

• Policies and guidelines: N/A

• Trademark approval: N/A

• Alignment with the Fedora Strategy:

Fedora will be demonstrating leading / state of the art integration of SEV-SNP feature into a Linux distribution's virtualization host stack.

Fedora will be providing the fully OSS host-to-guest stack for confidential virtual machines.

Upgrade/compatibility impact

No impact anticipated. Existing users of SEV/SEV-ES technology will keep running as is. The new SEV-SNP technology is an opt-in for users, with suitably new AMD CPUs.

Early Testing (Optional)

Do you require 'QA Blueprint' support? Y (probably useful?)

How To Test

• TBD: document any hardware setup pre-requisites (ie Firmware settings)
• TBD: document process for deploying host software components
• TBD: document process for launching a guest
• TBD: document process for attesting a running guest

User Experience

• Virtualization host owners will be launch confidential virtual machines using AMD SEV-SNP technology
• Virtualization host owners will be able to provide a secure virtual TPM to confidential guests, replacing the current non-confidential swtpm solution in the host
• Guest owners will be able to prove that their OS is running in a Fedora host confidential virtual machine protected by AMD SEV-SNP, by performing a guest attestastion
• Guest owners will be able to securely unlock LUKS block volumes using keys sealed against the virtual TPM

Dependencies

• kernel
• edk2
• coconut-svsm (new package)
• igvm (new package)
• qemu
• libvirt
• virt-manager (for virt-install tool)

Contingency Plan

• Contingency mechanism: None required. All the work is arriving either via rebases to new upstream versions of existing packages, or via new package reviews. If the deadline is missed, then whatever has already arrived in Fedora will remain in Fedora and will not harm other existing Fedora functionality. The remaining pieces will simply wait until the next dev cycle to be integrated, completing the desired user experience.
• Contingency deadline: N/A
• Blocks release? No

Documentation

• Insert link to kernel docs, when available
• Insert link to QEMU docs, when available
• Insert link to libvirt docs, when available
• Write a Fedora wiki page illustrating end-to-end setup and usage example