Abstract

OpenXT currently implements launch integrity via the Trusted Boot, or tboot, module, which uses Intel(R) TXT to perform a measured/verified launch. This RFC proposes replacing the current tboot-based measured launch implementation in OpenXT with the TrenchBoot framework, which provides a more robust approach to measured launch. TrenchBoot supports Dynamic Root of Trust for Measurement (DRTM) using both Intel TXT and AMD SKINIT, allowing OpenXT to expand its measured launch capabilities beyond Intel-only hardware, and mitigates a few of tboot's limitations, such as TPM event log access and UEFI access conflicts. The TrenchBoot project offers active upstream development, community-tested reference implementations (such as in Qubes OS AEM), and modern support for TPM 2.0, UEFI, and multiboot2.

The secure launch kernel used in TrenchBoot will be built from the TrenchBoot linux repository (branches linux-sl-6.15 for Intel and linux-sl-amd for AMD). It will be launched by a patched GRUB2 bootloader, which replaces tboot. Xen and dom0 Linux will be loaded as multiboot2 modules and measured by the secure launch kernel. This maintains compatibility with OpenXT's existing measurement launch infrastructure while modernizing the boot chain and enabling broader platform support.

Motivation and Design

The legacy tboot solution used in OpenXT has a few drawbacks. It generates a TXT-specific event log that requires significant customization to make it accessible to the rest of the OpenXT Measured Launch subsystem. It is also specific to Intel(R) TXT and so is not extensible to AMD processors. It is not UEFI-native, which significantly complicates the boot process - in the current design for UEFI boot, Xen must first be booted to execute a completely patched in code path that fabricates Multiboot2 headers and jumps into tboot. After tboot completes DRTM, control must return back to Xen, which then adjusts memory maps and page tables before continuing normal boot. This is a quite fragile/involved sequence that clashes with UEFI boot services, and has already made upgrades to newer Xen versions significantly more difficulty. The legacy boot path uses GRUB as the bootloader rather than the patched Xen EFI loader, leading to a complicated dual boot approach in the current design.

In contrast, TrenchBoot provides a unified framework designed to work with UEFI systems natively and to support DRTM on both Intel and AMD platforms. TrenchBoot uses a Linux-based secure launch kernel, which emits a standard TCG 2.0-compliant event log. It also performs its own measurements as part of the launch flow. which allows more flexibility in defining the measured launch profile - unlike tboot, which can only measure the multiboot modules preloaded by the bootloader, the TrenchBoot secure launch kernel has the ability to measure both the multiboot2 modules it is handed (Xen, dom0, initrd) and additional inputs under its own control. This includes kernel and hypervisor command lines, EFI variables, firmware blobs, and other platform data.

TrenchBoot continues to utilize the multiboot2 protocol and is used as intended by the specification without custom modifications, as opposed to the OpenXT's complex implementation previously described with the custom multiboot2 header setup approach. The Secure Launch Kernel serves as the multiboot2 kernel, while Xen, the dom0 kernel, initrd, and XSM policy are loaded as multiboot2 modules by GRUB2. Xen receives a standard multiboot2 environment, enabling easier upgrades to new Xen versions and better maintainability in general.

TrenchBoot uses a small, specially configured Linux kernel as the initial payload. This secure launch kernel is launched via a GRUB2 bootloader patched to support the multiboot2 protocol and TrenchBoot-specific extensions. Once launched, the secure launch kernel performs a DRTM instruction, resets the PCRs, extends measurements into TPM 2.0 DRTM PCRs (usually banks 17–23), and loads the Measured Launch Environment (MLE).

This also provides a more unified boot path for legacy and UEFI, which would help simplify the OpenXT design - GRUB2 would become the unified bootloader to replace the current dual approach. In the UEFI security model (Secure Boot), GRUB2 would be GPG-signed and verified by the Microsoft-signed shimx64.efi. GRUB2 would in turn verify its GPG-signed modules and Secure Launch kernel. The SL kernel then performs DRTM (Xen, dom0, initrd) to provide attestation evidence for the boot chain, thus completing the chain of trust.

Some of the implementation considerations to modify the current OpenXT design include replacing the portion of xen.efi that acts as a custom bootloader with TrenchBoot's GRUB2 fork, and translating from openxt.cfg to grub.cfg. The installer should be updated to use GRUB2 for both UEFI and legacy paths, and EFI boot entries would need to be modified to point shimx64.efi to the GRUB2 bootloader. From GRUB2, we need to load the secure launch kernel, which can be sourced and built from the TrenchBoot-maintained Linux repositories, and eventually jump into Xen. AEM has done a lot of the heavy lifting here, providing branches implementing TrenchBoot with GRUB2, SL kernel, and Xen, and ensuring it works with both Intel and AMD. For Intel TXT, the linux-sl-6.15 branch ([5]) provides the latest changes. For AMD SKINIT, the linux-sl-amd branch ([6]) adds AMD-specific launch code, including SKINIT instruction handling and AMD-specific PCR logic.

In terms of Xen modifications, current OpenXT patches for tboot interaction (such as tboot-measure-and-launch-from-xen-efi.patch and shim-support-for-shim-lock-measure.patch) can be deprecated. Instead, patches from the TrenchBoot Xen fork from AEM for v4.17.2 ([7]) should be ported to the current OpenXT Xen version (v4.18), including EFI loader handoff, PCR event parsing, and dynamic chipset detection.

Measured launch scripts (ml-functions, seal-system) can be updated to detect TrenchBoot and compute sealed PCR policies based on the event log exposed via the TrenchBoot-enabled kernel. Existing tboot event log handling code can be minimized in favor of standard tpm2-tools. While a TCG-formatted event log in dom0 allows this standard tooling (tpm2_eventlog) to parse measurements, OpenXT will still require a forward prediction tool (successor to pcr-calc) to compute expected DRTM PCR values from known inputs. Rather than the current C implementation, this could be re-implemented in a simpler way (e.g. Python or shell to consume the TCG log and module digests) so as not rely on a kernel module’s binary log interface.

Its integration into Qubes OS's Anti Evil Maid (AEM) project shows TrenchBoot's viability (see [2], [3]), as it performs the necessary patching of Xen, GRUB2, and the Linux kernel explained above and successfully tests against Intel and AMD (see [8]). This should be used as a reference when integrating into OpenXT as well.

Benefit to OpenXT

This change enables OpenXT to support DRTM on modern AMD hardware using SKINIT, as well as having a more reliable launch integrity flow. It brings the measured launch path up to date with active upstream development from the TrenchBoot project and its partners. Using more standard/generic interfaces (multiboot2, TCG2 event logs), OpenXT improves compatibility with current boot architectures. Simplifying the boot chain by eliminating tboot and replacing custom event log handling with standard interfaces can reduce maintenance overhead and risk of mismeasurement.

Security Impact

TrenchBoot provides hardware-rooted measured launch using platform DRTM capabilities. TrenchBoot Secure Launch for Linux provides for hardware-rooted integrity during boot (First Launch) and runtime (Runtime Launch). On Intel platforms, the secure launch kernel executes GETSEC[SENTER] and on AMD, it executes SKINIT. In both cases, PCRs 17–23 are reset and extended with measurements such as SL kernel, Xen, dom0, and initrd. Because the Secure Launch kernel measures the artifacts it loads (and their command lines), we gain flexibility to include or exclude inputs (e.g., policy files or firmware variables) in the DRTM profile.

Compared to tboot, TrenchBoot simplifies the event log path and exposes the measurement log via standard kernel interfaces, and mitigates known flaws in Intel TXT and tboot’s handling of SMI attacks, memory layout mismatches, and non-standard extensions. tboot supports only a single attestation model (predetermined PCR manifest verification), while TrenchBoot enables more flexible policy-based attestation, allowing remote verification tools to function more reliably using standard TPM 2.0 tooling.

Upgrades/Backwards Compatibility

The transition to TrenchBoot presents some challenges for existing OpenXT deployments, largely around PCR prediction and measured launch continuity. The core issue is that switching from tboot to TrenchBoot changes the program responsible for generating PCRs 17-23, making it tricky to use existing measurements to predict the new DRTM PCR values due to changes in event log formats, module loading and measurement orders, and potential differences in what exactly gets measured/extended. Predicting the PCR values for the new boot chain is the primary challenge we have to solve, and could be approached in a couple of different ways.

If DRTM PCRs for a given OpenXT build are consistent across different hardware platforms, we could pre-calculate expected PCR values during the build process and release them with the upgrade, allowing users to forward-seal to the new PCR values before upgrading. This may require extensive testing to verify PCR consistency across hardware.

Another option is a "one time reseal" mechanism where the user can provide an OTP to unlock the config partition, allowing new PCR values to be calculated and sealed via TrenchBoot. This would mean the system is decrypting from an unverified state, which has a security impact and should be avoided if possible.

With either option, OpenXT should likely support some form of backwards compatibility for a temporary period to gradually let customers migrate to the new system, e.g. having dual boot support during a transition period. We can implement migration tools (e.g. converting openxt.cfg configs to GRUB2 format), and maintain fallback options to ensure existing systems still work so that we can have backwards compatibility while customers are able to validate the TrenchBoot functionality themselves. We would need to come up with a clear announcement and timeline for this to provide to customers if we are going to eventually remove support for the old boot flow.

Test Plan

Initial testing will verify DRTM launch using TrenchBoot GRUB2 and secure launch kernel on Intel TXT-capable platforms, with the primary focus being to support TPM 2.0. This could first be tested with the changes on branches provided by AEM for Xen 4.17.2, GRUB, and kernel - these could be taken/written as patches to our current OpenXT versions. The normal measured launch process can be tested, as well as negative cases such as intentionally mismatching PCRs. PCRs can be validated post-launch using tpm2_pcrread, and event logs can be parsed using tpm2_eventlog to verify the correctness of the measurement chain and ensure that the system correctly identifies issues with Measured Launch on bad measurements.

We will also support and need to test forward sealing - we could generate expected DRTM PCR profiles from known inputs before first boot into TrenchBoot, validate predictions against tpm2_pcrread after boot, then seal the secrets to the validated profile. The test plan should include both "positive" runs where predicted and measured PCRs match and secrets unseal, and "negative" runs with intentional mismatches to verify refusal to unseal.

Following that, testing could be conducted on AMD SKINIT platforms using the linux-sl-amd branch of TrenchBoot. Functionality, PCR extensions, and boot integrity will be validated in the same way.

Legacy systems without DRTM support will be tested to ensure fallback boot paths operate correctly. Both legacy and UEFI modes can ultimately be tested to ensure correct functionality for both.

We will track formal test cases in OpenXT JIRA/Confluence, covering Intel TXT and AMD SKINIT paths, Secure Boot on/off, and fallback behavior. Where feasible, we will automate these as BATS tests (our current framework) to exercise PCR prediction, event-log parsing, sealing/unsealing workflows, and rescue boot modes.

References

[1] https://trenchboot.org/

[2] https://www.qubes-os.org/news/2023/01/31/trenchboot-aem-for-qubes-os/

[3] https://docs.dasharo.com/projects/trenchboot-aem-v2/

[4] https://github.com/TrenchBoot/grub/tree/aem-qubes-4.2.3

[5] https://github.com/TrenchBoot/linux/tree/linux-sl-6.15

[6] https://github.com/TrenchBoot/linux/tree/linux-sl-amd

[7] https://github.com/TrenchBoot/xen/tree/aem-4.17.2

[8] https://github.com/TrenchBoot/trenchboot-issues/issues/42