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

[Ard Biesheuvel]

On Wed, 18 Feb 2026, at 22:54, Andy Lutomirski wrote:
> On Wed, Feb 18, 2026 at 1:04 PM Simo Sorce <simo@xxxxxxxxxx> wrote:
>>
>> 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@xxxxxxxxx> wrote:
>> > >
>> > > On February 18, 2026 12:03:27 PM PST, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>> > > > On Thu, Feb 12, 2026 at 12:40 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
>> > > > >
>> > > > > On Thu, 12 Feb 2026, at 20:49, Daniel P. Smith wrote:
>> > > > > > On 2/9/26 09:04, Ard Biesheuvel wrote:
>> > > > > ...
>> > > > > 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.
>
> I kind of stand by my other previous suggestion, though:
>
> 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.
>

After setting the EFI boot path to GRUB (or systemd-boot or whatever) at installation time, what other meaningful interactions do we expect with the EFI runtime services?

And given that the secure launch is orchestrated by the bootloader , with which the kernel has a backchannel via its configuration file, it should be rather straight-forward to implement the staging of variable updates there if we really need it. 

Doing any of this at the EFI/spec level might lead to a situation where the OS now has to guess which of the provided APIs to manipulate variables is the least broken.

Of course, for readinf variables, dumping the RT variables into a memory buffer at boot time and exposing it via a EFI config table would be rather straight-forward, but it is also something I feel should be the job of the boot component that takes part in the decision to shield the runtime services from the OS.