On Thu, Aug 13, 2026 at 5:37 AM Ethan Azariah <[email protected]> wrote:
> Ah... am I right in thinking the exploit runs when cores other than the first
> are being started?
>
> Doesn't the boot firmware -- BIOS/UEFI -- have control over whether SMM is
> started? That's what I was thinking.
That's not really the right lens for it. SMM ("System Management
Mode") is not "started" per se, but rather, it is entered in response
to receipt of an SMI, or System Management Interrupt. What happens
when an SMI is received depends on what handler has been installed for
it, and by what: usually that is configured very early in the boot
process, in UEFI or a legacy BIOS, before the OS is even loaded. For
most UEFI systems, the handler is embedded in the perma-resident UEFI
runtime. As Ron mentioned, the registers involved are latched,
writeable only once until the system is reset.
Entry to, and exit from, SMM in response an SMI is performed by the
hardware in much the same way it enters or exits from an ordinary
interrupt or exception context, except that SMIs cannot be blocked and
add de-facto instruction and store barriers.
The salient characteristic here is that, modulo timing effects, what
happens in SMM or even that it was entered at all is _supposed_ to be
invisible to the ordinary, non-SMM software running on the LP
("Logical Processor": in x86 speak, that is the leaf unit of
execution, either a CPU core or a hardware thread) that the SMI
handler runs on. Yeah yeah, there are counters and stuff that you can
probe to see that it happened, and it may well be doing something on
behalf of that software (like device emulation), but the software
isn't supposed to be able to detect that SMM is the one doing it.
But, it is not architecturally required that this extends to all LPs
in multiprocessing systems: it's totally possible to have one LP in
SMM while the others are not. That said, most systems try to ensure
the property that only one LP is running in SMM and the others are
blocked so that when SMM is entered, all LPs aside from the one
running the handler are de facto stopped. Many of the safety
properties of the code that runs in SMM handlers on UEFI systems
depends on this behavior.
Under the hood, the SMI handler usually broadcasts an SMI to all the
other LPs in the system, and has to rendezvous with them to make sure
that all of them have actually entered SMM and are blocking on a
semaphore or something, before it goes about doing whatever it is that
it's going to do. The challenge here is that CPUs can enter SMM at
different times, because SMIs are delivered at "interruptible" points;
with very few exceptions, this implies delivery on instruction
boundaries: `REP` prefixed instructions can be interrupted on a
repetition boundary, with state synced to the relevant registers; a
CPU halted by a `HLT` instruction can resume execution, and so on, but
generally speaking you don't get an interrupt in the _middle_ of, for
example, an `ADD` instruction. So if a CPU has a pending SMI, but is
actually executing an instruction, the interrupt will pend until the
instruction retires, and then it will be delivered.
What the link that Ron posted shows is that it's possible for the
aforementioned rendezvous process to time out, if waiting for an LP
that is in executing an instruction that takes a really, really long
time (in computer terms), and in that case, it is theoretically
possible to snoop on what the core that entered SMM is doing, or
change something under the hood while it's running: the page mentions
exploiting a TOCTOU disparity an some SMM handler.
SMM is used for all sorts of stuff. The pedestrian examples include
primitive device emulation, so that system firmware can vector USB
interrupts into SMIs so that UEFI can take a trap use of USB HID
devices present them to software as an emulated PS/2 keyboard or mouse
or something for old OSes that don't speak USB (or don't speak that
particular controller variant). Power management is another big
consumer. So far as I know, however, it is not used to implement IPMI
or the functionality of the EC or BMC; those are handled by different
IPs. The EC is typically in the SoC (or perhaps the chipset?
Dunno...) while the BMC is usually physically separate. In either
case, those are independent processors running their own code.
SMM was designed to solve a real problem, but as with many things in
the UEFI/ACPI ecosystem, it is a poor solution to that problem.
- Dan C.
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T496d301e510c8cf1-M5739f47df8d48166c3d1a6e3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
