From Fedora Project Wiki
(submitting change to fesco)
 
(90 intermediate revisions by 2 users not shown)
Line 4: Line 4:


== Summary ==
== Summary ==
The Intel SGX technology enables creation of execution enclaves, whose memory is encrypted and thus protected from all other code running on the machine, including SMM, firmware, kernel and userspace. This proposal is to introduce the SGX host software stack to Fedora, to enable applications and features which have a dependency on SGX technology.
The Intel SGX technology enables creation of execution enclaves, whose memory is encrypted and thus protected from all other code running on the CPU, including SMM, firmware, kernel and userspace. This proposal is to introduce the SGX host software stack, architectural enclaves and development packages to Fedora, to enable future introduction applications and features which have a dependency on SGX technology.
 
The primary feature that will leverage SGX in a subsequent Fedora release is expected to be Intel TDX, which provides confidential virtual machines, and is in the process of being integrated with QEMU and Linux/KVM.


== Owner ==
== Owner ==
Line 11: Line 13:


== Current status ==
== Current status ==
[[Category:ChangePageIncomplete]]
[[Category:ChangeReadyForFesco]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
Line 23: Line 25:
* Targeted release: [https://docs.fedoraproject.org/en-US/releases/f42/ Fedora Linux 42]
* Targeted release: [https://docs.fedoraproject.org/en-US/releases/f42/ Fedora Linux 42]
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* [Announced]
* [https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/thread/UZVOEFCPR2BORGKL26FUELR3423U747M/ Announced]
* [<will be assigned by the Wrangler> Discussion thread]
* [https://discussion.fedoraproject.org/t/f42-change-proposal-intel-sgx-software-stack-self-contained/138981 Discussion thread]
* FESCo issue: <will be assigned by the Wrangler>
* FESCo issue: [https://pagure.io/fesco/issue/3304 #3304]
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: <will be assigned by the Wrangler>
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: <will be assigned by the Wrangler>
Line 33: Line 35:
The Intel SGX technology enables creation of execution enclaves, whose memory is encrypted and thus protected from all other code running on the machine, including SMM, firmware, kernel and userspace. While it has many potential use cases, this proposal is focused around the infrastructure needed to enable support for attestation of TDX confidential virtual machines.
The Intel SGX technology enables creation of execution enclaves, whose memory is encrypted and thus protected from all other code running on the machine, including SMM, firmware, kernel and userspace. While it has many potential use cases, this proposal is focused around the infrastructure needed to enable support for attestation of TDX confidential virtual machines.


The SGX software stack compromises a number of components
The SGX software stack that is to be introduced can be categorized into a number of distinct areas:


* Support for developing new enclaves
* Support for developing new enclaves
** Header files for the enclave code (a minimalist C library, C++ library, crypto and some other misc libraries)
** Header files for the enclave code (a minimalist C library, C++ library, crypto and some other misc libraries)
** Static library archives for the enclave code.  
** Static library archives for linking into the enclave binaries.  
** Build helper tools (for signing enclaves, generating code enclave API entrypoints)
** Build helper tools (for signing enclaves, generating code enclave API entrypoints)
* Support for developing applications that use enclaves
* Support for developing applications that use enclaves, eg to be able to load and communicate with enclaves.
** Header files for platform code
** Header files for platform code
** Dynamic libraries for platform code
** Dynamic libraries for platform code
* Support for deploying applications that use enclaves
* Support for deploying applications that use enclaves
** Enclave service daemon - assists unprivileged applications in loading enclaves
** Enclave service daemon - assists unprivileged applications in loading enclaves
** Registration tools - assists platform administrator in acquiring certificates to identity the platform
** Registration tools - assists platform administrator in acquiring certificates from Intel servers to identity the platform
** Quote generation daemon - assists QEMU in acquiring signed attestation reports for TDX VMs.
** Quote generation daemon - assists QEMU in acquiring signed attestation reports for TDX VMs.


=== Enclave use cases ===
The code and binaries related to the host OS platform components will be installed in the normal filesystem locations common to all Fedora packages. e.g. libraries in '''/usr/lib64''', headers in '''/usr/include''' and binaries in '''/usr/bin'''.


At a high level, SGX enclaves provide a way to run code in a secure, encrypted & isolated execution context, free from manipulation by any other software component on the machine, aside from DoS attacks.
For the purposes of packaging, the enclaves will be [https://fedoraproject.org/wiki/Virt/SGXEnclaves#Enclaves_as_a_platform_build_target treated as cross-compilation target]. While the compiler build architecture target is '''x86_64''', the runtime has custom C / C++ libraries that must be used, and requires a separate code loader, all completely separate from any existing Fedora libraries. Enclaves cannot be directly linked to applications, they are strictly independent & self-contained ELF binaries.


There are manways
With this in mind, following the example of MinGW64 packages living under '''/usr/x86_64-w64-mingw''', all enclave related headers and libraries are proposed to be placed under '''/usr/x86_64-intel-sgx''', specifically the '''lib64''' and '''include''' sub-directories. There is no concept of executable binaries for enclaves, only libraries, nor ancillary data files. Thus no '''bin''' or '''share''' directories are required under this location. The installation tree locations will be defined in RPM macros provided by the '''sgx-srpm-macros''' package


==== Compatibility with Fedora mission for software & content freedom ====
The generated binary packages will generally all have an ''sgx-'' prefix to their name, with those containing exclusively enclave related content having the more specialized ''sgx-enclave-'' name prefix.


When dealing with cryptographically attested software, it is important to consider '''whom is benefitting''' from verifying the execution context. There are generally three parties involved in such software
For reasons of brevity, this change proposal does not go far into all technical details of SGX. For a deeper understanding of SGX enclaves beyond this proposal, [https://fedoraproject.org/wiki/Virt/SGXEnclaves consult this companion document].


* '''Providing party''' - the organization or individual that is signing the software being used. This could be the original software author/vendor, or an intermediary such as a Linux distributor.
== Feedback ==
* '''Deploying party''' - the organization or individual that is running the software in question. This could be a so called 'end user', or it could be a service provider running something on their behalf.
* '''Verifying party''' - the organization or individual that is relying on verification of the executed software. This could be the so called 'end user', but it could be a 3rd party attempting to place constraints on usage (e.g. DRM)


The Fedora missions states 
* '''Feedback:''' ''The SGX technology can be used as a way to implement DRM. Notable example has been BluRay playback.''. '''Answer:''' As with many technologies, it is possible to use SGX in ways that are both positive and negative, wrt the owner / users of a machine. Use of SGX for DRM in BluRay playback is hostile to the owner/user of a machine. This change is '''NOT''' proposing to introduce / support any such usage/applications in Fedora. The fact that bad uses of SGX may exist outside of Fedora, is no justification for rejecting the use of SGX in Fedora when applied to scenarios that can offer features directly benefiting Fedora's users.


  We are dedicated to free software and content.  
* '''Feedback:''' ''The SGX enclave code is not open source, because it requires a vendor signature on output binaries''. '''Answer:''' All of the SGX code is made available under a variety open source licenses (Apache, BSD, MIT, GPL & more), which are fully approved by Fedora. One of the architectural enclaves, '''pce''', requires an Intel signature because it is used to establish the root of trust with the hardware. In their role of bootstrapping use of SGX hardware, the architectural enclaves are a type of firmware, and it is normal for firmware to have a vendor signature. In contrast to almost all firmware which is proprietary, the architectural enclave code is all under Fedora approved OSS licenses. All of the architectural enclaves, can be rebuilt from source by a user, with customizations, signed with a user specified key and then loaded if desired. There are some subtle limitations if attempting this, documented in [[Virt/SGXEnclaves#Rebuilding_&_self-signing_architectural_enclaves | the companion document]], but the code is none the less all OSS.
  Advancing software and content freedom is a  
  central community goal, which we accomplish
  through the software and content we promote.


In all cases, Intel acts as a "verifying party" when a platform is deployed or provisioned, when the platform owner requests a certificate to prove their hardware is authentic. This is a low level a bootstrapping task, to enable higher level use of SGX. Thus while Intel is the verifying party at a low level, the ultimate beneficiary is determined by the higher level usage of SGX who is also a verifying party.  
== Benefit to Fedora ==
As a general purpose infrastructure technology, SGX can be applied to / used by a wide variety of scenarios / applications.


Thus, while this low level usage has some impact on software freedom, it is limited to the minimum required to bootstrap use of the SGX technology. This is on a par with how firmware, or CPU microcode, binaries must have valid signatures to bootstrap use of the platform
In the context of this change proposal, '''no application''' usage is intended to be introduced, the focus is around general software infrastructure enablement.


A followup change proposal (for a subsequent Fedora release) will be made to introduce Intel TDX confidential virtual machines, which is anticipated to be the first end user facing application of SGX technology. Attestation is the means by which a guest VM owner can prove that their VM machine is running in confidential mode on genuine Intel hardware, as opposed to in a faked "blue pill" environment. All currently shipping Intel CPUs which support TDX build attestation on top of SGX with OSS enclave code (the '''tdqe''' enclave), as opposed to embedding attestation in proprietary firmware which is the approach taken by other vendors for confidential computing. NB, the '''tdqe''' enclave and '''qgs''' daemon will be included in this proposal, but will remain unused until this followup TDX support is integrated with Fedora.


It is well known that SGX technology can be applied is to build DRM systems which allow 3rd party organizations to control what users do with their machines. This proposal '''MUST NOT''' be interpreted as endorsing such use cases. Such DRM systems would almost certainly rely on close source enclaves signed exclusively by a 3rd party org, and could not be considered hardware enablement firmware. As such they would not be eligible for inclusion in Fedora.


Use of SGX as a DRM mechanism in BluRay playback software is not benefit for the user of the player, as it constrains the scenarios in which they can consume the content. The beneficiary is a 3rd party organization seeking to control the end user. Such use of SGX enclaves which compromise either software or contet freedom should be considered incompatible with Fedora's mission for end user freedom and thus not permitted.
== Scope ==
=== Proposal owners===
 
The proposal owners will be introducing a number of new packages to Fedora. Initially, no existing packages are likely to gain dependencies on the new SGX packages. At a future date when TDX is integrated into Fedora, one or more of the libvirt/qemu sub-RPMs may gain a dependency on certain SGX packages needed to support TDX.
 
The important new packages will be


Use of SGX as a mechanism for proving the integrity of a virtual machine has multiple beneficiaries. The Fedora user who owns the hypervisor OS install benefits in being able to prove integrity of the service they provide. Where the virtual machine is running Fedora as its OS, the Fedora user of the VM further benefits in being able to prove integrity of their guest OS. Including enclaves needed to attest TDX is generally compatible with Fedora's mission. The owners of the host & guest OS, gets to decide the usage policy and thus are not constraining their own software and content freedom. This usage of SGX is compatible with Fedora's mission for end user freeom and thus should be permitted.
* '''sgx-srpm-macros''': this will produce a binary RPM of the same name, containing RPM macros that define the directory locations for SGX enclaves under '''/usr/x86_64-intel-sgx'''. These macros will be consumed by other RPMs that deal with enclave pacakging
* '''linux-sgx''': this provides the full SGX software stack, including the enclave development libraries and headers, host OS development libraries and headers, supporting host OS build tools, and various host OS runtime daemons/binaries. This package will include '''unsigned''' builds of the architectural enclaves built using the standard Fedora toolchain. Users could choose to sign these with their own keys and deploy them, with the caveat noted earlier wrt the '''pce''' enclave in particular. This package will result in creation of many binary sub-RPMs for distinct components.
* '''linux-sgx-enclaves-prebuilt''': this provides solely the pre-built, signed architectural enclaves. While they could be provided as part of the '''linux-sgx''' package, it is split off to make it simpler to update the architectural enclave independently of the main software stack. This ability will be important if needing to ship a new release of SGX enclaves for a security fix in stable Fedora branches, without being forced to introduce updates of the host OS software stack that may have inappropriate changes for pushing into an existing stable branch.


=== Comparison with other technology ===
==== Optional extra: reproducible builds ====


There is not a directly analogous technology for SGX enclaves on PC class hardware from other vendors, but we can compare how tasks using SGX would be accomplished elsewhere
The SGX pre-built, signed architectural enclaves are built from code entirely under Fedora approved OSS licenses and support a reproducible build process. The upstream implementation of this process involves an Ubuntu dockerfile that populates a NixOS build environment. With some skilled work, it is possible to replicate an equivalent build environment in the context of Fedora. It requires providing custom builds of GCC, binutils, nasm, glibc (headers only) and kernel (uapi headers only) at specific release versions, with specific build configuration options and certain patches. Given such packages in Fedora, it is then possible to perform a reproducible build that successfully validates as matching the code payload of the pre-built, signed architectural enclaves.


The Intel TDX technology for virtual machines relies on SGX to provide signing of attestation reports. The guest VM will talk to the SEAM module to obtain an attestation report, which is then passed to the QEMU in the host OS. QEMU will pass it on to the 'qgs' daemon and which will use SGX enclaves to validate the attestation report and then create a signed quote for it. The guest owner can validate this quote and the chain of trust for the certificate used to sign it, linking back to Intel as the original hardware vendor
Maintaining such a reproducible build process in Fedora would have a non-negligible maintenance overhead if done on an ongoing basis. Originally it was thought that a reproducible build could be performed in the same package that provides the pre-built enclave binaries, as a way to block shipping of the pre-built binaries, unless proved to match the source.


The AMD SEV SNP technology by comparison relies on a physically separate processor known as the PSP (Platform Secure Processor). The guest VM will talk tot he PSP to obtain a signed attestation report. The geust owner can immediately validate this report and the chain of trust for the certificate used to sign it, linking back to AMD as the original hardware vendor.
Given the requirements for specific toolchain versions, however, this would impose considerable delays when shipping CVE updates in stable Fedora branches. eg a newly issued pre-built enclave binary containing a CVE fix, may imply use of newer GCC, binutils, nasm versions than are currently available in the Fedora stable release. It is highly undesirable to go through the new package process to add new toolschain versions to stable Fedora, as a pre-requisite to ship CVE fixes in a stable branch, even if the new package process were expedited to avoid full re-review.  


In the SGX/TDX approach, the SGX architectural enclaves provided by Intel establish the root of trust for the processor, allowing derivation of a key for signing the attestation reports, that has an associated certificate provided by Intel.
If a reproducible build were to be mandated, it would involve the following additional packages in Fedora:


In the AMD SEV SNP approach, the PSP firmware is shipped with the platform and has the required signing keys are derived without needing any additional userspace software.
* '''sgx-compat-gccXXXX''' - one (or more) GCC builds at specified designated versions required by the reproducible build
* '''sgx-compat-binutilsXXXX''' - one (or more) binutils builds at specified designated versions required by the reproducible build
* '''sgx-compat-nasmXXXX''' - one NASM build at specified designated versions required by the reproducible build
* '''sgx-compat-glibc-headersXXXX''' - one glibc build at specified designated versions required by the reproducible build. Note only the header files are required, no library build.
* '''sgx-compat-kernel-headersXXXX''' - one kernel build at specified designated versions required by the reproducible build. Note only the uapi header files are required, no vmlinux build
* '''sgx-enclaves-reproducibleXXX''' - one (or more) reproducible builds of SGX architectural enclaves


The SEV-SNP is the more classical hardware vendor approach, where the low level pieces are entirely closed source in the system firmware. The SGX/TDX approach is unusual / surprising, with code published as fully open source software. In both cases, the low level code has to be signed by keys controlled by the hardware vendor to establish the root of trust for the system. Thus while the SGX/TDX code is fully open source, there is a constraint in usage of certain output binaries which require the vendor's signature and can't be replaced by a user signature.
Note, the need for multiple versions of GCC & binutils in the reproducible build is an [https://github.com/intel/linux-sgx/issues/1045 upstream build environment bug].


== Feedback ==
Note, the need for glibc & header headers is also a likely [https://github.com/intel/linux-sgx/pull/1062 upstream build environment bug].
 
Note, the need for multiple '''sgx-enclaves-reproducibleXXX''' versions in parallel is because not all enclaves re-issued on each release. Only enclaves which have CVE fixes or functional changes get re-issued as new pre-built, signed binaries. IOW to validate all binary enclaves potentially requires doing reproducible builds of multiple SGX releases.
 
=== Other developers===
 
Maintainers of the '''fedora-release''' package will need to review a merge request that proposes new systemd unit file presets. See later in this document for the details of units.
 
===Release engineering===


N/A - does not impact deliverables for releng


== Benefit to Fedora ==
===Policies and guidelines===
As a general purpose infrastructure technology, SGX can be applied to / used by a wide variety of scenarios / applications.
 
Agreement is needed around the designation of the pre-built, signed SGX architectural enclaves as firmware. Note, "'''architectural enclaves'''" are being considered distinct from "'''application enclaves'''" - the latter should be expected to build from source in the normal manner & be signed by Fedora, if any such enclaves are ever added to Fedora.


The primary goal in introducing SGX into Fedora, however, is to support the Fedora KVM virtualization stack when it introduces confidential virtual machines running with Intel TDX. The TDX attestation implementation in currently integrated with Intel CPUs is built on the SGX technology. Attestation is the means by which a guest VM owner, can prove that their VM machine is running in confidential mode on genuine Intel hardware, as opposed to being in "blue pill" environment.
==== Architectural enclaves as firmware ====


== Scope ==
Normal Fedora practice requires building everything from source. There is a general exception to this for firmware blobs, which don't need to be built from source and don't need to be under an OSS compliant license as long as the binaries can be freely distributed. Hardware firmware binaries almost always include a digital signature from the vendor, to ensure that only trusted firmware is loaded onto the device. Thus even if source code is available for a given firmware binary, Fedora would still need to be shipping it as a pre-built vendor supplied signed binary, in order to pass the cryptographic verification checks typically performed by hardware when loading firmware.
=== Proposal owners===


Add the following packages to Fedora
Another example of shipping pre-built vendor binaries would be CPU microcode. This could be considered firmware for the core CPU, and again are vendor supplied, signed binaries, with no source code available.


* '''CppMicroServices''' - a C++ runtime library for building microservices daemons
The architectural enclaves satisfy the classical role of firmware, in the context of the SGX technology, providing enablement for application usage. Unusually for firmware they are made available with 100% of their code under Fedora approved OSS licenses. The architectural enclaves, however, are still consumed as pre-built signed binaries due to the need to establish a chain of trust rooted back to Intel as the CPU hardware vendor.
* '''sgx-srpm-macros''' - define some common macros for where SGX content will live in the filesystem tree
* '''sgx-compat-gccXXX''' - one (or more) '''specific''' GCC versions, built with ''targetted configure arguments'', to match the GCC configuration required for enclave reproducible build.
* '''sgx-compat-binutilsXXX''' - one (or more) '''specific''' binutils versions, built with ''targetted configure arguments'', to match the GCC configuration required for enclave reproducible build.
* '''sgx-compat-nasmXXX''' - one (or more) '''specific''' NASM versions, built with ''targetted configure arguments'', to match the GCC configuration required for enclave reproducible build.
* '''sgx-compat-glibc-headersXXX''' - one (or more) '''specific''' GCC versions, built with ''targetted configure arguments'', to match the GCC configuration required for enclave reproducible build.
* '''sgx-compat-kernel-headersXXX''' - one (or more) '''specific''' GCC versions, built with ''targetted configure arguments'', to match the GCC configuration required for enclave reproducible build.
* '''linux-sgx-enclavesXXX''' - one (or more) packages for performing a reproducible build of architectural enclaves
* '''linux-sgx''' - provide the SGX platform development headers & libraries, runtime libraries, and supporting daemons


The pre-built, signed architectural enclaves are not always re-created on each SGX release. New binaries are only issued if there was a required feature change, or a security fix required. Thus the package for the reproducible enclave builds is separated out from the general SGX package. Furthermore, to perform a reproducible build of the full set of enclaves, requires potentially more than one '''linux-sgx-enclavesXXX''' package. For example SGX 2.23 and 2.24 releases only updated the ''''qve'''' enclave, all other enclaves remained on version 2.22. This in turn creates the requirement for multiple '''GCC'''/'''binutils'''/'''nasm''' versions, at some points. The current newest 2.25 release has updated all enclaves, so initially only a single ''''linux-sgx-enclaves-2_25'''' is expected to be required.
'''Overall''', the architectural enclaves meet the definition of firmware documented in the [https://docs.fedoraproject.org/en-US/legal/license-approval/#_technical_firmware_requirements Fedora licensing guidelines]:


NB, [https://github.com/intel/linux-sgx/issues/1045 an upstream bug] has resulted in different parts of the enclave code being built with different GCC/binutils versions. This should be resolved in future releases:
# ''The files must be non-executable within the Fedora Linux context (note: this means that the files cannot run on their own, not that they are just chmod -x).'' ✅ enclave ELF binarjies must be loaded into memory using the specialized SGX loader.
# ''The files must not be libraries, within the Fedora Linux context.'' ✅ enclave ELF binaries must be loaded into memory using as specialized SGX loader, the glibc ELF loader can not be used for this.
# ''The files must be standalone, not embedded in executable or library code (within the Fedora Linux context).'' ✅ enclave binaries are always standalone, self-contained files. They are consumed by regular host software, but cannot be linked to Fedora platform binaries/libraries.
# ''The files must be necessary for the functionality of open source code being included in Fedora Linux or to enable Fedora Linux to boot on a specific device, where no other reliable and supported mechanisms exist.'' ✅ the pre-built, signed '''architectural enclaves''' shipped by Intel, serve to bootstrap the use of SGX technology by applications. ❌  as higher level software services, other '''application enclaves''' would not qualify.


NB, The requirement for glibc and kernel header packages is [https://github.com/intel/linux-sgx/pull/1062 likely another upstream bug]. The enclave code should be build exclusively against the SGX runtime, which is a completely custom C library. This is being investigated upstream.
Thus it should be permissible to ship the pre-built, signed '''architectural enclaves''' binaries with no policy changes.


=== Other developers===
Conversely '''application enclaves''' should NOT be considered firmware, and thus be required to follow the full Fedora packaging guidelines. No '''application enclaves''' are anticipated for inclusion in Fedora with this change proposal.


The kernel functionality required for SGX is already present in Fedora kernel packages, so no work by other maintainers is anticipated.
==== Reproducible build validation policy ====


===Release engineering===
Even if the view of '''architectural enclaves''' as firmware were to be rejected, there is an alternative precedent that can justify inclusion of the pre-built signed enclaves in Fedora.
In this case we consider the '''shim''' package, where Fedora builds a binary from known good source, possibly with local patches, and sends it off for signing by Microsoft, packaging the binary that is sent back into an RPM. Microsoft has various requirements before it will permit signing a vendor's shim.


N/A - does not impact deliverables for releng
Consider if the requirements on shim signing were tightened a little more to require a designated toolchain version, such that all shim builds became 100% reproducible on any platform. There would be no need to send the binary to Microsoft for signing, as any binary built in Fedora would inherently match a standard pre-published signed binary from that shim release + toolchain. It would be impossible to distinguish Microsoft signing & returning Fedora's reproducible build, from Microsoft sending back their original pre-signed build.


===Policies and guidelines===
This is effectively the situation SGX architectural enclaves are in.


* '''Architectural enclaves'''.
None the less, there are some differences between the shim & SGX scenarios.  
** Prebuilt binaries signed by Intel to be permitted under the existing firmware exception
** Given the availability of complete corresponding source code & a supported reproducible build process, all pre-built binaries MUST be verified through a reproducible build performed in Fedora, using a fully open source toolchain.


* '''Application enclaves'''
The first is that today Fedora has the ability to add arbitrary local patches to shim & build with arbitrary toolchain versions, which would be in conflict with a hypothetical requirement for reproducible builds & fixed toolchain.  
** No shipping of pre-built binaries permitted. Everything must follow normal Fedora policies requiring build from source. Any signature must use Fedora controlled persistent keys, or single use keys.


The distinction between architectural enclaves (signed by Intel to bootstrap trust) and application enclaves (signed by Fedora, with trust chained from the AEs), is considered conceptually similar to the distinction between shim (signed by Microsoft to bootstrap trust), vs kernel (signed by Fedora, with trust chained from shim).
The second is that on most (but not all) hardware, users can enroll personal certificates in the firmware to allow it to trust a shim binary signed by the user, rather than Microsoft. In the case of SGX enclaves, it is strictly possible from a technical POV for a user to build & load & run their own self-signed SGX architectural enclaves. From a practical POV, however, it is inescapable for the '''pce''' enclave to have an Intel signature. Without that signature, no certificate proving authenticity of the hardware can be obtained from Intel, which would thus undermine the goal of SGX technology. The certificate is the mechanism for the Fedora user to prove to themselves that their platform contains genuine Intel CPUs. The other enclaves do have ways to be used with user supplied signatures, provided the consuming applications allow sufficient flexibility in their verification mechanisms. From a practical POV, all usage will be expecting Intel signatures again because these signatures are a means for users to establish trust in their hardware platform, but users do have the freedom to diverge if needed.


===Trademark approval===
===Trademark approval===
Line 149: Line 164:


* '''"Reaching the world"'''. Including SGX will make the Fedora support for hosting Intel TDX confidential virtual machines feature complete, by enabling attestation by the guest owner
* '''"Reaching the world"'''. Including SGX will make the Fedora support for hosting Intel TDX confidential virtual machines feature complete, by enabling attestation by the guest owner
* '''"Innovation & leadership in technology"'''. SGX is a general purpose infrastructure technology which enables application developers to build systems to securely run sensitive workloads.
* '''"Innovation & leadership in technology"'''. SGX is a general purpose infrastructure technology which enables application developers to build systems to securely run sensitive workloads. Confidential virtual machines are expected to become a standard part of the public cloud in the coming years, as well as make inroads into private clouds in large organizations. As noted earlier, SGX unlocks the ability to ship TDX confidential VM technology in future Fedora.


== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==
Line 159: Line 174:
Do you require 'QA Blueprint' support? N
Do you require 'QA Blueprint' support? N


The proposed new packages are available for testing via Copr:
The proposed new packages are available for testing via Copr, until such time as they are reviewed & built in Fedora koji:
 
* https://copr.fedorainfracloud.org/coprs/berrange/sgx-ng/


  https://copr.fedorainfracloud.org/coprs/berrange/sgx-ng/
These should work on any Intel Xeon class platform which has a suitable HW configuration. NB there may be specific DIMM population requirements.


== How To Test ==
== How To Test ==


* Document how to validate a single-socket system by obtaining PCK certificates automatically
* [https://fedoraproject.org/wiki/Virt/SGX Documentation on host setup] is available but that's a fairly minimalist test. It does not do much that's interesting to an end user, but is at least proving that the '''pce''' and '''ide''' enclaves are usable. This is the limit of the anticipated testing of SGX in Fedora. More extensive testing will be performed when TDX is integrated at a later date, though some of this may be performed early on an adhoc basis using development snapshots of TDX.
* Document how to configure a multi-socket system to enable its registration with Intel services, and request a PCK certificate


== User Experience ==
== User Experience ==


Initially minimal user experience impact, since on its own it doesn't deliver noticeable end user features, as it is not believed that any existing applications in Fedora are able to leverage SGX.
Initially the will be minimal real world user experience impact, since on its own this proposal doesn't deliver noticeable end user features. No existing applications in Fedora are known to have support for SGX and none are being proposed yet.
 
The initial user benefit will be that users can bootstrap trust in SGX on their Fedora host. This will facilitate users in deploying 3rd party applications of their choosing that utilize SGX.
 
At a later time, when support for Intel TDX is integrated into KVM and QEMU, the immediate Fedora user benefit will significantly expand.
 
=== Limitations ===
 
As noted earlier, due to the need for Intel signatures on 4 pre-built architectural enclaves there is a small constraint on user software freedom, if they choose to make use of SGX technology.
 
For the '''ide''', '''qe3''' and '''tdqe''' architectural enclaves, it is possible for users to rebuild the source with arbitrary local modifications, and sign the result with their own local key. The resulting enclaves can be deployed and used at runtime, however, it is not guaranteed that applications will be able to successfully verify quotes produced by such enclaves. It depends on whether applications have been written to expect non-Intel signatures.


For the '''pce'' architectural enclaves, it is possible for users to rebuild the source with arbitrary local modifications, and sign the result with their key. The resulting enclave can be deployed and used at runtime, however, it will not be possible to obtain a certificate from Intel proving authenticity of the hardware. Thus when verifying quotes, it will not be able to successfully verify the complete chain of trust.
The conceptual user benefit will be that users can bootstrap trust in SGX on their Fedora host. This will facilitate users in deploying 3rd party applications of their choosing that utilize SGX. It will facilitate testing by engineers working on TDX support and its integration into Fedora.


There are no limitations on customization, rebuilds & re-signing of permitted application enclaves, as any usage with signing constraints is proposed to make such enclaves ineligible for inclusion in Fedora.
At a later time, when support for Intel TDX is integrated into KVM and QEMU, the real world Fedora user benefit will significantly expand.


== Dependencies ==
== Dependencies ==


No existing packages will have a dependency on this change initially. In future, some deployments of QEMU may change to pull in certain SGX packages, to support Intel TDX.
The primary functional dependency for use of SGX is kernel support, which has been enabled in Fedora for some time. See "'''CONFIG_X86_SGX=y'''" in the kconfig files.


Kernel support for SGX already exists in Fedora:
The packages include some new systemd unit files, two of which should be configured to be started by default. This will require changes to the systemd presets in the 'fedora-release' package.


  $ git grep CONFIG_X86_SGX=y
* '''mpa_registration.service''' - this is conditionalized on SGX being enabled, as witnessed by existence of '''/dev/sgx_eclave.''' Thus enabling it by default will be a no-op on any existing machines which have not had SGX turned on in the firmware. It is expected to be installed on all SGX installations
  kernel-x86_64-debug-fedora.config:CONFIG_X86_SGX=y
* '''qgs.socket''' (as a trigger for '''qgs.service''') - this is likewise conditionalized on SGX being enabled. This will may be pulled in as a dependency of either libvirt or QEMU RPMs, TBD in the future TDX change proposal.
  kernel-x86_64-debug-rhel.config:CONFIG_X86_SGX=y
  kernel-x86_64-fedora.config:CONFIG_X86_SGX=y
  kernel-x86_64-rhel.config:CONFIG_X86_SGX=y
  kernel-x86_64-rt-debug-rhel.config:CONFIG_X86_SGX=y
  kernel-x86_64-rt-rhel.config:CONFIG_X86_SGX=y


== Contingency Plan ==
== Contingency Plan ==


<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->


* Contingency mechanism: The new packages have no ill effects on existing Fedora usage. Any outstanding work can be postponed to a later release if required.
* Contingency deadline: Beta freeze
* Blocks release? No


== Documentation ==
== Documentation ==
<!-- Is there upstream documentation on this change, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
[https://fedoraproject.org/wiki/Virt/SGX Documentation on host setup] is available which is pretty much all that this change is expected to enable.
N/A (not a System Wide Change)
 
A change proposal in future Fedora will cover usage of SGX with TDX confidential virtual machines, which is more interesting to end users.


== Release Notes ==
== Release Notes ==

Latest revision as of 20:58, 16 December 2024

Intel SGX Software Stack

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

The Intel SGX technology enables creation of execution enclaves, whose memory is encrypted and thus protected from all other code running on the CPU, including SMM, firmware, kernel and userspace. This proposal is to introduce the SGX host software stack, architectural enclaves and development packages to Fedora, to enable future introduction applications and features which have a dependency on SGX technology.

The primary feature that will leverage SGX in a subsequent Fedora release is expected to be Intel TDX, which provides confidential virtual machines, and is in the process of being integrated with QEMU and Linux/KVM.

Owner

Current status

Detailed Description

The Intel SGX technology enables creation of execution enclaves, whose memory is encrypted and thus protected from all other code running on the machine, including SMM, firmware, kernel and userspace. While it has many potential use cases, this proposal is focused around the infrastructure needed to enable support for attestation of TDX confidential virtual machines.

The SGX software stack that is to be introduced can be categorized into a number of distinct areas:

  • Support for developing new enclaves
    • Header files for the enclave code (a minimalist C library, C++ library, crypto and some other misc libraries)
    • Static library archives for linking into the enclave binaries.
    • Build helper tools (for signing enclaves, generating code enclave API entrypoints)
  • Support for developing applications that use enclaves, eg to be able to load and communicate with enclaves.
    • Header files for platform code
    • Dynamic libraries for platform code
  • Support for deploying applications that use enclaves
    • Enclave service daemon - assists unprivileged applications in loading enclaves
    • Registration tools - assists platform administrator in acquiring certificates from Intel servers to identity the platform
    • Quote generation daemon - assists QEMU in acquiring signed attestation reports for TDX VMs.

The code and binaries related to the host OS platform components will be installed in the normal filesystem locations common to all Fedora packages. e.g. libraries in /usr/lib64, headers in /usr/include and binaries in /usr/bin.

For the purposes of packaging, the enclaves will be treated as cross-compilation target. While the compiler build architecture target is x86_64, the runtime has custom C / C++ libraries that must be used, and requires a separate code loader, all completely separate from any existing Fedora libraries. Enclaves cannot be directly linked to applications, they are strictly independent & self-contained ELF binaries.

With this in mind, following the example of MinGW64 packages living under /usr/x86_64-w64-mingw, all enclave related headers and libraries are proposed to be placed under /usr/x86_64-intel-sgx, specifically the lib64 and include sub-directories. There is no concept of executable binaries for enclaves, only libraries, nor ancillary data files. Thus no bin or share directories are required under this location. The installation tree locations will be defined in RPM macros provided by the sgx-srpm-macros package

The generated binary packages will generally all have an sgx- prefix to their name, with those containing exclusively enclave related content having the more specialized sgx-enclave- name prefix.

For reasons of brevity, this change proposal does not go far into all technical details of SGX. For a deeper understanding of SGX enclaves beyond this proposal, consult this companion document.

Feedback

  • Feedback: The SGX technology can be used as a way to implement DRM. Notable example has been BluRay playback.. Answer: As with many technologies, it is possible to use SGX in ways that are both positive and negative, wrt the owner / users of a machine. Use of SGX for DRM in BluRay playback is hostile to the owner/user of a machine. This change is NOT proposing to introduce / support any such usage/applications in Fedora. The fact that bad uses of SGX may exist outside of Fedora, is no justification for rejecting the use of SGX in Fedora when applied to scenarios that can offer features directly benefiting Fedora's users.
  • Feedback: The SGX enclave code is not open source, because it requires a vendor signature on output binaries. Answer: All of the SGX code is made available under a variety open source licenses (Apache, BSD, MIT, GPL & more), which are fully approved by Fedora. One of the architectural enclaves, pce, requires an Intel signature because it is used to establish the root of trust with the hardware. In their role of bootstrapping use of SGX hardware, the architectural enclaves are a type of firmware, and it is normal for firmware to have a vendor signature. In contrast to almost all firmware which is proprietary, the architectural enclave code is all under Fedora approved OSS licenses. All of the architectural enclaves, can be rebuilt from source by a user, with customizations, signed with a user specified key and then loaded if desired. There are some subtle limitations if attempting this, documented in the companion document, but the code is none the less all OSS.

Benefit to Fedora

As a general purpose infrastructure technology, SGX can be applied to / used by a wide variety of scenarios / applications.

In the context of this change proposal, no application usage is intended to be introduced, the focus is around general software infrastructure enablement.

A followup change proposal (for a subsequent Fedora release) will be made to introduce Intel TDX confidential virtual machines, which is anticipated to be the first end user facing application of SGX technology. Attestation is the means by which a guest VM owner can prove that their VM machine is running in confidential mode on genuine Intel hardware, as opposed to in a faked "blue pill" environment. All currently shipping Intel CPUs which support TDX build attestation on top of SGX with OSS enclave code (the tdqe enclave), as opposed to embedding attestation in proprietary firmware which is the approach taken by other vendors for confidential computing. NB, the tdqe enclave and qgs daemon will be included in this proposal, but will remain unused until this followup TDX support is integrated with Fedora.

It is well known that SGX technology can be applied is to build DRM systems which allow 3rd party organizations to control what users do with their machines. This proposal MUST NOT be interpreted as endorsing such use cases. Such DRM systems would almost certainly rely on close source enclaves signed exclusively by a 3rd party org, and could not be considered hardware enablement firmware. As such they would not be eligible for inclusion in Fedora.

Scope

Proposal owners

The proposal owners will be introducing a number of new packages to Fedora. Initially, no existing packages are likely to gain dependencies on the new SGX packages. At a future date when TDX is integrated into Fedora, one or more of the libvirt/qemu sub-RPMs may gain a dependency on certain SGX packages needed to support TDX.

The important new packages will be

  • sgx-srpm-macros: this will produce a binary RPM of the same name, containing RPM macros that define the directory locations for SGX enclaves under /usr/x86_64-intel-sgx. These macros will be consumed by other RPMs that deal with enclave pacakging
  • linux-sgx: this provides the full SGX software stack, including the enclave development libraries and headers, host OS development libraries and headers, supporting host OS build tools, and various host OS runtime daemons/binaries. This package will include unsigned builds of the architectural enclaves built using the standard Fedora toolchain. Users could choose to sign these with their own keys and deploy them, with the caveat noted earlier wrt the pce enclave in particular. This package will result in creation of many binary sub-RPMs for distinct components.
  • linux-sgx-enclaves-prebuilt: this provides solely the pre-built, signed architectural enclaves. While they could be provided as part of the linux-sgx package, it is split off to make it simpler to update the architectural enclave independently of the main software stack. This ability will be important if needing to ship a new release of SGX enclaves for a security fix in stable Fedora branches, without being forced to introduce updates of the host OS software stack that may have inappropriate changes for pushing into an existing stable branch.

Optional extra: reproducible builds

The SGX pre-built, signed architectural enclaves are built from code entirely under Fedora approved OSS licenses and support a reproducible build process. The upstream implementation of this process involves an Ubuntu dockerfile that populates a NixOS build environment. With some skilled work, it is possible to replicate an equivalent build environment in the context of Fedora. It requires providing custom builds of GCC, binutils, nasm, glibc (headers only) and kernel (uapi headers only) at specific release versions, with specific build configuration options and certain patches. Given such packages in Fedora, it is then possible to perform a reproducible build that successfully validates as matching the code payload of the pre-built, signed architectural enclaves.

Maintaining such a reproducible build process in Fedora would have a non-negligible maintenance overhead if done on an ongoing basis. Originally it was thought that a reproducible build could be performed in the same package that provides the pre-built enclave binaries, as a way to block shipping of the pre-built binaries, unless proved to match the source.

Given the requirements for specific toolchain versions, however, this would impose considerable delays when shipping CVE updates in stable Fedora branches. eg a newly issued pre-built enclave binary containing a CVE fix, may imply use of newer GCC, binutils, nasm versions than are currently available in the Fedora stable release. It is highly undesirable to go through the new package process to add new toolschain versions to stable Fedora, as a pre-requisite to ship CVE fixes in a stable branch, even if the new package process were expedited to avoid full re-review.

If a reproducible build were to be mandated, it would involve the following additional packages in Fedora:

  • sgx-compat-gccXXXX - one (or more) GCC builds at specified designated versions required by the reproducible build
  • sgx-compat-binutilsXXXX - one (or more) binutils builds at specified designated versions required by the reproducible build
  • sgx-compat-nasmXXXX - one NASM build at specified designated versions required by the reproducible build
  • sgx-compat-glibc-headersXXXX - one glibc build at specified designated versions required by the reproducible build. Note only the header files are required, no library build.
  • sgx-compat-kernel-headersXXXX - one kernel build at specified designated versions required by the reproducible build. Note only the uapi header files are required, no vmlinux build
  • sgx-enclaves-reproducibleXXX - one (or more) reproducible builds of SGX architectural enclaves

Note, the need for multiple versions of GCC & binutils in the reproducible build is an upstream build environment bug.

Note, the need for glibc & header headers is also a likely upstream build environment bug.

Note, the need for multiple sgx-enclaves-reproducibleXXX versions in parallel is because not all enclaves re-issued on each release. Only enclaves which have CVE fixes or functional changes get re-issued as new pre-built, signed binaries. IOW to validate all binary enclaves potentially requires doing reproducible builds of multiple SGX releases.

Other developers

Maintainers of the fedora-release package will need to review a merge request that proposes new systemd unit file presets. See later in this document for the details of units.

Release engineering

N/A - does not impact deliverables for releng

Policies and guidelines

Agreement is needed around the designation of the pre-built, signed SGX architectural enclaves as firmware. Note, "architectural enclaves" are being considered distinct from "application enclaves" - the latter should be expected to build from source in the normal manner & be signed by Fedora, if any such enclaves are ever added to Fedora.

Architectural enclaves as firmware

Normal Fedora practice requires building everything from source. There is a general exception to this for firmware blobs, which don't need to be built from source and don't need to be under an OSS compliant license as long as the binaries can be freely distributed. Hardware firmware binaries almost always include a digital signature from the vendor, to ensure that only trusted firmware is loaded onto the device. Thus even if source code is available for a given firmware binary, Fedora would still need to be shipping it as a pre-built vendor supplied signed binary, in order to pass the cryptographic verification checks typically performed by hardware when loading firmware.

Another example of shipping pre-built vendor binaries would be CPU microcode. This could be considered firmware for the core CPU, and again are vendor supplied, signed binaries, with no source code available.

The architectural enclaves satisfy the classical role of firmware, in the context of the SGX technology, providing enablement for application usage. Unusually for firmware they are made available with 100% of their code under Fedora approved OSS licenses. The architectural enclaves, however, are still consumed as pre-built signed binaries due to the need to establish a chain of trust rooted back to Intel as the CPU hardware vendor.

Overall, the architectural enclaves meet the definition of firmware documented in the Fedora licensing guidelines:

  1. The files must be non-executable within the Fedora Linux context (note: this means that the files cannot run on their own, not that they are just chmod -x). ✅ enclave ELF binarjies must be loaded into memory using the specialized SGX loader.
  2. The files must not be libraries, within the Fedora Linux context. ✅ enclave ELF binaries must be loaded into memory using as specialized SGX loader, the glibc ELF loader can not be used for this.
  3. The files must be standalone, not embedded in executable or library code (within the Fedora Linux context). ✅ enclave binaries are always standalone, self-contained files. They are consumed by regular host software, but cannot be linked to Fedora platform binaries/libraries.
  4. The files must be necessary for the functionality of open source code being included in Fedora Linux or to enable Fedora Linux to boot on a specific device, where no other reliable and supported mechanisms exist. ✅ the pre-built, signed architectural enclaves shipped by Intel, serve to bootstrap the use of SGX technology by applications. ❌ as higher level software services, other application enclaves would not qualify.

Thus it should be permissible to ship the pre-built, signed architectural enclaves binaries with no policy changes.

Conversely application enclaves should NOT be considered firmware, and thus be required to follow the full Fedora packaging guidelines. No application enclaves are anticipated for inclusion in Fedora with this change proposal.

Reproducible build validation policy

Even if the view of architectural enclaves as firmware were to be rejected, there is an alternative precedent that can justify inclusion of the pre-built signed enclaves in Fedora.

In this case we consider the shim package, where Fedora builds a binary from known good source, possibly with local patches, and sends it off for signing by Microsoft, packaging the binary that is sent back into an RPM. Microsoft has various requirements before it will permit signing a vendor's shim.

Consider if the requirements on shim signing were tightened a little more to require a designated toolchain version, such that all shim builds became 100% reproducible on any platform. There would be no need to send the binary to Microsoft for signing, as any binary built in Fedora would inherently match a standard pre-published signed binary from that shim release + toolchain. It would be impossible to distinguish Microsoft signing & returning Fedora's reproducible build, from Microsoft sending back their original pre-signed build.

This is effectively the situation SGX architectural enclaves are in.

None the less, there are some differences between the shim & SGX scenarios.

The first is that today Fedora has the ability to add arbitrary local patches to shim & build with arbitrary toolchain versions, which would be in conflict with a hypothetical requirement for reproducible builds & fixed toolchain.

The second is that on most (but not all) hardware, users can enroll personal certificates in the firmware to allow it to trust a shim binary signed by the user, rather than Microsoft. In the case of SGX enclaves, it is strictly possible from a technical POV for a user to build & load & run their own self-signed SGX architectural enclaves. From a practical POV, however, it is inescapable for the pce enclave to have an Intel signature. Without that signature, no certificate proving authenticity of the hardware can be obtained from Intel, which would thus undermine the goal of SGX technology. The certificate is the mechanism for the Fedora user to prove to themselves that their platform contains genuine Intel CPUs. The other enclaves do have ways to be used with user supplied signatures, provided the consuming applications allow sufficient flexibility in their verification mechanisms. From a practical POV, all usage will be expecting Intel signatures again because these signatures are a means for users to establish trust in their hardware platform, but users do have the freedom to diverge if needed.

Trademark approval

N/A

Alignment with the Fedora Strategy

This aligns with

  • "Reaching the world". Including SGX will make the Fedora support for hosting Intel TDX confidential virtual machines feature complete, by enabling attestation by the guest owner
  • "Innovation & leadership in technology". SGX is a general purpose infrastructure technology which enables application developers to build systems to securely run sensitive workloads. Confidential virtual machines are expected to become a standard part of the public cloud in the coming years, as well as make inroads into private clouds in large organizations. As noted earlier, SGX unlocks the ability to ship TDX confidential VM technology in future Fedora.

Upgrade/compatibility impact

This is a new package set which should not have any upgrade impact, as it will not initially be a dependency of other software. In future it may be pulled in automatically as a dependency in certain KVM deployment scenarios. Even when installed, using anything related to SGX first requires host firmware changes to enable use of the technology. The systemd services provided have their unit files conditionalized on the existence of /dev/sgx_enclave device nodes.

Early Testing (Optional)

Do you require 'QA Blueprint' support? N

The proposed new packages are available for testing via Copr, until such time as they are reviewed & built in Fedora koji:

These should work on any Intel Xeon class platform which has a suitable HW configuration. NB there may be specific DIMM population requirements.

How To Test

  • Documentation on host setup is available but that's a fairly minimalist test. It does not do much that's interesting to an end user, but is at least proving that the pce and ide enclaves are usable. This is the limit of the anticipated testing of SGX in Fedora. More extensive testing will be performed when TDX is integrated at a later date, though some of this may be performed early on an adhoc basis using development snapshots of TDX.

User Experience

Initially the will be minimal real world user experience impact, since on its own this proposal doesn't deliver noticeable end user features. No existing applications in Fedora are known to have support for SGX and none are being proposed yet.

The conceptual user benefit will be that users can bootstrap trust in SGX on their Fedora host. This will facilitate users in deploying 3rd party applications of their choosing that utilize SGX. It will facilitate testing by engineers working on TDX support and its integration into Fedora.

At a later time, when support for Intel TDX is integrated into KVM and QEMU, the real world Fedora user benefit will significantly expand.

Dependencies

The primary functional dependency for use of SGX is kernel support, which has been enabled in Fedora for some time. See "CONFIG_X86_SGX=y" in the kconfig files.

The packages include some new systemd unit files, two of which should be configured to be started by default. This will require changes to the systemd presets in the 'fedora-release' package.

  • mpa_registration.service - this is conditionalized on SGX being enabled, as witnessed by existence of /dev/sgx_eclave. Thus enabling it by default will be a no-op on any existing machines which have not had SGX turned on in the firmware. It is expected to be installed on all SGX installations
  • qgs.socket (as a trigger for qgs.service) - this is likewise conditionalized on SGX being enabled. This will may be pulled in as a dependency of either libvirt or QEMU RPMs, TBD in the future TDX change proposal.

Contingency Plan

  • Contingency mechanism: The new packages have no ill effects on existing Fedora usage. Any outstanding work can be postponed to a later release if required.
  • Contingency deadline: Beta freeze
  • Blocks release? No

Documentation

Documentation on host setup is available which is pretty much all that this change is expected to enable.

A change proposal in future Fedora will cover usage of SGX with TDX confidential virtual machines, which is more interesting to end users.

Release Notes