Message-Id: <b5f2b5a5-b984-4ed3-a023-c06d634f9146@app.fastmail.com>
Date: Mon, 09 Feb 2026 15:04:36 +0100
From: "Ard Biesheuvel" <ardb@...nel.org>
To: "Ross Philipson" <ross.philipson@...cle.com>,
 linux-kernel@...r.kernel.org, x86@...nel.org,
 linux-integrity@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-crypto@...r.kernel.org, kexec@...ts.infradead.org,
 linux-efi@...r.kernel.org, iommu@...ts.linux.dev
Cc: dpsmith@...rtussolutions.com, "Thomas Gleixner" <tglx@...utronix.de>,
 mingo@...hat.com, bp@...en8.de, "H . Peter Anvin" <hpa@...or.com>,
 dave.hansen@...ux.intel.com, mjg59@...f.ucam.org,
 James.Bottomley@...senpartnership.com, peterhuewe@....de, jarkko@...nel.org,
 jgg@...pe.ca, luto@...capital.net, nivedita@...m.mit.edu,
 herbert@...dor.apana.org.au, davem@...emloft.net, corbet@....net,
 ebiederm@...ssion.com, dwmw2@...radead.org, baolu.lu@...ux.intel.com,
 kanth.ghatraju@...cle.com, andrew.cooper3@...rix.com,
 trenchboot-devel@...glegroups.com
Subject: Re: [PATCH v15 00/28] x86: Secure Launch support for Intel TXT

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@...nel.org
>
> 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.

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?

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.

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.

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.

-- 
Ard.


[*] 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.

Powered by blists - more mailing lists