Intel TDX For Confidential VMs Causing Concern Among Fedora & Open-Source Advocates

One of the capabilities of newer Intel Xeon Scalable processors is support for Trust Domain Extensions (TDX) as a way of providing for confidential virtual machines. Intel TDX allows for "isolation, confidentiality, and integrity at the VM level" which is good from the security perspective but the dependence on signed binaries is causing mixed feelings within the Fedora camp at the broader open-source community.

Daniel Berrange on Red Hat's Virtualization Engineering Team opened a FESCo ticket seeking an exception to be allowed to ship pre-built, signed SGX enclave binaries within Fedora Linux. Long story short, to make use of Intel TDX remote attestation functionality for proof of trust in the hardware, the code running inside the SGX enclave with TDX needs to have a signature attached by the vendor that is then validated by the enclave.

Berrange explained in the ticket:

"It is possible to verify that an application provided enclave is running code signed by its particular vendor's certificate. This involves using some standard / fundamental SGX enclaves built and signed by Intel with a well known certificate, tieing the root of trust to the Intel hardware platform.

To support remote attestation of CVMs using Intel TDX, thus requires packaging much of the SGX software stack in Fedora. Packaging SGX software in Fedora requires packaging the small set of standard enclaves built and crucially signed by Intel - id_enclave.so le.so le.so.orig pce.so pve.so qe.so qe3.so qve.so tdqe.so.

While the enclaves are built into ELF so files, this is just a convenient format to package the code and signature together. These .so files are not loadable by Linux userspace ld-linux.so. The SGX host software will extract the executable code from the ELF file and place it into the enclave memory and verify the signature.
...
You can see from git that the code for these enclaves is all open source, and comprises a mixture of licenses, all of which are approved for inclusion in Fedora. It is possible to build the enclaves on Fedora, however, it would not be possible to use the result since the binaries would lack the required Intel cryptographic signatures the establish the root of trust back to the hardware.

This creates a packaging guideline compliance problem for us, given the normal requirement to build from source and not ship pre-built binaries in Fedora."

Thus Fedora is in a bit of a pickle. To be able to make use of the remote attestation with confidential VMs under Intel TDX, they would need to make use of signed binaries from Intel. The code is open-source albeit the signing certificate is not. What the Red Hat engineer is proposing and seeking approval from the Fedora Engineering and Steering Committee (FESCo) is:

"Pre-built binaries for the standard / fundamental SGX enclaves, signed and distributed by Intel, can be packaged Fedora, with the pre-condition that their payload is verified to be byte-for-byte identical to unsigned binaries fully packaged and built from source in koji using the designated SGX toolchain and runtime for reproducible builds."

This is leading to a lot of mixed feelings by Fedora stakeholders and ultimately a problem for the broader open-source/Linux ecosystem to consider as well as it will come up with other Linux distributions too. Some are in favor of shipping the signed Intel binaries in the name of confidential computing with secure VMs, some feel this is akin to closed-source firmware that is shipped by Linux distributions, and others are against it in the name of treacherous computing. There are also security concerns raised and the reliance on Intel to promptly provide updated and resigned binaries in the event of such problems.

So far no action has been decided upon by FESco for how Fedora will deal with Intel TDX confidential VMs support, but those interested in the ongoing discussion can find it here.