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-06-11
• [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 initiate attestation from within guest context, providing a standard mechanism across any virtualization environment running SEV-SNP, avoiding a reliance on any host platform tools/APIs.

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 firmware and OS, which also 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.

Feedback

• TBD

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, providing data confidentiality even if the host is compromised or malicious.
• Measure all aspects of the guest machine boot process into PCRs in a securely hosted virtual TPM
• Protect against various known weaknesses of the traditional SEV and SEV-ES technologies

Scope

Proposal owners

• Ensure kernel packages built in Fedora have SEV-SNP feature integrated and enabled. Code is in kvm/next tree, targetted to merge to linus's tree when 6.11 merge window opens. Will require backport to Fedora's 6.10 tree.
• Ensure QEMU packages built in Fedora have SEV-SNP feature integrated and enabled. Queued for merge into the forthcoming 9.1.0 upstream release - rc0 Jul 30th, GA Sep 3rd. F41 beta will ship a QEMU rc, and F41 GA will have QEMU GA release.
• Ensure libvirt packages built in Fedora have SEV-SNP feature integrated. Targeted to release immediately following merge into QEMU git HEAD. Releases on 1st of each month, anticipated Sept 1st release at latest, version 10.7.0, but ideally Aug 1st release.
• Ensure EDK2 packages built in Fedora have a EFI binary built suitable for use with SEV-SNP guests with SVSM paravisor. EDK2 currently in rawhide has support for SNP + SVSM. Only lacking vTPM support.
• Add new Coconut SVSM package, to provide paravisor for SEV-SNP guests. Work in progress adding required rust deps.
• Add new IGVM library package, to enable bundling of Coconut SVSM and EDK2 firmware into one launch binary. Work in progress adding required rust deps.
• Ensure that an IGVM binary is built containing paired EDK2 and SVSM binaries.
• Ensure that virt-install is able to launch an SEV-SNP guest with SVSM and EDK2

Other developers

• Kernel maintainers: responsible for building new kernel that includes SEV-SNP feature. Currently code is in kvm/next tree, targetted for linus' tree when the 6.11 merge window opens. ONLY if it merges to linus' tree, then proposal owners are to provide Fedora kernel maintainers with a set of backported patches against 6.10 prior to Fedora Beta. Fedora 41 will get 6.11 kernels after GA.

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 on modern AMD x86_64 EPYC hardware.

Upgrade/compatibility impact

No impact anticipated. Existing users of SEV/SEV-ES technology will keep using it without changes. The new SEV-SNP technology is strictly 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

Use of AMD SEV-SNP technology requires an AMD EPYC CPU with the Zen 3 generation micro-architecture, or newer (Milan, Genoa). These are identified by the 4th digit in the processor model name having the value '3' or greater. eg EPYC7xx3 or EPYC9xx4. See also SEV User Guide (pdf), Chapter 1 for CPU model support guidance.

• TBD: document process for configuring host bare metal firmware (if applicable?)
• TBD: document process for deploying host software components. Likely should not require any special steps, beyond the normal libvirt + KVM install process.
• TBD: document process for creating a guest. Will update existing libvirt SEV docs to cover SEV-SNP
• TBD: document process for attesting a running guest. Again, will update above libvirt SEV docs.

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 attestation
• Guest owners will be able to measure their guest OS software environment using the TPM. Caveat: this is an ephemeral TPM initially, which imposes limits on the ways in which users can take advantage of it. A persistent TPM will be supported at a later date.

Dependencies

• kernel
• edk2
• coconut-svsm (new package github upstream)
  • rust-intrusive-collections (new package, Review Request)
  • rust-packit (new package or include as vendored)
• igvm (new package github upstream)
  • rust-hmac-sha512 (new package, Review Request)
  • rust-bitfield-struct (new package, Review Request)
  • rust-open-enum (new package)
  • rust-open-enum-derive (new package)
  • rust-range-map-vec (new package, Review Request: Approved)
• qemu
• libvirt
• virt-manager (for virt-install tool)
• snphost github upstream
• snpguest (new package, github upstream)

Contingency Plan

• Contingency mechanism: None. All the work is arriving either via rebases to new upstream versions of existing packages, patches to 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 wait until the next Fedora dev cycle to be integrated, completing the desired user experience. As such, no contingency action needs to be taken should the Fedora feature completion deadline be missed.
• 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