On 22/04/2025 4:06 pm, 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.
I've stripped out the sha2 patch and fixed up to use the existing sha2, then kicked off some CI testing: https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1780285393 https://cirrus-ci.com/build/5452335868018688 When the dust has settled, I'll talk you through the failures. ~Andrew
