On Thu, 26 Feb 2026, at 19:31, [email protected] wrote:
> 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).
Indeed. kernel_info describes the kernel to the bootloader, not the other way
around.
There is prior art for adding fields to boot_params for passing data from
bootloader to kernel (e.g., ext_ramdisk_image/size, efi_info, cc_blob_address),
and I think adding a field for the SLRT is reasonable. Alternatively, we might
consider setup_data but I don't see why a field in boot_params would be
controversial here.
> 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.
>
I think that is irrelevant tbh. A bootloader is supposed to clear struct
boot_params before it copies struct setup_header into it, otherwise
sanitize_boot_params() will trigger on a non-zero sentinel field, and clean it
up. Given that there is no backwards compatibility concern for trenchboot, we
can just stipulate that the SLRT field is only valid if struct boot_params was
wiped correctly, and sanitize_boot_params() will be a no-op.
