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

[Ard Biesheuvel]

On Thu, 12 Feb 2026, at 20:49, Daniel P. Smith wrote:
> On 2/9/26 09:04, Ard Biesheuvel wrote:
...
>> 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
>

Thanks, I'll take a look at those.

But would it be better to disable the runtime services by default when doing a secure launch? PREEMPT_RT already does the same.

> 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.
>

I'd argue that relying on things like setup_header, boot_params and kernel_info is not a great way to achieve that. The reason I care about this is that you are relying on those things even when doing EFI boot, which makes your approach highly Linux/x86 specific.

Given that arm64 has no decompressor at all, it is highly likely (and acceptable) that only EFI boot can do a secure launch. It also implies that the core kernel is the only place where we can put the pieces that execute afterwards. So adopting a model now for x86 that we know does not generalize well across other architectures is something I am not keen on.

...
>> 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'd be happy to have a call to compare notes and see if we can come up with something we can all agree on (modulo the SHA-1 :-))