On 4/22/25 11:06, Sergii Dmytruk wrote:
The aim of the [TrenchBoot] project is to provide an implementation of
DRTM that is generic enough to cover various use cases:
- Intel TXT and AMD SKINIT on x86 CPUs
- legacy and UEFI boot
- TPM1.2 and TPM2.0
- (in the future) DRTM on Arm CPUs
DRTM is a version of a measured launch that starts on request rather
than at the start of a boot cycle. One of its advantages is in not
including the firmware in the chain of trust.
Xen already supports DRTM via [tboot] which targets Intel TXT only.
tboot employs encapsulates some of the DRTM details within itself while
with TrenchBoot Xen (or Linux) is meant to be a self-contained payload
for a TrenchBoot-enabled bootloader (think GRUB). The one exception is
that UEFI case requires calling back into bootloader to initiate DRTM,
which is necessary to give Xen a chance of querying all the information
it needs from the firmware before performing DRTM start.
From reading the above tboot might seem like a more abstracted, but the
reality is that the payload needs to have DRTM-specific knowledge either
way. TrenchBoot in principle allows coming up with independent
implementations of bootloaders and payloads that are compatible with
each other.
The "x86/boot: choose AP stack based on APIC ID" patch is shared with
[Parallelize AP bring-up] series which is required here because Intel
TXT always releases all APs simultaneously. The rest of the patches are
unique.
Sergii,
Thanks so much to you and the team over at 3mdeb for taking the lead on
getting Secure Launch written for Xen.
One quick comment, Secure Launch will eventually support other
architectures, and we really should not let the maintenance fall on the
x86 maintainers, or eventually to "the rest". I would like to suggest
adding an entry into the MAINTAINERS file for "TrenchBoot Secure Launch"
and list any new files that are being introduced for Secure Launch. When
adding the section to MAINTAINERS, I would kindly like to request that
myself be included as a maintainer and Ross Phillipson as a reviewer.
V/r,
Daniel P. Smith
