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

[H. Peter Anvin]

On February 18, 2026 11:54:55 PM PST, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
>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.
>
>
>
>

The statement "that the kernel has a backchannel to" is *not true in general*.