What is Intel TDX?
Intel® Trust Domain Extensions (Intel® TDX) is a hardware-backed security technology for confidential computing. TDX can cryptographically isolate a virtual machine (VM) from its host and hypervisor; that means users can run their workloads with sensitive data in shared environments, even on public cloud infrastructure, with strong privacy guarantees. The ability to protect data while in-use can transform how organizations think about where they can process their data.
Well-known virtualization software such as KVM, QEMU, and libvirt builds on top of Intel TDX to provide confidentiality to running workloads.
The offer: Early TDX enablement
Red Hat and Intel are providing a preview of the TDX-enabled virtualization stack on CentOS Stream 9, a Linux distribution that tracks just ahead of Red Hat Enterprise Linux (RHEL) development. Read on to understand our motivations, the technical challenges and how to start today with Intel TDX.
The problem: Stable software takes time
To run a confidential VM, multiple components of the virtualization stack need to support the TDX hardware. Intel is working to bring full TDX software support in the upstream Linux kernel, QEMU and libvirt.
RHEL's "upstream first" process, highlighted by CentOS Stream, is what makes the distribution more stable and reliable. It takes some time for software changes (or patches) to be included in the upstream components, however, and even more time passes while these changes propagate downstream.
The solution: Take advantage of Red Hat's platforms for innovation
Many of our existing and future partners will benefit from confidential computing. We're not comfortable keeping them waiting—we want to bring our partners with us on the path that leads to full support for Intel TDX in RHEL. Here we encourage our partners to evaluate and test the solutions we build while we're still building them, and we enable such a strategy via the CentOS Project.
Specifically, we're participating in the CentOS Virtualization Special Interest Group (SIG) to offer an opt-in repository of open source software components enabled for Intel TDX. Some technical documentation comes along, which explains how to install and test these components on CentOS Stream 9.
Collaboration: How we make it happen
Our development cycle starts by backporting patches. Intel identifies the patches needed for TDX features from the upstream and from Intel TDX public repositories. Starting from Intel's public repository, Red Hat engineers identify any dependencies missing in CentOS Stream 9 that are required by Intel's TDX code. The result is a set of patches consisting of both recent commits from upstream projects and code changes by Intel that enable TDX support.
The CentOS Stream source code, with the TDX patches applied, is used to build and release the software as CentOS RPM packages. This part of the workflow all happens on the CentOS infrastructure that's dedicated to SIGs. Automation populates the public repository in the SIG namespace, and the packages can be installed in any CentOS Stream 9 system just by enabling the SIG repository.
At this point, Intel QA verifies the freshly built packages. More than 100 test cases cover TDX initialization, virtual machine (TDVM) boot and lifecycle, functionality, stress testing and benchmarks across all three software components that we're releasing (Kernel, QEMU, libvirt). Red Hat QA tests SIG builds as well, so that any regressions impacting non-TDX VMs can be detected and fixed early. Newly discovered bugs then go straight to the CentOS Stream issue trackers.
In our iterative development process, there are three reasons to release a new build: When a bug is fixed, when Intel updates their public repositories, or as soon as our contributions are accepted in CentOS Stream 9. The latter is an exciting eventuality. Every time some of our changes are accepted, the difference between CentOS Stream 9 and the SIG packages decreases. This gets us closer to TDX support in RHEL.
Backports, behind the scenes
Many changes can be backported as-is, others are harder. For QEMU, the backport is largely the v2 series of adding TDX support in QEMU from August. Specifically, there is a tag which has some differences. That tag was on top of QEMU 8.1.0-rc0, but at the time CentOS Stream was on the older QEMU 8.0.0. Backporting the patches to the older version required solving only minimal conflicts.
The Linux kernel backports have been more demanding. The CentOS Stream 9 kernel was originally based on Linux 5.14, and tens of thousands of commits have been added since. Starting there, we synchronized the entire MTRR section with the more recent version 6.5 of Linux. Unaccepted memory support was backported too, together with two dependent pieces regarding EFI and MAX_ORDER.
Red Hat immediately contributes these updates to CentOS Stream, so that our ongoing work can benefit a wider audience.
Having our contributions to CentOS Stream accepted means that part of our SIG work is now available to all CentOS Stream 9 users without them needing to enable the SIG repository and add it. Additionally, the accepted contribution signals that RHEL will, eventually, ship our changes too, as it receives them directly from CentOS Stream. What an impact!
Working in the open with special interest groups
Working in the open is allowing Red Hat and Intel to accelerate the consumability of TDX in conjunction with a broad set of contributors while also making this work available to the upstream community. We publish our work, we document it and we amplify the reach of our improvements by proposing changes to projects further upstream.
As a CentOS SIG, we have access to infrastructure that’s parallel to the one delivering CentOS Stream. Separate instances guarantee that SIGs are able to do the work they need to do without having to navigate conflicts or coexistence issues with other groups. Additionally, the infrastructure provides the SIG with the same reliability that exists across the whole CentOS project.
The CentOS SIG infrastructure makes creating and delivering packages a streamlined process. Engineers in the SIG can build on top of the CentOS Stream release, modify it and add the bits as needed, and then ship the results in a dedicated repository. Users can easily enable the repository and install the SIG packages in their development environment. The SIG creates a fast track between the developers and the users of the software components.
Our SIG documentation has the pointers to the public code repositories and to the binary packages we produce. The documentation helps you understand how to assemble a working system and how to verify that your confidential computing stack is operational.
The issue tracker and the merge requests are public in our group on Gitlab. We welcome your feedback and contributions. If you test our software releases and find something can be improved, please open an issue or submit a code change yourself.
Participating in the community
Partners and community members who test the SIG releases are seizing the opportunity to verify the compatibility with their technology stack, to influence the development and to mature the experience ahead of time. The ultimate goal is to be prepared to deploy production-ready releases as soon as they become available.
If you have TDX-capable hardware at hand, head to our documentation and put it into practice. You’ll find instructions on how to configure a host with TDX support, how to run a TD guest virtual machine and how to contribute to the SIG.