Re: [PATCH v15 00/28] x86: Secure Launch support for Intel TXT
From: Daniel P. Smith
Date: Mon Feb 23 2026 - 16:39:32 EST
On 2/20/26 03:30, Ard Biesheuvel wrote:
On Thu, 19 Feb 2026, at 18:34, Andy Lutomirski wrote:
On Wed, Feb 18, 2026 at 11:55 PM 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.
So there's sort of a usability issue here. On the one hand, this can
all be orchestrated to work. We build a kernel, and the kernel
supports secure launch. Someone makes an installer image, and that
image is configured to skip secure launch, then install to disk, then
program EFI vars, then reboot. And the installed image is configured
to do the secure launch, and EFI variable writes are turned off.
On the other hand, this all sucks. I'm getting sick of having the
kernel tell me that I am not permitted to do things. I'm sick of
writing software that deals with unnecessary restrictions. If I were
writing an OS with a USB stick-based installer, I might want to be
able to boot the thing and decide later whether I'm installing an OS
to disk. (In fact, many USB installers work this way.) But, in the
model where EFI variable writes are hard-disabled on a secure launch,
the decision to do the secure launch happens before the decision to
install an OS, and we all lose.
So I'm proposing that EFI variable writes be treated a bit like kexec
[0] -- root (which is already part of the TCB for any practical
purpose) is going to decide, like a grown up, to execute some code
that it doesn't fully trust -- in this case, the EFI variable writes.
And root will coordinate, correctly, with whomever it's busy using the
TPM to coordinate with, and tell it that it's going to do something
that will change its trustworthiness. So it works like this:
1. Secure launch the environment on the stick. (At this stage,
neither the boot loader nor the kernel has the faintest clue whether
anyone needs that secure launch, but this doesn't matter.)
2. The owner of the machine clicks "install".
3. The installer makes some partitions and writes some files.
(Up until now, the security posture of the running environment has not changed.)
4. The installer decides that it's now time to do untrustworthy
things, namely writing EFI vars. So it unmounts anything it mounted
using TPM-sealed keys (or not -- this is between the distro and
whoever trusts the distro), and it does:
# echo 1 >/sys/.../extend_pcr_and_unlock_efi
which *first* extends a PCR because we are about to change our
security posture and *second* sets whatever flag permits use of EFI
runtime services.
5. The installer writes to EFI variables. And the installer can no
longer generate attestations to its previous security posture, which
is the correct behavior. And maybe the user can no longer unlock
their home directory or whatever until they reboot. Which is not
really a big deal.
(This is *dynamic* root of trust. In theory the system could do a
DRTM re-launch and recover its security posture, but I don't think
this is implemented.)
One thing I like about this is that it involves very little code.
It does seem rather straight-forward, and it doesn't have to be specific to TXT either. I.e., we should probably always measure the runtime enabled/disabled state into the PCRs.
As you mentioned, this is not unique to the DRTM case, but allow me to provide our perspective. We would enjoy a sysfs controlled lock that results in a PCR Event. With that said, while it may be getting down into the implementation details, I would like to suggest the PCR be configurable. When under DRTM, it would be desirable to have the ability for the measurement to be extended into a DRTM PCR.
v/r,
dps
But given the actual problem at hand (untrustworthy glue code running in ring 3 that does little more than poke SMM, which itself fundamentally remains part of the TCB), it would be nice if we could just sandbox that code using virtualization.
This came up in a separate discussion regarding ACPI PRM (the new dumping ground for evil vendor code now that SMM has gone out of fashion), although there it should be feasible to run it unprivileged, as the spec requires that capability for the PRM payloads.