Changes/IntelSGX

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

• Name: Daniel Berrange
• Email: berrange@redhat.com

Current status

• Targeted release: Fedora Linux 42
• Last updated: 2024-10-18
• [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>

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

NB, 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. For example SGX 2.23 and 2.24 releases only updated the 'qve' enclave, all other enclaves remained on version 2.22. Thus to perform a reproducible build of the full set of enclaves, requires potentially more than one linux-sgx-enclavesXXX package. 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: https://github.com/intel/linux-sgx/issues/1045

NB, The requirement for glibc and kernel header packages is likely a bug. The enclave code should be build exclusively against the SGX runtime, which is a completely custom C library. This is being investigated upstream https://github.com/intel/linux-sgx/pull/1062

Other developers

N/A

Release engineering

N/A

Policies and guidelines

Define policy requirements wrt shipping of pre-built SGX architectural enclaves (AEs) with cryptographic signatures from Intel.

Two options

• Declare SGX architectural enclaves can be considered firmware, and thus exempt from build-from-source policy requirements.

• Define a policy explicitly for SGX enclaves, that permits shipping pre-built signed binaries for architectural enclaves only, if-and-only-if, a reproducible build can validate the binaries.

NB, in all options, the proposed policy is ONLY intended to application to architectural enclave shipped by Intel. Any application that creates its own SGX enclaves would NOT be covered by this. ie this is NOT proposing to allow arbitrary 3rd party binary enclaves providing application code in Fedora, only the low level hardware enablement/bootstrapping enclave.

Application enclaves are considered out of scope for this feature proposal, but if required in the future, it is suggested that a Fedora signing key would be required for any application enclaves.

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

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 noticable end user features. Only once a followup proposal for integrating Intel TDX into KVM is done will the user experience changes.

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)