# The ACPI Tables That Quietly Secure Your Windows Machine
> Five small ACPI tables -- DMAR, IORT, WSMT, SDEV, WPBT -- form the firmware-OS contract behind VBS, Credential Guard, Kernel DMA Protection, and BitLocker.
*Published: 2026-05-11*
*Canonical: https://paragmali.com/blog/the-acpi-tables-that-quietly-secure-your-windows-machine*
*License: CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/*
---
Windows's strongest security guarantees -- Credential Guard, BitLocker, Kernel DMA Protection, Memory Integrity -- all rest on five small ACPI tables the OEM's firmware writes before the Windows boot loader runs. Two of them (DMAR / IORT, WSMT) are hard prerequisites for VBS launch; one (SDEV) decides which devices the Secure Kernel may partition; one (WPBT) lets the firmware drop a SYSTEM-privileged binary into Windows on every boot, and accepted revoked certificates until 2021. This article walks each table, the failure families they admit, and the inventory commands to audit them on your own laptop.
## 1. A Revoked Cert, A Secured-Core PC, A 52-Byte Table
In September 2021, researchers at Eclypsium published a video of a Secured-Core PC -- the most heavily protected Windows configuration money can buy, with Credential Guard, HVCI, BitLocker, and Kernel DMA Protection all enabled -- being silently rooted at boot [@eclypsium-wpbt]. The malicious binary was Authenticode-signed with a Hacking Team code-signing certificate that had been revoked six years earlier. Windows ran it anyway, with SYSTEM privileges, before the user even reached the lock screen. The mechanism was a single ACPI table almost no one outside platform-firmware engineering can name.
> **Note:** The Eclypsium researchers wrote: *"This issue affects all Windows-based devices going back to Windows 8 when WPBT was first introduced. We have successfully demonstrated the attack on modern, Secured-Core PCs that are running the latest boot protections"* [@eclypsium-wpbt]. Microsoft's recommended mitigation was not to fix the certificate validator. It was to ask customers to author a Windows Defender Application Control policy that constrains WPBT-injected binaries [@eclypsium-wpbt].
How is this possible if every box on the security checklist was ticked? The answer is structural. Every modern Windows guarantee -- Credential Guard isolating LSASS in a higher Virtual Trust Level, the [Secure Kernel](https://paragmali.com/blog/when-system-isnt-enough-the-windows-secure-kernel-and-the-en/) partitioning a fingerprint reader away from kernel-mode drivers, [BitLocker](https://paragmali.com/blog/bitlocker-on-windows-architecture-attacks-and-the-limits-of-/) sealing volume keys against PCR[7], Kernel DMA Protection blocking a Thunderclap-class peripheral [@thunderclap-io] -- assumes the [hypervisor](https://paragmali.com/blog/above-ring-zero-how-the-windows-hypervisor-became-a-security/) came up *knowing the correct shape of the platform*. That shape is not discovered by Windows. It is described to Windows, in five small ACPI tables the OEM's UEFI firmware built before the Windows boot manager even started.
> **Key idea:** Every modern Windows security guarantee assumes the hypervisor came up knowing the correct shape of the platform. That shape is described in five small ACPI tables the OEM's UEFI firmware built before the Windows boot manager even started. The hardware does the enforcement; the tables decide what gets enforced.
Their names, in the order this article walks them, are **DMAR** (Intel VT-d, the IOMMU table on x86 [@acpica-actbl1]), **IORT** (the Arm SMMU analogue [@acpica-actbl2-iort]), **WSMT** (the OEM's pact with Microsoft about System Management Mode behaviour [@acpica-actbl3-wsmt]), **SDEV** (the list of devices the Secure Kernel may wall off from non-secure code [@acpi-65-sdev]), and **WPBT** (the channel by which the firmware can drop a binary into `c:\windows\system32` and run it on every boot [@acpica-actbl3-wpbt]). Each table is a few dozen to a few thousand bytes. Together, they are the firmware-OS contract on which everything else above the hypervisor depends.
Four questions fall out of that framing, and the rest of this article answers each in turn. *Who populates these tables?* *Who validates them?* *What does Windows do when they are wrong?* *What does the attacker get when they forge them?* Along the way we will encounter the design idiom that recurs across every one of the five: the OEM declares a property the operating system has no independent way to verify. Microsoft's own engineers say so on the public Learn page for WSMT [@ms-oem-uefi-wsmt]. Once you internalise that idiom, the rest of the article reads as five variations on a single theme.
This is the substrate article in a longer series on Windows platform security. The hypervisor-as-isolation-primitive [@hyperv-sibling], the trustlets that run in the Secure Kernel [@vbs-trustlets-sibling], [Pluton-as-TPM](https://paragmali.com/blog/pluton-a-tpm-on-silicon-microsoft-can-patch/) [@pluton-sibling], the [discrete TPM](https://paragmali.com/blog/the-tpm-in-windows-one-primitive-twenty-five-years-and-the-c/) [@tpm-sibling], BitLocker [@bitlocker-sibling], [Secure Boot](https://paragmali.com/blog/secure-boot-in-windows-the-chain-from-sector-zero-to-userini/) [@secure-boot-sibling], application identity and code-integrity policy [@app-identity-sibling], and USB device-arrival policy [@plug-and-trust-sibling] all rest on these five tables. We do not redefine those concepts; we trace where they touch the table set, and we link out where the curious reader wants the deeper tour.
So: where do these tables come from in the first place? They have a thirty-year history that explains the structural problem.
## 2. ACPI as the Firmware-OS Contract: 1996 to Now
How did we get from "describing sleep states" to "deciding whether Credential Guard turns on"? The answer is a thirty-year drift, and it is worth a short tour because each new table answered an attack class the prior contract could not describe.
ACPI 1.0 shipped in December 1996, jointly authored by Intel, Microsoft, and Toshiba; HP, Huawei, and Phoenix joined later, and in October 2013 the ACPI Special Interest Group transferred all assets to the UEFI Forum, which still publishes the standard today (current revision 6.6, released May 13, 2025) [@wikipedia-acpi]. The original idea was modest: replace the Advanced Power Management 1.x INT 15h real-mode mess with a *generic table-passing chassis* the OS could read in protected mode.APM 1.0 shipped in 1992; revision 1.2 in 1996 was the last version of the spec, and Microsoft dropped APM support in Windows Vista [@wikipedia-apm]. APM expected the OS to invoke real-mode BIOS routines through INT 15h; once Windows ran a hardware abstraction layer in protected mode that was no longer architecturally tolerable.
The firmware-written, OS-read table format that describes a platform's non-discoverable devices, capabilities, and security properties. The OS finds an entry-point structure (the RSDP) via the EFI system table, walks it to either an RSDT or XSDT, and from there reads typed tables identified by 4-byte ASCII signatures.
The mechanics are uniform. Microsoft's own bring-up documentation describes them verbatim: *"Windows depends on UEFI firmware to boot up the hardware platform . . . The platform firmware fills in the address of either the RSDT or XSDT in the RSDP. (If both table addresses are provided, Windows prefers the XSDT)"* [@ms-acpi-tables]. Each table carries the same 36-byte header (signature, length, revision, checksum, OEM ID, OEM table ID, OEM revision, creator ID, creator revision); the body is signature-specific. The contract: **firmware writes typed tables, the OS reads them, the OS trusts them.**
For the first decade of ACPI, every table described power, addressing, or device topology. Then the security tables began to arrive, one per attack class, each one narrowing the gap between *what hardware can do* and *what the OS believes the hardware will do*.
timeline
title ACPI security-table genealogy
1996 : ACPI 1.0 released (Dec, Intel/Microsoft/Toshiba)
2007 : DMAR introduced (Intel VT-d / Q35)
2011 : WPBT spec dated 29 November (Windows 8 era)
2015 : IORT introduced (ACPI 6.0, April)
2016 : WSMT v1.0 dated 18 April (Windows 10 v1607)
2017 : SDEV introduced (ACPI 6.2, May)
2021 : Eclypsium discloses WPBT revoked-cert acceptance
2025 : ACPI 6.6 published (May 13)
Timeline date sources, in row order: ACPI 1.0 [@wikipedia-acpi]; DMAR with Intel Q35 [@acpica-actbl1]; WPBT [@acpica-actbl3-wpbt]; IORT in ACPI 6.0 [@acpica-actbl2-iort]; WSMT v1.0 [@acpica-actbl3-wsmt]; SDEV in ACPI 6.2 [@acpica-actbl2-sdev]; Eclypsium 2021 [@eclypsium-wpbt]; ACPI 6.6 May 13, 2025 [@wikipedia-acpi].
The arc compresses to five timestamps. **DMAR**, around 2007 with Intel's Q35 chipset and the first VT-d implementations, was the first ACPI table whose purpose was *security* rather than power: it described the IOMMU translation contexts that let the OS confine a peripheral's DMA reach [@acpica-actbl1]. **WPBT**, dated November 29, 2011 in the ACPICA conformance comment and shipped with Windows 8 [@acpica-actbl3-wpbt; @eclypsium-wpbt], was the first table whose payload was *executable code*: a physical pointer to a binary that Windows would copy into `system32` and run. **IORT**, introduced in ACPI 6.0 in April 2015 [@acpica-actbl2-iort], extended the IOMMU-description idea to Arm; the substrate became pan-architectural. **WSMT**, version 1.0 dated April 18, 2016 and supported in Windows 10 v1607 [@acpica-actbl3-wsmt; @ms-oem-uefi-wsmt], was the first table whose payload was an *OEM warranty about behaviour Windows cannot verify*. **SDEV**, introduced in ACPI 6.2 in May 2017 [@acpi-65-sdev; @acpica-actbl2-sdev], was the first table whose role was to *describe the security partition itself* -- a hint about which devices belong inside the Secure Kernel.
A pattern unifies them. In every case, the OEM *describes* a boundary the OS does not have an independent way to verify. WSMT articulates the principle most explicitly: *"Because SMM is opaque to the operating system, it is not possible to produce a test which runs in Windows to verify that the protections prescribed in the WSMT specification are actually implemented in SMM"* [@ms-oem-uefi-wsmt]. The same shape recurs in DMAR (the firmware describes the address-translation policy; Windows trusts that the IOMMU is enabled and that no over-broad reserved memory regions punch holes in it), in SDEV (the firmware lists secure devices; Windows trusts that the listing is correct and complete), and in WPBT (the firmware nominates a binary; Windows trusts that the signature was, until 2021, sufficient to keep adversaries out).
> **Key idea:** The ACPI security-table set is *attestable but not enforceable* from inside Windows. The OEM declares a property; the OS reads the declaration; the OS cannot independently refute lies in the contents. Every generation of mitigation since -- Secured-core PC certification, Pluton-rooted measured boot, Windows Defender Application Control over WPBT -- is an attempt to turn one corner of that unenforceable contract into an enforceable check, either pre-ship, at boot, or per-deployment.
If the firmware describes the platform and the OS trusts the description, what happens when the firmware describes a peripheral that can DMA-read your password? That is the IOMMU question. It is the oldest of the five tables, and the cleanest example of the *table describes; hardware enforces* pattern. Its name is DMAR -- and on Arm, IORT.
## 3. DMAR and IORT: The IOMMU Tables That Make Kernel DMA Protection Possible
In the mid-2000s a researcher named Maximillian Dornseif demonstrated, in 2004, that he could plug an iPod into a locked laptop over FireWire and read the laptop's physical memory [@wikipedia-dma-attack]. The fix took fifteen years. Here is why.
The DMA-attack class is older than the IOMMU. FireWire and OHCI 1394 SBP-2 spoofing made it concrete in the 2000s; Thunderbolt 1 (2011) and Thunderbolt 2 (2013) brought the same primitive back through a different connector [@wikipedia-dma-attack]; in February 2019, the Thunderclap NDSS paper by A. Theodore Markettos, Colin Rothwell, Brett F. Gutstein, Allison Pearce, Peter G. Neumann, Simon W. Moore, and Robert N. M. Watson demonstrated that *even with the IOMMU on*, OS-side mistakes in *what the table describes* let a malicious peripheral exfiltrate keys in seconds [@thunderclap-io]. The paper is the load-bearing academic primary for the entire genre.
The hardware unit that translates per-device DMA addresses to physical addresses, restricting a peripheral's DMA reach to assigned pages. On x86 it is Intel VT-d or AMD-Vi; on Arm it is the SMMU. Per Wikipedia: *"Memory is protected from malicious devices that are attempting DMA attacks and faulty devices that are attempting errant memory transfers because a device cannot read or write to memory that has not been explicitly allocated (mapped) for it"* [@wikipedia-iommu].
Microsoft's first software-side DMA defence appeared in the Windows 7 era as a registry-driven disablement of FireWire SBP-2 attaches when the screen was locked [@wikipedia-dma-attack]. It was a dead end. Thunderbolt brought the same primitive back through a different connector almost immediately, and the only durable answer was to enrol the IOMMU.
### DMAR: the Intel VT-d table
DMAR is the table whose body Windows reads to decide whether DMA remapping is even possible. The ACPICA reference header (`actbl1.h`) declares the signature and the conformance: *`#define ACPI_SIG_DMAR "DMAR" /* DMA Remapping table */`* and *"Conforms to 'Intel Virtualization Technology for Directed I/O', Version 2.3, October 2014"* [@acpica-actbl1].
The body is a sequence of typed sub-tables. The taxonomy from `actbl1.h`, with the byte values that identify each sub-table:
| Sub-table | Value | Purpose |
| --- | --- | --- |
| DRHD (Hardware Unit) | 0 | Describes a single VT-d remapping unit and the devices it covers |
| RMRR (Reserved Memory) | 1 | Identity-mapped memory windows for legitimate firmware-DMA needs |
| ATSR (Root ATS) | 2 | PCIe Address Translation Services support |
| RHSA (Hardware Affinity) | 3 | NUMA affinity for remapping units |
| ANDD (Namespace) | 4 | ACPI Namespace Device Descriptors |
| SATC | 5 | SoC Integrated Address Translation Cache |
| SIDP | 6 | SoC-Integrated Device Property Reporting |
The top-level Flags byte declares three platform-level properties: `ACPI_DMAR_INTR_REMAP` (bit 0, interrupt remapping support), `ACPI_DMAR_X2APIC_OPT_OUT` (bit 1), and `ACPI_DMAR_X2APIC_MODE` (bit 2) [@acpica-actbl1]. Microsoft's Windows-side opt-in piggy-backs onto the same Flags byte: bit 2 must be set, and the Microsoft OEM Kernel DMA Protection page calls it `DMA_CTRL_PLATFORM_OPT_IN_FLAG`, citing *Intel VT-d Spec Rev 2.5 Section 8.1* as the authoritative definition [@oem-kernel-dma]. Without that bit set, Memory Access Protection stays off even if VT-d hardware is fully functional.
### IORT: the Arm SMMU table
IORT does the same job for the Arm SMMU. The ACPICA header pins the conformance: *`#define ACPI_SIG_IORT "IORT"`* and *"Conforms to 'IO Remapping Table System Software on ARM Platforms', Document number: ARM DEN 0049E.f, Apr 2024"* [@acpica-actbl2-iort]. The node taxonomy, from the same header:
| Node type | Value | Role |
| --- | --- | --- |
| ITS_GROUP | 0x00 | GIC Interrupt Translation Service group |
| NAMED_COMPONENT | 0x01 | Non-PCI named device |
| PCI_ROOT_COMPLEX | 0x02 | PCIe root complex |
| SMMU | 0x03 | SMMUv1 / v2 |
| SMMU_V3 | 0x04 | SMMUv3 |
| PMCG | 0x05 | Performance Monitoring Counter Group |
| RMR | 0x06 | Reserved Memory Region (Arm analogue of x86 RMRR) |
| IWB | 0x07 | I/O Wakeup |
IORT folds two responsibilities together that x86 keeps separate: in addition to describing SMMU translation contexts, it carries the GIC ITS entries that govern interrupt remapping. (On x86, interrupt remapping lives in MADT, not DMAR.) Each PCI_ROOT_COMPLEX or NAMED_COMPONENT node carries an ID-mapping array of `(InputBase, IdCount, OutputBase, OutputReference)` tuples that translate PCIe Requester IDs to SMMU StreamIDs. The mapping arithmetic is the IOMMU. The table just tells the OS where the arithmetic lives.
### How Windows turns the table into policy
Kernel DMA Protection enrols when a small number of conditions all hold. Microsoft's documentation lays them out [@oem-kernel-dma; @kernel-dma-thunderbolt; @dma-remapping-drivers], and they form a textbook AND-gate.
flowchart TD
A[DMAR/IVRS/IORT present?] -->|No| OFF[Kernel DMA Protection: Off]
A -->|Yes| B[DMA_CTRL_PLATFORM_OPT_IN_FLAG set?]
B -->|No| OFF
B -->|Yes| C[VT-d/AMD-Vi/SMMU enabled in firmware setup?]
C -->|No| OFF
C -->|Yes| D{"Driver opt-in?"}
D -->|No, legacy device| OFF2[Device denied DMA, KDP partially enrolled]
D -->|Yes, RemappingSupported INF directive| ON[Kernel DMA Protection: On for this device]
The driver opt-in deserves a closer look, because it is where Thunderclap left its scar. The legacy mechanism was a per-driver `DmaRemappingCompatible` parameter; Windows 24H2 introduced a per-device `RemappingSupported` INF directive that supersedes it [@dma-remapping-drivers]. The modern intent is finer-grained: a single driver may legitimately ship across compatible and incompatible device variants, and the per-device declaration is the only safe granularity. Graphics is the canonical hold-out -- WDDM 3.0+ drivers can opt in, but earlier graphics stacks could not, and shipping graphics cards before WDDM 3.0 effectively blocked Kernel DMA Protection on whole platforms [@kernel-dma-thunderbolt].
When the AND-gate fails, Windows surfaces it as a single line in `msinfo32` System Summary: `Kernel DMA Protection: Off`. The remediation is rarely software. *"Reboot into UEFI settings, Turn on Intel Virtualization Technology, Turn on Intel Virtualization Technology for I/O (VT-d)"* is Microsoft's own checklist [@kernel-dma-thunderbolt]. If the table is missing entirely, the only fix is an OEM BIOS update.
### Three failure families, observable from inside Windows
Three observable failure families recur. *Missing DMAR / IVRS / IORT* surfaces as `Kernel DMA Protection: Off` and the only fix is a BIOS update [@kernel-dma-thunderbolt]. *Over-broad RMRR / RMR* was the Thunderclap finding: even with the IOMMU on, identity-mapped memory windows that legitimately exist for USB handoff or integrated graphics can overlap sensitive memory; a malicious peripheral assigned to the same context exfiltrates secrets while the IOMMU faithfully reports it as policy-compliant [@thunderclap-io]. *VT-d disabled in firmware setup* surfaces identically to a missing table; the remediation is a UEFI menu, not a Windows update.
{`
function kdpDecision({dmarPresent, optInFlagSet, iommuEnabled, driverRemappingCompatible}) {
if (!dmarPresent) return "KDP: Off (reason: DMAR/IVRS/IORT table missing -- BIOS update required)";
if (!optInFlagSet) return "KDP: Off (reason: DMA_CTRL_PLATFORM_OPT_IN_FLAG not set in DMAR Flags byte)";
if (!iommuEnabled) return "KDP: Off (reason: VT-d/AMD-Vi disabled in UEFI setup)";
if (!driverRemappingCompatible) return "KDP: Off for that device (reason: driver lacks RemappingSupported INF entry)";
return "KDP: On";
}
console.log("Secured-Core PC: ", kdpDecision({dmarPresent:true, optInFlagSet:true, iommuEnabled:true, driverRemappingCompatible:true}));
console.log("OEM omission: ", kdpDecision({dmarPresent:false, optInFlagSet:false, iommuEnabled:true, driverRemappingCompatible:true}));
console.log("VT-d disabled: ", kdpDecision({dmarPresent:true, optInFlagSet:true, iommuEnabled:false, driverRemappingCompatible:true}));
console.log("Driver not opted-in:", kdpDecision({dmarPresent:true, optInFlagSet:true, iommuEnabled:true, driverRemappingCompatible:false}));
`}
The Thunderclap residual is the article's first *aha* moment. The IOMMU is on. The hardware is working. The OS has read DMAR and turned on Kernel DMA Protection. And a malicious Thunderbolt device exfiltrates a TLS key in a few seconds, because the *table* described an RMRR that overlaps the victim driver's heap, or because the victim driver shared sensitive memory with a peripheral DMA window. The hardware was not the issue. The *table* was. From this point forward in the article, you should not ask *"is the IOMMU on?"* You should ask *"is the IOMMU on, and did the firmware describe the right thing?"*
> **Note:** DMAR (Intel), IVRS (AMD), and IORT (Arm) are mutually exclusive on a given platform. All three are first-class for Kernel DMA Protection; the OEM opt-in flag lives in a different field of each, and the Windows-side prerequisites are otherwise the same.
The IOMMU question was an above-the-board hardware boundary. The next question is below-the-board: System Management Mode, the privilege level above the kernel that the OS literally cannot inspect. Microsoft's response was to make the OEMs sign a pact about it. The pact is a 40-byte ACPI table (a 36-byte ACPI header plus a 4-byte ProtectionFlags field) called WSMT.
## 4. WSMT: Microsoft's Pact With OEMs About SMM
There is a CPU privilege level above the kernel. Windows cannot see what runs there. So Microsoft made the OEMs sign a pact about it.
An x86 CPU mode entered via System Management Interrupt (SMI). SMM code runs in SMRAM, a region of physical memory the OS cannot map or read. SMI handlers run with full physical-memory access and can read, write, and modify any kernel structure. SMM is sometimes called *ring -2* because it sits architecturally below Hyper-V's *ring -1*. The Intel 386SL was the first chip to implement it; every modern x86 CPU does [@wikipedia-smm].
A class of attack where a less-privileged caller induces a more-privileged subject to perform an unintended action by passing in attacker-controlled inputs the subject does not validate. In the SMM case, an unprivileged kernel-mode caller hands an SMI handler a pointer to memory the kernel controls; the SMI handler dereferences it without checking whether the target lives inside SMRAM, and the attacker has just bought a write into ring -2.
The attack class is older than the table. UEFI rootkits like LoJax (September 2018), attributed to Sednit / APT28 by ESET, weaponised SMM-adjacent persistence: *"This persistence method is particularly invasive as it will not only survive an OS reinstall, but also a hard disk replacement"* [@eset-lojax-html]. The 2015 Hacking Team breach published an entire UEFI rootkit module along with the code-signing certificate that Eclypsium would later reuse in 2021 [@mitre-attack-s0047].The Hacking Team certificate that drove the 2021 Eclypsium WPBT proof-of-concept was the same one shipped with the 2015 Hacking Team UEFI module. A revoked code-signing cert from one breach became the unlock for an unrelated table six years later, because the WPBT signature gate did not check revocation. A software-only OS-side fix to the SMI-handler-pointer-validation problem is impossible by construction: Windows cannot inspect SMM code, and SMRAM is not addressable to it.
So Microsoft did the only thing that was tractable. On April 18, 2016, version 1.0 of the Windows SMM Security Mitigations Table specification was published [@acpica-actbl3-wsmt]. The body is one 32-bit field. ACPICA codifies it:
```c
typedef struct acpi_table_wsmt {
ACPI_TABLE_HEADER Header;
UINT32 ProtectionFlags;
} ACPI_TABLE_WSMT;
#define ACPI_WSMT_FIXED_COMM_BUFFERS (1)
#define ACPI_WSMT_COMM_BUFFER_NESTED_PTR_PROTECTION (2)
#define ACPI_WSMT_SYSTEM_RESOURCE_PROTECTION (4)
```
Three bits. Each bit is a warranty by the OEM that their SMI handlers behave correctly in one specific way. Microsoft's published semantics, paraphrased lightly so the bits read as English [@ms-oem-uefi-wsmt]:
| Flag | Bit | What the OEM warrants |
| --- | --- | --- |
| `FIXED_COMM_BUFFERS` | 0x1 | All SMI communication buffers live in firmware-allocated memory of fixed location and size; SMM never reads or writes outside those buffers |
| `COMM_BUFFER_NESTED_PTR_PROTECTION` | 0x2 | Pointers nested inside those buffers are validated against the same allowed regions before SMM dereferences them (the confused-deputy fix) |
| `SYSTEM_RESOURCE_PROTECTION` | 0x4 | Critical platform resources (CPU MSRs, chipset registers) are guarded from unintended SMM modification by lower-privilege callers |
When does Windows read this table? *"Supported versions of the Windows operating system read in the Windows SMM Security Table early during initialization, prior to start of the ACPI interpreter"* [@ms-wsmt-fixed-combuffer]. *Prior to start of the ACPI interpreter* is the load-bearing phrase. Windows has not yet booted the hypervisor when it consumes WSMT; it has not yet decided whether to launch VBS. The table is read first; the decision follows.
sequenceDiagram
participant FW as OEM Firmware (build time)
participant POST as POST / DXE
participant BL as Windows Boot Manager
participant WBL as Winload.efi
participant HV as Hyper-V
participant VBS as VBS / Secure Kernel
FW->>POST: Build WSMT with ProtectionFlags
POST->>BL: Hand off ACPI table set via EFI system table
BL->>WBL: Load winload.efi
WBL->>WBL: Read WSMT prior to ACPI interpreter start
alt Flags == 0x7 (all three asserted)
WBL->>HV: Launch hypervisor
HV->>VBS: Start Secure Kernel, enrol Credential Guard / HVCI
else Flags partial or missing
WBL->>WBL: De-feature: VBS may not start, HVCI may stay disabled
end
The OEM-VBS page makes WSMT a hard prerequisite, not a nice-to-have: *"Firmware support for SMM protection -- System firmware must adhere to the recommendations for hardening SMM code described in the Windows SMM Security Mitigations Table (WMST) specification . . . Firmware must implement the protections described in the WSMT specification, and set the corresponding protection flags as described in the specification to report compliance with these requirements to the operating system"* [@oem-vbs]. If the flags are clear, VBS may de-feature. Memory Integrity may not enable. Credential Guard may refuse to start. The customer never sees a banner; they see the absence of a feature.
> **Note:** Microsoft's OEM page on Virtualization-based security makes WSMT compliance with the corresponding Protection Flags asserted a hard prerequisite for VBS launch [@oem-vbs]. A laptop without WSMT, or with the flags clear, may report that VBS is *available* and yet refuse to start it on every boot.
The structural punchline lands here, in Microsoft's own words:
"Because SMM is opaque to the operating system, it is not possible to produce a test which runs in Windows to verify that the protections prescribed in the WSMT specification are actually implemented in SMM. From the operating system, the only check that is possible is to look for the presence of the WSMT, and check the state of all defined Protection Flags." -- Microsoft Learn, *Windows SMM Security Mitigations Table* [@ms-oem-uefi-wsmt]
This is the article's second *aha* moment. *Windows reads the flags. Windows trusts the flags. Windows cannot verify the flags.* The OEM declares; Windows reads; Windows cannot refute. Once you internalise that idiom, every other ACPI security table in this article reads as a variation on it. SDEV declares which devices are secure. WPBT declares which binary is signed. DMAR declares which RMRR ranges are legitimate. In every case, the OEM authors a property and Windows believes it.
A worked example makes the consequence concrete. Open a PowerShell prompt and run `Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard`. The two fields that matter are `VirtualizationBasedSecurityStatus` (0 = off, 1 = enabled but not running, 2 = running) and `SecurityServicesRunning` (an array, where 1 = Credential Guard and 2 = HVCI). On a machine where WSMT is missing or its flags are clear, you may see `VirtualizationBasedSecurityStatus = 1` and an empty `SecurityServicesRunning` array. The system *intends* to run VBS. The system *cannot* run VBS. The cause is invisible until you consult the DeviceGuard WMI class -- and even then, the WSMT influence is implicit, not named.
WSMT tells the hypervisor what SMM promised not to do. The next table tells the hypervisor which devices to wall off from non-secure code in the first place. Its name is SDEV.
## 5. SDEV: The Firmware Tells the Hypervisor Which Devices Are For Trustlets Only
Your fingerprint reader is supposed to be unreachable from a kernel-mode rootkit. How does Windows know it is the fingerprint reader the firmware claims it is, and not, say, a USB device the attacker plugged in five seconds ago?
The answer is SDEV. The ACPI 6.5 specification, Section 5.2.27, is unusually candid about what the table is and is not [@acpi-65-sdev]:
> "The Secure DEVices (SDEV) table is a list of secure devices known to the system. The table is applicable to systems where a secure OS partition and a non-secure OS partition co-exist. A secure device is a device that is protected by the secure OS, preventing accesses from non-secure OS. The table provides a hint as to which devices should be protected by the secure OS. The enforcement of the table is provided by the secure OS and any pre-boot environment preceding it. **The table itself does not provide any security guarantees.**"
"The table itself does not provide any security guarantees." -- ACPI Specification 6.5, Section 5.2.27 [@acpi-65-sdev]
An ACPI table introduced in ACPI 6.2 (May 2017) that enumerates the devices the firmware believes should be partitioned into the Secure Kernel rather than the normal kernel. The Windows-side consumer struct is `_SDEV_SECURE_ACPI_INFO_ENTRY`, available since Windows 10 version 2004 (May 2020) [@ms-sdev-struct].
### The three states a device can be in
The spec defines three SDEV states, and they map directly onto what the Secure Kernel does at boot [@acpi-65-sdev]:
| SDEV state | Spec language | Operational consequence |
| --- | --- | --- |
| Listed, Allow-Handoff clear | *"the device should be always protected within the secure OS . . . the secure OS may require that a device used for user authentication must be protected to guard against tampering by malicious software"* | Device is owned by VTL1 for the lifetime of the boot; the normal kernel cannot reach it |
| Listed, Allow-Handoff set | *"the device should be initially protected by the secure OS, but it is up to the discretion of the secure OS to allow the device to be handed off to the non-secure OS when requested"* | Secure Kernel takes ownership at boot but may release the device to VTL0 on demand |
| Not listed | *"no hints are provided. Any OS component that expected the device to be in secure mode would not correctly function"* | Features that need a secure-device anchor (Enhanced Sign-in Security for Windows Hello, the vTPM trustlet) silently disable |
The two SDEV entry types are, from ACPICA's `actbl2.h`: *`ACPI_SDEV_TYPE_NAMESPACE_DEVICE = 0`* (an ACPI Namespace device path like `\_SB.PCI0.XHCI`) and *`ACPI_SDEV_TYPE_PCIE_ENDPOINT_DEVICE = 1`* (a PCIe Bus / Device / Function tuple). The header Flags byte uses two bits: `ACPI_SDEV_HANDOFF_TO_UNSECURE_OS` (bit 0) and `ACPI_SDEV_SECURE_COMPONENTS_PRESENT` (bit 1) [@acpica-actbl2-sdev]. The *Allow-Handoff* bit is the one that decides which of the three states above applies.
The Windows-side struct is published on Microsoft Learn as `_SDEV_SECURE_ACPI_INFO_ENTRY` [@ms-sdev-struct]:
```c
typedef struct _SDEV_SECURE_ACPI_INFO_ENTRY {
SDEV_ENTRY_HEADER Header;
USHORT IdentifierOffset;
USHORT IdentifierLength;
USHORT VendorInfoOffset;
USHORT VendorInfoLength;
USHORT SecureResourcesOffset;
USHORT SecureResourcesLength;
} SDEV_SECURE_ACPI_INFO_ENTRY;
```
The Windows-side consumer struct lists *"Minimum supported client: Windows 10, version 2004"* [@ms-sdev-struct]. That is May 2020, three years after SDEV was introduced in ACPI 6.2 (May 2017). ACPI tables routinely outlive the OS consumers that read them by years; the table set is a bus, and consumers attach to it on their own schedule.
### How SDEV becomes trustlet ownership
The Secure Kernel does not consume SDEV directly to start a [trustlet](https://paragmali.com/blog/vbs-trustlets-what-actually-runs-in-the-secure-kernel/). SDEV is the *hint*; the binding to a specific trustlet is encoded in Windows policy and OEM driver INFs. The companion article on VBS trustlets walks the trustlet IDs in detail [@vbs-trustlets-sibling]; the routing is implicit.
flowchart TD
A[Firmware lists device in SDEV] --> B{Allow-Handoff bit set?}
B -->|Clear -- always secure| C[Trustlet-aware driver present?]
B -->|Set -- handoff allowed| D[Trustlet-aware driver present?]
C -->|Yes| E[Device owned by VTL1 trustlet -- BioIso / LsaIso / vmsp]
C -->|No| F[Device unusable -- ESS feature silently disabled]
D -->|Yes| G[Trustlet may release device to VTL0 on request]
D -->|No| H[Device falls back to VTL0 ownership]
A2[Device not in SDEV] --> I[No trustlet ownership; ESS, vTPM disabled]
### Where SDEV becomes a Secured-core PC certification gate
The current OEM Standards for highly secure Windows 11 devices page makes SDEV authoring an explicit certification gate when the platform claims Windows Hello with Enhanced Sign-in Security: *"A device with Windows Hello with ESS is enabled if it has the ESS hardware built-in components for face or fingerprint authentication, and the necessary support in BIOS"* [@oem-highly-secure-11]. The SDEV listing of the biometric device is, in practice, what *"the necessary support in BIOS"* cashes out to. Without it, the hardware exists, the driver loads, the user's face is captured -- and the secure pipeline never engages, because the Secure Kernel was never told the camera was its responsibility.
Three observable failure families recur. *Device not listed* surfaces as Enhanced Sign-in Security silently disabling; the user sees *"Windows Hello requires additional setup"* and never reaches the secure path. *Listed but driver-incompatible* triggers the Allow-Handoff fallback and the device is owned by the normal kernel, exactly the outcome SDEV was meant to prevent. *Adversarially listed* is the worst case: an attacker with a DXE foothold (the firmware-stage class that LogoFAIL [@nvd-cve-2023-40238] and BIOSDisconnect typify) writes a malicious SDEV entry into ACPI memory and routes a device the attacker controls into the Secure Kernel partition. That last case is what the ACPI 6.5 spec means when it says *"the table itself does not provide any security guarantees."* The Secure Kernel enforces the partition; the table only suggests where the partition should fall.
The article's third recurring failure family is now visible in three of the five tables: *missing*, *malformed*, *forged*. SDEV decides which devices the firmware says are secure. The next table -- WPBT -- decides which *binaries* the firmware says Windows should run. That is the dial that, when broken, turned everything-protections-on Secured-Core PCs into rootkit hosts.
## 6. WPBT: The OEM Rootkit That Microsoft Designed In On Purpose
In 2012 Microsoft shipped a feature that lets the firmware drop a binary into `c:\windows\system32` and run it at SYSTEM on every boot [@eclypsium-wpbt]. The reason was customer experience. The result was a designed-in rootkit channel.
A fixed-layout ACPI table whose body is a physical pointer to a binary stored in firmware memory. At every boot, the Windows session manager reads the pointer, copies the binary into `c:\windows\system32`, validates its Authenticode signature, and executes it with SYSTEM privileges before the user reaches the lock screen. ACPICA's reference header pins the conformance to *"Windows Platform Binary Table (WPBT) 29 November 2011"* [@acpica-actbl3-wpbt].
The Microsoft specification, preserved verbatim by Eclypsium, describes the mechanism without flinching: *"The WPBT is a fixed Advanced Configuration and Power Interface (ACPI) table that enables boot firmware to provide Windows with a platform binary that the operating system can execute. The binary handoff medium is physical memory, allowing the boot firmware to provide the platform binary without modifying the Windows image on disk"* [@eclypsium-wpbt]. The ACPICA struct is small enough to read in one breath:
```c
typedef struct acpi_table_wpbt {
ACPI_TABLE_HEADER Header;
UINT32 HandoffSize;
UINT64 HandoffAddress; /* physical pointer to the binary */
UINT8 Layout;
UINT8 Type;
UINT16 ArgumentsLength;
} ACPI_TABLE_WPBT;
```
The single load-bearing field is `HandoffAddress`: a 64-bit physical pointer to the binary. The signing requirement, again preserved verbatim by Eclypsium [@eclypsium-wpbt]:
> "All binaries published to Windows using the WPBT mechanism outlined in this paper must be embedded signed and timestamped. These images should be linked with the /INTEGRITYCHECK option and signed using the SignTool command-line tool with the /nph switch to suppress page hashes."
Why did Microsoft ship this? OEM customer-experience continuity across clean reinstalls. A customer who runs Windows Setup from USB and wipes their machine reasonably expects everything they paid for to come back: vendor utilities, enterprise enrolment shims, anti-theft agents. WPBT was Microsoft's answer to *"how does the OEM persist its software across an OS-level reinstall?"* The answer Microsoft chose was: by handing the firmware a sanctioned channel to inject a SYSTEM-level binary into every boot. Eclypsium's own coverage records that *"acclaimed researcher and co-author of Windows Internals, Alex Ionescu, has been calling out the dangers of WPBT as a rootkit as early as 2012 and continues to do so today"* [@eclypsium-wpbt].
sequenceDiagram
participant FW as OEM Firmware
participant ACPI as ACPI table set
participant SMSS as Session Manager (smss.exe)
participant CI as Code Integrity
participant EXE as wpbbin.exe (SYSTEM)
FW->>ACPI: Build WPBT, set HandoffAddress to in-memory binary
ACPI->>SMSS: Session manager reads WPBT during early boot
SMSS->>SMSS: Copy binary from physical memory into system32
SMSS->>CI: Validate Authenticode signature
CI-->>SMSS: Accept (until 2021: even revoked certs accepted)
SMSS->>EXE: Launch as SYSTEM, before lock screen
### A history of WPBT abuse, in three acts
The WPBT abuse history predates the table itself. The mechanism existed informally as a BIOS Option ROM trick before it was standardised; once standardised, the abuse cases scaled [@securelist-computrace].
| Year | Incident | Channel | What was broken |
| --- | --- | --- | --- |
| 2008-2014 | Computrace / Absolute LoJack | BIOS Option ROM dropper (pre-WPBT) | Vendor-installed anti-theft agent persisted across reinstalls; C&C protocol enabled hijacking |
| 2015 | Lenovo Service Engine (LSE) | Formal WPBT (Windows 8 era) | Buffer overflow allowed remote code execution via vendor-installed binary |
| 2018 | LoJax (APT28 / Sednit) | UEFI rootkit reusing Computrace's persistence design | First in-the-wild UEFI rootkit; survived OS reinstall and disk replacement |
| 2021 | Eclypsium "Everyone Gets a Rootkit" | Formal WPBT signature gate | Signature check accepted revoked certificates; Secured-Core PCs vulnerable |
Computrace, analysed by Vitaly Kamluk and Sergey Belov in February 2014, was the legitimate ancestor. Their post documented an Absolute Software anti-theft agent that survived clean Windows reinstalls because the firmware re-injected `rpcnetp.exe` at every boot via a WPBT-class mechanism that predated WPBT itself: *"the owner of the system claimed he had never installed Absolute Computrace and didn't even know the software was present on his computer"* [@securelist-computrace]. The reverse-engineering revealed a Russian-doll structure -- *"`rpcnetp.exe` inside `autochk.exe` inside EFI Application inside another EFI-Application inside ROM Module"* [@securelist-computrace] -- and a C&C protocol weak enough that the researchers built proof-of-concept hijacking. WPBT-class persistence existed as attack surface before WPBT was a table.
LSE was the first formal-WPBT abuse. CISA's August 12, 2015 alert framed it tersely: *"Certain Lenovo personal computers contain a vulnerability in LSE (a Lenovo BIOS feature). Exploitation of this vulnerability may allow a remote attacker to take control of an affected system"* [@cisa-lse]. The NVD entry pinned the weakness class: *"A buffer overflow vulnerability was reported, (fixed and publicly disclosed in 2015) in the Lenovo Service Engine (LSE), affecting various versions of BIOS for Lenovo Notebooks, that could allow a remote user to execute arbitrary code on the system"* [@nvd-cve-2015-5684]. LSE injected `wpbbin.exe` into `system32`, downloaded a separate utility called *OneKey Optimizer*, and overwrote `autochk.exe` to maintain persistence. The only reliable fix was an OEM BIOS update.
LoJax came in September 2018. ESET's white paper documented the first in-the-wild UEFI rootkit, attributed to the Sednit / APT28 group: *"This persistence method is particularly invasive as it will not only survive an OS reinstall, but also a hard disk replacement"* [@eset-lojax-html]. The persistence design was directly inspired by Computrace's LoJack; ESET noted that *"In May 2018, an Arbor Networks blog post described several trojanized samples of Absolute Software's LoJack small agent, rpcnetp.exe"* [@eset-lojax-html]. A 2008-vintage anti-theft mechanism became the template for state-actor espionage.
### The 2021 Eclypsium disclosure: "Everyone Gets a Rootkit"
In September 2021, the Eclypsium research team published the structural finding that reframed WPBT from *"controversial OEM convenience"* to *"structurally broken signature gate"*. The post was institutionally authored by *"the Eclypsium research team"* with no by-line in the rendered article body; this article preserves that institutional attribution. The finding [@eclypsium-wpbt]:
"While Microsoft requires a WPBT binary to be signed, it will accept an expired or revoked certificate. This means an attacker can sign a malicious binary with any readily available expired certificate. This issue affects all Windows-based devices going back to Windows 8 when WPBT was first introduced. We have successfully demonstrated the attack on modern, Secured-Core PCs that are running the latest boot protections." -- Eclypsium, *Everyone Gets a Rootkit* (September 2021) [@eclypsium-wpbt]
The proof-of-concept was elegant in the worst way. The researchers signed a malicious binary with a Hacking Team code-signing certificate that had been revoked in 2015 (a side effect of the 2015 Hacking Team breach). They placed it in firmware memory. They wrote a WPBT entry pointing at it. On a Secured-Core PC with Credential Guard, HVCI, BitLocker, and Kernel DMA Protection all enabled, Windows ran the binary at SYSTEM before the user reached the lock screen. The signature gate was the only thing standing between the firmware and arbitrary kernel-grade code. The signature gate accepted revoked certificates.
Microsoft's response was not to fix the validator [@eclypsium-wpbt]:
> "Microsoft recommends customers use Windows Defender Application Control (WDAC) to limit what is allowed to run on their devices. WDAC policy is also enforced for binaries included in the WPBT and should mitigate this issue. We recommend customers implement a WDAC policy that is as restrictive as practical for their environment."
That is an explicit acknowledgement that the original signing-only model was structurally inadequate; the fix was outsourced to a customer-authored allow-list. WDAC is the [App Identity](https://paragmali.com/blog/who-is-this-code----the-quiet-33-year-reinvention-of-app-ide/) sibling article's territory [@app-identity-sibling]; for the present article, the relevant fact is that the only mitigation Microsoft recommended did not change Microsoft's code. It changed the customer's policy.
> **Key idea:** WPBT is a designed-in OEM persistence channel that, until 2021, allowed any binary signed with any code-signing certificate -- including certificates revoked years earlier -- to execute at SYSTEM on every boot of every Windows-since-8 machine, including the most heavily protected Secured-Core PCs. The fix was not a patch to the validator. The fix was to ask customers to author Windows Defender Application Control policies that constrain what WPBT may run.
The mitigation paths a defender can take today, in order of how supported they are:
| Path | Status | What it does |
| --- | --- | --- |
| WDAC policy over WPBT | Microsoft-recommended | Constrains which binaries WPBT may execute, regardless of signing-cert status |
| BIOS option to disable WPBT | OEM-dependent | A few enterprise-class OEMs offer it; most do not |
| `dropWPBT` (community tool) | Unsupported | Removes the WPBT entry from in-memory ACPI before Windows reads it |
| Cert-revocation enforcement | Unimplemented | Microsoft has not changed the WPBT validator to honour revocation |
> **Note:** Microsoft does not document a supported way to disable WPBT consumption from inside Windows. The community `dropWPBT` project is unsupported. Any defender who wants to neutralise WPBT must rely on either an OEM BIOS toggle (where offered) or a WDAC policy that constrains the binaries WPBT may execute.
We have walked five tables: DMAR, IORT, WSMT, SDEV, WPBT. Three failure families recur in each: omission, mistake, forgery. Time to make the threat model honest.
## 7. Forged, Missing, and Lying Tables: An Honest Threat Model
We have seen the tables. We have seen one of them break catastrophically. Now name the failure families honestly, because each has a different attacker, a different fix, and a different observable signal.
flowchart TD
A[Failure mode] --> B[OEM omission]
A --> C[OEM mistake]
A --> D[Adversarial forgery]
B --> B1[Cause: table absent or flag clear]
B1 --> B2[Observable: msinfo32 / Win32_DeviceGuard]
B2 --> B3[Fix: OEM BIOS update]
C --> C1[Cause: table present but lying about behaviour]
C1 --> C2[Observable: none from inside Windows]
C2 --> C3[Fix: certification, external research, OEM BIOS update]
D --> D1[Cause: attacker with DXE foothold rewrites table]
D1 --> D2[Observable: requires measured ACPI to detect]
D2 --> D3[Fix: WDAC over WPBT, Pluton-rooted attestation -- partial]
### OEM omission: the most common failure
The most common case is the simplest. Kernel DMA Protection silently shows `Off` because the OEM's DMAR is missing or because the `DMA_CTRL_PLATFORM_OPT_IN_FLAG` is clear in the Flags byte [@oem-kernel-dma]. Windows Hello with Enhanced Sign-in Security silently disables because the fingerprint reader was never listed in SDEV [@oem-highly-secure-11]. VBS de-features because WSMT is missing or its three Protection Flags are partially clear [@ms-oem-uefi-wsmt]. The defender's observable surface is `msinfo32`, the `Win32_DeviceGuard` WMI class, and the System Summary pane; the fix in every case is an OEM BIOS update, on the OEM's release schedule, with whatever distribution latency that involves.
### OEM mistake: present but lying
The second case is the worst-case from a detection standpoint, because it is unobservable from inside Windows. WSMT may report all three Protection Flags asserted on a platform whose SMI handlers were never actually rewritten to validate nested pointers. SDEV may list a device whose driver was never hardened to enforce its trustlet ownership. DMAR may declare a tight policy for a chipset whose VT-d implementation has a documented errata that defeats it. Microsoft itself states the impossibility result for WSMT in the public Learn prose [@ms-oem-uefi-wsmt]. The only mechanisms that catch this class are (a) certification programs that audit the firmware before it ships (Windows Hardware Lab Kit, Secured-core PC requirements [@oem-highly-secure-11]) and (b) external research, after the fact. The fix is, again, an OEM BIOS update.
### Adversarial forgery: an attacker with a DXE foothold
The third case is the most consequential. An attacker with a foothold in the firmware boot environment -- the DXE class typified by LogoFAIL (CVE-2023-40238, the Insyde BMP decoder memory-corruption Binarly published at Black Hat Europe 2023 [@nvd-cve-2023-40238]) -- writes a new WPBT entry, or a new SDEV entry, or a different DMAR Flags value into ACPI memory before Windows reads it. The Eclypsium 2021 demonstration showed that this works against Secured-Core PCs in 2021 [@eclypsium-wpbt]. The defender's observable surface is, by construction, none unless the firmware measured the relevant tables into a TPM PCR and the hypervisor consumes that measurement. The fix is partial today: WDAC over WPBT for the binary-execution case, Pluton-rooted attestation for the table-content-drift case, and OEM BIOS hardening for everything else.
> **Note:** LogoFAIL is the cleanest example of why forgery is the hardest failure family. It is a pre-OS UEFI image-parser remote code execution in DXE, the firmware execution environment that *builds* the ACPI tables in the first place [@nvd-cve-2023-40238]. If you can patch DXE, you can patch the tables before Windows reads them. The five tables we have walked sit *below* Secure Boot's verifier; LogoFAIL sits *below* the five tables. Cross-link the Secure Boot sibling article for the full chain [@secure-boot-sibling].
### Pluton's honest residual
Pluton-rooted attestation closes some, but not all, of the forgery gap. The TCG PC Client Platform Firmware Profile specifies how firmware events are extended into TPM Platform Configuration Registers; Microsoft requires platform firmware to extend a specific event into PCR[7] when DMA protection is disabled or downgraded: *"On every boot where the IOMMU (VT-D or AMD-Vi) or Kernel DMA Protection are disabled, will be disabled, or configured to a lower security state, the platform MUST extend an EV_EFI_ACTION event into PCR[7] before enabling DMA. The event string SHALL be 'DMA Protection Disabled'"* [@oem-kernel-dma]. That is the only narrowly-specified flow in this article that lets a remote verifier learn -- via TPM quote -- that the table set was downgraded between firmware build and OS boot.
It is also a single example. The general case -- *"every security-bearing ACPI table was measured into a known PCR at firmware load, and the hypervisor refuses to launch trustlets if the measurement does not match a known-good baseline"* -- is not a deployed mechanism on Windows today. Pluton-as-TPM is a precondition; the measurement schema is the missing piece [@ms-pluton; @pluton-sibling].
> **Key idea:** Pluton-rooted measured boot closes the *freshness gap* (the table did not change between firmware build and OS parse). It does not close the *contents-correctness gap* (the table contents were correct at firmware build in the first place). A WSMT with all three flags asserted by an OEM that did not actually harden their SMM handlers will measure the same way every boot, and the Pluton-rooted attestation will faithfully report it as valid. The contents-correctness problem requires either out-of-band certification (Secured-core PC) or a fundamentally different architecture (a vendor-controlled hardware-software stack, as on Apple's Secure Enclave-equipped silicon) -- not measured boot.
The window in which an attacker may modify an ACPI table after the firmware authored it but before the operating system reads it. Pluton-rooted measured boot detects modifications in this window because the PCR measurement at boot will not match the known-good baseline.
The class of failures in which the table contents were *incorrect at firmware build* -- the OEM declared properties that do not hold, or the firmware authored a wide RMRR that overlaps sensitive memory, or the WSMT flags overstate the SMM hardening that actually shipped. Measured boot cannot detect this class because the measurement matches the baseline; the baseline itself is wrong.
The freshness gap and the contents-correctness gap are independent failure modes, and they need independent mechanisms. Pluton solves the first. Nothing in the deployed Windows-on-OEM-firmware model solves the second; out-of-band certification (Secured-core PC) is the closest approximation, and it works only for the sample of devices Microsoft tests pre-ship.
We can name the failures. So who is responsible for fixing each one? That is the lifecycle question.
## 8. The Lifecycle Question: Who Populates, Who Validates, Who Owns the Bug
The OS reads the tables. It does not write them. So who does, and who checks the writer's work?
### Population
SDEV, WSMT, and WPBT entries are constructed by the OEM's UEFI BIOS team, sometimes via platform-controller-side helpers (Intel ME, AMD PSP) when secure-resource enumeration crosses platform-controller boundaries. DMAR is mostly built by the reference Independent BIOS Vendor code that ships with Intel and AMD reference designs (American Megatrends, Insyde, Phoenix -- the three IBVs listed in the public UEFI Forum membership directory [@uefi-forum-members]) and customised by the OEM. IORT is filled in by the System-on-Chip vendor's reference firmware on Arm (Qualcomm, Ampere, NVIDIA on Grace-class platforms). The table set is *assembled at firmware build time*, not at boot. Once Windows is running, the tables are read-only; the only way to change them is to re-flash the firmware.
### Validation, pre-ship
Pre-ship validation runs through the Windows Hardware Lab Kit and the Microsoft Hardware Compatibility Program. Secured-Core PC certification raises the bar de facto. Per the OEM Standards for highly secure Windows 11 devices page, Secured-Core requires Secure Boot enabled with the third-party UEFI CA not trusted by default; TPM 2.0 meeting the latest TCG requirements; *"the device supports Memory Access Protection (Kernel DMA Protection)"* (i.e., DMAR / IVRS / IORT correctly authored); *"System Guard Secure Launch (D-RTM) with System Management Mode (SMM) isolation"* OR *"S-RTM and Standalone MM with MM supervisor (the approach implemented on FASR devices)"*; HVCI enabled; Windows Hello with Enhanced Sign-in Security (i.e., SDEV authored); and BitLocker [@oem-highly-secure-11]. WSMT-flags-asserted is checked transitively via the SMM-isolation requirement.
flowchart LR
subgraph OEM
P1[Build DMAR / IORT / WSMT / SDEV / WPBT at firmware build time]
P2[Re-author on each BIOS update]
end
subgraph Microsoft
V1[WHQL / HLK pre-ship validation]
V2[Secured-Core PC certification]
V3[Post-ship: ad-hoc research only]
end
subgraph Customer
C1[Run msinfo32, Win32_DeviceGuard, Get-MpComputerStatus]
C2[Author WDAC policy that constrains WPBT-injected binaries]
C3[Apply OEM BIOS updates -- only path for table-content fixes]
end
P1 --> V1
V1 --> V2
V2 --> C1
P2 --> C3
V3 -.-> C2
### Validation, post-ship
There is almost none, except via the WHQL driver flow and ad-hoc Microsoft research after a public disclosure. The 2021 Eclypsium WPBT-cert-validation finding triggered a Microsoft re-examination, and the response was a customer-side WDAC mitigation rather than an OS-side validator change [@eclypsium-wpbt]. The servicing-velocity problem is structural: ACPI table content cannot be patched by Windows Update; it requires a UEFI BIOS update from the OEM. The 2015 Lenovo Service Engine incident required Lenovo BIOS updates [@cisa-lse; @nvd-cve-2015-5684]; the Eclypsium finding could not wait for a comparable industry-wide BIOS-update wave, so Microsoft chose the WDAC path.
### Servicing
OEM BIOS update is the only path for table-content fixes. OS-side WDAC is the only path for binary-execution constraints over WPBT. Pluton-rooted attestation is the only path for drift detection between firmware build and OS boot. The three are layered, not redundant: a defender who cares about the WPBT class needs all three.
### The four open problems
The four open problems are not implementation details. They are structural negative spaces where no shipping mechanism today fills the gap.
*First, there is no industry-standard attestable claim that an OEM has actually implemented the SMM mitigations they declared in WSMT.* The obvious direction is a Pluton-attested SMM-mitigation manifest: a hardware-rooted statement that the firmware that built the WSMT also includes the SMI-handler implementations that justify the flags. Not standardised today. The current WSMT flags are a free-text declaration the OEM may make for any reason; the only check is presence.
*Second, SDEV does not name which trustlet a device should be routed to.* The binding between an SDEV-listed device and the consuming trustlet (BioIso, LsaIso, vmsp) is encoded implicitly in Windows policy and OEM driver INFs. There is no extensibility story for future trustlets, and no way for a third-party trustlet to declare which SDEV entries it expects to consume. If Microsoft ships a new trustlet for Wi-Fi credentials in five years, SDEV cannot describe the binding without a spec revision.
*Third, WPBT signing trust roots are not declared in the table.* The implicit assumption was that any Authenticode-trusted certificate would do. The Eclypsium 2021 disclosure broke that assumption [@eclypsium-wpbt]. WDAC is the workaround; a fix would require WPBT to declare a narrower trust root the firmware vouches for, and the OS to enforce only that root. Such a change has not shipped.
*Fourth, forged-table detection from the Secure Kernel is partial.* Not all five security tables are measured into well-defined PCRs. The only narrowly-specified flow is the PCR[7] EV_EFI_ACTION *"DMA Protection Disabled"* event Microsoft requires when DMA protection is downgraded [@oem-kernel-dma]. A unified *"measured ACPI"* PCR -- e.g., PCR[5] extended with the hash of every security-bearing table at firmware load, paired with hypervisor-side enforcement that refuses to launch trustlets if the measurement does not match a known-good baseline -- is the obvious direction. It is not deployed.
> **Key idea:** The four open problems are: (1) no attestable claim that WSMT-declared SMM mitigations are actually implemented; (2) SDEV does not name the consuming trustlet; (3) WPBT signing trust roots are not declared in the table; (4) forged-table detection from VTL1 is partial. None of these is solved in shipping Windows in 2026. This is the live frontier of the firmware-OS contract.
Knowing the failure families and the lifecycle, what should you actually do on Monday morning? That is the practical guide.
## 9. Practical Guide: Inventory, Procurement, Defence
You are now equipped to read these tables on your own laptop and to argue procurement criteria with a vendor. Here is the operational toolkit.
### Inventory commands
The fastest way to find out what is actually enabled on a Windows machine is a short PowerShell session followed by an optional Linux-side dump for the table contents themselves.
| Command | What it tells you |
| --- | --- |
| `Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard` | VBS / HVCI / Credential Guard state; the implicit witness for whether WSMT influence allowed VBS to start |
| `msinfo32` (System Summary pane) | Kernel DMA Protection (DMAR / IVRS / IORT influence), Secure Boot State, Memory Integrity, Virtualization-based security state |
| `Get-PnpDevice -PresentOnly | Where-Object \{ $_.Class -eq "Biometric" \}` | Lists biometric devices; cross-check against Enhanced Sign-in Security state to infer SDEV listing |
| `Get-MpComputerStatus` | Defender state including AMSI providers, useful for cross-checking the WDAC-over-WPBT mitigation |
| Linux: `sudo acpidump -b -o tables.acpi && acpixtract -a tables.acpi && iasl -d *.dat` | Dumps and disassembles the ACPI table set; you can read SDEV / WSMT / WPBT / DMAR / IORT in human form |
A worked example brings the flags to life. Suppose you dump the tables on a Surface-class laptop. SDEV will list `\_SB.PCI0.GFX0.IRCM` (the integrated infrared camera used by Windows Hello) with the Allow-Handoff bit clear -- the camera is owned by the Secure Kernel for the lifetime of the boot. WSMT will show `ProtectionFlags = 7` (all three bits set: `FIXED_COMM_BUFFERS | COMM_BUFFER_NESTED_PTR_PROTECTION | SYSTEM_RESOURCE_PROTECTION`). DMAR will show DRHD entries for each VT-d remapping unit and the Flags byte will have bit 2 (`DMA_CTRL_PLATFORM_OPT_IN_FLAG`) set. WPBT may or may not be present; if present, you can extract `HandoffSize` and the binary itself, and pass the binary to `signtool verify /pa /v` to read its Authenticode chain.
```
PS> $g = Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard
PS> "VBS status: $($g.VirtualizationBasedSecurityStatus); services running: $($g.SecurityServicesRunning -join ',')"
```
`VirtualizationBasedSecurityStatus`: 0 = off, 1 = enabled but not running, 2 = running. `SecurityServicesRunning`: 1 = Credential Guard, 2 = HVCI, 3 = HVCI + System Guard. A *1 / empty-array* result is the classic *"WSMT or another VBS prerequisite is missing"* signature.
### Procurement criteria for a security-conscious buyer
The procurement conversation is the most consequential one a defender can have. The five table set is not patchable from Windows Update; if you bought wrong, you are stuck with it for the device's lifetime. The criteria worth pinning down before you sign a purchase order:
| Criterion | What it guarantees |
| --- | --- |
| Secured-Core PC certification | DMAR / IVRS / IORT present and correctly authored, Memory Access Protection enrollable, WSMT flags asserted, SDEV populated for biometrics, HVCI on, BitLocker on [@oem-highly-secure-11] |
| BIOS option to disable WPBT | Customer-side opt-out from the WPBT class without relying on WDAC |
| IORT presence on Arm laptops | Confirms SMMU-on-by-default in firmware (Snapdragon X / Surface Pro X-class) |
| Vendor BIOS-update SLA covering ACPI security tables | Predictable patch cadence for the tables that cannot be Windows-Updated |
| Pluton-as-TPM option | Closes the LPC-bus eavesdropping gap and supports PCR-based table measurement [@ms-pluton] |
### Defender-side Monday-morning actions
Three actions are worth doing on the next available maintenance window.
*Deploy a WDAC policy that constrains WPBT-injected binaries.* This is Microsoft's recommended Eclypsium mitigation [@eclypsium-wpbt]. The App Identity sibling article walks WDAC authoring in detail [@app-identity-sibling]. Even a permissive policy that requires a specific signing root for WPBT binaries (e.g., your OEM's production cert, no others) eliminates the revoked-cert-attack class.
*Verify that Memory Integrity, VBS, and Credential Guard are actually running, not just supported.* Run `Win32_DeviceGuard.SecurityServicesRunning` across your fleet and alert on machines where the array is empty but `VirtualizationBasedSecurityStatus = 1`. That signature is the classic *"the prerequisites are not met"* outcome -- often WSMT.
*Snapshot the ACPI table set on managed endpoints; alert on deltas across BIOS updates.* A WPBT delta that does not correspond to a documented BIOS-update changelog entry is a SOC alert. So is the appearance or removal of an SDEV entry between two consecutive boots. Most enterprise firmware tooling can do this; if yours cannot, the Linux-side `acpidump | acpixtract | iasl -d` pipeline is a workable fallback.
> **Note:** For high-value endpoints, treat `Kernel DMA Protection: Off` in `msinfo32` as a SOC alert worth chasing, not a tolerable default. The remediation is usually a UEFI menu (turn on VT-d) or a BIOS update (fix DMAR authoring), not a Windows operation. The five minutes spent enabling it are worth more than the next quarter of EDR alerts.
Two final operational anchors round out the article: a frequently-asked-questions block you can hand to a colleague, and a closing study guide for revision.
## 10. FAQ and Closing
### A few questions a colleague will ask
Mostly no on enterprise SKUs. You may lose an OEM tracking agent, a warranty-recovery utility, or a vendor-supplied dock-firmware updater. Microsoft does not document a supported way to disable WPBT consumption from inside Windows [@eclypsium-wpbt], so the BIOS toggle (where the OEM offers it) is the cleanest path. On a managed enterprise fleet where the recovery flow is owned by IT and the OEM utility is not load-bearing, the cost is usually zero and the security benefit is the entire WPBT class.
Yes. That is exactly the point of the table. A device listed in SDEV with the Allow-Handoff bit clear is owned by the Secure Kernel for the lifetime of the boot; non-secure-OS code, including the Windows kernel, cannot reach it [@acpi-65-sdev]. The companion article on VBS trustlets walks the partitioning mechanics for the BioIso, LsaIso, and vmsp trustlets [@vbs-trustlets-sibling]. Caveat: if SDEV does not list the device, the Secure Kernel never takes ownership, and the device is owned by the normal kernel by default.
VBS will likely de-feature, and you may not be able to enable Credential Guard or HVCI. Severity depends on what you are using the device for. Microsoft Learn names WSMT compliance with the corresponding Protection Flags asserted as a hard prerequisite for VBS launch [@oem-vbs]. On a developer workstation that handles no production credentials, the practical impact may be modest. On a laptop a domain administrator carries to a coffee shop, the practical impact is a lot of post-exploitation primitives that were supposed to be blocked.
Not on its own. Windows runs the binary. The mitigations are a Windows Defender Application Control policy that constrains what WPBT may execute [@eclypsium-wpbt] or a BIOS option to disable WPBT consumption (where the OEM offers it). Until the WPBT signature validator changes -- which Microsoft has not committed to -- there is no Windows-side mechanism that refuses an attacker-signed binary if the certificate is technically Authenticode-valid (even if revoked).
ACPI's design point in 1996 was that the OS abstracts away platform variance via OEM-declared tables. The same property that lets a single Windows binary run on a thousand SKUs is the property that puts the OEM on the trust path. The trade-off has been visible since 1996 [@wikipedia-acpi]. The alternative architecture -- a vendor-controlled hardware-and-software stack like Apple's Mac silicon, where the same vendor controls both ends -- closes the contents-correctness gap by collapsing the OEM and the OS into a single entity. It also collapses the customer-choice space.
All three describe an IOMMU. DMAR is the table for Intel VT-d; IVRS is the table for AMD-Vi; IORT is the table for the Arm SMMU. They are mutually exclusive on a given platform; a laptop ships with exactly one of them depending on the silicon vendor. All three are first-class for Kernel DMA Protection, and the OEM opt-in flag lives in a different field of each [@oem-kernel-dma].
Partial. The TCG Platform Configuration Register framework supports the idea, and Microsoft requires PCR[7] EV_EFI_ACTION events when DMA protection is downgraded [@oem-kernel-dma], but a unified measured-ACPI PCR -- one that extends every security-bearing table at firmware load and lets the hypervisor refuse to launch trustlets when the measurement does not match a known-good baseline -- is not standardised today. This is the live frontier; the Pluton sibling article tracks the silicon-attestation context [@pluton-sibling].
### Closing
This article is the substrate for the rest of the Windows platform-security series. The hypervisor-as-isolation-primitive [@hyperv-sibling] runs only when WSMT lets it. The trustlets that run inside the Secure Kernel [@vbs-trustlets-sibling] reach SDEV-listed devices and only those. Pluton-as-TPM [@pluton-sibling] and the discrete TPM [@tpm-sibling] anchor the measured-boot chain that, in principle, could detect a forged ACPI table -- and in practice, today, detects exactly one downgraded-DMA-protection event in PCR[7]. BitLocker [@bitlocker-sibling] seals against PCR values that are themselves measurements of the firmware that built the table set. Secure Boot [@secure-boot-sibling] verifies the bootloader that reads the table set; LogoFAIL showed that the firmware *underneath* Secure Boot can patch the tables before Secure Boot's verifier fires. Application identity and code integrity policy [@app-identity-sibling] is the only customer-side lever for the WPBT class. USB device-arrival policy [@plug-and-trust-sibling] is the only customer-side lever for the runtime portion of the DMA class.
Every guarantee those articles describe rests on five tables the firmware writes and the OS trusts. You now know the names of the tables, the names of the failure families, and the inventory commands to read them on your own machine. The next time you see `Kernel DMA Protection: Off` in `msinfo32`, you will know what is missing, who can fix it, and why it matters more than the EDR vendor's marketing slide implied. The next time someone tells you their Secured-Core PC is rootkit-proof, you will know which 52-byte table to ask about.
```
---WRITER METRICS---
Word count: 12316
Citations: 111 inline citation markers across 34 unique sources (26 unique URLs + 8 sibling-article placeholders)
Mermaid diagrams: 7
Definitions: 8
Sidenotes: 4
FAQ questions: 7
---END WRITER METRICS---
```