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

[Simo Sorce <simo@redhat.com>]

On Wed, 2026-02-18 at 12:34 -0800, Andy Lutomirski wrote:
> On Wed, Feb 18, 2026 at 12:29 PM H. Peter Anvin <hpa@zytor.com> wrote:
> > 
> > On February 18, 2026 12:03:27 PM PST, Andy Lutomirski <luto@amacapital.net> wrote:
> > > On Thu, Feb 12, 2026 at 12:40 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > > 
> > > > 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.
> > > 
> > > So I have a possible way to disable EFI runtime service without losing
> > > the ability to write EFI vars.  We come up with a simple file format
> > > to store deferred EFI var updates and we come up with a place to put
> > > it so that we find it early-ish in boot the next time around.  (This
> > > could be done via integration with systemd-boot or shim some other
> > > boot loader or it could actually be part of the kernel.)  And then,
> > > instead of writing variables directly, we write them to the deferred
> > > list and then update them on reboot (before TXT launch, etc).  [0]
> > > This would be a distincly nontrivial project and would not work for
> > > all configurations.
> > > 
> > > As a maybe less painful option, we could disable EFI runtime services
> > > but have a root-writable thing in sysfs that (a) turns them back on
> > > but (b) first extends a PCR to say that they're turned back on.
> > > 
> > > (Or someone could try running runtime services at CPL3...)
> > > 
> > > [0] I have thought for years that Intel and AMD should do this on
> > > their end, too.  Keep the sensitive part of SMI flash entirely locked
> > > after boot and, instead of using magic SMM stuff to validate that
> > > write attempts have the appropriate permissions and signatures, queue
> > > them up as deferred upates and validate the signatures on the next
> > > boot before locking flash.
> > > 
> > 
> > *If* a physical EFI partition exists there is a lot to be said for this approach.
> > 
> > The only issue with this that I can see is for things like network or CD/DVD booting where there isn't necessarily any EFI boot partition, it might not be writable, or it might not be persistent (e.g. http booting typically uses a ramdisk, like the old Linux initrd.)
> 
> Hmm, I guess my approach is a 100% complete nonstarter for installing
> Linux from a CD, and it's really not awesome for installing Linux from
> a USB stick.

Doing any of this on a removable device feels generally like a trap.
You get your USB disk in, try to boot, and it saves vars, but reboot
fails for whatever reason, you plug it in another machine ... and it
tries to "continue" from there? The amount of validation needed and
testing for failure modes across reboots sounds really painful.


-- 
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc