Re: [PATCH v15 00/28] x86: Secure Launch support for Intel TXT

[Daniel P. Smith]

On 2/9/26 09:04, Ard Biesheuvel wrote:
> On Tue, 16 Dec 2025, at 00:32, Ross Philipson wrote:
> > Secure Launch is a vendor-neutral approach to implementing TGC Dynamic
> > Root of Trust (DRTM) support in the kernel. This is complementary to
> > better known Static Root of Trust (SRTM) schemes such as UEFI SecureBoot.
> >
> > This series provides the common infrastructure along with Intel TXT
> > support, without needing the tboot exokernel. Support for AMD SKINIT is
> > pending the common infrastructure getting nailed down, and ARM are
> > looking to build on it too.
> >
> > Originally, tboot were approached to see if they'd take support for
> > other vendors, but they elected not to. Hence this approach instead.
> >
> > Work is being coordinated by the Trenchboot project,
> > https://trenchboot.org/,
> > organising Secure Launch support for upstream open source projects
> > including
> > Grub, iPXE and Xen. The goal of the Trenchboot project is to make DTRM
> > easy
> > to use.  e.g. for Grub, it's simply adding "slaunch" as a command in
> > the boot
> > stanza.  See
> > https://trenchboot.org/user-docs/QUICKSTART/#linux-quick-start-guide
> > for more details
> >
> > Patch set based on commit:
> > torvalds/master/fd57572253bc356330dbe5b233c2e1d8426c66fd
> >
> > Depends on v3 of the following TPM patch set (note this patch
> > set is being actively worked on separately):
> > [PATCH v3 00/10]  tpm: Decouple Trenchboot dependencies
> > Message ID: 20250929194832.2913286-1-jarkko@xxxxxxxxxx
> >
> > Finally we would like to thank everyone for their input and
> > assistance. It has all been very helpful in improving the quality of
> > our solution and in reviewing/strengthening our security posture.
>
> Hi Daniel and Ross,
>
> I have finally gotten around to getting the right hardware and building GRUB and Linux with your patches, and I have managed to get them running on an old Skylake HP laptop successfully.

That is great to hear!

> Surprisingly, even when doing a secure launch, the EFI runtime services still work happily, which means (AIUI) that code that was excluded from the D-RTM TCB is still being executed at ring 0? Doesn't this defeat D-RTM entirely in the case some exploit is hidden in the EFI runtime code? Should we measure the contents of EfiRuntimeServicesCode regions too?

Yes, in fact in the early days I specifically stated that we should 
provide for the ability to measure the RS blocks. Particularly if you 
are not in an environment where you can isolate the calls to RS from the 
TCB. While the RS can pose runtime corruption risks, the larger concern 
is integrating the D-RTM validation of the Intel System Resources 
Defense (ISRD), aka SMI isolation/SMM Supervisor, provided by the Intel 
System Security Report (ISSR). Within the ISSR is a list of memory 
regions which the SMM Policy Shim (SPS) restricts a SMI handler's access 
when running. This allows a kernel to restrict what access a SMI handler 
are able to reach, thus allowing them to be removed from the TCB when 
the appropriate guards are put in place.

If you are interested in understanding these further, Satoshi Tanda has 
probably the best technical explanation without Intel market speak.

ISRD: https://tandasat.github.io/blog/2024/02/29/ISRD.html
ISSR: https://tandasat.github.io/blog/2024/03/18/ISSR.html

> In any case, I am aware that upstreaming this work has been a painful experience so far. Unfortunately, I don't think we're quite there yet.
>
> The way the work is divided between GRUB and Linux seems to be predicated entirely (at least originally) on the idea that the GRUB->Linux handover and the secure launch should be one and the same. I.e., GRUB sets the stage, pokes the ACM, which returns to the loaded linux image and boots it. This requires a lot of coordination, e.g., putting a MLE header in the kernel image and exposing it to GRUB in a certain manner, resource tables and other things that have to remain in sync between both sides.

I would add one clarification, where you say GRUB, we would say any 
bootloader and where you say Linux, we would say any kernel that could 
be started with D-RTM. While you all care about Linux specifically, the 
goal for TrenchBoot is to build a common approach that we can implement
across any other open source OS.

> There also appears to be an assumption that the fact that the ACM returns to the loaded image in 32-bit mode requires a round trip through the decompressor, which may relocate itself in memory and do other things that the slaunch code then has to work around again.
>
> Due to the changes to the EFI boot path, this design has been watered down a bit already, in the sense that GRUB invokes the EFI entry point as usual, and only later, the pivot via the ACM is made.
>
> Other than the SHA-1 debate [*], the main issue I have with this approach is that it adds things to the boot ABI that are closely tied to TXT on the one hand, and bzImage oddities on the other (kernel_info, setup block etc). IOW, the complete lack of abstractions is going to make this a maintenance burden going forward.
>
> I've had a stab at implementing all of this in a manner that is more idiomatic for EFI boot:
>
> - GRUB does minimal TXT related preparation upfront, and exposes the remaining functionality via a protocol that is attached to the loaded image by GRUB
> - The SL stub is moved to the core kernel, with some startup code added to pivot to long mode
> - the EFI stub executes and decompresses the kernel as usual
> - if the protocol is present, the EFI stub calls it to pass the bootparams pointer, the base and size of the MLE and the header offset back to the GRUB code
> - after calling ExitBootServices(), it calls another protocol method to trigger the secure launch.
>
> The only pre-launch ABI that is being added here is a GRUB-specific protocol that is not necessarily tied to TXT. (For legacy boot, it should be feasible to call back into GRUB too, although it would be more of a ad-hoc construction, via the SLR table perhaps.) But no kernel_info and MLE headers etc being added to the ABI surface. Also, there is no longer a need for the GRUB code to understand how the decompressor is constructed, with a setup block etc, or take special care to perform PMR checks when its moves itself around in memory.

> [*] which I still don't get: why is it fine to cap other banks with a single 0x1 byte [as the ACM does too, apparently], but do we require an SHA-1 implementation for capping the SHA-1 banks? Also, the TXT spec dropped all support for TPM1.2 so I wonder if that should be dropped from this series as well.

I think this is a great approach for UEFI, though we need to reconcile 
this with non-UEFI situations such as booting under coreboot. The one 
concern we have before committing to yet another rework is to get 
confirmation from the x86 maintainers. Would they be okay with a new 
entry point into the mainline kernel, or any other major sticking points 
they might see from this approach?

Dave Hansen, since you have been helping us as an x86 maintainer, would 
be willing to provide feedback on our concerns moving forward with the 
above proposal?

> Code can be found here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/ardb/grub.git/log/?h=sl-v2
> https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=x86-slaunch
>
> I am aware that this is not the feedback you are waiting for at this point, given that we're at v15 already. But there are some warts in the current design that really need to be addressed before we can proceed with this IMHO.

V/r,
DPS