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

[ross . philipson]

On 2/18/26 9:30 AM, 'Ard Biesheuvel' via trenchboot-devel wrote:
> On Thu, 12 Feb 2026, at 21:39, Ard Biesheuvel wrote:
> > On Thu, 12 Feb 2026, at 20:49, Daniel P. Smith wrote:
> > > On 2/9/26 09:04, Ard Biesheuvel wrote:
> > ...
> > > > 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.
> > ...
> > > I think this is a great approach for UEFI, though we need to reconcile
> > > this with non-UEFI situations such as booting under coreboot.
> >
> > There are two approaches that I think are feasible for coreboot in this model:
> >
> > - just unpack the ELF and boot that - there is already prior art for
> > that with Xen. We can stick the MLE header offset in an ELF note where
> > any loader can find it.
> >
> > - stick with the current approach as much as possible, i.e., disable
> > physical KASLR so that the decompressed kernel will end up right where
> > the decompressor was loaded, which allows much of the secure launch
> > preparation to be done as before. Only the final bits (including the
> > call into the ACM itself) need to be deferred, and we can propose a
> > generic mechanism for that via boot_params.
> >
> > I'm working on a prototype of the latter, but GRUB is an odd beast and
> > my x86 fu is weak.
>
> I've managed to get a working implementation of the legacy entrypoint, by repurposing the dl_handler() entrypoint you added for EFI [which no longer needs it in my version] as a callback for the legacy boot flow. This /should/ work for i386-coreboot too, but I have no way of testing it (I only tried 'slaunch --legacy-linux' using the x86_64-efi build).

Using that GRUB argument should cause GRUB to choose the legacy boot path. That is where we were going with things.

> I've pushed the changes to the branches I mentioned previously in this thread.

I will pull your latest, thank you Ard

>