Intel SGX Software Stack
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 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.
Owner
- Name: Daniel Berrange
- Email: berrange@redhat.com
Current status
- Targeted release: Fedora Linux 42
- Last updated: 2024-10-25
- [Announced]
- [<will be assigned by the Wrangler> Discussion thread]
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
Detailed Description
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
- 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 the enclave code.
- Build helper tools (for signing enclaves, generating code enclave API entrypoints)
- Support for developing applications that use 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 to identity the platform
- Quote generation daemon - assists QEMU in acquiring signed attestation reports for TDX VMs.
Comparison with other technology
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 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
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.
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.
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.
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.
Feedback
Benefit to Fedora
As a general purpose infrastructure technology, SGX can be applied to / used by a wide variety of scenarios / applications.
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.
Scope
Proposal owners
Add the following packages to Fedora
- CppMicroServices - a C++ runtime library for building microservices daemons
- 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.
NB, 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:
NB, The requirement for glibc and kernel header packages is 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.
Other developers
The kernel functionality required for SGX is already present in Fedora kernel packages, so no work by other maintainers is anticipated.
Release engineering
N/A - does not impact deliverables for releng
Policies and guidelines
- Architectural enclaves.
- 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
- 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).
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.
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:
https://copr.fedorainfracloud.org/coprs/berrange/sgx-ng/
How To Test
- Document how to validate a single-socket system by obtaining PCK certificates automatically
- Document how to configure a multi-socket system to enable its registration with Intel services, and request a PCK certificate
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.
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.
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.
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.
Kernel support for SGX already exists in Fedora:
$ git grep CONFIG_X86_SGX=y kernel-x86_64-debug-fedora.config:CONFIG_X86_SGX=y 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 mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change), Yes/No
Documentation
N/A (not a System Wide Change)