(adding tracker bug) |
|||
(37 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
= Confidential Virtualization Host with AMD SEV-SNP = | = Confidential Virtualization Host with AMD SEV-SNP = | ||
== Summary == | == Summary == | ||
Line 10: | Line 8: | ||
* Name: [[User:berrange| Daniel P. Berrangé]] | * Name: [[User:berrange| Daniel P. Berrangé]] | ||
* Email: berrange@redhat.com | * Email: berrange@redhat.com | ||
== Current status == | == Current status == | ||
[[Category:SelfContainedChange]] | [[Category:SelfContainedChange]] | ||
[[Category:ChangeAcceptedF41]] | |||
* Targeted release: [https://docs.fedoraproject.org/en-US/releases/f41/ Fedora Linux 41] | * Targeted release: [https://docs.fedoraproject.org/en-US/releases/f41/ Fedora Linux 41] | ||
Line 29: | Line 21: | ||
ON_QA -> change is fully code complete | ON_QA -> change is fully code complete | ||
--> | --> | ||
* [Announced] | * [https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/thread/QBDGTXHFVDUJSFLHHOCHSFTNROQUGUQC/ Announced] | ||
* [ | * [https://discussion.fedoraproject.org/t/f41-change-proposal-confidential-virtualization-host-with-amd-sev-snp-self-contained/120326 Discussion thread] | ||
* FESCo issue: | * FESCo issue: [https://pagure.io/fesco/issue/3236 #3236] | ||
* Tracker bug: | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2298853 #2298853] | ||
* Release notes tracker: <will be assigned by the Wrangler> | * Release notes tracker: <will be assigned by the Wrangler> | ||
Line 38: | Line 30: | ||
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. | 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 | 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, 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. | 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 [https://github.com/coconut-svsm/svsm 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 == | == Feedback == | ||
* TBD | |||
== Benefit to Fedora == | == Benefit to Fedora == | ||
Line 49: | Line 42: | ||
Confidential guests running under a Fedora SEV-SNP enabled KVM host will be able to: | 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 | * 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 | * 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 == | == 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 [https://wiki.qemu.org/Planning/9.1 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 | |||
Fedora will be providing the fully OSS host-to-guest stack for confidential virtual machines. | === 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 == | == Upgrade/compatibility impact == | ||
No impact anticipated. Existing users of SEV/SEV-ES technology will keep | 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) == | == Early Testing (Optional) == | ||
Line 90: | Line 88: | ||
== How To Test == | == 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 [https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/tuning-guides/58207-using-sev-with-amd-epyc-processors.pdf 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 [https://libvirt.org/kbase/launch_security_sev.html libvirt SEV docs] to cover SEV-SNP | |||
* TBD: document process for attesting a running guest. Again, will update above libvirt SEV docs. | |||
== User Experience == | == 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 == | == Dependencies == | ||
* kernel | |||
* edk2 | |||
* coconut-svsm (new package [https://github.com/coconut-svsm/svsm github upstream]) | |||
** rust-intrusive-collections (new package, [https://bugzilla.redhat.com/show_bug.cgi?id=2290692 Review Request]) | |||
** rust-packit (new package or include as vendored) | |||
* igvm (new package [https://github.com/microsoft/igvm/ github upstream]) | |||
** rust-hmac-sha512 (new package, [https://bugzilla.redhat.com/show_bug.cgi?id=2290698 Review Request]) | |||
** rust-bitfield-struct (new package, [https://bugzilla.redhat.com/show_bug.cgi?id=2290696 Review Request]) | |||
** rust-open-enum (new package) | |||
** rust-open-enum-derive (new package) | |||
** rust-range-map-vec (new package, [https://bugzilla.redhat.com/show_bug.cgi?id=2282977 Review Request]: Approved) | |||
* qemu | |||
* libvirt | |||
* virt-manager (for virt-install tool) | |||
* snphost [https://github.com/virtee/snphost github upstream] | |||
* snpguest (new package, [https://github.com/virtee/snpguest github upstream]) | |||
== Contingency Plan == | == 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 | |||
* Contingency deadline: N/A | |||
* Blocks release? | |||
== Documentation == | == Documentation == |
Latest revision as of 13:16, 19 July 2024
Confidential Virtualization Host with AMD SEV-SNP
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-07-19
- Announced
- Discussion thread
- FESCo issue: #3236
- Tracker bug: #2298853
- 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