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).
I've pushed the changes to the branches I mentioned previously in this thread.
Hello Ard,
I am working on incorporating the changes we have been discussing. So far
everything has been rather smooth. I noticed in the legacy support you did
here, you introduce a new boot_param. This is something that we tried to do
early on but changes to the boot_params layout is rather frowned upon. We
worked with Peter A. on the kernel_info scheme but this parameter you
introduced is not used that way (kernel_info is meant to be RO after the kernel
is built). I guess my first questions are whether this will be an acceptable
approach (per the x86 maintainers) to add a boot_param and, if so, whether the
spot you chose is reasonable. E.g. will it survive the sanitize boot params
step.
Thanks
Ross
