From Fedora Project Wiki

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

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.

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 at least the following source 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
  • linux-sgx - provide the SGX platform development headers & libraries, runtime libraries, and supporting daemons

Assuming that pre-built, signed SGX architectural enclaves will be shipped, the following additional package is proposed:

  • linux-sgx-enclavesXXX - one (or more) packages containing architectural enclaves

Not every architectural enclave binary is re-issued on every release. New signed builds are only made available when there is a CVE fix, or a feature enhancement. At time of writing the SGX 2.25 release included new builds for every enclave. A future 2.26 release may only update a subset. Hence at some points in time, Fedora may have more than one linux-sgx-encalvesXXX package present.

If it is required to perform a reproducible build of the above architectural enclave binaries, to prove the binaries match the claimed sources, the following toolchain packages are needed:

  • 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.

At time of writing, with the SGX 2.25 release, the versions required to perform a fully reproducible build will be

  • gcc: 8.5.0, 9.5.0
  • binutils: 2.38, 2.40
  • nasm: 2.16.01
  • glibc: 2.38
  • kernel: 5.17

Note, while Fedora already ships builds fo gcc, binutils, etc, performing reproducible builds requires specific versions, configured with particular choice of build options. Hence the intention to ship parallel packages, which are exclusively intended for use in reproducing enclaves. There will be no support for using these toolchain packages for any other situation in Fedora.

Note: the fact that two versions are needed for binutils and GCC, is an upstream an upstream bug

Note: the enclaves are supposed to be built exclusively against the SGX SDK which provides its own C runtime headers. Thus the fact that it has a requirement for header files from glibc & kernel is also likely another upstream bug.

The full set of proposed source RPMs and their corresponding binary RPM outputs can be see from Copr:

https://copr.fedorainfracloud.org/coprs/berrange/sgx-ng/monitor/

Note, the pre-built, signed architectural enclaves are not always re-created on each SGX release.

Other developers

It is not anticipated that other package maintainers need do anything to support introduction of SGX. The kernel is already built with the SGX feature enabled.

systemd ships with udev rules to enable creation of some of the required device nodes. The SGX package contains addon udev rules for remaining device nodes. The latter may be contributed upstream to systemd in future, and would flow back into Fedora in a normal systemd update.

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)

Release Notes

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/IntelSGX&oldid=723566"