F41 Change Proposal: Confidential Virtualization Host with AMD SEV-SNP (self-contained)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Wiki - https://fedoraproject.org/wiki/Changes/ConfidentialVirtHostAMDSEVSNP
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-confidential-virtualization-host-with-amd-sev-snp-self-contained/120326

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: [[User:berrange| Daniel P. Berrangé]]
* Email: berrange@xxxxxxxxxx



== 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 [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 ==

* 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
[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

=== 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
[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 ==

* 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 [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 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

== Release Notes ==



-- 
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney
--
_______________________________________________
devel-announce mailing list -- devel-announce@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-announce-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux