Wiki - https://fedoraproject.org/wiki/Changes/ConfidentialVirtHostIntelTDX Discussion thread - https://discussion.fedoraproject.org/t/f43-change-proposal-confidential-virtualization-host-for-intel-tdx-self-contained/148877
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 change will introduce support for Fedora virtualization hosts to run confidential guests on suitable Intel TDX hardware. == Owner == * Name: [[User:berrange| Daniel Berrange]] * Email: berra...@redhat.com == 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, and since Fedora 41, using the SEV-SNP technology. In the Fedora 42 release, support for the Intel SGX platform was introduced, and this change builds on that work to allow creation of Intel TDX guests on Fedora hosts. Intel TDX provides confidential virtualization functionality that is on a par with the recent AMD SEV-SNP support. == Feedback == TBD == Benefit to Fedora == * This change allows creation of Intel TDX guests on Fedora virtualization hosts when suitable Intel TDX hardware (EmeraldRapids or newer Xeon CPUs) is available == Scope == The vast majority of work will arrive in Fedora automatically via regularly performed rebases to new upstream releases. * Proposal owners: ** Rebase QEMU to 10.1.0 release (GA ~ Sept 1st, release candidates available before Fedora freeze) ** Rebase libvirt to 11.8.0 release (GA ~ Sept 1st, release candidates, or patch backports, available before Fedora freeze) ** Write SELinux policy for 'qgs' daemon (qgs_t) to allow QEMU (svirt_t) to talk to it for attestation. ** Enhance virt-install to allow creation of TDX guests and arrange for new release & rebase, or patch backport * Other developers: ** Rebase kernel to >= 6.16 (TDX host patches targetted for 6.16 merge window in 1st week of April) ** Merge new SELinux policy rules for 'qgs' daemon and QEMU * Release engineering: N/A (not needed for this Change) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) ==Alignment with the Fedora Strategy == * Fedora will be demonstrating leading / state of the art integration of Intel TDX 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 Intel x86_64 Xeon hardware. == Upgrade/compatibility impact == None expected, the new functionality doesn't impact on existing functionality in Fedora == Early Testing (Optional) == N/A == How To Test == Full details TBD - high level intent is: * Check whether the host hardware configuration is capable of supporting TDX (very strict DIMM population requirements, along with EmeraldRapids or newer Xeon class CPUs) * Configure EFI firmware to enable use of SGX and TDX * Disable hibernation support in host kernel via adding 'nohibernate' to /etc/default/grub and re-creating grub.cfg * Use 'virt-install' to provision an confidential VM * Request an attestation report from the guest using sysfs * Validate the attestation report on a trusted machine using <some tool> == User Experience == * Virtualization host owners will be able to launch confidential virtual machines using Intel TDX technology * Guest owners will be able to prove that their OS is running in a Fedora host confidential virtual machine protected by Intel TDX, by performing a guest attestation == Dependencies == * Fedora SELinux maintainers need to review & merge new policy to be submitted by proposal owners for the 'qgs' daemon * Fedora kernel maintainers need to rebase to >= 6.16 (should be happening regardless, as normal kernel maint work) * virt-install owner to do rebase or accept MR to backport TDX support patches == Contingency Plan == * Contingency mechanism: Ship whatever was ready in time, and leave rest until Fedora 44 * Contingency deadline: Change completion deadline * Blocks release? No == Documentation == * NBD: document hot to validate hardware pre-requisites * [https://fedoraproject.org/wiki/Virt/SGX#Firmware_configuration Configure the Firmware to enable SGX] * TBD: document general host kernel/OS setup tasks (prior art https://sig.centos.org/virt/tdx/host/#verification/) * TBD: document one-time setup tasks for attestation on multi-socket machines * TBD: document how to use 'virt-install' to provision a guest * TBD: document how to query the attestation report in the guest == Release Notes == Fedora virtualization hosts running on suitably configured Intel Xeon hardware, have the ability to launch confidential virtual machines using the Intel TDX feature. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org 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-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
