Parag Mali - tag: windows-kernel

The Registry Adventure: How One Researcher Read 100,000 Lines of Windows Kernel C and Found 50 Bugs

noreply@paragmali.com (Parag Mali) — Sun, 24 May 2026 00:00:00 GMT

Between May 2022 and December 2023, Mateusz Jurczyk of Google Project Zero manually audited the Windows kernel registry parser and filed 39 bug reports under Project Zero's 90-day disclosure deadline plus 20 low-severity reports without deadline, which Microsoft serviced as 50 CVEs total (44 from the 90-day cohort and 6 more in a March 2024 bulletin). The bugs share a root cause: a thirty-year-old hybrid on-disk-and-in-memory format with a deterministic, unrandomized cell allocator that Microsoft cannot redesign without breaking backward compatibility to Windows NT 4.0. The methodology pivot is the story. Jurczyk started with a coverage-guided fuzzer, found one bug, then put the fuzzer down and read 100,000 lines of kernel C for twenty months. What the audit implies for the rest of the Windows kernel is the open question the article ends on.

1. I Loaded a Registry Hive From a Network Share and the Kernel Crashed

In May 2022, Mateusz Jurczyk pointed a coverage-guided fuzzer at the Windows registry. Within days the fuzzer crashed the kernel and produced CVE-2022-35768. Twenty months later, when he stopped, Jurczyk had filed thirty-nine bug reports against the same subsystem, Microsoft had assigned fifty CVEs to his name, and the fuzzer was sitting unused. Somewhere in those first few days, Jurczyk had realised that the bugs he actually wanted were ones a fuzzer could not see [@pz1-registry-adventure-1].

The threat model is almost too small to fit on a slide. An unprivileged process running at Medium Integrity Level calls RegLoadAppKey with the path of a file the attacker controls. The kernel opens the file, runs its in-house binary parser on the bytes, and exposes the resulting tree of keys back to the caller through a private handle. Microsoft's own documentation describes the surface this way: the hive becomes a private namespace reachable only through that handle, but "the registry will prevent an application from accessing keys in this hive using an absolute path" [@ms-regloadappkey]. The handle is sandboxed. The parser, which is the interesting part, is not. It runs in the kernel with attacker-supplied input, and it has been doing so since Windows Vista.

A file-and-in-memory tree of registry keys and values, encoded in Microsoft's regf binary format and operated on by the Windows kernel's Configuration Manager. Hives live on disk as `*.dat` files (plus `.log` and `.alt` companions) and are loaded into the kernel's address space when an application or the operating system opens them [@ms-registry-hives]. Medium Integrity Level: the integrity label an ordinary logged-in Windows user runs at. Crossing from Medium IL to SYSTEM is what a kernel local privilege escalation does. The class of bug this article is about reliably accomplishes that crossing from an attacker-supplied file.

The fifty CVEs that Jurczyk's audit produced are not a uniform pile. Most of them are kernel local privilege escalations (LPEs); a handful are information disclosures; one is a denial of service [@pz1-registry-adventure-1]. The seventeen that matter for this article are the cohort Jurczyk later catalogued in his Project Zero post on practical exploitation: a tight set of memory-corruption bugs that share a single root cause and a single exploitation primitive, which he named hive-based memory corruption [@pz8-registry-adventure-8].

flowchart TD A["Medium-IL user process"] --> B["RegLoadAppKey API"] B --> C["NtLoadKeyEx system call"] C --> D["Configuration Manager dispatch"] D --> E["Hv* hive parser"] E --> F["Cell allocator and KCB tree"] F --> G["Mapped section pages -- kernel address space"]

Two questions are doing all the work in this article. Why is a thirty-year-old binary parser running in the Windows kernel willing to accept arbitrary input from unprivileged users? And why did it take a single researcher twenty months to map the consequences? The first question is about Microsoft and design. The second is about Jurczyk and method. To take either one seriously, we have to start at the very beginning -- with Windows 3.1.

2. Why There Is a Hive Parser in the Kernel

In 1992 the registry was 64 kilobytes. Windows 3.1 shipped with a single file at C:\WINDOWS\REG.DAT, encoded in a small custom format whose magic bytes spelled SHCC3.10. It held one top-level key, no named values, and existed solely to register OLE objects and shell file-type associations [@pz2-registry-adventure-2]. The first regedit.exe shipped alongside it. There was no security descriptor, no recovery story, and no kernel involvement. You could fit the whole thing in the L2 cache of a 2026 laptop.

Windows NT 3.1, released in July 1993, swept that design away and introduced something different. The new format was called regf, and the design decision that has determined the next thirty-three years of Windows kernel security was made here: the on-disk format and the in-memory format are the same format. Jurczyk's blog post on the regf file format states this plainly: "the regf format aims to bypass the reparsing step -- likely to optimize the memory/disk synchronization process -- and reconcile the two types of data encodings into a single one... This unique approach comes with its own set of challenges, and has been a contributing factor in a number of historical vulnerabilities" [@pz5-registry-adventure-5].

Microsoft's binary registry file format, introduced in Windows NT 3.1 (1993) and stabilized at v1.3 in NT 4.0 (1996). Later versions (v1.4 Whistler beta, v1.5 XP, v1.6 Win10 AU) layer features on top but all remain cross-compatible with the v1.3 baseline. The same format encodes a hive on disk and in kernel memory; there is no separate "loaded" representation [@pz5-registry-adventure-5]. Microsoft has never published an official regf specification [@pz5-registry-adventure-5].

The motivation was reasonable. NT was a multi-user, securable, network-capable operating system targeting servers; its configuration store needed access control, transactional recovery, and the ability to grow well past 64 KiB. Reusing the same byte layout for disk and memory meant a hive could be loaded by mapping or copying its file image, modified in place, and flushed back without a serialization step.

Pre-release builds used regf v1.0; the first shipping NT used v1.1; NT 3.5 and 3.51 used v1.2 [@pz2-registry-adventure-2]. The Win9x consumer line went a different direction entirely, with an incompatible format called CREG that never made it into the NT lineage and quietly died with Windows Me.Windows 95, 98, and Me used a completely incompatible CREG format that did not survive into NT. The modern registry inherits nothing from the Win9x line; every memory corruption bug Jurczyk found descends from the NT 3.1 decision.

The next stabilization happened on July 29, 1996. Windows NT 4.0 (whose pre-RTM development builds had introduced v1.3 in 1995) froze the backward-compatibility baseline at regf v1.3, added a "fast leaves" optimization for subkey lookups, and locked in the binary layout that the modern Windows kernel still reads thirty years later. Later versions layered features on top -- v1.4 (Whistler beta, big values), v1.5 (Windows XP, 2001, hash leaves), and v1.6 (Windows 10 Anniversary Update, 2016, layered keys) -- but every one of them remains cross-compatible with v1.3-aware parsers, and v1.3 itself still encodes a number of Windows 11 hives [@pz5-registry-adventure-5].

Microsoft's own documentation for RegSaveKeyExA describes REG_STANDARD_FORMAT as "the only format supported by Windows 2000," meaning that hives written by Windows 2000 and later, in the default format, are interchangeable with hives produced by Windows NT 4.0 [@ms-regsavekeyex]. A hive file authored on NT 4.0 in 1996 will still mount on Windows 11 in 2026. That backward compatibility is not an accident; it is a load-bearing requirement of system-image management, forensics, and third-party installers.

gantt title Registry format evolution dateFormat YYYY axisFormat %Y section Win 3.x reg.dat (SHCC3.10) :1992, 1993 section NT 3.x regf v1.0 to v1.2 :1992, 1996 section NT 4.0+ regf v1.3 (standard) :1996, 2026 section XP regf v1.5 (hash leaves) :2001, 2026 section Vista RegLoadAppKey + KTM :2006, 2026 section Win 8.1 LOG1 and LOG2 logging :2013, 2026 section Win 10 RS4 Section-backed hives :2018, 2026 section Win 10 AU regf v1.6 (layered keys) :2016, 2026

Ten years later, in November 2006, Windows Vista added the second design decision that completes the threat model. RegLoadAppKey shipped as a public Win32 API, allowing an unprivileged application to load an arbitrary hive file as a private "application hive" reachable only through the returned handle [@ms-regloadappkey]. The motivation was legitimate; per-application configuration sidecars are a reasonable feature.

The consequence was that the kernel-mode regf parser, frozen at v1.3 a decade earlier and unchanged in any of its load-bearing routines, was now reachable from Medium IL with no special privileges. Jurczyk's introduction to the series says it plainly: "arbitrary registry hives can be loaded from disk without any special privileges via the RegLoadAppKey API (since Windows Vista)" [@pz1-registry-adventure-1].

A Win32 API introduced in Windows Vista (2006) that lets an unprivileged process load an arbitrary hive file as a private "app hive," running the full kernel-mode regf parser on attacker-supplied bytes. Microsoft documents the API as one that "loads the specified registry hive as an application hive" reachable only through a private handle; the parser itself is not sandboxed [@ms-regloadappkey].

With the parser reachable from low privilege and the format frozen for thirty years, the only question left was who would notice.

3. Prior Attempts: The "Fuzzed Precisely Once" Misconception

Before we go further, a fact you may have heard in a conference Q&A: the Windows registry is "the most-fuzzed subsystem in Windows," "fuzzed precisely once," by one person. It is not true. The registry has been poked at, in one form or another, since 1996. None of those efforts found the bug class that Jurczyk would eventually name -- but that is a different statement, and the difference is the point of this section.

The first instrument to touch the registry from outside Microsoft was Mark Russinovich and Bryce Cogswell's RegMon, released in 1996 as a Sysinternals utility. RegMon was a kernel driver that intercepted every registry call and surfaced the path, type, process identifier, and result to a user-mode console. It was operational tooling, not a bug-finding tool. Microsoft's own page on the modern successor, Process Monitor, attributes the lineage to Russinovich and notes that Procmon "combines the features of two legacy Sysinternals utilities, Filemon and Regmon" [@ms-procmon]. RegMon made the registry observable from outside the kernel. It could not see corruption inside a hive.

The next wave came from forensics. Microsoft never published a regf specification, so the digital-forensics community reverse-engineered one. Timothy D. Morgan's regfi paper appeared at DFRWS in 2009. Joachim Metz's libregf project published its first format-spec document in July 2009 and has been updated continuously through 2026 [@libregf-spec]. Maxim Suhanov's regf specification covers, among other things, the old single-.log dirty-vector recovery format and the new two-file LOG1/LOG2 layout introduced in Windows 8.1 [@msuhanov-spec]. These were user-space parsers built to mount hive files for evidence extraction. They exercised the format from the outside. They never touched the kernel parser.

A separate research line, in parallel, pursued the layer above the parser. James Forshaw of Project Zero spent years hunting capability and access-control bugs in the registry's name-resolution and permission logic -- registry symbolic links, virtualization quirks, sandbox-escape paths that ride on registry redirection. Jurczyk's PZ #4 covers some of this surface in passing, noting that the registry has at least four distinct ways in which "access to a registry key can be transparently redirected to another path" [@pz4-registry-adventure-4]. These were logic bugs, not memory-corruption bugs. The parser was not the target.

Then, in 2016, Jurczyk and Forshaw collaborated on a black-box bitflipping fuzzing pass against RegLoadKey and RegLoadAppKey. Jurczyk acknowledges the collaboration directly in his retrospective: "I was also somewhat familiar with basic harnessing of the registry, having fuzzed it in 2016 together with James Forshaw" [@pz1-registry-adventure-1]. The cohort produced a handful of registry bug reports filed as Project Zero issues #873, #874, #876, and #993.

It did not find the hive-memory-corruption class. The reason is the same one that would defeat the 2022 fuzzer: random byte flips on a hive file produce a malformed-but-rejected hive far more often than they produce one that passes base-block validation, enters the parser proper, and exercises an interesting bug.Per-issue contents of the 2016 cohort are not anonymously fetchable; the Project Zero tracker now lives at project-zero.issues.chromium.org and redirects unauthenticated requests to a Google sign-in page [@pz-tracker-root]. The cohort's existence is primary-source-confirmed by Jurczyk's reference in PZ #1.

The hive binary format is not very well suited for trivial bitflipping-style fuzzing, because it is structurally simple, and random mutations are much more likely to render (parts of) the hive unusable than to trigger any interesting memory safety violations. -- Mateusz Jurczyk, *The Windows Registry Adventure #1* [@pz1-registry-adventure-1]

In early 2022, Jurczyk made a more serious attempt. He built a coverage-guided Bochs-based kernel fuzzer, the same lineage as his earlier Bochspwn work, and pointed it at the kernel's hive-loading path. Within days the harness produced its first registry kernel bug, filed as Project Zero issue #2299 and assigned CVE-2022-35768 by Microsoft. The fuzzer worked. It just did not scale to the bug class Jurczyk actually wanted, which is the part of the story that matters.

A frequent third-party confusion is worth naming and dispatching here. Bochspwn Reloaded is not the registry-research tool. The repository's own README describes the goal as detecting "the disclosure of uninitialized kernel stack/heap memory," not memory corruption, and reports "over 70 bugs in the Windows kernel" found by the tool in 2017 and early 2018 [@bochspwn-reloaded-repo]. The 2018 white paper makes the same scope clear; the project's technical content is about shadow-memory representation and tainting stack frames and pool allocations to catch infoleaks [@bochspwn-reloaded-paper]. The 2022 Bochs-based registry harness is a separate, unreleased instrument sharing the lineage but not the codebase.

A 2018 Bochs-based Project Zero tool by Mateusz Jurczyk for detecting uninitialized kernel memory disclosures via taint tracking [@bochspwn-reloaded-repo]. *Not* the registry-audit instrument. The 2022 coverage-guided Bochs registry harness is a separate, unreleased tool that shares Bochspwn's general design but is not the public Bochspwn Reloaded repository. flowchart LR A["RegMon (1996)
Operational visibility"] --> B["Forensic parsers
regfi, libregf, msuhanov
2008 to present"] B --> C["Forshaw logic bugs
Sym-links, virtualization
2014 to present"] C --> D["Jurczyk-Forshaw fuzz
Bitflipping RegLoadKey
2016"] D --> E["Bochs coverage fuzz
One good bug
2022"] E --> F["Jurczyk manual audit
50 CVEs
2022 to 2023"]

Every prior attempt had hit the same ceiling. The bug class lived in the code, not in the file. And the code had not yet been read.

4. Six Generations of Hardening Without Redesign

Between 1992 and 2018, Microsoft shipped six generations of registry changes. Not one of them redesigned the parser. Every generation added a feature, hardened a recovery path, lifted a scale limit, or shifted a memory model. Each of those changes also created new surface for the next decade's attackers. The cell allocator at the heart of the format has been substantively the same routine for twenty-five years.

The table below collapses Stage 2's defensive arc into one view. Each row is a generation; the "Surface effect" column captures the bug class that became reachable as a side effect of the improvement.

Gen	Year	What was added	Surface effect
A-1	1992	`reg.dat` / SHCC3.10, 64 KiB OLE database	None in the kernel; user-mode only [@pz2-registry-adventure-2]
A-2	1993	regf v1.0/v1.1, hybrid on-disk and in-memory	Every memory-corruption bug class to follow [@pz5-registry-adventure-5]
A-3	1996	regf v1.3 lock-in, fast-leaves optimization	30-year backward compatibility freezes the parser [@ms-regsavekeyex]
A-3b	2001 / 2016	regf v1.5 (XP, hash leaves), v1.6 (Win10 AU, layered keys)	New features, same v1.3-cross-compatible parser core [@pz5-registry-adventure-5]
A-4	2006	`RegLoadAppKey`, KTM transactions	Parser becomes reachable from Medium IL with no privileges [@ms-regloadappkey]
A-5	2013	LOG1/LOG2 incremental write-ahead logging	New log-replay path becomes attacker-influenceable [@pz5-registry-adventure-5]
A-6	2018	Section-backed hive mapping	Pages become pageable; double-fetch class enabled [@pz5-registry-adventure-5]

Each row deserves a sentence. A-1 is the registry's prehistory; nothing here lives in the kernel, but the hierarchical key/value mental model is established. A-2 is the load-bearing decision: hybrid on-disk and in-memory format, modified in place [@pz5-registry-adventure-5]. A-3 is the moment Microsoft signed a thirty-year contract; the format defined by REG_STANDARD_FORMAT is binary-compatible with NT 4.0 [@ms-regsavekeyex].

A-3b is the format-level feature layering done since: v1.5 (Windows XP, 2001) added hash leaves to speed up large subkey lookups, and v1.6 (Windows 10 Anniversary Update, 2016) added layered keys for differencing hives; both stay cross-compatible with v1.3-aware parsers, and v1.3 still encodes a number of Windows 11 hives [@pz5-registry-adventure-5]. A-4 is the entry-point change: RegLoadAppKey and the Kernel Transaction Manager arrive together in Vista, and both are now attacker-reachable [@ms-regloadappkey].

A-5 introduces the new log format; PZ #5 describes "incremental logging added in Windows 8.1" as one of the two big runtime-recovery overhauls of the modern era [@pz5-registry-adventure-5]. A-6 is the section-backed mapping shipped in Windows 10 RS4 (April 2018), and is the change that makes a hive on an SMB share into a moving target -- hive pages become pageable, and a page that was validated on load can be evicted and re-read with different contents [@pz5-registry-adventure-5].Some Windows 11 system hives, such as UsrClass.dat under HKU\<SID>_Classes, are still written in regf v1.3 -- a format frozen in 1996. The backward-compatibility freeze is not a hypothetical concern [@pz5-registry-adventure-5].

The unit of allocation inside a hive. A length-prefixed chunk of bytes; positive prefix means the cell is free, negative prefix means it is allocated, and the absolute value of the prefix is the size in bytes (multiples of eight). Cells are the building blocks of keys, values, security descriptors, and index nodes [@msuhanov-spec]. Key Control Block: the in-memory kernel object that represents an open registry key. It holds the cell index of the on-disk key node, a parent pointer, a refcount, and a per-key synchronization primitive [@pz6-registry-adventure-6]. The KCB tree is the live representation of every currently-open registry key.

Note: Each generation added new mitigation, new performance, or new functionality. None redesigned the cell allocator, the cell-index-to-virtual-address translation, or the hybrid on-disk-and-in-memory layout. Six generations of mitigation; one unmoved load-bearing routine.

Mapping the result is helpful before we get to the audit. Here is what a hive looks like in the 2025-era kernel from the bytes on disk up to the kernel-object tree that user-mode code touches.

flowchart TD A["Hive file on disk
REGF base block + HBINs"] --> B["Memory-mapped section
pageable pages"] B --> C["_HHIVE structure
0x600 bytes, hive descriptor"] C --> D["_CMHIVE structure
0x12F8 bytes, kernel state"] D --> E["Cell map
cell-index translation"] E --> F["Hv* allocator
HvAllocateCell, HvFreeCell"] F --> G["KCB tree
open keys in kernel memory"] G --> H["User-mode handles via NtCreateKey"]

The diagram is not a model; it is the structure. PZ #6 documents the exact sizes: _CMHIVE is 0x12F8 bytes and contains an embedded _HHIVE of 0x600 bytes at offset zero [@pz6-registry-adventure-6]. None of these objects existed in NT 3.1; what existed was the bottom three layers and a simpler kernel-side wrapper. The architecture grew. The cell allocator did not.

By 2018 the parser had been substantively unchanged for twenty-five years, and nobody had read all of it.

5. The Pivot: Audit, Not Fuzz

Return to May 2022, but now with the full context loaded. Six generations of hardening have created a thirty-year-old attack surface. Forty years of forensic and security research have not penetrated the parser. Jurczyk is sitting at his desk with a working coverage-guided Bochs harness and one good registry bug, and instead of letting the fuzzer run for another six months, he stops.

The detective work that produced the stop is documented in the introduction to the series. Jurczyk noticed two facts that together amount to a methodology critique.

First, the regf format is "structurally simple" in the sense that bitflipping a random byte usually produces an invalid base-block checksum, an out-of-range cell offset, or some other condition that the kernel rejects long before it reaches anything interesting [@pz1-registry-adventure-1]. The base-block validator is doing a lot of work.

Second, the bug class he was chasing -- one that produces kernel memory corruption from an attacker-controlled hive -- requires legal-on-disk hives that exercise particular combinations of features. The interesting bugs live in interactions: transactions plus virtualization plus predefined keys plus log replay, all in the same legal hive image. No byte-level mutator is going to synthesize that.

So Jurczyk did something almost retro. He pulled ntoskrnl.exe with public PDB symbols into the kind of static-and-dynamic analysis toolchain PZ #3 enumerates -- IDA Pro for cross-referencing, WinDbg attached to a kernel target, Ghidra alongside [@pz3-registry-adventure-3] -- and started reading the Configuration Manager. He cross-referenced every entry point against libregf, against Suhanov's spec, and against Windows Internals, Part 2, 7th edition by Allievi, Russinovich, Ionescu, and Solomon [@winint7-part2; @libregf-spec; @msuhanov-spec]. Every attacker-reachable function got traced to every cell read, write, free, and allocation on every path. PZ #3 lists the bibliography he assembled along the way and marks the Russinovich book with the equivalent of a gold star [@pz3-registry-adventure-3]. The methodology is twentieth-century. The yield is not.

The numbers came in twenty months later. Per PZ #1, the audit produced 39 bug reports, which Microsoft serviced as 44 CVEs in the 90-day cohort plus 6 more in a March 2024 low-severity batch, for 50 CVEs total; the average time from report to fix was 81 days [@pz1-registry-adventure-1]. By December 2024, with more Microsoft CVE assignments rolling in, PZ #5 was reporting 52 CVEs [@pz5-registry-adventure-5]. By May 2025, PZ #7 was at 53 [@pz7-registry-adventure-7]. The growth across the publication arc reflects CVE assignment, not new discoveries. "50+" is the safe headline figure.

Inside those 50 CVEs, a tight subset of 17 share a single root cause and a single exploitation primitive [@pz8-registry-adventure-8]. Jurczyk's PZ #8 gives them a name -- hive-based memory corruption -- and divides them into two subclasses. Spatial violations are cell-boundary overflows: writes that cross the boundary of a legitimately-allocated cell into an adjacent cell whose type, owner, or pointer the attacker now controls. Temporal violations are cell-reuse use-after-frees: writes through a cell-index reference whose backing storage has been freed and reallocated to attacker-influenced content. Spatial and temporal together; everything else is detail.

Mateusz Jurczyk's coinage for the bug class that corrupts the in-memory representation of an active hive via the deterministic cell allocator [@pz8-registry-adventure-8]. The spatial subclass is cell-boundary overflows. The temporal subclass is cell-reuse use-after-frees. The class is named in PZ #8 and demonstrated on Windows 11 with all modern kernel mitigations enabled.

The exploitation primitive is the deliberate engineering of the cell allocator, and PZ #8 is unsentimental about it.

The registry cell allocator... completely lacks any safeguards against memory corruption, and... has no element of randomness, making its behavior entirely predictable. -- Mateusz Jurczyk, *The Windows Registry Adventure #8* [@pz8-registry-adventure-8]

A deterministic, unrandomized allocator with no integrity checks on its cell metadata is what you would design if you wanted recovery from a torn write to produce the same byte image every time. It is also, identically, what you would design if you wanted an exploit primitive that places a controlled object at a predictable cell index. The property that makes the parser correct under crash recovery and the property that makes it exploitable are the same property.

Key idea: The bug class was semantic. The fuzzer was syntactic. That mismatch is the audit's entire reason for existing.

How does an attacker-controlled hive actually become a corruption primitive? The sequence is shorter than you might expect.

sequenceDiagram participant U as Medium-IL process participant K as Configuration Manager participant V as Base-block validator participant P as Bin and cell parser participant A as Cell allocator U->>K: RegLoadAppKey(hive_path) K->>V: Validate REGF header V->>P: Walk HBINs, accept legal cells P->>A: Reserve cell indices for keys, values, security A->>P: Hand back deterministic indices P->>K: Build cell map, expose KCB Note over A,P: Attacker-shaped cells now live at predictable kernel addresses K->>U: Return private handle U->>K: Trigger second-stage operation (e.g., transaction abort) K->>A: Spatial or temporal violation fires

The diagram makes the loss of generality clear. The base-block validator does its job; the bin and cell parser accept a legal hive; the cell allocator places attacker-shaped cells at deterministic indices; and then a second-stage operation -- a transaction abort, a log replay, a predefined-key dereference -- reuses a cell index whose backing storage no longer means what the kernel assumes. There is no point in the lifecycle where a fuzzer's mutator could have engineered the legal-on-disk-but-semantically-explosive hive that the audit's reader engineered by hand.

Coverage-guided fuzzing and manual audit are not equivalent tools on this target. The empirical numbers from the same researcher, on the same target, are instructive.

Method	Researcher-months	Good registry kernel bugs	Empirical rate
Bitflipping fuzz of `RegLoadKey` / `RegLoadAppKey` (2016)	~few [@pz1-registry-adventure-1]	4 (PZ #873, #874, #876, #993)	~1 per month or worse
Bochs coverage-guided harness (early 2022)	~1 to 2	1 (CVE-2022-35768)	~0.5 to 1 per month
Manual audit (May 2022 -- December 2023)	20	50 CVEs across 39 reports [@pz1-registry-adventure-1]	~2.5 CVEs per month

To understand why hive-based memory corruption works as a primitive, we have to look at what the parser actually is.

6. Anatomy of the Configuration Manager

If you want to find bugs in the registry, you have to know exactly what a hive is. Here is what one looks like on disk and in memory.

A hive begins with a base block: a 4 KiB header that contains the magic string regf, the format version (v1.3 in modern hives), a sequence-number pair for crash recovery, a checksum, the root cell index, the hive length, the boot type and recovery information [@pz5-registry-adventure-5; @libregf-spec]. The validator that runs at hive load time vets this block first. If the checksum does not match, if the version is unrecognized, if the lengths do not add up, the parser refuses the file and no further code runs. This is the line of defense that ate 99% of the bitflipping fuzzer's effort in 2016 and again in 2022.

After the base block come one or more HBIN blocks. Each HBIN is a 4-KiB-multiple chunk of the hive carved into cells. Microsoft's documentation on registry hives describes the on-disk supporting files alongside the main hive: an .alt backup of the critical HKLM\System hive, a .log transaction log, and a .sav backup [@ms-registry-hives]. The HBIN is the layer the cells live in.

A cell is a length-prefixed chunk of bytes whose first 32-bit field is a signed integer. Positive means free, negative means allocated, and the absolute value is the cell size in bytes (cells are 8-byte aligned). The Suhanov spec documents the convention plainly, alongside the cell types we are about to walk through [@msuhanov-spec]. The signed-size convention is not just a curiosity; it is the load-bearing invariant that the cell allocator must protect, and it is the convention an attacker exploits when they convince the kernel to walk one allocated cell into the next.

{` // Demonstrates the regf signed-size cell convention from Suhanov's spec. // A cell whose first 32-bit field is positive is FREE. // A cell whose first 32-bit field is negative is ALLOCATED; |size| is bytes.

function readCellHeader(buf, offset) { const raw = new DataView(buf).getInt32(offset, true); // little-endian const allocated = raw < 0; const sizeBytes = Math.abs(raw); return { allocated, sizeBytes, raw }; }

// Build a 16-byte buffer: cell #1 allocated, 16 bytes, then a sentinel. const buf = new ArrayBuffer(20); new DataView(buf).setInt32(0, -16, true); // header: -16 -> allocated, 16 B new DataView(buf).setInt32(16, 1234, true); // sentinel "next cell" prefix

console.log("Cell 1:", readCellHeader(buf, 0)); console.log("Cell 2 sentinel:", readCellHeader(buf, 16));

// A trivial validator that only checks "is the size positive after abs()" // will accept a maliciously flipped header that overlaps into the next cell. const tampered = buf.slice(); new DataView(tampered).setInt32(0, -24, true); // size now spans into cell 2 console.log("Tampered cell 1:", readCellHeader(tampered, 0)); `}

A hive holds a small number of cell types. The five that matter for security analysis are catalogued below. Each describes a different on-disk concept, and each can be malformed in ways the parser must catch.

Cell type	Signature	What it stores	Failure mode
Key node	`nk`	A registry key: name, parent index, child-list index, value-list index, security index, timestamp [@libregf-spec]	Dangling indices; malformed name length; recursive parenting
Value	`vk`	A registry value: name, type tag, length, inline data or data-block index [@libregf-spec]	Length-versus-buffer mismatch; type-tag confusion
Security descriptor	`sk`	A security descriptor for one or more keys; reference-counted [@libregf-spec]	Refcount underflow on shared SDs
Index node	`lf` / `lh` / `li` / `ri`	A subkey list: leaves with hash hints, intermediate ri lists [@msuhanov-spec]	Out-of-order entries; phantom subkeys
Big-data block	`db`	A continuation cell for values larger than 16,344 bytes (just under 16 KiB) [@libregf-spec]	Length math overflow; truncated continuation

Between the cells and the parser sits a layer most people do not know about: the cell map. Bins are not guaranteed to be contiguously mapped in kernel virtual address space, so the Configuration Manager maintains a page-table-like indirection that translates a 32-bit cell index into a virtual address. PZ #6 documents this in detail in its discussion of _HHIVE and _CMHIVE, with the latter spanning 0x12F8 bytes and the former 0x600 bytes at offset zero [@pz6-registry-adventure-6].Per PZ #6: _CMHIVE is 0x12F8 bytes and contains an embedded _HHIVE of 0x600 bytes at offset 0. The depth of Jurczyk's reverse-engineering is reflected in these exact offsets, which are not in any Microsoft-published documentation.

A page-table-like indirection layer that translates a 32-bit cell index into a kernel virtual address [@pz6-registry-adventure-6]. The cell map exists because the bins making up a hive are not guaranteed to be contiguously mapped. Most cell-boundary exploitation primitives walk through the cell map. flowchart LR A["32-bit cell index"] --> B["Directory index"] A --> C["Table index"] A --> D["Cell offset within bin"] B --> E["Cell map directory"] E --> F["Cell map table"] C --> F F --> G["Bin base address"] D --> G G --> H["Kernel virtual address of cell"]

The cell allocator itself -- HvAllocateCell, HvReallocateCell, HvFreeCell [@pz8-registry-adventure-8] -- is small, deterministic, and unrandomized. There is no allocator metadata integrity check; freed cells are eagerly reused; cell placement is a function of the bins' free lists, which the attacker can influence by shaping the input hive. Combined with the cell map, the result is that the attacker can place a chosen byte pattern at a chosen cell index with reasonable predictability, and -- because the same allocator services both attacker-influenced and kernel-managed cells -- the attacker can place that pattern adjacent to a kernel-managed object whose corruption hands them an elevation primitive [@pz8-registry-adventure-8].

Since Windows 10 RS4, hive pages are not copied into the paged kernel pool; they are backed by memory-mapped sections that can be paged in from the underlying file [@pz5-registry-adventure-5]. The performance and footprint benefits are real. The security side effect is a new bug class: the kernel can read a hive byte at validation time, then read the same byte again at use time, and the underlying page can have been re-fetched in between. This is the double-fetch pattern, and CVE-2024-43452 -- a double-fetch while loading hives from remote network shares -- is the canonical example Jurczyk cites in PZ #5 [@pz5-registry-adventure-5].

A vulnerability pattern where the kernel reads the same attacker-influenced memory location twice and treats both reads as authoritative. The section-backed registry (Windows 10 RS4) made hive pages pageable, which enables this on hive files served from remote SMB shares: between the kernel's two reads, the attacker swaps the byte under the kernel's feet. CVE-2024-43452 is the canonical example [@pz5-registry-adventure-5].

A small but stubborn misconception about the registry deserves a callout before we move on. The registry is not lock-free. The Configuration Manager uses pushlocks -- a Windows kernel synchronization primitive supporting shared and exclusive modes -- on a per-Key-Control-Block basis, plus a hive-wide pushlock for operations that touch the hive globally [@pz6-registry-adventure-6]. PZ #6's discussion of _CMHIVE and _HHIVE documents the pushlock placements directly. The design is fine-grained pushlock synchronization, not lock-free concurrency, and the difference matters because temporal hive-memory-corruption bugs frequently exploit the gap between unlocking a parent and re-locking it, which exists in pushlock designs and would not exist in a true lock-free one.

A Windows kernel synchronization primitive supporting shared and exclusive modes [@pz6-registry-adventure-6]. The registry uses per-KCB pushlocks and a hive-wide pushlock. The implementation is *not* lock-free; that is a third-party misconception, and several of Jurczyk's temporal hive-memory-corruption bugs exploit the moment a pushlock is released and re-acquired.

Two other runtime subsystems sit on top of the parser. The Kernel Transaction Manager (KTM) lets registry writes be grouped into atomic, rollbackable transactions; KTM rides on the Common Log File System (CLFS).KTM's CLFS backing is interesting in its own right: CLFS has had its own significant CVE history, and a transactional registry write whose KTM log can be tampered with reaches a separate kernel subsystem with its own attack surface. The transactional layer is one of the "semantic combinators" Jurczyk explicitly lists as outside the syntactic-fuzzer reach.

Incremental write-ahead logging via LOG1 and LOG2 provides crash-recoverable durability for individual writes that have not yet been flushed to the main hive [@pz5-registry-adventure-5]. Both layers add features. Both layers add cell-lifetime states the parser must reason about. Both layers contributed bugs to the audit.

The PZ #1 summary breakdown of the 50-CVE cohort is the clearest single statistic in the entire series.

Category	Count
Elevation of privilege	39 [@pz1-registry-adventure-1]
Information disclosure	9 [@pz1-registry-adventure-1]
Memory information disclosure	1 [@pz1-registry-adventure-1]
Denial of service	1 [@pz1-registry-adventure-1]
Total	50

Of those 50, the subset PZ #8 picks out as exploitable via the hive-memory-corruption primitive numbers seventeen: CVE-2022-34707, CVE-2022-34708, CVE-2022-37956, CVE-2022-37988, CVE-2022-38037, CVE-2023-21675, CVE-2023-21748, CVE-2023-23420, CVE-2023-23421, CVE-2023-23422, CVE-2023-23423, CVE-2023-28248, CVE-2023-35382, CVE-2023-38139, CVE-2024-26182, CVE-2024-43641, and CVE-2024-49114 [@pz8-registry-adventure-8]. Seventeen kernel LPEs from one researcher, one subsystem, one bug class, one exploitation primitive.

Microsoft has known about every one of these issues since the day they were reported. Why has the parser not been rewritten?

7. Why Doesn't Microsoft Just Rewrite It?

The first thing anyone asks after seeing the architecture is the obvious question. Why doesn't Microsoft rewrite this thing? The answer is, roughly, "because they cannot."

Backward compatibility is the dominant constraint. A hive file from NT 4.0 in 1996 still mounts on Windows 11 in 2026; that is the published behaviour of REG_STANDARD_FORMAT in RegSaveKeyExA [@ms-regsavekeyex]. Three decades of system images, third-party installers, forensic tooling, configuration-management products, and group-policy templates depend on the regf v1.3 format being readable. A new on-disk format with a hardened in-memory representation would not be a parser change; it would be the kind of compatibility break Microsoft has not made since the move from Win9x to NT.

There are databases inside Windows that look like reasonable alternatives at a glance. None of them is a drop-in replacement, for reasons that have less to do with their internals than with what the registry is asked to do.

System	Implementation	Used for	Why it is not a drop-in
Registry	regf, kernel parser	All Windows configuration, COM, security, policy [@ms-structure-registry]	The thing we are auditing
ESE	`esent.dll`, full ACID DB	Active Directory, Windows Search, Mail, Exchange [@winint7-part2]	Different access model; userland; not designed for boot-path config
LSA Secrets / `SECURITY` hive	regf substrate, restricted access	Cached credentials, Kerberos keys [@winint7-part2]	Same parser, same bug class -- moving the lock does not move the bug
Object Manager Namespace	Kernel object directory	Named kernel objects (events, mutexes, sections)	Different threat model; not a config store
MSIX / AppX state	Per-package JSON/XML in app container	UWP/Store-app configuration	New apps only; cannot host legacy registry consumers

ESE -- the Extensible Storage Engine -- is the closest existing internal candidate. It is a full ACID embedded database, used by Active Directory and Windows Search, and it is much better-engineered as a storage layer than regf is. It is also userland, designed for very different consumers, and not on the kernel boot path. Reusing it would require porting every kernel-mode registry caller across the kernel-user boundary, which has performance implications that nobody has signed off on publicly.

Microsoft's Extensible Storage Engine, an embedded ACID database implemented in `esent.dll`. Active Directory, Windows Search, Exchange, and Windows Mail all use it as their internal data store [@winint7-part2]. It is a much more modern design than the registry's regf, but it is userland, not boot-path, and its access model is different enough that it is not a drop-in replacement for the kernel-mode configuration store.

The LSA Secrets and SECURITY hive are even more instructive. They are regf-format hives with stricter access controls. They inherit the entire hive-memory-corruption bug class verbatim; restricting who can talk to the parser does not change what the parser does with the bytes it receives.

The Windows kernel has another old, hierarchical, semantically-rich subsystem that has not been audited at this scale: the Object Manager Namespace, which exposes named kernel objects (events, sections, mutexes, devices, symbolic links) through a path-like API. It is the same era as the registry, the same kind of in-kernel data structure with a path-resolution layer, the same authorization model that has been hardened incrementally over thirty years. James Forshaw's work has touched it in places; no one has yet read it the way Jurczyk read the Configuration Manager. The Object Manager Namespace is the most plausible next target for a Jurczyk-style audit by anyone who wants to repeat the result on a different subsystem.

The structural argument is the one to remember. The registry's on-disk format and its in-memory format are the same format, and its recovery semantics depend on deterministic cell placement; the attack surface and the recovery semantics are therefore literally the same code [@pz5-registry-adventure-5; @pz8-registry-adventure-8]. You cannot harden one without weakening the other unless you give up the hybrid-format premise entirely -- in which case, you are not hardening the parser; you are rewriting it. And rewriting it is what backward compatibility forbids.

If a wholesale redesign is off the table, can the existing parser be hardened in place?

8. The Theoretical Limits of In-Place Hardening

If Microsoft cannot rewrite the parser, can they at least harden it? Four levers are theoretically available. Each one trades against a different property the existing design depends on.

Lever	What it would achieve	Backward-compat cost	Effectiveness against hive-memory-corruption
Allocator randomization	Break the placement predictability the exploitation primitive relies on	Breaks log-replay recovery semantics that depend on deterministic cell placement [@pz8-registry-adventure-8]	High in principle; incompatible in practice
Cell-metadata integrity checks	Catch naive corruption at allocator boundaries	Modest format change for in-memory layout; on-disk format unaffected	Low; catches accidental corruption, not crafted-input semantic violations
Structured deserialization at load time	Validate the entire hive into a separate in-memory structure	Abandons the hybrid-format premise; effectively rewrites the parser	High but indistinguishable from rewriting
Move the parser to user mode	Reduce blast radius of a parser bug to one process	Performance and correctness implications for boot-path config	Mitigation only; the bug class survives in userland

Allocator randomization is the obvious idea. ASLR-like randomization of cell placement would defeat the "place attacker-controlled bytes at predictable index" half of the primitive, but it would also break recovery semantics: log replay assumes that after a crash, the cells in the recovered hive end up at the same indices the log expected, because the on-disk-equals-in-memory format encodes the cell index in the hive itself. PZ #8's framing of the allocator's lack of randomness as a design property rather than an oversight is precisely about this trade-off [@pz8-registry-adventure-8].

Cell-metadata integrity checks are cheap to add and have an obvious limit. The cell allocator currently has no metadata integrity at all; adding a checksum or a canary would catch a corrupted size header, a stale free-list pointer, or a write that accidentally overran a cell boundary. It would not catch an attacker who shapes a legal hive that exercises the parser's combinatorial logic. The semantic bugs Jurczyk hunted do not write garbage cells; they trick the parser into reusing valid cells for purposes the parser does not realize it is being asked to.

Structured deserialization at hive-load time is the option computer-science textbooks recommend. Validate the entire input file against a formal grammar, deserialize into a separate in-memory representation that is unrelated to the on-disk byte layout, and let the kernel operate on that. This is what the LangSec discipline calls for, and what structure-aware fuzzing surveys treat as the right shape for parser hardening [@manes-fuzz-survey]. It is also identical to "rewrite the parser." The hybrid-format premise that has been load-bearing since 1993 has to die for this option to exist.

Language-theoretic security: a discipline that treats parsers as recognizers for a formal grammar, rejecting inputs outside the grammar instead of recovering from malformed input. The registry parser does the opposite by design: it accepts inputs that the recognizer would call "marginal" (a slightly-malformed log, an off-by-one bin) because recovery from a torn write requires acceptance, not rejection.

Note: LangSec's central recommendation is that a parser should be a recognizer for a formal language: an input either belongs to the language or it is rejected outright, with no recovery and no partial acceptance. The registry's regf parser is not a recognizer in this sense, and cannot be retrofitted into one without abandoning the hybrid on-disk-and-in-memory premise.

Moving the parser to user mode -- running the parser inside an isolated process and exposing only sanitized handles to kernel callers -- is what the academic literature recommends for other kernel parsers. There is no public Microsoft work on doing this for the registry specifically, and the performance cost of a kernel/user boundary on the boot-path configuration store is, charitably, "unstudied." The bug class would still exist; the blast radius would shrink.

Static analysis cannot save us in general. Rice's theorem says, informally, that any non-trivial semantic property of an arbitrary program is undecidable: there is no algorithm that takes a program and tells you whether it has property $P$, for any interesting $P$. Memory safety is interesting. Therefore, any static-analysis approach to "find every memory-safety bug in the Configuration Manager" must be either unsound (it misses bugs) or incomplete (it flags false positives), and in practice usually both. Formal verification of a *specific* parser against a *specific* specification can sidestep this -- the EverParse project at `github.com/project-everest/everparse` does exactly that for TLS and QUIC message parsers in Microsoft research -- but it requires a formal specification of the input language, and the regf format has none.

The honest answer is the one Jurczyk gives in PZ #7 and PZ #8: the parser can be incrementally hardened, and is being, in response to each individual CVE [@pz7-registry-adventure-7; @pz8-registry-adventure-8]. The deeper design choices that make the parser exploitable are the same choices that make it work at all. We have a thirty-year-old parser that cannot be redesigned, cannot easily be replaced, and can only be hardened in ways that trade safety for compatibility. So what does that tell us about the rest of the Windows kernel?

9. Open Problems and What the Audit Implies

Jurczyk read one Windows kernel subsystem for twenty months and produced fifty CVEs. Windows has dozens of kernel subsystems. None of them has been read this way.

That sentence is the article. The rest of this section is bookkeeping.

First, the open business inside the audit itself. Microsoft chose not to fix some of Jurczyk's low-severity reports; PZ tracker issue #2508 is the canonical example of a WontFix close, and the broader "low severity in isolation" category is not "not exploitable in combination" -- modern kernel exploitation is bug-chaining, and a benign-looking primitive plus a benign-looking infoleak often compose into something less benign [@pz7-registry-adventure-7]. PZ #1 also explicitly flags higher-level wrapper logic (path translation in CmpDoOpen, predefined-key abuses, virtualization layers) as parts of the surface that the 20-month audit did not exhaust [@pz1-registry-adventure-1]. There are more registry bugs to find.

Second, the cross-subsystem implication. Microsoft's Windows Insider Preview bounty program pays "from $500 to $100,000 USD" for qualifying critical kernel bugs [@msrc-bounty-windows-insider]. The 50-CVE cohort, valued at the upper bound of the Insider Preview range, is somewhere in the neighbourhood of $5M in latent bounty value, all produced by one person reading code.

Note: At Microsoft's published $100,000 ceiling for critical Windows kernel bugs under the Windows Insider Preview program [@msrc-bounty-windows-insider], the 50-CVE cohort represents roughly $5M in latent bounty value. That is one person, twenty months, one subsystem. The question is not how to fix the registry; it is how many other subsystems would yield similar numbers under similar treatment.

What does that imply for the Object Manager Namespace, the I/O Manager, the print stack, the transactional file system, the Common Log File System, or the WinUSB stack? No public audit of any of those subsystems at the depth of Jurczyk's registry work exists. Some of them have had targeted fuzzing campaigns; none has had a 100,000-line code review by a single expert reader. The expected yield is, charitably, unknown.

flowchart TD A["Windows kernel subsystems"] --> B["Registry / Configuration Manager"] A --> C["Object Manager Namespace"] A --> D["I/O Manager"] A --> E["KTM and CLFS"] A --> F["Print spooler stack"] A --> G["Transactional NTFS"] A --> H["GDI and Win32k"] B --> B1["Jurczyk 2022-2023, 50 CVEs"] C --> C1["Partial Forshaw 2014+, logic bugs"] D --> D1["Episodic fuzzing, no public deep audit"] E --> E1["Episodic CLFS exploitation, no full audit"] F --> F1["PrintNightmare-era patches, no full audit"] G --> G1["No public deep audit"] H --> H1["Years of TYPESAFE_CAST + targeted fuzzing"]

Third, Microsoft's own internal posture. The MSRC SDL pipeline includes OneFuzz-lineage tooling internally, though the public OneFuzz repository was archived in September 2023 [@onefuzz-repo]. No public Microsoft statement confirms or denies whether the registry was systematically fuzzed or audited inside Microsoft before Jurczyk's 2022 audit. The absence of such a statement is itself information: if Microsoft had a parallel internal effort that found these bugs first, they would normally publish that.

Fourth, the methodological question that the article cannot answer because nobody has the data. Does manual code audit scale? One researcher, twenty months, one subsystem, fifty CVEs. Two researchers do not produce twice the bugs because of overlap and coordination cost; the typical second-researcher contribution on the same target is sublinear. There is no obvious path to ten Jurczyks reading ten subsystems in parallel and producing five hundred CVEs.

Key idea: The registry is not interesting because it had bugs. The registry is interesting because someone read it.

Jurczyk did not break new ground by finding a bug. He broke new ground by reading the code -- and the implication for everything else nobody has read is left, as Jurczyk himself might say, as an exercise for the reader.

10. A Practical Guide

Up to here, this article has been about the research. The rest is for practitioners.

For vulnerability researchers

If you want to understand Jurczyk's audit at the level required to repeat it, the Project Zero series is the primary text and the reading order is not the publication order. PZ #4 (hives and the registry layout) and PZ #5 (the regf file format) are the canonical references for the substrate; PZ #6 (kernel-mode objects) is the reverse-engineering of the in-memory structures; PZ #7 (attack surface analysis) is the bug-class taxonomy; PZ #8 (practical exploitation) is the exploitation primitive on Windows 11 with modern mitigations [@pz4-registry-adventure-4; @pz5-registry-adventure-5; @pz6-registry-adventure-6; @pz7-registry-adventure-7; @pz8-registry-adventure-8]. PZ #1 and #2 are the framing and the history; PZ #3 is the bibliography. Read 4 -- 5 -- 6 -- 7 -- 8, in that order, with PZ #1 alongside as a CVE-index lookup.

Audience	Where to start	Why
Researcher learning the surface	PZ #4 then PZ #5 [@pz4-registry-adventure-4; @pz5-registry-adventure-5]	Substrate first; specifics later
Defender / SOC engineer	PZ #7 attack-surface taxonomy [@pz7-registry-adventure-7]	Detection patterns map to bug classes
Kernel engineer (defensive)	PZ #4--6 collectively	Best non-Microsoft technical reference on the Configuration Manager
Patch manager	PZ #8's 17-CVE list + PZ #1 full table [@pz8-registry-adventure-8; @pz1-registry-adventure-1]	Prioritize the hive-memory-corruption cohort

The Jurczyk pattern is reproducible. Pick a closed-source Windows kernel subsystem with a structurally rigid input format. Get the public PDB symbols for `ntoskrnl.exe` (or the relevant driver). Find the equivalent of `RegLoadAppKey` for the surface in question -- the unprivileged user-mode entry point that runs the most kernel code on the most attacker-influenced input. Then read every reachable function. The unglamorous methodology and the long-form Project Zero blog series are the same artifact.Jurczyk's 2022 registry-specific coverage-guided Bochs harness has never been publicly released. The lineage -- Bochspwn (2013), Bochspwn Reloaded (2018) -- is well-documented in Jurczyk's public papers and repositories [@bochspwn-reloaded-paper; @bochspwn-reloaded-repo]. The registry-specific configuration is not.

For defenders

The detection story for hive-memory-corruption attempts is unusual. Most real-world exploitation chains will load an attacker-controlled hive via RegLoadAppKey (or its close relatives RegLoadKey, RegLoadKeyEx, RegRestoreKey) from an unusual path -- typically a temporary directory under the calling user's profile or an SMB share. The hive file itself can be analyzed offline by mounting it with a forensic parser such as libregf [@libregf-repo] or Suhanov's regf tools [@msuhanov-repo].

The kernel exposes the operation via the Microsoft-Windows-Kernel-Registry ETW provider, and Sysmon surfaces registry operations under event IDs 12 (key create/delete), 13 (value set), and 14 (key/value rename) [@ms-sysmon]. A simple detection heuristic is "Medium-IL process performs an unusual rate of hive-load operations on attacker-shaped paths." Detection logic looks like the following.

{` // Toy detection: Medium-IL process loads multiple app hives from // non-standard paths within a short window. Inspired by Sysmon event IDs // 12 (registry create/delete) and 13 (registry value set).

function suspiciousHiveLoad(event, profileWindowMs) { const isLoad = event.operation === 'CreateKey' || event.operation === 'LoadAppKey'; if (!isLoad) return false;

const path = event.targetPath || ''; const fromTempOrShare = path.match(/AppData\\Local\\Temp/i) || path.match(/^\\\\[^\\]+\\/) || path.match(/Users\\Public/i);

const lowIntegrity = event.integrityLabel === 'Medium' || event.integrityLabel === 'Low';

const recentCount = countRecentEventsFromPid(event.pid, profileWindowMs); const burst = recentCount > 5;

return lowIntegrity && fromTempOrShare && burst; }

function alert(event) { if (suspiciousHiveLoad(event, 60000)) { console.log('ALERT: anomalous hive load from PID ' + event.pid + ' path=' + event.targetPath); } } `}

Note: The 17 CVEs in Jurczyk's PZ #8 cohort all share the same exploitation primitive. If you are triaging a backlog of Windows security updates, prioritize fixes for these CVE IDs over the broader 50-CVE list: CVE-2022-34707, -34708, -37956, -37988, -38037; CVE-2023-21675, -21748, -23420, -23421, -23422, -23423, -28248, -35382, -38139; CVE-2024-26182, -43641, -49114 [@pz8-registry-adventure-8].

For engineers maintaining adjacent code

PZ #4, #5, and #6 collectively are the most accessible non-Microsoft technical reference on the Configuration Manager [@pz4-registry-adventure-4; @pz5-registry-adventure-5; @pz6-registry-adventure-6]. If you are doing security review of a subsystem that interacts with the registry -- ETW, KTM, AppX state, group policy -- those three posts plus PZ #7 give you the model of the in-kernel data structures you are talking to.

For everyone else

The 50 CVE IDs spanning CVE-2022-34707 through CVE-2024-49114 are a checklist for "have these been rolled across our fleet?" [@pz1-registry-adventure-1]. The 17-CVE hive-memory-corruption subset is the priority order [@pz8-registry-adventure-8]. The fixes are in Microsoft's monthly servicing channel; there are no out-of-band patches required, but the cohort is large enough that a fleet that fell behind on Patch Tuesday in 2022 -- 2024 may have several of these still outstanding.

The research is published. The detection is uncomplicated. The next twenty months of Windows kernel research will not be about the registry, which makes the question this article ends on -- what about everything else nobody has read -- the only question left.

11. FAQ

A handful of questions worth correcting before they propagate. These are the misconceptions inherited from secondary summaries of the research, including the prompt for this article.

No. **Bochspwn Reloaded** is a separate 2017--2018 Project Zero tool, also by Jurczyk, that detects uninitialized kernel memory disclosures via x86 taint tracking [@bochspwn-reloaded-repo; @bochspwn-reloaded-paper]. The 2022--2023 registry research is **The Windows Registry Adventure**, an eight-part Project Zero blog series [@pz1-registry-adventure-1]. The 2022 coverage-guided Bochs harness Jurczyk briefly used on the registry was a separate, unreleased tool sharing the same general lineage, but it is not the public Bochspwn Reloaded repository. Conflating the two is the most common third-party error about this research. No. At a minimum, Jurczyk and Forshaw fuzzed it in 2016 -- the bug reports filed as Project Zero issues #873, #874, #876, and #993 are the surviving artifacts of that effort [@pz1-registry-adventure-1] -- and Jurczyk built a coverage-guided Bochs harness against it in early 2022 that produced CVE-2022-35768 within days. The 2022--2023 work that produced 50 CVEs was a manual code audit, not a fuzzing campaign. The "fuzzed precisely once" claim mixes up "no published fuzzing campaign at scale" with "no one ever pointed a fuzzer at this," and the latter is just not true. No. The Configuration Manager uses **pushlocks** (shared and exclusive modes) on a per-Key-Control-Block basis, plus a hive-wide pushlock for global hive operations [@pz6-registry-adventure-6]. "Lock-free" is a misconception that appears in some secondary summaries -- including the prompt for this article. The actual design is fine-grained pushlock-synchronized, and several of Jurczyk's temporal hive-memory-corruption bugs exploit the moment a pushlock is released and re-acquired. All of those are correct at different points in the publication arc. PZ #1 (April 2024) counts 44 from the 90-day cohort plus 6 from the March 2024 low-severity batch = 50 [@pz1-registry-adventure-1]. PZ #5 (December 2024) reports 52 [@pz5-registry-adventure-5]. PZ #7 (May 2025) reports 53 [@pz7-registry-adventure-7]. The growth reflects Microsoft assigning more CVE IDs to Jurczyk's existing bug reports over time, not new discoveries. "50+" is the safe shorthand; "50 in the original cohort, 53 by mid-2025" is the precise version. **OffensiveCon 2024**, in Berlin. The talk was "Practical Exploitation of Registry Vulnerabilities in the Windows Kernel"; slides and recording are public [@offcon24-jurczyk-speaker; @offcon24-slides; @offcon24-video]. The earlier **BlueHat Redmond 2023** talk (titled "Exploring the Windows Registry as a powerful LPE attack surface") was the first public disclosure of the research [@bluehat23-slides; @bluehat23-video]. "OffensiveCon 2025" is wrong; that talk has not happened. No. Microsoft has never published a regf specification; PZ #5 states this directly: "Throughout the 30 years of the format's existence, Microsoft has never released its official specification" [@pz5-registry-adventure-5]. Unofficially, two community-maintained specs cover almost all of it: Joachim Metz's libregf, updated continuously since July 2009 [@libregf-spec], and Maxim Suhanov's regf project [@msuhanov-spec]. The Microsoft-blessed reference book is *Windows Internals, Part 2, 7th Edition* by Allievi, Russinovich, Ionescu, and Solomon [@winint7-part2]. Everything else is forensics-community reverse engineering.

The eight Project Zero posts run roughly 120,000 words across April 2024 -- May 2025. Microsoft has serviced 53 CVEs from them so far. The registry's parser remains substantively the same routine it has been since Windows NT 4.0. There is no public roadmap for a redesign. The question that follows -- what is the expected yield of similar audits of every other Windows kernel subsystem that no one has read end-to-end -- is the one a research community could answer in another twenty months, if it chose to.

Rust in the Windows Kernel: A Field Guide to the 2024-2026 Memory-Safety Refit

noreply@paragmali.com (Parag Mali) — Sat, 23 May 2026 00:00:00 GMT

**Rust ships in the Windows kernel today.** The binary is `%SystemRoot%\System32\win32kbase_rs.sys`, first surfaced in Insider Preview Build 25905 on 12 July 2023 and most recently in the news through Check Point Research's May 2025 "Denial of Fuzzing" disclosure. The realistic ten-year trajectory is **not** a Windows rewrite. It is "memory-safe by default for newly written code" plus targeted rewrites of high-blast-radius modules, with the unsafe-FFI boundary as the irreducible audit frontier. This article is a primary-sourced field guide to what actually shipped from BlueHat IL 2019 through Windows 11 24H2 in 2026, what did not, and what the next decade looks like.

1. The Blue Screen That Wasn't a Bug

On 28 May 2025, Microsoft shipped KB5058499 to patch a kernel bug in Windows 11 24H2 [@kb5058499]. The bug was an out-of-bounds array access in a Rust function called region_from_path_mut() inside the binary %SystemRoot%\System32\win32kbase_rs.sys [@cybersecuritynews]. Rust correctly detected the access. Because the detection fired at high IRQL inside a kernel binary compiled with panic = "abort", the response was a system-wide blue screen [@checkpoint-dof].

Read that again. Rust. In ntoskrnl's neighbourhood. In production. Detecting a memory-safety violation. Panicking. Bugchecking the box.

The class of programming error -- buffer overflow, use-after-free, type confusion, integer overflow, double-free, uninitialised read -- where unsafe memory access leads to undefined behaviour. For two decades the Microsoft Security Response Center has reported that roughly seventy percent of Microsoft's CVE-assigned vulnerabilities come from this class. The first Windows kernel binary written in Rust. It contains the Win32k GDI region and shape engine, and after 2025 includes portions of the EMF and EMF+ metafile parsing path. The `_rs` suffix is Microsoft's internal convention for Rust-implemented kernel binaries. You can verify the file exists on any modern Windows 11 install by checking `%SystemRoot%\System32\win32kbase_rs.sys`.The first public ship was Windows 11 Canary-channel Insider Preview Build 25905 on 12 July 2023. The Windows Insider blog called out the change explicitly: "This preview shipped with an early implementation of critical kernel features in safe Rust" [@insider-25905].

The Check Point Research write-up tells the story tightly [@checkpoint-dof]. A handcrafted Enhanced Metafile Format Plus (EMF+) record -- specifically an EmfPlusDrawBeziers shape with a mismatched point count -- arrives at the kernel by way of a normal-looking NtGdiSelectClipPath syscall. The metafile parser hands the malformed point array to region_from_path_mut(), the Rust function that converts a Bezier path into a clipping region. Indexing into the array, Rust observes the index is out of bounds. Safe Rust's bounds check fires. core::panicking::panic_bounds_check runs. And because the binary lives in kernel mode, the panic does not unwind: it aborts [@esecurityplanet]. The bugcheck code is SYSTEM_SERVICE_EXCEPTION [@cybersecuritynews].

The Windows kernel's per-CPU priority level, ranging from PASSIVE_LEVEL up through DIRQL. At IRQL ≥ DISPATCH_LEVEL the scheduler cannot run, paged memory cannot be touched, and almost no recovery path is available. A panic at high IRQL has nowhere to go except the system-wide bugcheck. The Rust compilation profile setting that converts any runtime panic into an immediate process abort rather than stack unwinding. It is mandatory for `no_std` kernel binaries because there is no unwinder, no `std::panic::catch_unwind`, and no way to clean up locks, allocations, or interrupt state held at the point of panic.

Microsoft classified the issue as a moderate-severity denial of service. The patch tightened the bounds check upstream, kept the Rust panic as the last-resort backstop, and shipped on. There is no CVE-2025 RCE here, no privilege escalation, no infoleak: this Rust panic was the security boundary doing exactly what it was designed to do, and the price was a controlled BSOD rather than a memory-corruption primitive in attacker hands [@checkpoint-dof].

That single bug carries two non-obvious claims that the rest of the article will unpack. First, this is the largest language-level memory-safety refit in NT's roughly thirty-three-year history, distinct in kind from /GS stack cookies, Address Space Layout Randomization (ASLR), Control Flow Guard (CFG), Hypervisor-protected Code Integrity (HVCI), or Intel Control-flow Enforcement Technology (CET). All of those are mitigations that raise the cost of exploiting a memory-safety bug. Rust eliminates the bug class in the modules it covers. That is a different kind of fix.

Second, the realistic ten-year shape is "memory-safe by default for new code," not "rewrite Windows." Microsoft's distinguished engineer Galen Hunt got in trouble in December 2025 for a LinkedIn post about an internal "1 engineer, 1 month, 1 million lines of code" research target [@register-2025-12-24]. Frank X. Shaw, head of Microsoft's communications, confirmed within days that the company has no plan to rewrite Windows 11 using AI [@windowslatest-galen; @infoworld-not-rewriting]. The trajectory is policy, not project.

So: Rust in the Windows kernel. Real binary, real BSOD, real patch, real timeline. How did we get here, and why is a Rust-detected memory-safety violation still a system-wide crash?

2. The 70-Percent Number and Why Mitigations Plateaued

In early February 2019, in Tel Aviv, Matt Miller stood up at BlueHat IL and asked the question that anchored the next seven years of Microsoft's security strategy. After two decades of Microsoft Security Response Center (MSRC) triage, what fraction of vulnerabilities are still memory-safety bugs? His answer, drawn from a decade of CVE data: about seventy percent [@miller-bluehat-2019; @infoq-mitigating].

The number was not new in 2019. The MSRC's own July 2019 essay re-stated it in plain prose: "approximately 70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues" [@msrc-proactive-2019]. It had not moved in a decade despite /GS stack cookies, Data Execution Prevention (DEP), ASLR, CFG, Hypervisor-protected Code Integrity, and Intel CET [@msrc-safer-2019]. Mark Russinovich repeated the number at RustConf 2025 in Seattle: "about 70% over the past two decades" [@newstack-russinovich].

A note on attribution. The originating talk was Miller's, not David Weston's. The press cycle following Weston's 2023 BlueHat IL announcement often credited him with the 70% figure. Weston and Russinovich operationalised it; Miller and the MSRC published it. The deck is in the microsoft/MSRC-Security-Research repository on GitHub under the 2019_02_BlueHatIL directory; you can read it today [@miller-bluehat-2019].Miller was MSRC's Partner Security Software Engineer at the time of the talk. He has since moved on, but Microsoft kept the BlueHat IL 2019 deck in the public security-research repo as a primary artefact for the figure.

Note: The 70% figure was roughly the same in 2009 as in 2019. The mitigations stack had absorbed two decades of compiler, OS, and hardware investment without moving the curve. That is why the question shifted from "how do we make exploitation harder" to "how do we eliminate the bug class itself."

To see why the curve stayed flat, walk the supersession history. Each generation of mitigation closed a specific exploitation primitive. None closed a bug class.

/GS (Visual Studio .NET 2002/2003) inserted a per-function stack canary to detect linear stack-buffer overruns that overwrote a saved return address [@learn-gs]. It defended only the prologue-epilogue window of stack frames. Heap overflows, non-adjacent stack writes, type confusion, and info-leak-then-corrupt all walked around it.

DEP / NX (Windows XP Service Pack 2, 2004) marked data pages non-executable so attackers could not jump into a buffer they had written [@learn-dep]. Hovav Shacham's 2007 paper on Return-Oriented Programming showed how to compose Turing-complete payloads from existing executable code without ever introducing a new instruction [@shacham-rop-2007]. DEP raised exploit cost. It did not close the bug class.

ASLR (Windows Vista, 2006) randomised module, heap, and stack base addresses so attackers could not pre-compute jump targets [@learn-aslr]. The defeat was a single information-disclosure primitive away. Every modern Windows exploit chain begins with an infoleak.

CFG (Windows 8.1, 2014) restricted indirect calls to a per-binary set of valid call targets [@learn-cfg]. XFG (announced at BlueHat Shanghai 2019, /guard:xfg compiler support shipped in MSVC in 2020, available in Windows 11 from 2021 as an opt-in compile-time flag, not enabled by default for third-party binaries) tightened that to type-signed indirect call sites [@quarkslab-xfg; @mcgarr-examining-xfg]. CET shadow stack (broadly shipping in Windows 11 in 2021) sealed the return-address half of the same family on hardware that supports it [@msft-cet-shadow]. All three are forms of Control-Flow Integrity, and all three by construction defend the control-flow graph only.

The family of compile-time and hardware mitigations -- including CFG, XFG, and CET shadow stack -- that restricts indirect control transfers (jumps, calls, returns) to a per-binary set of valid targets. CFI is, by construction, blind to attacks that corrupt program data without changing the control-flow graph. A class of exploitation in which an attacker corrupts program *data* without changing the control-flow graph. Hu et al. proved at IEEE Symposium on Security and Privacy 2016 that DOP is Turing-complete -- meaning an attacker who can corrupt the right pieces of data can compute arbitrary functions while the protected program faithfully follows its original control flow [@hu-dop-2016].

That theorem is the structural ceiling. If DOP can express arbitrary computation while the program's control-flow graph remains unviolated, then no amount of CFI can close the bug class. Every CFI variant could be implemented perfectly tomorrow and the 70% figure would still not move. The MSRC's July 2019 "We need a safer systems programming language" essay said the quiet part aloud: "no matter the amount of mitigations put in place, it is near impossible to write memory-safe code using traditional systems-level programming languages at scale" [@msrc-safer-2019].

The MSRC essay -- written by Matt Miller's team in the same July 2019 cycle as the BlueHat IL talk -- ends with a striking concession: "rather than providing guidance and tools for addressing flaws, we should strive to prevent the developer from introducing the flaws in the first place" [@msrc-safer-2019]. That sentence is the strategic pivot. After two decades of *mitigation* investment, Microsoft publicly accepted that mitigations could not solve the problem alone. The only structural fixes are at the language layer (eliminate the unsafe primitives) or the hardware layer (enforce safety at every dereference). Hu et al.'s DOP theorem was the formal moment "mitigations are necessary but not sufficient" stopped being a slogan and became math.

The supersession trace is compact enough to fit in one table.

Generation	Mitigation	Year	Closes	Defeated by	Residual bug class
G1	`/GS` stack canary	2002/2003	Linear stack overruns past return address	Heap overflows, non-adjacent writes, infoleaks	Memory corruption (all classes except narrow stack)
G2	DEP / NX	2004	Code injection into data pages	ROP (Shacham 2007)	Memory corruption (control transferred to existing code)
G3	ASLR	2006	Pre-computed gadget addresses	Information-disclosure primitives	Memory corruption (after infoleak)
G4	CFG (default) / XFG (opt-in)	2014 / 2021	Arbitrary indirect call targets	Data-oriented programming (Hu 2016)	Data-only memory corruption
G4	CET shadow stack	2021	Return-address rewrites	DOP, non-return CFI bypass	Data-only memory corruption
G5	HVCI, Driver Verifier, WDAC	2015+	Unsigned/unverified driver code	Memory corruption in signed drivers	Memory corruption in trusted code
G6	Rust in the Windows kernel	2023+	The bug class itself, in covered modules	Bugs in `unsafe` blocks; panic-as-BSOD	Logic bugs, FFI invariant violations, DoS via panic

The cross-vendor data agrees. Chromium's own engineering reports peg roughly 70% of high-severity browser bugs as memory safety. Google's Android security team published in September 2024 that memory-safety vulnerabilities in Android dropped from 76% of total in 2019 to 24% in 2024 -- not by rewriting existing C and C++, but by writing new code in Rust [@google-android-2024]. The structural fix shows up in the data when it ships.

Key idea: Mitigations bound the cost of exploitation. Only a memory-safe language or capability hardware bounds the size of the bug class itself. After two decades, the 70% figure had not moved. The structural answer was no longer optional.

If the structural fix had to come from the language layer, why did Microsoft choose Rust -- and not the safer-systems-language it had been researching since 2006?

flowchart LR GS["/GS stack cookie
2002 / 2003"] --> DEP["DEP / NX
2004"] DEP --> ASLR["ASLR
2006"] ASLR --> CFG["CFG / XFG
2014 / 2021"] CFG --> CET["CET shadow stack
2021"] CFG --> HVCI["HVCI + WDAC
2015+"] CET --> Rust["win32kbase_rs.sys
Rust in kernel
2023"] HVCI --> Rust ASLR -.->|"defeated by infoleaks"| Bypass1["arbitrary primitives"] CFG -.->|"defeated by DOP, Hu 2016"| Bypass2["data-only attacks"] Rust ==>|"closes the bug class
in covered modules"| Win["memory-safe by default
for new code"]

3. Verona, windows-rs, and the Long Approach

Microsoft's first publicly-named safer-systems-language experiment was not Rust. It was Singularity, the Microsoft Research operating system Galen Hunt and Jim Larus described in ACM SIGOPS Operating Systems Review in April 2007 [@singularity]. Singularity was built in Sing#, a dialect of C# extended with software-isolated processes, contract-based channels, and manifest-based programs that the OS verified at install time. The idea was the same as Rust's: prove memory safety at the language level so the runtime cost of process isolation becomes negligible. Singularity worked. It also stayed in the lab.

A decade later, in 2019, Microsoft Research open-sourced Project Verona at github.com/microsoft/verona, a collaboration with Imperial College London and Uppsala University [@verona-github; @verona-msr]. Verona explores concurrent ownership in regions: where Rust's borrow checker tracks one owner per object, Verona lets multiple objects share a single region-level ownership lifetime, simplifying some concurrent patterns at the cost of additional runtime structure.Verona's region-based concurrent ownership lets multiple objects share a single ownership lifetime. The academic publications appear at OOPSLA and PLDI. The repository README is explicit that the project is "not ready to be used outside of research." Verona remains alive as research. It has not been productised.

So why did Rust win against two memory-safe languages of Microsoft's own design?

The answer is adoption. Singularity and Verona were technically interesting; the community around them was Microsoft Research. Rust came with crates.io, a stable compiler, a community of working programmers, a foreign-function-interface story, and -- as of January 2020 -- official Microsoft-maintained bindings. Microsoft Research kept its own safe-systems-language line for the questions Rust does not answer, and Microsoft the platform vendor met developers where they already were.

The pivot to Rust shows up in three threads.

Thread A -- the user-mode bindings. In January 2020, Microsoft published microsoft/windows-rs on GitHub, a set of idiomatic Rust bindings to the entire Win32, Windows Runtime, and Component Object Model surface generated on the fly from Windows-metadata projections. The README is exact: "the windows and windows-sys crates let you call any Windows API past, present, and future using code generated on the fly directly from the metadata describing the API" [@windows-rs-github]. The crate is strictly user-mode. The kernel bindings come later, in a different repository.The premise paragraph that originally framed this article conflated windows-rs with the kernel bindings. They are different repositories: microsoft/windows-rs is user-mode (Win32, WinRT, COM); microsoft/windows-drivers-rs is the kernel and driver bindings. We will look at the latter in section 4.3.

Thread B -- the institutional commitment. On 8 February 2021, Microsoft joined the Rust Foundation as a founding (Platinum) member, and announced it was forming an in-house Rust team to contribute compiler and tooling work [@msft-rust-foundation]. The same year, Microsoft began funding Ralf Jung's verification line at the Max Planck Institute for Software Systems -- the MIRI interpreter, the RustBelt proofs -- both of which give the formal teeth that distinguish "Rust is safer" from "Rust is provably safe in a specific sense."

Thread C -- the academic foundation. In April 2021, Jung, Jourdan, Krebbers, and Dreyer published "Safe Systems Programming in Rust" in Communications of the ACM [@cacm-jung-2021]. The paper builds on their RustBelt result at POPL 2018, which constructed the first formal, machine-checked safety proof for a realistic subset of Rust [@rustbelt-popl-2018; @rustbelt-popl-page]. The RustBelt theorem has a property no informal language design has: it is extensible. The project page states the result precisely: "for each new Rust library that uses unsafe features, we can say what verification condition it must satisfy" [@rustbelt-popl-page]. In plain language: safe Rust is type-sound by construction, and every unsafe block can be discharged separately by a per-library proof obligation.

That property -- a discharged proof obligation per unsafe block -- is the engineering hook that makes Rust-in-kernel tractable. The kernel is full of unsafe. There is no way around that fact; the kernel is the trusted base, the layer that touches raw pointers and hardware. But if every unsafe block has a local, statable proof obligation, then the engineering question shrinks from "is the language safe?" to "is the audit of these specific blocks correct?" That is a question reviewers can answer.

Singularity / Sing# and Verona are not the only Microsoft-adjacent safer-systems-language threads. The Cyclone project (AT&T / Cornell, mid-2000s) added region-based memory management to C; the Spec# / Code Contracts line (Microsoft Research, late 2000s) attached pre- and post-conditions to .NET methods. All three were technically attractive. None achieved industrial-scale adoption. The lesson Microsoft drew from those efforts -- visible in the windows-rs investment -- is that the surrounding toolchain and community trump language design. Rust came with crates.io and a working community; the Microsoft Research languages did not.

By early 2023 the four ingredients were in place: a user-mode-scale Rust footprint at Microsoft, executive commitment via the Foundation, a verification story with RustBelt-grade formal teeth, and a working windows-rs for the user-mode call sites. The pieces existed.

What did it take to put Rust inside the kernel itself?

4. Three Generations of Microsoft's Rust-in-Windows Effort

The 2019-to-2026 story falls naturally into three generations. Each one solves the problem the previous one identified.

flowchart TD subgraph G1["Generation 1 -- 2019 to early 2023: Prerequisites"] A1["Miller BlueHat IL 2019
(70 percent figure)"] A2["MSRC safer-systems essay
(July 2019)"] A3["windows-rs
(January 2020)"] A4["Rust Foundation founding
(February 2021)"] A5["Secure Future Initiative
(November 2023)"] end subgraph G2["Generation 2 -- March to July 2023: First ship"] B1["Weston BlueHat IL 2023
(March 29 to 30)"] B2["DWriteCore in user-mode Rust
(152K LOC)"] B3["win32kbase_rs.sys in kernel Rust
(36K LOC, behind flag)"] B4["Insider Build 25905
(July 12, 2023)"] end subgraph G3["Generation 3 -- 2024 to 2026: Expansion and toolchain"] C1["windows-drivers-rs public
(2024)"] C2["EMF parser in win32kbase_rs
(by May 2025)"] C3["Surface Rust drivers ship
(July 2025)"] C4["Russinovich RustConf 2025
(September 2 to 5, Seattle)"] C5["cargo-wdk on crates.io
(November 2025)"] end G1 --> G2 G2 --> G3

4.1 Generation 1 (2019 to early 2023): the prerequisites

Generation 1 was preparation. Four things had to land before Rust could ship in the kernel itself: Microsoft running Rust at user-mode scale internally; a working no_std kernel target (the Rust compilation profile that strips the standard library's OS-services assumptions so a binary can run in kernel context); a verification story credible enough for executive sign-off; and that sign-off itself.

The chronology is clean. January 2020: windows-rs ships [@windows-rs-github]. February 2021: Microsoft joins the Rust Foundation as a founding member [@msft-rust-foundation]. 2019 through 2022: Project Verona and Singularity supply the academic foundations and the in-house safer-systems-language credibility [@verona-github; @singularity]. April 2021: the Jung et al. Safe Systems Programming in Rust paper in CACM gives the public-facing formal warrant [@cacm-jung-2021]. November 2, 2023: Brad Smith and Charlie Bell launch the Secure Future Initiative (SFI), a company-wide commitment that explicitly names memory-safety-language adoption as a software-engineering pillar [@sfi-onissues; @sfi-secblog]. The March 6, 2024 update on SFI confirms the engineering follow-through after the Storm-0558 and Midnight Blizzard incidents [@sfi-march24].

The limitation of Generation 1 is in the name. Prerequisites. No Rust had shipped in the Windows kernel yet. DWriteCore was in user mode. windows-rs was in user mode. Verona was research. The next generation had to fire the actual gun.

4.2 Generation 2 (March to July 2023): the first ship

On 29 and 30 March 2023 in Tel Aviv, David "dwizzle" Weston, then Vice President of Enterprise and OS Security at Microsoft, took the BlueHat IL stage and announced two distinct Rust ports.BlueHat IL 2023 was held in Tel Aviv on 29 to 30 March 2023; the dominant English-language press coverage broke same-day on 27 April 2023 when an embargo lifted. The article uses 27 April 2023 throughout when the date in question is the public record rather than the talk itself. The Register's same-day write-up has the canonical quote set and used Weston's earlier "Director" title [@register-2023-04-27]. The article keeps the two ports strictly separate because conflating them is the most common error in the secondary coverage.

The first port was DWriteCore, the text-rendering and shaping engine that ships through the Windows App SDK. The Register's same-day coverage carried the line-of-code and performance numbers from Weston's deck -- we return to the exact counts in §6.2 -- but the load-bearing point at BlueHat IL 2023 was that DWriteCore is strictly user-mode code, not in the kernel [@register-2023-04-27].

The second port was the one that the article you are reading is mostly about: win32kbase_rs.sys, a kernel binary containing the Win32k GDI region and shape engine -- about 36,000 lines of Rust, behind a feature flag, with at least one syscall in the Windows kernel implemented in Rust [@register-2023-04-27]. Weston's verbatim line is the moment that mattered.

There's actually a SysCall in the Windows kernel now that is implemented in Rust. -- David Weston, BlueHat IL 2023 [@register-2023-04-27].

The first reader-verifiable artefact of that ship came on 12 July 2023. Windows 11 Canary-channel Insider Preview Build 25905 dropped, and the Windows Insider blog called out the change: "Rust in the Windows Kernel ... win32kbase_rs.sys contains a new implementation of GDI region" [@insider-25905]. From that moment forward, any reader with a recent Windows 11 Insider build could open Explorer at C:\Windows\System32, sort by name, and find win32kbase_rs.sys on disk. Generation 2 was a proof of existence. The binary was real. The syscall path it implemented was real. Some pieces ran behind a feature flag, but the cement had set.

The limitation of Generation 2 was that the toolchain was Microsoft-internal. External driver authors could not reproduce the build pipeline; the no_std kernel target had not been upstreamed to rust-lang/rust; the allocator shim that adapted GlobalAlloc onto ExAllocatePool2 lived in a private repository. Generation 3 had to address the third-party adoption question.

4.3 Generation 3 (2024 to mid-2026): expansion and toolchain rollout

Generation 3 has four threads running in parallel.

Thread 1: the public driver-development crate suite. Microsoft published microsoft/windows-drivers-rs -- the public repository of Rust crates for Windows driver development [@windows-drivers-rs; @heise-rust]. The repository contains six crates (wdk, wdk-sys, wdk-alloc, wdk-build, wdk-panic, wdk-macros) plus the cargo-wdk Cargo subcommand that wraps link.exe, inf2cat, signtool, and friends into a coherent Rust build. A companion sample repository microsoft/Windows-rust-driver-samples provides Rust ports of the canonical Windows Driver Samples [@windows-rust-samples]. The README of windows-drivers-rs is candid: the project is "still in early stages of development and is not yet recommended for production use" [@windows-drivers-rs]. It also pins LLVM 17 explicitly, because LLVM 18 introduced an ARM64 bindgen bug that breaks WDK header binding generation [@windows-drivers-rs].The windows-drivers-rs README specifically pins LLVM 17 because LLVM 18 has a bug that causes bindings to fail to generate for ARM64. The fix is expected in LLVM 19. This is the kind of detail that distinguishes a developer-preview toolchain from a production one.

Thread 2: the 2025 in-kernel Rust expansion. Between the 2023 ship and the May 2025 Check Point disclosure, the Rust footprint inside win32kbase_rs.sys grew. The growth surface that became publicly known is the Enhanced Metafile Format (EMF / EMF+) parsing path -- the code that converts a path of Bezier curves into a clipping region [@checkpoint-dof; @cybersecuritynews]. The Check Point disclosure documents region_from_path_mut() as Rust; the KB5058499 patch hardened the call site upstream of the Rust panic [@kb5058499; @esecurityplanet].The original article-focus paragraph speculated that the 2025 in-kernel expansion was the Win32k DirectDraw stack. No first-party Microsoft material identifies a DirectDraw Rust port. The publicly documented 2025 expansion is in the EMF / EMF+ metafile parser inside win32kbase_rs.sys. We follow the public record.

Thread 3: the first in-box Rust drivers. In July 2025, Microsoft's Surface team confirmed that several new Copilot+ Surface PCs ship with drivers written in Rust [@winbuzzer-surface; @thurrott-rust]. Microsoft's Melvin Wang wrote on the Windows Driver Development blog that "the Surface team has contributed further to the open-source windows-drivers-rs repository for driver development and shipped Surface drivers written in Rust" [@thurrott-rust]. By September 2025, The Register reported that no production third-party Rust driver had yet shipped through Windows Hardware Compatibility Program (WHCP) certification: CodeQL supports Rust in public preview at version 2.22.1, but only version 2.21.4 is "validated for use with WHCP" [@register-2025-09-04]. The certification path is being assembled in public.

Thread 4: the executive narrative. On 2 to 5 September 2025, Mark Russinovich -- Azure CTO, Deputy CISO, and Technical Fellow -- delivered the RustConf 2025 keynote in Seattle, titled "From Blue Screens to Orange Crabs: Microsoft's Rusty Revolution" [@rustconf-2025-prog; @newstack-russinovich; @itpro-rust]. The keynote made three claims that matter for this article. First, Rust is "mandated for new Azure components that handle untrusted input." Second, Microsoft is using Rust across "kernel components, a cryptography library (rustls-symcrypt), and ancillary components (DirectWrite)" plus Project Mu firmware, Caliptra, the Azure Integrated HSM, OpenVMM, and Hyperlight [@infoq-russinovich]. Third, the Check Point bug is success, not failure: a Rust panic that crashes the box is operationally better than a memory-corruption primitive that escalates privilege [@newstack-russinovich].The InfoQ piece that covers Russinovich's named-project list is dated May 2025 and is actually about his Rust Nation UK talk earlier that year, not RustConf 2025. The substantive content overlaps, but the venue is not the same. For RustConf 2025 itself, the primary references are the Rust Foundation program page and The New Stack's same-week summary [@rustconf-2025-prog; @newstack-russinovich].

One more thread to acknowledge: on 24 December 2025, a LinkedIn post by Microsoft distinguished engineer Galen Hunt triggered a press cycle around an internal "1 engineer, 1 month, 1 million lines of code" research target [@register-2025-12-24]. The picture was corrected within days by Hunt's own clarification and Frank X. Shaw's denial that Microsoft has any plan to rewrite Windows 11 using AI [@infoworld-not-rewriting; @windowslatest-galen]. The §9 Aside walks the story in full.

Three generations in, the toolchain is public, the binaries ship, the executive commitment is on the record, the certification path is being assembled, and the press has been corrected twice on the difference between research and roadmap. The pieces are in place. What is the insight that makes Rust-in-kernel tractable as an engineering policy?

5. Memory-Safe by Default for New Code + the Unsafe-FFI Boundary

The structural insight that emerged from Generations 2 and 3 is one Russinovich named explicitly at RustConf 2025: Rust adoption inside an existing C / C++ kernel of roughly thirty million lines -- a widely-cited engineering estimate; Microsoft has not published an exact figure -- is a policy decision, not a rewrite project [@newstack-russinovich]. The policy has two clauses. For new code, default to Rust. For existing code, rewrite the high-blast-radius surfaces -- the GDI region engine, the EMF parser -- but not the rest. Russinovich's framing at the keynote: Rust is "mandated for new Azure components that handle untrusted input" [@infoq-russinovich].

The new-code policy is empirically validated. The Android security team's September 2024 publication tracks the share of memory-safety vulnerabilities in Android over five years [@google-android-2024]. The headline curve looks like this.

Year	Memory-safety share of vulnerabilities
2019	~76%
2024	~24%

The drop did not come from rewriting existing C and C++. It came from writing new code in Rust while letting the older code stop being modified. Vulnerabilities in any specific code module decay exponentially as that module stops changing, because (a) bugs that were going to be discovered get patched, and (b) new bugs are introduced primarily by new code [@google-android-2024]. Stop adding C, and the long-run share of memory-safety CVEs falls without anybody rewriting anything. That is the empirical anchor for the "memory-safe by default for new code" policy.

The policy alone is not enough. The mechanism that makes it executable is the unsafe-FFI boundary: a narrow, typed, auditable seam where safe Rust meets the C kernel it has to talk to.

A Rust crate attribute (`#![no_std]`) that opts out of linking the Rust standard library. The crate keeps `core` (and optionally `alloc`), and gets nothing else for free. Required for kernel binaries because the standard library assumes OS services -- file descriptors, threads, dynamic memory through libc -- that the kernel itself is in the business of providing. The Rust standard-library trait that defines the global memory allocator. In kernel Rust, the trait is implemented by `wdk-alloc` to call `ExAllocatePool2` (allocate) and `ExFreePoolWithTag` (free) -- the NT pool allocator entry points that drivers have used since the late 1990s. The mechanism a programming language uses to call functions written in another language across an Application Binary Interface (ABI). In kernel Rust, FFI to C kernel headers is generated mechanically by `bindgen` from WDK headers; every call site that crosses the boundary is wrapped in `unsafe`. A region of Rust code where the compiler relaxes its safety invariants and the programmer accepts responsibility for upholding them. Inside `unsafe`, raw pointers may be dereferenced, mutable static state may be touched, and FFI calls may be made. The safety guarantee of any Rust system is exactly as strong as the human audit of these blocks.

Every Rust kernel module has three unsafe layers, and the audit of those three layers is the safety story.

Layer 1: the allocator shim. The kernel has no malloc. It has ExAllocatePool2, which takes a pool type, a size, and a four-character tag, and returns memory from one of the NT pool managers. Rust's Box<T>, Vec<T>, String, and Arc<T> all expect a GlobalAlloc implementation underneath. wdk-alloc is the bridge: it implements GlobalAlloc over ExAllocatePool2 / ExFreePoolWithTag, with unsafe blocks at every FFI call [@windows-drivers-rs]. If the allocator shim is wrong -- if it forgets to zero memory, mismatches a tag, or returns a misaligned pointer -- every safe Rust collection above it is suddenly not safe.

Layer 2: the FFI surface. Bindgen generates extern "system" declarations from the WDK headers, turning each C function signature into a Rust prototype with unsafe semantics [@windows-drivers-rs]. Every cross-language call is an unsafe block in the Rust caller. The audit obligation here is: did bindgen translate the C signature faithfully? Is the calling convention right? Are pointer ownership and lifetime invariants in the C function's documentation actually upheld in the Rust caller? Bindgen is mechanical; the audit is not.

Layer 3: the pointer-arithmetic wrappers. Where Rust must observe raw C structs -- IRP, KAPC, FAST_IO_DISPATCH, and the various Win32k-internal layouts -- the boundary code wraps each struct in a typed Rust newtype that asserts the invariants the C code expects, before any non-unsafe Rust code touches it. A common pattern is the RegionImpl<'a> family of wrappers: a Rust struct that holds a raw pointer plus a lifetime parameter, with all public methods written in safe Rust and a small number of private unsafe methods that do the actual dereferencing.

flowchart TD subgraph Safe["Safe Rust"] SR["Rust kernel module
(safe code, ~90% of LOC)"] end subgraph Unsafe["Three unsafe layers"] U1["Allocator shim
wdk-alloc on ExAllocatePool2"] U2["FFI surface
bindgen extern system decls"] U3["Pointer-arithmetic wrappers
IRP, KAPC, FAST_IO_DISPATCH"] end subgraph C["C kernel"] NT["ntoskrnl, win32k, hal"] end SR --> U1 SR --> U2 SR --> U3 U1 --> NT U2 --> NT U3 --> NT

The picture is small. A typical Rust kernel module has a few hundred FFI call sites, all typed, all auditable, with the conventional Rust community discipline that every unsafe block carries a SAFETY: comment justifying the invariants the human author claims to uphold.The Rust community convention is that every unsafe block carries a SAFETY: comment justifying the invariants the human author guarantees. Microsoft's internal review guidance reinforces this for kernel code, and the windows-drivers-rs samples follow the pattern consistently. The safety guarantee of the whole module is exactly as strong as the audit of those few hundred sites. Not magic. Not a free lunch. A finite, reviewable boundary.

The windows-drivers-rs README acknowledges this without euphemism. Microsoft's Nate Deisinger captured the position in the November 2025 Windows Driver Development blog post:

Drivers using these crates still need to make use of unsafe blocks for interacting with the Windows operating system, removing some of the benefits of Rust. -- Nate Deisinger, *Towards Rust in Windows Drivers* [@techcommunity-rust-drivers].

That is the load-bearing acknowledgement. Rust does not magically make the C kernel disappear. It pushes the audit frontier to a narrow, typed, fuzz-able boundary. The wins compound there: type checking catches whole bug families before they ever reach review, fuzzing concentrates on a few hundred sites rather than a million, and the rest of the Rust code -- the other 90% -- gets the full benefit of the safety guarantee with no per-call-site audit burden.

Key idea: Rust in the Windows kernel is not magic. It is a finite, typed, fuzzable, reviewable boundary between safe Rust and unsafe C interop. The safety guarantee of any module is exactly as strong as the audit of that boundary -- which is exactly what makes it engineering policy rather than a wishful slogan.

That is the strategy in the abstract. What does it actually look like on disk in Windows 11 24H2 in May 2026?

6. What Actually Ships in Windows 11 24H2 in 2026

This section is an inventory of artefacts you can verify yourself: files on disk, GitHub repositories, KB articles, conference keynotes. Six subsections, each with receipts.

6.1 `win32kbase_rs.sys` -- the in-kernel GDI region and shape engine

File location: %SystemRoot%\System32\win32kbase_rs.sys. Reader-verifiable on any Windows 11 24H2 install. This is the binary the article opened on.

Original scope at the April 2023 announcement: the Win32k GDI region and shape engine, about 36,000 lines of Rust, behind a feature flag, with at least one syscall in the Windows kernel implemented in Rust [@register-2023-04-27]. By July 2023 the binary was visible in Canary Insider Preview Build 25905 with the GDI region implementation called out by name in the Windows Insider blog [@insider-25905].

The 2025 expansion surface is the Enhanced Metafile Format / EMF+ metafile-parsing path. The Check Point Research disclosure -- whose call flow §1 walks through in prose and the diagram below replays -- documents the bug; KB5058499, dated 28 May 2025, hardens the bounds check upstream and ships as a preview update for OS Build 26100.4202 [@checkpoint-dof; @kb5058499].

sequenceDiagram participant App as Untrusted process participant K as Win32k C dispatcher participant R as win32kbase_rs.sys (Rust) participant Panic as core::panicking App->>K: NtGdiSelectClipPath (malformed EMF+ metafile) K->>R: parse EmfPlusDrawBeziers record R->>R: build path with mismatched point count R->>R: region_from_path_mut() indexes out of bounds R->>Panic: panic_bounds_check (safe Rust detects OOB) Panic->>Panic: panic = abort (no unwinder in no_std) Panic-->>K: bugcheck SYSTEM_SERVICE_EXCEPTION K-->>App: machine bluescreens (DoS, not RCE) Note over R,K: Microsoft fixed in KB5058499 on May 28, 2025

The article does not claim a 2026 line-of-code figure for win32kbase_rs.sys. The most recent first-party number is the April 2023 ~36,000 figure quoted to The Register; no first-party Microsoft source has published a refresh. Open Problem P1 in section 9 keeps that an honest open question.Earlier drafts of articles like this one have asserted "over 100,000 lines of in-kernel Rust by 2026." That number is not in the primary record. The empirical claim we can make is that the binary exists, the GDI region engine is in Rust, the EMF parser is partly in Rust, and the binary is observably larger and more functional in 2026 than the 2023 ship -- but the actual line count is unpublished.

6.2 DWriteCore -- user-mode Rust in the Windows App SDK

DWriteCore is the standalone, distributable text-rendering and OpenType-shaping engine that ships through the Windows App SDK. At the April 2023 BlueHat IL announcement Weston quoted about 152,000 lines of Rust plus about 96,000 lines of C++, with a 5 to 15% performance improvement on selected OpenType shaping paths [@register-2023-04-27]. Russinovich at RustConf 2025 framed the team size and timeline: "Two Microsoft developers did it in six months -- 154,000 lines of code" [@newstack-russinovich]. DWriteCore is strictly user mode. The distribution channel is Windows App SDK 1.2 and above, not Windows 11 22H2/23H2 system updates. It is the user-mode counterpart to the kernel-mode win32kbase_rs.sys, not the same thing.

6.3 The `windows-drivers-rs` crate suite

The driver-development face of Microsoft's Rust effort is microsoft/windows-drivers-rs [@windows-drivers-rs]. The repository contains six crates:

wdk -- safe wrappers over the Windows Driver Kit
wdk-sys -- bindgen-generated raw FFI bindings
wdk-alloc -- the GlobalAlloc shim onto ExAllocatePool2 / ExFreePoolWithTag
wdk-build -- build script infrastructure for Cargo.toml
wdk-panic -- the panic_handler implementation with panic = "abort"
wdk-macros -- procedural macros (driver entry-point, IOCTL routing, etc.)

The cargo-wdk subcommand wraps link.exe, inf2cat, and signtool so cargo build does the right thing in a developer-mode signed driver workflow. November 2025: cargo-wdk became publishable on crates.io [@techcommunity-rust-drivers]. The companion samples repository microsoft/Windows-rust-driver-samples provides Rust ports of the canonical Windows Driver Samples for KMDF and UMDF [@windows-rust-samples].

Note: The windows-drivers-rs README is explicit: "still in early stages of development and is not yet recommended for production use" [@windows-drivers-rs]. Treat the crate suite as a developer-preview toolchain. KMDF 1.33-era bindings are on crates.io; WDM and UMDF are possible with wdk-build modification. LLVM 17 is pinned because LLVM 18 has an ARM64 bindgen bug.

6.4 OpenVMM, OpenHCL, and Hyperlight -- the virtualization-side Rust

microsoft/openvmm is a modular, cross-platform Virtual Machine Monitor written in Rust. The README is candid about scope: OpenVMM "can function as a traditional VMM, [but] OpenVMM's development is currently focused on its role in the OpenHCL paravisor" [@openvmm-github; @openvmm-guide]. OpenHCL is the Rust paravisor for AMD SEV-SNP and Intel TDX confidential virtual machines -- a guest-side software component that sits between the hardware-isolated VM and the host, mediating the small set of operations that have to round-trip [@phoronix-openhcl]. Hyperlight is Microsoft's Azure-side micro-VMM for very-low-latency function execution, with cold-start times in the low millisecond range [@newstack-russinovich].

A common confusion: OpenVMM is *not* the production [Hyper-V VSP (Virtualisation Service Provider) front-end](/blog/hyper-v-enlightenments-vmbus-and-the-synthetic-device-model/) that ships inside Windows 11 24H2. OpenVMM is a separate Rust VMM whose primary production deployment in 2026 is as the OpenHCL paravisor for confidential VMs in Azure [@openvmm-github]. The Rust status of the in-Windows Hyper-V VSP front-end has not been publicly announced; we treat it as Open Problem P6 in section 9.

6.5 The first in-box Rust drivers (Surface)

In July 2025, Microsoft's Surface team confirmed that several new Copilot+ Surface PCs ship with drivers written in Rust [@winbuzzer-surface; @thurrott-rust]. The drivers are Microsoft-internal -- shipped under the Surface OEM identity, signed through Microsoft's own driver-signing keys, exempted from the WHCP path that third parties must traverse. The Register, reporting in September 2025, summarised the third-party status: "There is also work underway to use Rust in the Windows kernel itself, some of which shipped in Windows 11 24H2" but no production third-party Rust driver has yet shipped under WHCP, because CodeQL's Rust support is in public preview at version 2.22.1 and the WHCP-validated version is still 2.21.4 [@register-2025-09-04].

6.6 The toolchain itself

The toolchain is the boring foundation that makes everything above possible. The shape, as of mid-2026:

Compiler: a recent stable rustc plus the MSVC linker. No specific minimum version is pinned by the public README; the LLVM dependency through bindgen is what determines the version floor [@windows-drivers-rs].Earlier coverage has speculated about a "rustc 1.72+" minimum version pin for the Microsoft kernel target. We have not found a first-party Microsoft source that pins this exact number. The README pins LLVM 17 (the bindgen LLVM, not the rustc LLVM) and is silent on the rustc minimum version.
Target: a custom no_std kernel target, not upstreamed to rust-lang/rust. Third-party reproducibility is therefore limited.
Bindings: bindgen-generated extern "system" declarations from WDK headers; LLVM 17 pinned because of the LLVM 18 ARM64 bug.
Allocator: wdk-alloc implementing GlobalAlloc over ExAllocatePool2 / ExFreePoolWithTag.
Panic handler: wdk-panic with panic = "abort".
Build orchestration: cargo-wdk plus cargo-make.
Verification: MIRI (where the code is portable enough to interpret), Driver Verifier (always-on inside the kernel test loop), OneFuzz and WinAFL for fuzzing, CodeQL with Rust support in public preview.

Russinovich announced at RustConf 2025 that Microsoft is also working on a "Cargo plugin for MSBuild," which would let MSBuild-driven internal builds invoke cargo cleanly [@newstack-russinovich]. Across Microsoft, Rust shows up in many places beyond Windows: SymCrypt-in-Rust, the Project Mu firmware effort, Azure Caliptra, the Azure Integrated HSM, and components of Azure Data Explorer all use Rust today [@infoq-russinovich]. The cross-context Microsoft Rust footprint is much larger than the in-Windows-kernel footprint alone, which gives the kernel effort upstream pressure to keep evolving.

Microsoft's posture is articulated and shipping. Is this a Microsoft idiosyncrasy or a cross-vendor convergence?

7. Linux, Android, Apple, CHERI: The Cross-Vendor Picture

Microsoft is not alone. The convergence is industry-wide -- with structurally different details per vendor.

Rust for Linux. Under maintainer Miguel Ojeda, Rust support landed in mainline Linux 6.1 in December 2022 [@rust-for-linux]. The "experimental" label was removed in late 2025. In-tree Rust drivers today include the AMCC QT2025 PHY, Android Binder, the ASIX PHY, DRM Panic QR, the Nova GPU driver (a long-term NVIDIA-replacement effort), Null Block, and the Tyr GPU; out-of-mainline-tree work includes the Apple AGX driver shipping on Asahi Linux, NVMe, and PuzzleFS [@rust-for-linux]. The structural difference from Microsoft's path is upstream: Linux forbids bindgen for in-tree drivers. Every Rust binding to a kernel C struct or function must be hand-reviewed and accepted onto LKML. The acceptance criteria are public; the upstream community has been contested -- Wedson Almeida Filho resigned in September 2024 citing non-technical conflicts -- but the project continues under Ojeda and the kernel maintainers' summit has reaffirmed it.

Android. Google's September 2024 "Eliminating Memory Safety Vulnerabilities at the Source" post is the empirical anchor for this article's policy claim [@google-android-2024]. The numbers we summarised in section 5 (76% in 2019 to 24% in 2024) come from this post. The strategy is identical to Microsoft's: write new code in Rust, leave most existing C and C++ alone, observe the long-run share of memory-safety bugs drop as the old code stops being modified. Android is the proof of concept that the new-code policy works at scale.

Apple. No public kernel-Rust commitment. XNU, Darwin, and IOKit remain C, C++, and Swift. The Asahi GPU project -- which lets Apple Silicon Macs boot Linux with full GPU acceleration -- is written in Rust and runs Apple hardware. But that is Rust running on Linux on Apple silicon, not Rust in Apple's own operating system. As of mid-2026, Apple has not publicly announced a Rust-in-kernel program.

CHERI and CHERIoT. The structural alternative to "Rust for new code" is "capability hardware that enforces memory safety on every dereference, including for legacy C and C++." CHERI is the Cambridge and SRI International project that extends conventional instruction set architectures with capability pointers -- tagged, bounded, monotonic references that the hardware checks at every load and store [@cheri-cambridge]. Arm's Morello prototype processor, released in January 2022, is the first commercial-class implementation. CHERIoT is Microsoft's microcontroller adaptation, a CHERI-extended RISC-V profile aimed at embedded and IoT workloads [@cheriot-org]. The CHERIoT RTOS lives at microsoft/cheriot-rtos [@cheriot-rtos-ms]. Structurally CHERI is different from Rust: it does not require a language rewrite, because the hardware enforces spatial and temporal safety on whatever language emits the pointers. Microsoft maintains both lines in parallel -- Rust for general-purpose Windows code, CHERIoT for embedded silicon -- and the two paths are complementary at the platform level.

Project Verona. Still alive as Microsoft Research [@verona-github; @verona-msr]. Publications at OOPSLA and PLDI. Not productising. Region-based concurrent ownership answers a different question from Rust's per-object model. Verona's value to the kernel-Rust effort was the academic credibility it lent the safer-systems-language thread; as a productisation candidate it remains unpursued.

flowchart LR subgraph Windows W1["win32kbase_rs.sys
Rust GDI/EMF"] W2["windows-drivers-rs
preview"] W3["CHERIoT for IoT
MSR plus partners"] W4["HVCI, CFG, CET
mitigations stack"] end subgraph Linux L1["Rust for Linux
mainline since 6.1"] L2["Hand-reviewed bindings
no bindgen in-tree"] end subgraph Android A1["New code in Rust
76 percent to 24 percent"] A2["Existing C / C++
left in place"] end subgraph Apple AP1["XNU in C and C plus plus
no public Rust commitment"] AP2["Asahi GPU in Rust
on Linux"] end subgraph Hardware H1["Arm Morello
CHERI prototype 2022"] H2["CHERIoT silicon"] end W1 --> Common["memory-safe by default
for new code
plus targeted rewrites"] W2 --> Common L1 --> Common A1 --> Common Common --> Defense["defence in depth
with mitigations stack
plus CHERI hardware where available"] W3 --> Defense W4 --> Defense H1 --> Defense H2 --> Defense

The pattern across the table is consistent. Every major operating-system vendor's safest forward path is some combination of (Rust for new code) + (CHERI-class hardware capabilities where the silicon supports them) + (the existing mitigations stack as defence-in-depth). No vendor is rewriting wholesale. The vendors differ on bindgen-versus-hand-written bindings, on in-tree process discipline, on capability-hardware availability, and on the relative weight of the three threads. They agree on the shape.

A compact decision matrix may help architects compare the seven approaches that were considered in the source survey.

Approach	Closes bug class	Worst-case crash	Hardware requirement	Production in Win 11 24H2
Legacy C/C++ with `/GS`, DEP, ASLR, CFG, CET	No (raises cost)	Memory corruption to exploitation	None (CET on Tiger Lake+)	Yes (default)
Rust in-kernel modules	Yes (covered modules)	Rust panic to kernel BSOD	None	Yes (`win32kbase_rs.sys`)
`windows-drivers-rs` for third-party drivers	Yes (per module)	Driver panic to bugcheck	None	Preview only
CHERI / Arm Morello capability hardware	Yes (all pointers, all languages)	Capability fault, process aborted	Yes (Morello, CHERIoT)	No (embedded only)
Verification (MIRI, RustBelt, formal proofs)	Yes (where proofs cover)	Caught at build time	None	Tooling only
OpenVMM / OpenHCL (Rust paravisor)	Yes (paravisor surface)	Paravisor panic in confidential VM	TDX or SEV-SNP CPU	Yes (Azure confidential VMs)
AI-assisted C-to-Rust migration	Aspirational	Per migrated module	None	Research only

The convergence is real. The strategy is articulated. So what cannot Rust-in-kernel do, even when everything goes right?

8. Four Theoretical Limits Rust-in-Kernel Cannot Escape

This section is the corrective. Even when everything goes right, Rust-in-kernel runs into four principled limits.

Limit 1: the unsafe boundary is irreducible. Any Rust module that interoperates with the C kernel must call into it; the FFI is unsafe by construction. The safety guarantee is exactly as strong as the audit of the unsafe blocks. This is not a flaw in Rust; it is a property of any safe-language-in-an-unsafe-substrate adoption. Inside unsafe, Rust does not check what you do; it trusts the human review. The audit therefore has to be load-bearing. The windows-drivers-rs README's statement that "drivers ... still need to make use of unsafe blocks for interacting with the Windows operating system" is the candid admission of this limit [@windows-drivers-rs; @register-2025-09-04].

Limit 2: a Rust panic at high IRQL is a kernel bugcheck. Because panic = "abort" is the only sound policy for no_std kernel binaries, and because at IRQL ≥ DISPATCH_LEVEL the kernel has nowhere to send a panic except the system-wide bugcheck, a correctly-fired Rust safety check in kernel context becomes a BSOD. Check Point's "Denial of Fuzzing" disclosure is dispositive: Rust correctly detected the out-of-bounds access, but the operational response was SYSTEM_SERVICE_EXCEPTION [@checkpoint-dof; @cybersecuritynews]. Rust transforms memory-corruption CVEs into denial-of-service CVEs in the kernel context. It does not eliminate the CVE class.

Russinovich framed this limit as a feature, not a bug, at RustConf 2025:

This we view as a success ... a bug that would have actually resulted in a potential elevation of privilege, as opposed to a blue screen crash. -- Mark Russinovich, RustConf 2025 [@newstack-russinovich].

He is right operationally. A BSOD is far cheaper than a remote code execution. But the CVE class did not vanish; it shifted. The new class is "panic-in-kernel-context, denial of service." That is the bug class that any future Rust-in-kernel security architect has to plan for.

Limit 3: the legacy C and C++ kernel -- roughly thirty million lines on common engineering estimates -- will not be rewritten on any plausible timeline. Even Galen Hunt's "1 engineer, 1 month, 1 million lines of code" research aspiration -- explicitly clarified by Hunt himself as research, not a corporate mandate -- would require sustained multi-decade effort to clear the whole kernel [@register-2025-12-24; @infoworld-not-rewriting; @windowslatest-galen]. Realistically the kernel will keep most of its existing C and C++ for the foreseeable future. The wins come from partial rewrites of high-blast-radius modules plus the new-code policy. Existing modules that do not change do not need to be rewritten to benefit from the new-code policy -- that is the Android empirical observation [@google-android-2024] -- but they remain potential bug-class carriers nonetheless.

Limit 4: Rust + unsafe cannot beat hardware capabilities on every bug class. CHERI and CHERIoT detect spatial and temporal memory-safety violations at every pointer dereference, including across the C and C++ legacy substrate that language-level approaches cannot rewrite [@cheri-cambridge; @cheriot-org].Spatial safety means accesses stay within an object's bounds; temporal safety means accesses do not touch freed objects. CHERI capabilities enforce both at the hardware ISA level for every load and store. The most defensible posture combines Rust for new code with CHERI-class hardware where the silicon supports it. Rust is necessary; on legacy code, it is not sufficient. The CHERIoT line at Microsoft (the microsoft/cheriot-rtos repository [@cheriot-rtos-ms]) is the explicit acknowledgement that Microsoft is investing in both layers because neither alone closes the question.

Key idea: Rust transforms memory-corruption CVEs into denial-of-service CVEs in the kernel context. It does not eliminate the CVE class -- and that is still a major win, but it is the actual win, not the marketing one.

If the policy is sound but the limits are real, what does the next decade actually look like in numbers and named open problems?

9. The 2026 Frontier and the Ten-Year Trajectory

Open problems matter when they are named. The state-of-the-art survey identified eight; each gets a paragraph here.

P1. The public corpus size of in-kernel Rust. The most recent first-party Microsoft figure remains the April 2023 number quoted to The Register: about 36,000 lines of Rust in win32kbase_rs.sys [@register-2023-04-27]. There has been no first-party refresh since. Any 2026 line-of-code claim greater than this -- including the "over 100,000 lines" framing that has circulated in secondary press -- is unsourced. We treat it as an open question.

P2. Upstreaming the no_std kernel target. Microsoft's Rust kernel target is not in rust-lang/rust. Third-party driver developers cannot reproduce the toolchain exactly without internal Microsoft assets. The windows-drivers-rs repository contains the public-facing crates and the cargo-wdk build orchestration, but the underlying compilation target is private [@windows-drivers-rs]. Upstreaming it would let external WHCP-bound driver authors build against the same toolchain as Microsoft's in-box drivers.

P3. WHCP and driver certification. As of September 2025, CodeQL supports Rust at version 2.22.1 (public preview), while only version 2.21.4 is "validated for use with WHCP" [@register-2025-09-04]. No production third-party Rust driver has yet shipped through WHCP. The certification path is being assembled in public; it is not yet open for production third-party submissions.

P4. Panic-as-BSOD mitigation. This is the Check Point bug class -- a correct Rust safety check in kernel context becomes a system-wide bugcheck [@checkpoint-dof]. The options are imperfect. Unwinding instead of aborting is unsound at high IRQL because the unwinder needs to run code that may itself page-fault. IRQL-aware fallbacks (degrade gracefully when at high IRQL, panic when at PASSIVE_LEVEL) are doable but add complexity. More conservative bounds-checking patterns in hot paths can reduce the panic surface but cannot eliminate it. This is an active research and engineering frontier.

P5. Mechanised formal verification of kernel unsafe blocks. RustBelt-grade proofs exist for specific libraries [@rustbelt-popl-page]. Production-scale verification of arbitrary kernel unsafe is open. The proof obligations are statable thanks to the RustBelt framework; discharging them at production scale across an entire driver's worth of unsafe blocks is not yet routine.

P6. The Hyper-V VSP migration. OpenVMM is in flight as the modular cross-platform Rust VMM whose primary deployment in 2026 is the OpenHCL paravisor [@openvmm-github; @phoronix-openhcl]. The in-Windows Hyper-V VSP front-end's Rust status is unannounced. This is the Stage-3 P6 open problem; the article does not assert that the production Hyper-V VSP has been migrated.

P7. AI-assisted migration. Galen Hunt's "1 engineer, 1 month, 1 million lines of code" target is the headline aspiration [@register-2025-12-24]. The methodological dependencies are non-trivial. Code-graph construction has to be accurate. AI translation quality has to be high. Semantic-equivalence preservation has to be checkable. Manual-intervention burden at the unsafe-FFI boundary will be significant. Recent academic work on type-directed C-to-safe-Rust translation -- Compiling C to Safe Rust, Formalized (Fromherz and Protzenko, OOPSLA 2026) -- shows what mechanical, proof-grade translation looks like for restricted subsets [@arxiv-c-to-rust], and that is the direction Russinovich has framed as preferred over LLM-only approaches.

On 24 December 2025, Galen Hunt's LinkedIn post -- *"My goal is to eliminate every line of C and C++ from Microsoft by 2030 ... Our North Star is 1 engineer, 1 month, 1 million lines of code"* -- was reported by *The Register* under the headline "Microsoft wants to replace its entire C and C++ codebase" [@register-2025-12-24]. The press cycle briefly suggested Microsoft was rewriting Windows in Rust. Within days, the picture was corrected. Hunt's own clarification: "My team's project is a research project. We are building tech to make migration from language to language possible. ... [The intent was] to find like-minded engineers, not to set a new strategy for Windows 11+ or to imply that Rust is an endpoint" [@infoworld-not-rewriting]. Microsoft's communications head Frank X. Shaw confirmed to Windows Latest that the company has no plans to rewrite Windows 11 using AI [@windowslatest-galen]. The "1 / 1 / 1M" project is a research aspiration inside the CoreAI group, not a Windows roadmap. Several outlets republished without that correction; the *InfoWorld* and *Windows Latest* pieces are the load-bearing references for the accurate framing.

P8. Ten-year trajectory. Three independent dynamics will determine the shape: Microsoft's conversion rate of existing high-blast-radius modules, the rate at which new code is written in Rust by default, and the empirical Android curve as a reference point [@google-android-2024]. The conclusion is not that the legacy kernel will be rewritten. The conclusion is that the share of memory-safety CVEs in Windows is likely to follow a trajectory shaped like Android's -- a multi-year decline driven by new-code-in-Rust plus targeted rewrites, with the absolute floor set by the residual unsafe audit surface at the FFI boundary and the not-rewritten C and C++ that retains some level of new development.

Quick reference for the questions almost everyone asks comes next. First, what you can do on Monday.

10. Practical Guide

Four audiences. Each gets a subsection.

10.1 For Windows-internals and security researchers

Identifying Rust-implemented kernel binaries is the first step. The Microsoft internal convention is the _rs suffix; the canonical example is %SystemRoot%\System32\win32kbase_rs.sys. The fastest verification:

Note: Open PowerShell on any Windows 11 24H2 machine and run: Get-Item C:\Windows\System32\win32kbase_rs.sys. If the file is present, you are running a Windows with kernel-mode Rust code today.

{// Demonstrates the logic of: Test-Path "\$env:SystemRoot\\System32\\win32kbase_rs.sys" const knownRustKernelBinaries = ["win32kbase_rs.sys"]; // Insider Preview 25905 (July 12, 2023) and later const systemRoot = "C:\\\\Windows"; const found = knownRustKernelBinaries.map(b => systemRoot + "\\\\System32\\\\" + b); for (const path of found) { console.log("Expected: " + path); } console.log("On a real Windows 11 24H2 install, this file is present.");}

Reverse engineering: dumping strings against win32kbase_rs.sys will surface Rust panic markers like panic_bounds_check, core::panicking::panic, and core::result::unwrap_failed -- the names the Rust standard library inserts when bounds checks or Option::unwrap calls misfire [@cybersecuritynews]. The Rust v0 name mangling scheme starts with _R and uses a Punycode-derived encoding for non-ASCII characters [@rust-rfc-2603]; tools that understand the scheme (recent IDA, recent Ghidra, rustfilt) demangle it. Functions like region_from_path_mut will appear in the binary as mangled _R... symbols.

For reproducing Check Point's "Denial of Fuzzing" methodology: the public write-up names WinAFL plus WinAFL-Pet as the orchestration tier, with crafted EMF and EMF+ metafile corpora driving NtGdiSelectClipPath and other Win32k entry points; BugId handles crash triage; MemProcFS handles memory-dump forensics [@checkpoint-dof]. The toolchain is reproducible on a research VM.

The Check Point harness suggests four productive bug-class targets when fuzzing the Rust kernel surface: (1) `panic_bounds_check` firings at array-indexing sites in geometry pipelines; (2) integer-overflow-checked-arithmetic divergences from C++ behaviour (Rust panics on overflow in debug builds, wraps in release -- check your build profile); (3) allocator-out-of-memory at the `wdk-alloc` boundary, where `ExAllocatePool2` can return `NULL` under pressure; (4) mismatches at `unsafe`-block invariants where a Rust safe wrapper trusts an assertion the C kernel does not actually guarantee.

10.2 For Windows driver developers evaluating Rust

The setup recipe for windows-drivers-rs:

Clone microsoft/windows-drivers-rs and microsoft/Windows-rust-driver-samples [@windows-drivers-rs; @windows-rust-samples].
Install a recent stable rustc with the x86_64-pc-windows-msvc toolchain.
Install the Windows Driver Kit (WDK) from Microsoft Learn.
Install LLVM 17. Not LLVM 18 (ARM64 bindgen bug); LLVM 19 is the awaited fix [@windows-drivers-rs].
Install cargo-make.
Enter an eWDK developer prompt so MSBuild and the WDK environment variables are present.
cargo install cargo-wdk (or take the version published on crates.io as of November 2025) [@techcommunity-rust-drivers].

{// The shape of the manifest documented in microsoft/windows-drivers-rs README. const cargoToml = [ "[package]", "name = \\"example-driver\\"", "version = \\"0.1.0\\"", "edition = \\"2021\\"", "", "[lib]", "crate-type = [\\"cdylib\\"]", "", "[profile.dev]", "panic = \\"abort\\"", "lto = true", "", "[profile.release]", "panic = \\"abort\\"", "lto = true", "", "[dependencies]", "wdk = \\"*\\"", "wdk-sys = \\"*\\"", "wdk-alloc = \\"*\\"", "wdk-panic = \\"*\\"", "", "[build-dependencies]", "wdk-build = \\"*\\"", "", "[package.metadata.wdk.driver-model]", "driver-type = \\"KMDF\\"", "kmdf-version-major = 1", "target-kmdf-version-minor = 33" ].join("\\n"); console.log(cargoToml);}

KMDF 1.33-era bindings are on crates.io. WDM and UMDF are possible with wdk-build modification but are not the documented happy path [@windows-drivers-rs]. The WHCP certification path is not yet greenlit for production third-party Rust drivers [@register-2025-09-04]. When not to choose Rust: driver classes with mature, well-fuzzed C and C++ equivalents, small attack surfaces, and broad cross-vendor deployments where churn cost outweighs Rust's safety benefits. The first generation of production third-party Rust drivers will likely be filter drivers, virtual-device drivers, and parsers for untrusted formats -- exactly the surfaces where Microsoft's own first-party Surface drivers have shipped [@winbuzzer-surface; @thurrott-rust].

10.3 For security architects

Strategic frame: treat Rust adoption as a long-term policy lever, not a near-term mitigation. For the next five years, assume the kernel is still 95%+ C and C++. Treat in-kernel Rust as incremental risk reduction at the modules where it lands -- the GDI region engine, the EMF parser, future surfaces around metafile and graphics parsing, possibly virtualization plumbing. Treat the unsafe-FFI boundary as the audit frontier; concentrate fuzzing, code review, and CodeQL-Rust analysis there. Rely on the existing mitigations stack -- HVCI, CFG, XFG, CET, Driver Verifier, WDAC -- as defence-in-depth that Rust does not replace [@learn-cfg; @learn-gs; @learn-dep]. Plan for the panic-as-BSOD class as the new DoS surface, and architect monitoring (event-log mining for SYSTEM_SERVICE_EXCEPTION rates, fleet telemetry for Rust-panic markers) accordingly.

10.4 For security researchers fuzzing the Rust kernel surface

Check Point's methodology is the public reference [@checkpoint-dof]; the productive bug classes and the WinAFL + WinAFL-Pet + BugId + MemProcFS pipeline are described in §10.1 above. Two items are specific to the Rust kernel surface and worth adding here. First, integrate CodeQL's Rust query pack once 2.22.1+ ships in your build pipeline -- only 2.21.4 is WHCP-validated today [@register-2025-09-04]. Second, the empirical companion-CVE pattern: the same Check Point campaign that surfaced "Denial of Fuzzing" also produced several C/C++ GDI vulnerabilities (CVE-2025-30388, CVE-2025-53766, CVE-2025-47984), which suggests there is more to find in the GDI region of Win32k regardless of language [@checkpoint-drawn].

11. Frequently Asked Questions

No. Microsoft's stated policy is "memory-safe by default for newly written code" plus targeted rewrites of high-blast-radius modules. The legacy C and C++ kernel is not being rewritten on any announced timeline. Galen Hunt's "1 engineer, 1 month, 1 million lines of code" framing is a research target inside Microsoft's CoreAI group; Frank X. Shaw, head of Microsoft's communications, confirmed within days of the December 2025 LinkedIn post that the company has no plan to rewrite Windows 11 using AI [@windowslatest-galen; @infoworld-not-rewriting; @register-2025-12-24]. No. Rust eliminates the memory-corruption CVE class *in the modules it covers*. It does not eliminate logic bugs, race conditions, or denial-of-service vulnerabilities. Check Point Research's "Denial of Fuzzing" disclosure -- patched in KB5058499 on 28 May 2025 -- is the dispositive case. Rust correctly detected an out-of-bounds access in `region_from_path_mut()` inside `win32kbase_rs.sys`; because `panic = "abort"` is mandatory in `no_std` kernel binaries, the response was a system-wide BSOD rather than a remote code execution [@checkpoint-dof; @kb5058499]. No. DWriteCore is user-mode code distributed through the Windows App SDK 1.2 and above. The kernel-mode Rust binary is `win32kbase_rs.sys`. The two are often conflated in secondary coverage because David Weston announced both at BlueHat IL 2023 on the same slide deck. DWriteCore is roughly 152,000 lines of Rust plus 96,000 lines of C++; `win32kbase_rs.sys` is the in-kernel piece, originally about 36,000 lines [@register-2023-04-27]. No. The public Microsoft GitHub repository is `microsoft/windows-drivers-rs`. The crate suite contains six crates named `wdk`, `wdk-sys`, `wdk-alloc`, `wdk-build`, `wdk-panic`, and `wdk-macros`. The Cargo subcommand is `cargo-wdk`. There is no "WDR" abbreviation in the official Microsoft naming. The companion samples repository is `microsoft/Windows-rust-driver-samples` [@windows-drivers-rs; @windows-rust-samples]. No. The originating talk was Matt Miller's at BlueHat IL in early February 2019, titled *Trends, Challenges, and Shifts in Software Vulnerability Mitigation*. The deck is in the `microsoft/MSRC-Security-Research` GitHub repository. Weston and Mark Russinovich later operationalised the figure in their own talks. The Microsoft Security Response Center re-stated it in plain prose in two essays in July 2019 [@miller-bluehat-2019; @msrc-proactive-2019; @msrc-safer-2019; @infoq-mitigating]. No. OpenVMM is a separate modular Rust VMM whose primary 2026 production deployment is as the OpenHCL paravisor for AMD SEV-SNP and Intel TDX confidential virtual machines [@openvmm-github; @phoronix-openhcl]. Hyperlight is the Azure-side production Rust micro-VMM with sub-2-millisecond cold-start times. The in-Windows Hyper-V Virtualisation Service Provider (VSP) front-end's Rust status has not been publicly announced; that is Open Problem P6 in the article's frontier section [@newstack-russinovich].

<StudyGuide slug="rust-in-the-windows-kernel-2026-field-guide" keyTerms={[ { term: "win32kbase_rs.sys", definition: "The first Rust-implemented Windows kernel binary; contains the Win32k GDI region/shape engine and, by 2025, parts of the EMF/EMF+ metafile parser." }, { term: "panic = abort", definition: "The Rust compilation profile that converts a panic into an immediate abort rather than stack unwinding; mandatory for no_std kernel binaries." }, { term: "no_std", definition: "Rust crate attribute opting out of the standard library; required for kernel binaries because std assumes OS services the kernel itself provides." }, { term: "GlobalAlloc", definition: "The Rust trait for the global memory allocator; in kernel Rust it is implemented by wdk-alloc over ExAllocatePool2/ExFreePoolWithTag." }, { term: "FFI", definition: "Foreign Function Interface; the ABI-crossing mechanism by which Rust calls C kernel functions. Every FFI call in kernel Rust is an unsafe block." }, { term: "CFI", definition: "Control-Flow Integrity; the mitigation family (CFG, XFG, CET) that defends the control-flow graph; by construction blind to data-only attacks." }, { term: "DOP", definition: "Data-Oriented Programming; Hu et al. (IEEE S&P 2016) proved data-only attacks are Turing-complete and invisible to every CFI variant." }, { term: "IRQL", definition: "Interrupt Request Level; the Windows kernel per-CPU priority. At IRQL >= DISPATCH_LEVEL a panic has nowhere to go except the system bugcheck." } ]} />

The article's smallest claim is also its largest. Rust is in the Windows kernel today, in production, with a real binary you can list at a real path. The article's largest claim is its smallest. The realistic ten-year shape is not a Windows rewrite; it is a policy that compounds, over decades, across modules whose authors choose Rust on first contact. The most defended forward posture combines Rust for new code, targeted rewrites of high-blast-radius modules, CHERI-class hardware capabilities where silicon supports them, and the existing mitigations stack as the patient defence-in-depth backstop. Each piece is partial. The combination is the answer to the 70-percent figure that Matt Miller stood up and named in Tel Aviv in early February 2019.

Now go check C:\Windows\System32\win32kbase_rs.sys. It is there.

The Driver That Was Signed and the Driver That Won't Load: Windows Kernel Code Integrity, 2006-2026

noreply@paragmali.com (Parag Mali) — Thu, 14 May 2026 00:00:00 GMT

**Windows ships a list of Microsoft-signed drivers it refuses to load.** That list -- `DriverSiPolicy.p7b` -- exists because every previous generation of kernel-driver trust assumed a signed driver was a safe driver, and a twenty-year run of Bring-Your-Own-Vulnerable-Driver attacks (Stuxnet, Capcom.sys, RTCore64.sys, gdrv.sys) proved that assumption wrong. The 2026 default-on stack -- KMCS, the block list, HVCI in VTL1, Smart App Control, and Defender ASR coverage -- is five gates doing what one ideal gate cannot do: name the specific weakness, not just the publisher. The architectural gap that motivates the stack is undecidable in principle and will not close.

1. The Driver That Loaded

On 13 September 2016, the researcher Matt Nelson posted on his enigma0x3 blog that a Capcom-published kernel driver, Capcom.sys, exposed IOCTL 0xAA013044 and used it to execute a user-supplied function pointer in kernel mode, with SMEP disabled along the way [@gh-tandasat-capcom] [@gh-tandasat-capcom]. Within two weeks the technique was operational in Metasploit. Later in September 2016, Capcom pushed the same driver to Street Fighter V's entire installed base as part of an anti-cheat update; in October 2016, Satoshi Tanda published the canonical standalone exploit on GitHub. Capcom withdrew the SFV driver shortly after, but the bytes were already in the wild.The often-told version of this story compresses three distinct events into one. Matt Nelson's Let's Be Bad Guys post on 13 September 2016 disclosed the IOCTL number and the function-pointer-execution primitive. OJ Reeves opened the canonical Metasploit pull request, rapid7/metasploit-framework#7363 [@gh-msf-pr-7363], shortly after; the PR was created on 27 September 2016 and merged the following day [@gh-msf-pr-7363]. Satoshi Tanda's tandasat/ExploitCapcom repository was first published in October 2016 and is the canonical standalone PoC, and the artefact this article cites for the IOCTL number and SHA-1 hash.

The driver was properly Authenticode-signed. It chained to a Microsoft-recognised root. It loaded cleanly on every default-configured Windows 7, 8.1, and 10 machine in the world.

That is the puzzle this article exists to answer. How does an operating system whose entire kernel-loading policy is was this binary signed? answer a vulnerability whose only failure mode is yes, by a real publisher, doing exactly what the signature says it does?

A class, not an incident

Capcom.sys was not the first signed kernel driver with a primitive IOCTL, and it would not be the last. The pattern recurs across two decades and is the through-line of this article. The catalogue includes Micro-Star's RTCore64.sys (the kernel component of MSI Afterburner), Gigabyte's gdrv.sys, and the KProcessHacker driver shipped with Process Hacker. Section 4 walks through each one with its primary disclosure record.

The attack class has a name. Bring Your Own Vulnerable Driver, or BYOVD. The adversary does not need to find a kernel zero-day. They need to find one signed driver, anywhere, whose interface is unsafe by design, and to ship it.

Key idea: Windows in 2026 ships a curated list of Microsoft-signed drivers it refuses to load. Understanding that list is understanding why every previous attempt to make kernel-mode trust mean safety instead of just identity eventually broke.

The current Windows 11 22H2 client honours %windir%\system32\CodeIntegrity\DriverSiPolicy.p7b, a Microsoft-signed deny list enforced by a hypervisor-isolated code-integrity engine sitting in Virtual Trust Level 1. The same engine refuses to map any kernel page that is simultaneously writable and executable. Both behaviours are documented on Microsoft Learn's Memory Integrity page [@ms-hvci-vbs] and the Microsoft-recommended driver block rules page [@ms-driver-block-rules] [@ms-hvci-vbs] [@ms-driver-block-rules]. Neither existed in 2006.

To understand why Windows now refuses to load drivers it once asked Microsoft to sign, we need to go back thirty years to the moment Windows first asked a publisher to sign anything at all.

2. Advisory Trust: 1996 to 2005

For its first decade, the Windows driver signing policy was a polite recommendation.

Microsoft shipped its first user-mode code-signing primitive, Authenticode, in 1996, packaged for developers in the same tool kit that gave us SignTool, MakeCat, and Inf2Cat -- the suite Microsoft Learn still documents under "Cryptography tools" [@ms-crypto-tools] [@ms-crypto-tools]. Authenticode wrapped a PKCS#7 signature around the SHA-1 (and later SHA-256) hash of a PE image and let a recipient walk the signer's certificate chain to a trusted root. It was the first answer to the question who shipped this binary? It was, deliberately, never an answer to is this binary safe?

Microsoft's PKCS#7-based code-signing format for Windows binaries. Authenticode attests to the publisher's identity by binding the binary's hash to a certificate chain anchored at a trusted root. It does not analyse the program's behaviour.

For drivers, the user-mode signing primitive was paired with a separate quality program. The Windows Hardware Quality Labs programme, documented today via the Hardware Lab Kit [@ms-hlk], tested third-party drivers against a Microsoft-curated compatibility suite and rewarded passing drivers with a counter-signature, eventually surfaced as the "Designed for Windows" or "Certified for Windows" mark [@ms-hlk]. The badge was operationally meaningful for OEM badging and Windows Update distribution. It was not a load-time gate. An unsigned .sys file dropped on disk by a setup script still loaded.

Microsoft's compatibility-test programme for third-party drivers. A driver that passes the HLK test suite receives a Microsoft counter-signature and is eligible for OEM and Windows Update distribution. The programme produces a quality signal, not a load-time enforcement decision.

The SetupAPI prompt

On 32-bit Windows, the gate the user actually saw was the SetupAPI driver-installation prompt. The administrator could set the system to Ignore, Warn, or Block unsigned drivers; the default was Warn. Warn meant a click-through dialog at install time. An administrator who clicked Install this driver anyway loaded the unsigned driver, no further questions asked. The structural truth is the one Microsoft's modern KMCS policy page [@ms-kmcs-policy] acknowledges by contrast: under advisory policy, the prompt is the policy, and a prompt is exactly as strong as the user clicking past it [@ms-kmcs-policy].

The Sony BMG XCP incident in October 2005 made the structural weakness concrete. The XCP copy-protection software, shipped on retail audio CDs, autorun-installed an unsigned kernel-mode filter driver. The driver hid any file, registry key, or process whose name began with the string $sys$ -- a textbook rootkit by capability if not by intent. The driver loaded after an administrator clicked through the warning prompt, exactly as advisory policy allowed. The pattern is described well in Wikipedia's code-signing article [@wp-code-signing] [@wp-code-signing].The Sony BMG XCP rootkit triggered class-action lawsuits, FTC settlements, and an industry-wide reconsideration of what "the user clicked OK" actually authorises. From a kernel-trust perspective, the lesson is narrower: any policy that ends in a dismissible dialog has the same threat model as no policy at all, against an attacker who can show the user a dialog.

The structural takeaway from 1996 through 2005 is the one the next decade tried to repair. When the signing policy is advisory, an attacker who has -- or can socially engineer -- administrator privilege only needs to dismiss a prompt to load a kernel driver. The signing primitive worked. The policy around the primitive did not.

If the prompt is the only thing between an attacker and ring zero, the kernel itself has to take over. And on a brand-new x64 architecture, Microsoft could break backward compatibility to make that happen.

3. KMCS: The Vista x64 Revolution (2006-2016)

In November 2006, Vista x64 made a decision that x86 never could: it refused to load any unsigned kernel driver, full stop.

The mechanism was Kernel-Mode Code Signing, or KMCS. The previous-versions Microsoft Learn page on Vista-era driver signing [@learn-microsoft-com-design-dn653567vvs85]) records the policy [@ms-dn653567]. At the point where the I/O manager called IoLoadDriver, the Code Integrity module (ci.dll) intercepted the load, extracted the Authenticode signature embedded in the PE image or attached via a published catalogue, walked the certificate chain, and refused to map the image if the chain did not terminate at a Microsoft-trusted root. There was no SetupAPI prompt to dismiss. If the kernel refused, the kernel refused. The decision lived below the user's reach.

The Vista-era mandatory load-time signature policy on 64-bit Windows. Before mapping a kernel driver's PE image, the Code Integrity module verifies that the image's Authenticode signature chains to a Microsoft-trusted root. Drivers that fail the check are refused at load time, not at install time.

x86 kept the advisory policy. Microsoft could not break compatibility with two decades of unsigned drivers on the dominant platform. But x64 was a young architecture with a few hundred drivers in the field, and Microsoft used that moment to flip the default. The structural shift was real: kernel-driver trust on x64 became a property of the binary, decided in the kernel, against a fixed set of trusted roots.

Cross-certificates: opening the gate to the world

A Microsoft-trusted root alone would have meant Microsoft signs every driver, which Microsoft did not want. Instead Microsoft cross-certified a small set of commercial code-signing certificate authorities -- including VeriSign, DigiCert, Entrust, GlobalSign, GoDaddy, and several smaller successors enumerated on the historical cross-certificate list (2020 archive) [@ms-cross-cert-archive] -- so that a publisher could buy a code-signing certificate from a commercial CA, sign their driver, and have the chain still terminate at a Microsoft-recognised root [@ms-cross-cert-archive]. The architecture is documented on the cross-certificates for kernel-mode code signing page [@ms-cross-cert], which now opens with a sentence that did not exist in 2006: "Cross-signing is no longer accepted for driver signing" [@ms-cross-cert]. We will come back to that.

sequenceDiagram participant IO as I/O Manager participant CI as Code Integrity (ci.dll) participant CA as Cross-certified CA chain participant Root as Microsoft trusted root

IO->>CI: Map PE for kernel driver
CI->>CI: Extract Authenticode signature (PKCS#7)
CI->>CA: Walk certificate chain
CA->>Root: Anchor at Microsoft cross-cert
alt Chain valid and not revoked
    CI->>IO: Allow section creation
    IO->>IO: Load driver into kernel address space
else Chain invalid or unsigned
    CI->>IO: STATUS_INVALID_IMAGE_HASH
    IO->>IO: Abort load
end

Documented escape hatches

KMCS shipped with three documented bypasses for developers and special cases, all enumerated on the KMCS policy page [@ms-kmcs-policy] [@ms-kmcs-policy]:

bcdedit /set TESTSIGNING ON enables test-signing mode. The kernel will load drivers signed with self-issued test certificates. The cost is a desktop watermark.
The F8 advanced-boot option Disable Driver Signature Enforcement turns off KMCS for one boot.
The legacy nointegritychecks BCD flag disables enforcement entirely, but is rejected on systems where Secure Boot is on.

Each of these was a development workflow concession. Each of them, with admin privileges and a willingness to reboot, also serves as a kernel-driver loading path for an attacker who has already escalated. The policy holds against unprivileged adversaries. Against an attacker who already runs as administrator, the policy was already, by 2010, defending against a different threat than the one people thought it was defending against.Microsoft has been formally clear about this since at least 2016: the administrator-to-kernel transition is not a security boundary in the MSRC servicing-criteria sense. Elastic Security Labs writes the position out explicitly in their analysis of vulnerable-driver mitigations [@elastic-admin] [@elastic-admin]. The historical irony is that Vista x64 KMCS was widely read at the time as a defence against admin-level adversaries; it was actually a defence against unprivileged or pre-admin ones.

PatchGuard: the parallel runtime defence

KMCS was a load-time check. The runtime parallel arrived in 2005 with Kernel Patch Protection, informally PatchGuard or KPP, which the Wikipedia entry on Kernel Patch Protection [@wp-kpp] describes as a feature of 64-bit Windows that prevents patching of critical kernel structures [@wp-kpp]. KPP polls a set of integrity-critical kernel objects -- the System Service Descriptor Table, IDT, GDT, certain function prologues -- and triggers a bug check if it detects tampering. It is the watchdog against runtime modification of the kernel by code that has already loaded; KMCS gates what loads in the first place.

What this fixed: the unsigned-driver-loading path closed on 64-bit Windows in production mode. Kernel rootkits of the early 2000s -- FU, Mailbot, Rustock, and their contemporaries, widely documented in the security-research literature of the era -- could no longer ship as bare .sys files an admin script dropped on disk. The structural class of "unsigned kernel rootkit" effectively died on x64.

But the day Vista x64 shipped, two new attack surfaces opened up. The first one Stuxnet found four years later. The second one nobody had a name for yet.

4. Stuxnet, BYOVD, and the Two Things Vista Did Not Fix

On 17 June 2010, researchers in Belarus and Iran identified Stuxnet, a worm targeting supervisory control and data acquisition systems [@wp-stuxnet] used in industrial-control environments [@wp-stuxnet]. Two of its drivers carried perfectly valid Authenticode signatures.

The signatures were genuine. The certificates were not. Stuxnet had been signed with private keys stolen from semiconductor vendors whose code-signing certs chained to legitimate cross-certified roots. KMCS verified the chain, found it good, and let the drivers load.Stuxnet is widely reported to have used stolen signing keys from two real semiconductor vendors. The malware-analysis literature is consistent on the pattern; specific cert-holder attributions are reproduced in many places but the primary advisory record we cite here is the Wikipedia Stuxnet article [@wp-stuxnet] and the general framing in the Wikipedia code-signing article [@wp-code-signing] [@wp-stuxnet] [@wp-code-signing]. The reactive answer was certificate revocation, but revocation propagates through Windows on a schedule, not instantly, and the cached chain on millions of machines remained valid for days.

That was the first failure mode KMCS could not block by design. The signature primitive answers was this signed by a key that chains to a trusted root? It cannot answer was the key still in the publisher's control when it signed this?

The Capcom.sys reframe

The second failure mode arrived publicly in 2016. A Capcom driver shipped via a Street Fighter V update exposed an IOCTL, numbered 0xAA013044, that took a user-supplied function pointer and executed it in kernel mode -- with Supervisor Mode Execution Prevention (SMEP) disabled while it did so. The driver was signed and chained correctly. Satoshi Tanda's standalone proof of concept at tandasat/ExploitCapcom [@gh-tandasat-capcom] remains the canonical reference, including the SHA-1 of the binary (c1d5cf8c43e7679b782630e93f5e6420ca1749a7) [@gh-tandasat-capcom].

There was nothing for KMCS to catch. The driver did exactly what the signature said it did: ship bytes from a publisher Microsoft could identify. The signature has no opinion about the IOCTL surface.

A signed driver means only that someone Microsoft can identify shipped this binary. It does not mean the driver lacks a function-pointer IOCTL.

That observation is the first of three reframes in this article and the easiest to underestimate. Up to 2010 the conventional security reading of a Microsoft-rooted Authenticode signature was that the driver had passed a review. After Stuxnet, the reading narrowed to the publisher is identifiable. After Capcom.sys, it narrowed again to the binary's identity is verifiable. None of these readings includes the binary does not have a kernel-write primitive in its IOCTL handler.

An attack pattern in which an adversary, having obtained or already holding administrator privileges, installs a signed but design-vulnerable third-party kernel driver and uses its exposed primitives -- arbitrary memory read/write, port I/O, MSR access, or function-pointer dispatch -- to gain ring-zero capability. The signature primitive does not refuse the load because the driver is, on signature alone, legitimate.

The catalogue grows

The BYOVD catalogue accumulated through the 2010s.

RTCore64.sys, the kernel component of MSI's Afterburner overclocking utility, exposed read/write access to arbitrary kernel memory, I/O ports, and Model-Specific Registers from user mode. The NVD entry for CVE-2019-16098 [@nvd-cve-2019-16098] is unusually direct: "These signed drivers can also be used to bypass the Microsoft driver-signing policy to deploy malicious code." [@nvd-cve-2019-16098] The driver became a workhorse for ransomware crews. Sophos's October 2022 incident analysis of BlackByte's new variant [@sophos-blackbyte] documents the abuse: BlackByte "abus[ed] a known vulnerability in the legitimate vulnerable driver RTCore64.sys" to disable "a whopping list of over 1,000 drivers on which security products rely to provide protection" [@sophos-blackbyte].

gdrv.sys, the Gigabyte APP Center driver, exposed a ring-zero memcpy-equivalent that a local attacker could use to overwrite arbitrary kernel addresses. CVE-2018-19320 [@nvd-cve-2018-19320] is on CISA's Known Exploited Vulnerabilities catalogue [@nvd-cve-2018-19320]. The RobinHood ransomware abused it during the 2019 Baltimore municipal-government attack -- a connection widely documented by Sophos and CrowdStrike incident-response teams, though absent from the bare NVD record.

KProcessHacker, the kernel companion to the Process Hacker administration tool, exposed a process-termination primitive that bypassed even the Protected Process Light (PPL) shielding around antivirus and EDR processes. CrowdStrike's DoppelPaymer write-up [@cs-doppelpaymer] documents the abuse explicitly: "the hijacking technique ... leverages ProcessHacker's kernel driver, KProcessHacker, that has been registered under the service name KProcessHacker3 ... terminate processes, including those protected by Protected Process Light (PPL)." [@cs-doppelpaymer]

sequenceDiagram participant Adv as Adversary (admin user mode) participant SCM as Service Control Manager participant CI as Code Integrity (ci.dll) participant Drv as Signed vulnerable driver participant K as Kernel state

Adv->>SCM: Install signed driver as kernel service
SCM->>CI: Request load
CI->>CI: Authenticode check passes
CI->>SCM: Allow
SCM->>Drv: Load into kernel
Adv->>Drv: IOCTL with attacker-supplied pointers
Drv->>K: Write attacker bytes at arbitrary kernel address
K->>K: Clear EDR notify routine / escalate token

The third bypass: patching the policy from kernel mode

There is a third failure mode that closes the loop. Once an attacker has a signed driver with an arbitrary kernel-write primitive, they can write directly into the in-kernel Code Integrity state. The variable of interest is g_CiOptions, an integer inside ci.dll whose bits gate Driver Signature Enforcement. TrustedSec describes the technique cleanly: "this configuration variable has a number of flags that can be set, but typically for bypassing DSE this value is set to 0, completely disabled DSE and allows the attacker to load unsigned drivers just fine." [@trustedsec-gcioptions] Set g_CiOptions to zero and the subsequent driver loads do not need signatures at all. The signed driver, in effect, is a one-shot key that opens the gate for any unsigned driver behind it. The pattern recurs through the early 2020s; specific malware-family attributions remain research-folklore, but the technique class is well attested in TrustedSec's account.

The structural takeaway: KMCS verifies who signed, never what was signed. Once an attacker has a signed driver with a write primitive, they have ring zero. Stricter signing closes the front door for new malicious drivers. Every commercial-CA cert that was ever issued is still loadable. The policy decision has to move out of the attacker's reach. And the kernel itself has to stop being the thing that decides.

5. Microsoft as the Only Signer (2016-2024)

In August 2016, Microsoft did something the WHQL programme had refused to do for twenty years: it became the only entity that could counter-sign a new Windows kernel driver.

The transition shipped with Windows 10 version 1607. The KMCS policy page [@ms-kmcs-policy] records the cut precisely: for end-entity certificates issued after 29 July 2015, the chain had to terminate at one of three Microsoft-owned roots -- Microsoft Root Authority 2010, Microsoft Root Certificate Authority, or Microsoft Root Authority -- and the binary had to be counter-signed via the Windows Hardware Dev Center submission portal [@ms-kmcs-policy]. The commercial CAs were out. Microsoft was in, as the single point through which any new third-party kernel driver had to pass.

Two pipelines

Behind the portal sat two submission paths. The HLK/WHQL path required a full Hardware Lab Kit compatibility test pass on the publisher's hardware -- the lab kit is the modern incarnation of the WHQL programme, documented on Microsoft Learn [@ms-hlk] [@ms-hlk]. A passing run produced a "Certified for Windows" mark and made the driver eligible for OEM badging and Windows Update distribution. The lighter-friction path, called attestation signing [@ms-attestation], did not require an HLK run [@ms-attestation]. The publisher submitted a CAB containing the driver and supporting metadata. Microsoft's backend ran a malware scan and an automated policy check; if both passed, Microsoft applied a counter-signature. Attestation-signed drivers, the page notes, ship only to client SKUs.

The lower-friction post-2016 Microsoft signing path for Windows kernel drivers. The publisher uploads a CAB to the Hardware Dev Center; Microsoft runs malware scanning and an automated policy check; on pass, Microsoft applies its counter-signature. The path replaces full HLK testing for client-only drivers.

EV certificates as the account-binding primitive

Both paths required the publisher to hold an Extended Validation code-signing certificate. The EV cert does not sign the driver image itself; it signs and binds the Hardware Dev Center submission. That gives Microsoft a real-name handle on every kernel-driver publisher. EV certificates ride a strong identity check, cost meaningfully more than commercial OV certs, and live on a hardware token in the publisher's possession. The 2021 Microsoft Security blog announcing the Vulnerable & Malicious Driver Reporting Center spells the requirement out: "Kernel-mode driver publishers must pass the Hardware Lab Kit (HLK) compatibility tests, malware scanning, and prove their identity through extended validation (EV) certificates." [@ms-vdrc-blog]

flowchart LR A[Publisher EV cert + driver CAB] --> B[Hardware Dev Center upload] B --> C[Malware scan] C --> D{HLK required?} D -- "Yes" --> E[HLK compatibility test pass] D -- "No" --> F[Attestation policy check] E --> G[Microsoft counter-sign] F --> G G --> H[Optional Windows Update distribution]

The legacy long tail

The pivot to Microsoft-only signing closed the door for new drivers. It did not close the door for old ones.

The KMCS policy page [@ms-kmcs-policy] is candid about the carve-outs: "Cross-signed drivers are still permitted if any of the following are true: The PC was upgraded from an earlier release of Windows to Windows 10, version 1607. Secure Boot is off in the BIOS. Drivers was signed with an end-entity certificate issued prior to July 29th 2015 that chains to a supported cross-signed CA." [@ms-kmcs-policy]

Operationally, every signed-but-vulnerable driver from the 2006-2015 era remains loadable on a meaningful population of Windows machines: upgraded installs, devices with Secure Boot disabled in firmware, and drivers with pre-cutoff end-entity certs whose chains are still valid. Capcom.sys, RTCore64.sys, gdrv.sys, KProcessHacker -- the entire 2010s BYOVD catalogue -- continues to chain to roots Windows still accepts.

What attestation signing catches and what it does not

The malware scan inside attestation signing looks for known dangerous behaviour. The Microsoft Security blog post on the Vulnerable & Malicious Driver Reporting Center enumerates the categories the backend flags: "Drivers with the ability to read or write arbitrary kernel, physical, or device memory, including Port I/O and central processing unit (CPU) registers from user mode." [@ms-vdrc-blog] In other words, the scanner already understands the BYOVD pattern.

What it does not catch are novel design flaws. A driver whose IOCTL surface is structurally unsafe in a way the scanner does not have a signature for passes the scan and ships with a Microsoft counter-signature. The Capcom.sys pattern is in the scanner's repertoire today; the pattern in the next driver to ship is, by definition, not.

A second weakness sits on the publisher side. EV-key compromise -- whether through the LAPSUS$ supply-chain leaks of 2022 or other vendor incidents -- gives the attacker the Microsoft-only-signing flavour of the Stuxnet problem. The signed-by-Microsoft chain is exactly as strong as the EV key's safekeeping at the publisher.

One bottleneck for signing is an improvement. But the bottleneck still trusts the kernel that asks the question. As long as the policy engine runs in the same memory the attacker can write, the policy engine loses.

6. HVCI: Moving the Policy Out of Reach (2015-present)

In July 2015, Microsoft shipped a feature so structurally important that it took six years to become a consumer default, and so misunderstood that it still travels under three different names.

The names are the easiest place to start. Virtualization-Based Security (VBS) is the platform: a Hyper-V-rooted virtualisation layer that exists on every modern Windows installation that meets the hardware requirements. Hypervisor-protected Code Integrity (HVCI) is the kernel-code-integrity consumer of VBS. Memory Integrity is the label the Windows Security UI uses today. The Microsoft Learn page on Memory Integrity [@ms-hvci-vbs] is the canonical primary source [@ms-hvci-vbs]. TrustedSec called out the conflation explicitly in their g_CiOptions in a virtualized world post [@trustedsec-gcioptions] [@trustedsec-gcioptions].

Key idea: A security check that shares a trust domain with what it is checking has, by definition, already lost. HVCI moves the check out of the attacker's trust domain. It is the answer to who decides. It is not the answer to what gets decided.

That sentence is the second of this article's three reframes, and the one that makes everything that follows make sense.

VBS and the Virtual Trust Levels

On a VBS-on Windows machine, Hyper-V is the Type-1 hypervisor. The bootloader brings the hypervisor up first, the hypervisor brings up two execution environments side by side, and the normal Windows kernel runs in one of them while a much smaller Secure Kernel runs in the other.

The VBS abstraction that partitions a Windows installation into two execution environments. VTL0 is the normal Windows kernel and its drivers. VTL1 is a much smaller Secure Kernel and a curated set of "trustlets" -- isolated user-mode processes that hold the most sensitive secrets. VTL1 can read and write VTL0 memory; VTL0 cannot read or write VTL1 memory. Code-integrity policy lives in VTL1.

The Code Integrity engine on an HVCI-on machine -- signature verification and policy-file consultation -- runs inside VTL1's Secure Kernel as the Secure Kernel Code Integrity component, SKCI. The VTL0 kernel cannot read or write VTL1 memory by hardware construction: the hypervisor's second-level address translation tables, programmed before VTL0 ever runs, mark VTL1 pages as unreachable from VTL0. The in-memory g_CiOptions state continues to reside in ci.dll's VTL0 data section -- it does not relocate into VTL1 -- but on an HVCI-on machine Kernel Data Protection (KDP), exposed to VTL0 drivers as MmProtectDriverSection, asks the Secure Kernel to mark the containing page read-only at the SLAT level. A fully compromised VTL0 kernel -- with kernel debugging attached, with all of ring zero's privileges -- cannot rewrite g_CiOptions to zero, because the SLAT mapping refuses the write.

flowchart TD subgraph VTL1 [VTL1 -- Secure Kernel] SK[Secure Kernel] SKCI[SKCI -- Code Integrity] Policy["Code Integrity policy
(DriverSiPolicy.p7b)"] SK --> SKCI SKCI --> Policy end subgraph VTL0 [VTL0 -- Normal Windows] Kern[NT Kernel] Drv[Driver attempting load] CI[ci.dll user-side] Kern --> CI CI --> Drv end Hypervisor{"Hyper-V SLAT"} Kern -->|"Section create"| Hypervisor Hypervisor -->|"Forward"| SKCI SKCI -->|"Allow or deny"| Hypervisor Hypervisor -->|"Result"| Kern

W^X on kernel memory

There is a second, equally structural property HVCI enforces. When the VTL0 kernel tries to map an executable section -- to create a kernel-executable page from a PE image -- the hypervisor forces the request through SKCI. SKCI verifies the Authenticode signature at section creation time, not only at the IoLoadDriver entry point a load goes through later [@ms-hvci-vbs]. And SKCI refuses any page that is simultaneously writable and executable. The classic exploitation technique of allocating a writable kernel buffer, writing shellcode into it, and then jumping to it stops working: the page either is writable, in which case it is not executable, or is executable, in which case it is not writable.

The hardware acceleration matters. The Memory Integrity page [@ms-hvci-vbs] is unusually direct about the requirement: "Memory integrity works better with Intel Kabylake and higher processors with Mode-Based Execution Control, and AMD Zen 2 and higher processors with Guest Mode Execute Trap capabilities. Older processors rely on an emulation of these features, called Restricted User Mode, and will have a bigger impact on performance." [@ms-hvci-vbs]Mode-Based Execute Control (MBEC) is the Intel feature that lets the hypervisor distinguish "executable in supervisor mode" from "executable in user mode" at the page-table-entry level. AMD's Guest Mode Execute Trap (GMET) is the structurally equivalent feature. Older silicon falls back to Restricted User Mode emulation, which works correctly but pays a meaningfully larger performance tax. The hardware cutoff is a major reason HVCI defaulted off on pre-2017 OEM hardware for years.

What HVCI fixed

The g_CiOptions patching family, the third bypass we met in section 4, closes on HVCI-on systems. TrustedSec's post [@trustedsec-gcioptions] gives a clean account: g_CiOptions still lives in ci.dll's VTL0 data section, but Kernel Data Protection -- exposed to VTL0 drivers as MmProtectDriverSection -- asks the Secure Kernel in VTL1 to mark its containing page read-only at the SLAT level, so a VTL0 ring-zero write to it faults; the VTL0 kernel cannot rewrite the variable; live-kernel debuggers attached to VTL0 cannot rewrite it either [@trustedsec-gcioptions]. The arbitrary-write-to-disable-DSE pattern that worked on Windows 7 through pre-HVCI Windows 10 is, on an HVCI-on Windows 11, no longer a primitive that exists in the attacker's threat model. The trust domain that decides the policy is not the trust domain the attacker can reach.

What HVCI did not fix

It is essential to be clear about what HVCI does not catch, because misreading this is how the BYOVD class survives.

HVCI verifies the signature and enforces W^X. It does not analyse the driver's behaviour. The 2019 RTCore64.sys driver passes SKCI section-mapping unchanged: it is signed by MSI through a Microsoft-recognised chain, it has no writable-and-executable pages, and the Authenticode hash on disk matches the binary in memory. After it loads, an attacker in user mode sends an IOCTL; the driver, executing legitimately in ring zero, writes attacker-controlled bytes to an attacker-chosen kernel address; the EDR notify routine table is patched; the BYOVD attack proceeds. Everything that happens inside the IOCTL handler happens with kernel privilege, on properly-signed code paths, inside HVCI's W^X policy. The structural BYOVD class is unaffected.

That is the gap the next two sections close.

Note: The Memory Integrity page [@ms-hvci-vbs] is explicit that "some applications and hardware device drivers may be incompatible with memory integrity. This incompatibility can cause devices or software to malfunction and in rare cases may result in a boot failure (blue screen)." [@ms-hvci-vbs] For years OEM and gaming-system vendors shipped with HVCI off because legacy ISV drivers, anti-cheat kernel components, or older virtualisation tools could not coexist with it. On an HVCI-off system the g_CiOptions patching family is back in play, the kernel-CI engine and the kernel it polices are in the same trust domain, and the analysis of section 4 applies unchanged. The 2026 default-on baseline is real, but it is not yet universal.

HVCI is the answer to who decides. It is not the answer to what gets decided. We still need a way to say: this specific signed binary is one we do not trust.

7. The Block List: Naming the Weakness (2020-present)

In October 2020, Microsoft started shipping something it had spent twenty-five years avoiding: a list of specific drivers it would refuse to load by name.

The artefact lives at %windir%\system32\CodeIntegrity\DriverSiPolicy.p7b. The file is a PKCS#7-signed App Control for Business policy -- "WDAC" by its former name -- whose body consists of deny rules expressed at the granularity of file hash, file name, or publisher. The canonical Microsoft-recommended driver block rules page [@ms-driver-block-rules] is the primary source, and is unusually rich for a Microsoft Learn page [@ms-driver-block-rules].

Microsoft's policy-driven application-control engine. An App Control policy is a signed XML or binary file that lists allow rules, deny rules, and signer-level rules; at load time, the policy engine consults the rules and either allows or refuses the image. `DriverSiPolicy.p7b` is itself an App Control policy whose body is all deny rules.

Cadence and the published-vs-shipped gap

The block list is refreshed on two cadences. Microsoft publishes the source XML on the block-rules page [@ms-driver-block-rules] on a quarterly schedule and pushes the binary DriverSiPolicy.p7b to client devices through monthly Windows servicing [@ms-driver-block-rules]. Microsoft's Security Baselines team also publishes a running update post [@ms-tc-blocklist-baselines] cataloguing the changes [@ms-tc-blocklist-baselines].

The candid admission on the block-rules page [@ms-driver-block-rules] is the part of the story that is most worth understanding.

The blocklist included in this article and in the associated downloadable files usually contains a more complete set of known vulnerable drivers than the version in the OS and delivered by Windows Update. It's often necessary for us to hold back some blocks to avoid breaking existing functionality. -- Microsoft Learn, *Microsoft-recommended driver block rules* [@ms-driver-block-rules]

The published list is, on purpose, more inclusive than the shipped list. The reason is operational: every entry in the shipped list is a driver that would refuse to load on millions of devices, some of which have legitimate dependencies. Microsoft holds entries back when the compatibility cost is too high, even when the security signal is strong. We will come back to whether that gap is closeable in section 9.

The 22H2 cut and the Server 2016 carve-out

Two dates anchor the deployment story.

The block list was an optional feature in Windows 10 1809, enabled by default only on systems that ran Hypervisor-protected Code Integrity, Smart App Control, or Windows in S-mode [@ms-kb5020779] [@ms-kb5020779]. With the Windows 11 2022 Update, also known as 22H2 [@ms-blogs-win11-2022], released on 20 September 2022, default-on coverage extended to every client device, not just the HVCI-on subset [@ms-blogs-win11-2022]. The 22H2 release is the moment the block list became universal Windows client behaviour, six years after the first BYOVD primitive that motivated it.

The block-rules page [@ms-driver-block-rules] notes a single explicit carve-out worth flagging."Except on Windows Server 2016, the vulnerable driver blocklist is also enforced when either memory integrity (also known as hypervisor-protected code integrity or HVCI), Smart App Control, or S mode is active." [@ms-driver-block-rules] Windows Server 2016 does not get the default-on block list even when HVCI is on. An enterprise admin managing Server 2016 has to deploy an explicit App Control policy to get the same coverage. The October 2022 preview cycle saw a documented quirk -- KB5020779 [@ms-kb5020779] explains that a preview release shipped without an actual blocklist refresh, addressed by a subsequent servicing update [@ms-kb5020779].The KB5020779 episode is a useful reminder that the in-box block list ships through the same Windows Update cycle as everything else. Preview releases do not always carry a fresh policy, and the cadence on the block-rules page [@ms-driver-block-rules] describes the intended steady state rather than every individual update [@ms-driver-block-rules].

Naming the weakness, not the publisher

For the first time in the story, the question Windows asks at load time is not only who signed this binary? but also is this specific signed binary one we have learned is unsafe? The block list is a step the previous generations could not have taken with the primitives they had: it requires a deny list that can be authored after the fact, distributed quickly, and enforced inside a trust domain the attacker cannot reach. KMCS supplied the load-time enforcement primitive; HVCI supplied the immune-from-VTL0 enforcement context; only with both in place could DriverSiPolicy.p7b actually do its job.

flowchart TD A[Driver image requested for load] --> B[Hypervisor mediates section create] B --> C[SKCI verifies Authenticode chain] C --> D{"Chain OK?"} D -- "No" --> X[Refuse] D -- "Yes" --> E[Consult DriverSiPolicy.p7b deny rules] E --> F{"Hash, name, or signer on deny list?"} F -- "Yes" --> X F -- "No" --> G[Allow section creation] G --> H[Driver maps into kernel address space]

The Vulnerable & Malicious Driver Reporting Center

The block list grew faster after Microsoft built a structured channel to feed it. The December 2021 Microsoft Security blog post [@ms-vdrc-blog] announced the Vulnerable & Malicious Driver Reporting Center: a portal where researchers and vendors can submit kernel drivers for evaluation, backed by an automated analysis pipeline that looks for the BYOVD primitives -- "the ability to read or write arbitrary kernel, physical, or device memory, including Port I/O and central processing unit (CPU) registers from user mode." [@ms-vdrc-blog] The post explicitly lists the historical CVE backdrop that motivated the centre, naming RobinHood, Uroburos, Derusbi, GrayFish, and Sauron as families that leveraged driver vulnerabilities such as CVE-2008-3431, CVE-2013-3956, CVE-2009-0824, and CVE-2010-1592 [@ms-vdrc-blog].

The same post anchors the EV-certificate publisher requirement and the HLK or attestation gating that produces the block list's inputs in the first place. The reporting centre is the path by which a flagged driver moves from "spotted in research" to "deny rule in the next quarterly XML push".

Defender ASR as the HVCI-off coverage path

There is a third surface worth knowing about. Microsoft's Attack Surface Reduction rules [@ms-asr-rules] include "Block abuse of exploited vulnerable signed drivers" (56a863a9-875e-4185-98a7-b882c64b5ce5) as part of the standard ASR protection set [@ms-asr-rules]. For Microsoft Defender for Endpoint customers on Windows 10 E3 or E5, the rule covers machines where HVCI is not on. Microsoft notes that "the same blocklist is also used by Microsoft Defender Antivirus customers" via the ASR rule [@ms-vdrc-blog]. The path is narrower than HVCI-rooted enforcement -- Defender has to be running, the rule has to be enabled -- but it extends the block list to enterprise environments that have not yet flipped HVCI on.

LOLDrivers and the dual-use externality

The block list is not the only catalogue of vulnerable Windows drivers. The community-maintained LOLDrivers project [@loldrivers-io] -- "Living Off The Land Drivers" -- collects vulnerable, malicious, and known-malicious Windows drivers in one place. Every entry carries YAML metadata and where possible YARA, Sigma, ClamAV, and Sysmon rules, plus a pre-compiled App Control deny policy that can be deployed standalone [@gh-loldrivers] [@loldrivers-io]. As of the source verification for this article, LOLDrivers carried approximately 2,132 driver entries -- considerably more than the Microsoft-shipped list.

Check Point Research called out the dual-use problem in their 2024 piece [@cpr-byovd]: a public catalogue of vulnerable drivers is also a reading list for attackers. The same researchers ran the methodology in reverse: "we conducted a mass hunt for new drivers that may be vulnerable, uncovering thousands of potentially at-risk drivers." [@cpr-byovd] Defenders use the list for hardening; attackers use it for shopping. Both effects are real.

Note: Defenders who can tolerate compatibility risk can compile the source XML from the block-rules page [@ms-driver-block-rules] into an App Control policy and deploy it directly, picking up the entries Microsoft holds back from the in-box list. Optionally layer the LOLDrivers App Control policy [@gh-loldrivers] on top for community-curated coverage. Test in audit mode first -- both lists are more aggressive than the shipped baseline and may flag drivers your environment depends on [@ms-driver-block-rules] [@gh-loldrivers].

A WDAC rule evaluator, in miniature

The semantics of an App Control policy are simple enough to model in a few lines. Deny rules win; allow rules are consulted next; the default action handles whatever is left.

{` // Simplified model of the App Control / WDAC rule-evaluation engine. // Deny rules win, allow rules permit the remainder, and an explicit // default action handles images neither denied nor allowed.

const policy = { denyByHash: new Set(["c1d5cf8c43e7679b782630e93f5e6420ca1749a7"]), // Capcom.sys denyByName: new Set(["RTCore64.sys"]), denyBySigner: new Set(["CN=Some Compromised Publisher, O=Example"]), allowBySigner: new Set(["CN=Microsoft Windows, O=Microsoft Corporation"]), defaultAction: "BLOCK", };

function evaluate(image, policy) { if (policy.denyByHash.has(image.sha1)) return "BLOCK (hash on deny list)"; if (policy.denyByName.has(image.fileName)) return "BLOCK (name on deny list)"; if (policy.denyBySigner.has(image.signer)) return "BLOCK (signer on deny list)"; if (policy.allowBySigner.has(image.signer)) return "ALLOW (signer on allow list)"; return policy.defaultAction === "ALLOW" ? "ALLOW (default)" : "BLOCK (default)"; }

const cases = [ { sha1: "c1d5cf8c43e7679b782630e93f5e6420ca1749a7", fileName: "Capcom.sys", signer: "CN=CAPCOM Co., Ltd." }, { sha1: "0000000000000000000000000000000000000000", fileName: "RTCore64.sys", signer: "CN=Micro-Star International Co., Ltd." }, { sha1: "1111111111111111111111111111111111111111", fileName: "ntfs.sys", signer: "CN=Microsoft Windows, O=Microsoft Corporation" }, ]; for (const c of cases) console.log(c.fileName, "->", evaluate(c, policy)); `}

Naming the weakness is genuinely new. But the list only ever lists what someone has already found. The window between disclosure and enforcement is months, and Microsoft documents that the shipped list is by design weaker than the published one. What gets the rest of the way?

8. The 2026 Stack: Defence in Depth Made Concrete

On a default-configured Windows 11 22H2 machine in 2026, a kernel driver that tries to load passes through five distinct gates. Each one closes a blind spot the previous one cannot reach.

The order matters, and so do the dependencies. The gates are:

Kernel-Mode Code Signing. The Authenticode chain must terminate at a Microsoft-owned root. The chain check rejects unsigned drivers and drivers chained to non-Microsoft roots, except under the documented grandfathering carve-outs [@ms-kmcs-policy] [@ms-kmcs-policy].
The Vulnerable Driver Block List. SKCI consults DriverSiPolicy.p7b for hash, file-name, and signer-level deny rules. The list is default-on for every client device since Windows 11 22H2 [@ms-blogs-win11-2022], and is updated quarterly through Microsoft Learn's published source XML and monthly through Windows servicing [@ms-driver-block-rules] [@ms-blogs-win11-2022].
HVCI / SKCI. The Code Integrity engine runs in VTL1, verifies signatures at section-mapping time rather than only at IoLoadDriver, and enforces W^X on kernel memory. The policy engine is structurally out of reach of a fully compromised VTL0 kernel [@ms-hvci-vbs].
App Control / Smart App Control. Enterprise admins author explicit App Control allowlists; consumer devices on clean Windows 11 installs run Smart App Control [@ms-sac-faq], a Microsoft-authored allowlist policy backed by cloud reputation [@ms-sac-faq] [@ms-appcontrol].
Defender ASR. On Microsoft Defender for Endpoint deployments, the "Block abuse of exploited vulnerable signed drivers" ASR rule extends block-list coverage to HVCI-off environments [@ms-asr-rules].

The Windows 11 22H2+ consumer-facing front end for App Control for Business. SAC enforces a Microsoft-authored policy and supplements it with cloud reputation lookups from the Intelligent Security Graph. SAC is only available on clean installs and is shipped in evaluation mode by default; once turned on, it also unconditionally enforces the vulnerable driver block list [@ms-sac-faq]. The cloud-backed reputation service that Smart App Control consults to predict whether a given binary is safe. When confident, ISG approves the binary; when unconfident, SAC falls back to signature checks; absent both, the binary is blocked [@ms-sac-faq].

Orthogonality, not redundancy

The five gates look redundant from a distance. They are not. Each closes a class of failure the others cannot reach. The orthogonality is the reason for the stack.

Gate	Catches	Misses
KMCS	Unsigned and cross-cert-only-signed drivers	Signed-but-vulnerable drivers
Block list	Known-vulnerable signed drivers (post-disclosure)	Unknown-vulnerable signed drivers
HVCI / SKCI	`g_CiOptions`-patching from VTL0; writable+executable kernel pages	Behavioural BYOVD inside a properly-signed driver
WDAC / SAC	Anything not on the allowlist (enterprise) or unknown-reputation (consumer)	Allowlisted drivers with unknown defects
Defender ASR	Block-list entries on HVCI-off machines (where the rule is enabled)	Drivers not on Microsoft's blocklist

The matrix is the practical justification for the stack. If DriverSiPolicy.p7b had perfect coverage there would be no need for SAC; if SAC had a complete allowlist there would be no need for the block list; if HVCI proved driver safety rather than driver identity there would be no need for either. None of those preconditions hold, and section 9 explains why they cannot.

Smart App Control's particulars

SAC merits a few specifics because its behaviour differs from the rest of the stack in ways that surprise readers. First, it is consumer-facing and only available on clean Windows 11 installs -- an upgrade does not get SAC. Second, SAC ships in evaluation mode by default. Windows watches user behaviour, and if the user mostly runs cloud-reputable software, SAC quietly flips to enforce; if the user runs a lot of niche or self-developed software, SAC quietly flips to off. Third, until a 2024 servicing change [@ms-sac-faq] made SAC re-enableable from Windows Security, turning SAC off used to require a clean install to bring it back [@ms-sac-faq]. Fourth, on enterprise-managed devices, SAC turns itself off automatically after 48 hours; managed environments are expected to deploy WDAC instead [@ms-appcontrol].

The cold-start failure mode is worth knowing. A small independent hardware vendor whose driver has never been seen at scale lacks a cloud reputation when SAC asks about it. The fallback is signature, but a signed driver from an unknown publisher does not always clear SAC's confidence threshold. Small IHVs occasionally find their drivers blocked on consumer hardware running SAC for that reason alone.

flowchart TD A[Driver image requested] --> B[Gate 1: KMCS Authenticode chain] B --> C{"Microsoft-rooted?"} C -- "No" --> X[Refuse] C -- "Yes" --> D[Gate 2: DriverSiPolicy.p7b] D --> E{"On block list?"} E -- "Yes" --> X E -- "No" --> F[Gate 3: HVCI / SKCI section mapping] F --> G{"Signature OK, W^X satisfied?"} G -- "No" --> X G -- "Yes" --> H[Gate 4: App Control / SAC] H --> I{"On allowlist or reputable?"} I -- "No" --> X I -- "Yes" --> J[Gate 5: Defender ASR rule applicable] J --> K[Driver loads into VTL0 kernel]

Verifying what the machine actually does

The state of the stack on any given Windows machine is observable. The Win32_DeviceGuard WMI class exposes a SecurityServicesRunning array whose integer codes name the security services currently active. The aside below covers the practitioner-facing details.

Two commands answer most of the question. From an elevated PowerShell prompt, `Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard` returns a structure whose `SecurityServicesRunning` array enumerates the services in operation; a value of **1** indicates **Credential Guard**, a value of **2** indicates **HVCI / Memory Integrity**, and additional values cover newer services (System Guard Secure Launch, SMM Firmware Measurement, Kernel-mode Hardware-enforced Stack Protection, and Hypervisor-Enforced Paging Translation) [@ms-hvci-vbs]. `bcdedit /enum {default}` shows whether `hypervisorlaunchtype` is set to `Auto`, the prerequisite for VBS being on at all. The block list file itself lives at `%windir%\system32\CodeIntegrity\DriverSiPolicy.p7b`; if it is missing, the in-box list is not deployed on that machine. None of these tell you whether your Defender ASR rule is active without a separate `Get-MpPreference` check.

A toy decoder helps make the WMI surface concrete.

{` // Mirror of the integer codes the Win32_DeviceGuard WMI class reports // for SecurityServicesRunning. Documented on Microsoft Learn under // the Memory Integrity / HVCI guidance.

const SERVICE_NAMES = { 1: "Credential Guard", 2: "Hypervisor-protected Code Integrity (HVCI / Memory Integrity)", 3: "System Guard Secure Launch", 4: "SMM Firmware Measurement", 5: "Kernel-mode Hardware-enforced Stack Protection", 6: "Kernel-mode Hardware-enforced Stack Protection (Audit mode)", 7: "Hypervisor-Enforced Paging Translation", };

function explain(servicesRunning) { if (!servicesRunning.length) { return "No VBS-rooted security services are running on this device."; } return servicesRunning .map((code) => SERVICE_NAMES[code] || ("unknown service " + code)) .map((s) => " - " + s) .join("\n"); }

console.log("Sample 1: HVCI on, Credential Guard on"); console.log(explain([1, 2])); console.log("\nSample 2: nothing running"); console.log(explain([])); console.log("\nSample 3: full stack on a Secured-core PC"); console.log(explain([1, 2, 3, 4, 5])); `}

Five gates is a lot of work to do what one ideal gate could not. The reason for the inflation is uncomfortable: the one ideal gate cannot, in principle, exist.

9. The Undecidability Wall

Why does Windows need five layers to do what one perfect signature ought to do? Because the perfect signature is mathematically impossible.

The third reframe of this article is the one that turns engineering frustration into theoretical inevitability. The property of interest -- "this signed driver, when exercised through its IOCTL surface, can be coerced into giving an attacker an arbitrary kernel-write primitive" -- is a non-trivial semantic property of the driver's program text. Rice's theorem says that for any non-trivial semantic property of programs, the predicate is undecidable on the class of all programs. No algorithm exists that, in finite time, answers correctly for every input.

A useful way to state the bound: if $P$ is the set of all kernel drivers and $\text{Unsafe}(p) = 1$ iff driver $p$ exposes a kernel-write primitive through its IOCTL handler, then no total computable function $f: P \to {0, 1}$ satisfies $f = \text{Unsafe}$. Every approximation either over-blocks ($f(p) = 1$ when $\text{Unsafe}(p) = 0$, false positives, broken drivers) or under-blocks ($f(p) = 0$ when $\text{Unsafe}(p) = 1$, false negatives, BYOVD in the wild). The signing pipeline scans for the obvious cases; sophisticated dynamic analysers will catch more of the not-obvious cases; but the unrestricted version of the problem has no complete solution.

Key idea: Whether an arbitrary signed driver can be coerced into giving an attacker a kernel-write primitive is undecidable. No static signing scheme can ever block exactly the unsafe drivers. The Windows answer is therefore not a single perfect gate; it is defence in depth that narrows, but does not close, the gap.

Microsoft's formal acknowledgement

Microsoft has been formally clear about a related point for years: the administrator-to-kernel transition is not, in the MSRC servicing-criteria [@elastic-admin] sense, a security boundary [@elastic-admin]. Elastic Security Labs put the position in plain English: "the blocklist's deployment model can be slow to adapt to new threats, with updates automatically deployed typically only once or twice a year. Users can manually update their blocklists, but such interventions bring us out of 'secure by default' territory ... When determining which vulnerabilities to fix, the Microsoft Security Response Center (MSRC) uses the concept of a security boundary." [@elastic-admin]

Administrator-to-kernel is not a security boundary, in the MSRC servicing-criteria sense. The defence-in-depth mechanisms described here mitigate it; from the impossibility result, none can close it.

The MSRC framing is engineering policy. The undecidability result is theoretical inevitability. They land in the same place: an attacker who has administrator privilege, who can pick from the entire history of signed Windows drivers, who is patient, is not stopped by any number of signature checks. The defence-in-depth mechanisms make the attacker work harder; they raise the cost; they shrink the surface of viable signed drivers. They do not close the structural gap.

Closeable gaps and irreducible gaps

It is worth separating two kinds of gap.

The published-vs-shipped block list gap is a policy decision, not an engineering limit. Microsoft documents that "it's often necessary for us to hold back some blocks to avoid breaking existing functionality." [@ms-driver-block-rules]The published-vs-shipped gap is the closeable part. An administrator who can author or import an App Control policy can deploy the published XML directly and pick up Microsoft's full curation. The irreducible part of the gap sits behind it: even the published list lists only what someone has already disclosed. The undecidability result applies to finding unsafe drivers, not to listing known-unsafe ones. Defenders willing to accept compatibility risk can close it on their own machines today.

The gap that cannot close is the one between the published list and the universe of vulnerable drivers Microsoft has not yet learned about. That is where the undecidability result bites. No amount of pipeline tightening eliminates the class of design flaws whose recognition requires understanding what the driver's IOCTL handler will do under all possible inputs.

What static methods can achieve

Quantifying what the existing layers achieve is more useful than lamenting what they cannot. The complexity bounds for each layer are well-defined.

Authenticode signature verification is bounded below by one public-key operation and one cryptographic hash over the PE image, regardless of policy. SKCI's per-section cost is dominated by that constant. The Memory Integrity page is conspicuously silent on a published benchmark number; in practice the overhead is small but non-zero on Intel Kabylake-and-later or AMD Zen-2-and-later silicon with MBEC/GMET hardware acceleration, and meaningfully higher on the emulated Restricted-User-Mode fallback path that older silicon falls back to [@ms-hvci-vbs].

WDAC allowlist evaluation is $O(\log r)$ per image on $r$ rules with a hashed index, or $O(r)$ on the naïve linear scan; the deny-rule check in DriverSiPolicy.p7b follows the same bound.

The gap between achievable static enforcement and the ideal "block all and only the unsafe drivers" is, in the limit, irreducible.

Three axes that can be improved

If the gap cannot close, it can be narrowed along three independent axes -- and the improvements that matter, look like one of these:

Reactiveness. The disclosure-to-enforcement latency is months today. Forthcoming WHCP submission-time analyses can compress it.
Coverage of unknown-bad signed drivers. Reputation, allowlists, and dynamic analysis at scale extend coverage beyond what a static deny list lists.
Visibility into binary contents. SBOMs answer "what is inside this driver?" -- a question the signature alone never asked.

Each axis is the answer to a different blind spot. None substitutes for another. Section 11 returns to the SBOM axis specifically because it is the one Microsoft is building into the submission flow right now.

Static signing has hit a wall it cannot push through. The only way forward is to widen the question. Two of the answers exist on other operating systems. The third is being built now.

10. The Other Two Operating Systems

Linux solved the signing half and pushed the curated-denylist half down to distribution vendors. macOS solved both by making third-party drivers stop being drivers.

Linux: signatures without a curated denylist

Linux has supported in-kernel module signing since version 3.7 (December 2012), under the configuration symbol CONFIG_MODULE_SIG. The kernel documentation [@docs-kernel-module-sig] catalogues the supported algorithms: "The built-in facility currently only supports the RSA, NIST P-384 ECDSA and NIST FIPS-204 ML-DSA public key signing standards." [@docs-kernel-module-sig] The choice of signature scheme is a build-time decision, and the kernel can be told to use a key embedded in the kernel image, a key loaded into the trusted keyring at runtime, or a Machine Owner Key managed by shim and the platform's UEFI boot stack.

The structural decision that matters is the enforcement mode. CONFIG_MODULE_SIG_FORCE is the toggle. The kernel documentation describes the two settings cleanly: "If this is off (ie. 'permissive'), then modules for which the key is not available and modules that are unsigned are permitted, but the kernel will be marked as being tainted ... If this is on (ie. 'restrictive'), only modules that have a valid signature that can be verified by a public key in the kernel's possession will be loaded." [@docs-kernel-module-sig]

Most mainstream distributions ship permissive: unsigned modules taint the kernel but load. The defender-shipping-restrictive-enforcement model is real on Secure-Boot-on RHEL and modern Ubuntu, paired with the Linux lockdown security module, which restricts certain root-level kernel-modification paths even on signed builds.The Linux lockdown LSM is the closest mainline-Linux analogue to HVCI's policy-out-of-reach property. The kernel_lockdown(7) man page [@man7-kernel-lockdown] describes lockdown as "designed to prevent both direct and indirect access to a running kernel image" and enumerates the restricted surfaces: /dev/mem, /dev/kmem, /dev/kcore, kprobes, BPF, MSR alteration, ACPI table overrides, and unsigned kexec [@man7-kernel-lockdown]. It is a partial analogue, not equivalent: lockdown still runs in the same trust domain as the kernel it polices, so a sufficient kernel exploit defeats it. HVCI's VTL0/VTL1 split is structurally stronger.

What Linux does not have is the equivalent of DriverSiPolicy.p7b. There is no kernel-level curated denylist of "we have learned this module is unsafe; refuse to load it by name". Defenders rely on per-distribution CVE trackers, on modprobe.blacklist, and on udev rules to keep specific modules out. The G5 generation -- naming the weakness rather than the publisher -- has no mainline Linux equivalent at the kernel-loader level.

macOS: DriverKit removes the surface

Apple's answer is structurally different. Starting with macOS Catalina 10.15 [@apple-legacy-extensions] in 2019, Apple deprecated legacy kernel extensions for third parties and pushed them onto the DriverKit [@apple-driverkit] framework instead [@apple-legacy-extensions] [@apple-driverkit].

Apple's user-space driver framework, introduced with macOS Catalina 10.15. Third-party drivers ship as `.dext` user-space extensions linked against a curated IOKit subset; they receive IOKit messages from the kernel and respond with the same operations they used to perform in ring zero, but the code itself runs in user mode under sandbox restrictions. The kernel side of the new model exposes a controlled message surface; the third-party side cannot directly execute kernel code.

A .dext runs in user space under a sandbox profile. It can claim devices, register for IOKit interrupts, and exchange messages with kernel-side broker code -- but it cannot, in any usable sense, execute arbitrary code in the kernel address space. The Capcom.sys class of vulnerability cannot be expressed in DriverKit: there is no IOCTL surface whose handler runs in ring zero, because the handler does not run in ring zero. Apple reinforces the boundary further with System Integrity Protection [@apple-sip] (since 2015) and, on Apple Silicon, Kernel Integrity Protection (KIP), which makes the kernel page tables read-only after boot [@apple-sip].

The price was paid by Apple's IHV community. Whole categories of third-party drivers -- deep audio, virtualisation, certain security tools -- spent years migrating, and some categories took multiple macOS releases before a DriverKit equivalent of a particular kext capability existed. Apple Silicon requires explicit reduced-security mode to load any legacy kext at all: Apple's Platform Security guide [@apple-kext-aux] records that "Kexts must be explicitly enabled for a Mac with Apple silicon by holding the power button at startup to enter into One True Recovery (1TR) mode, then downgrading to Reduced Security and checking the box to enable kernel extensions" [@apple-kext-aux].

Why Windows cannot copy Apple

The reason Windows cannot make Apple's move in the short term is operational, not architectural. Windows' IHV installed base is orders of magnitude larger and less centrally controlled. Microsoft does not own its hardware vendors the way Apple owns Macs. Breaking compatibility with twenty years of shipped kernel drivers would impose unbounded migration cost on third parties Microsoft cannot direct.

Dimension	Windows (2026)	Linux (mainline + RHEL-class hardening)	macOS (Catalina+ / Apple Silicon)
Default signature enforcement	Mandatory on x64 since 2006	Permissive (taints kernel); restrictive on hardened distros	Mandatory; legacy kexts deprecated
Curated denylist of signed-but-vulnerable artefacts	`DriverSiPolicy.p7b`, default-on since 22H2	None at kernel loader; per-distro CVE trackers	Not needed -- third-party kexts removed
Policy engine isolated from kernel it polices	HVCI in VTL1	Lockdown LSM (same trust domain)	KIP and SIP on Apple Silicon
Third-party drivers in kernel	Yes, still the model	Yes	No -- DriverKit user-space dexts
Operational price of the model	Compatibility carve-outs, opt-outs	Permissive default	Multi-year IHV migration

Windows cannot move drivers to user space at Apple's speed. But it can look at what is inside a driver in a way the signature alone never could. And it has been quietly building that capability since 2022.

11. What Comes Next: SBOM, Artifact Signing, Dynamic Analysis

If signatures cannot answer "is this driver safe", and the block list can only ever answer "is this driver known-unsafe", the next question Windows has to learn how to ask is "what is inside this driver?"

SBOM for drivers

A Software Bill of Materials is a structured inventory of the components, dependencies, and versions inside a software artefact. The mainstream community formats are SPDX (now at version 3.0) and CycloneDX; Microsoft contributes to and ships an open-source tool, microsoft/sbom-tool [@gh-sbom-tool], that produces SPDX-compatible SBOMs as part of a build pipeline [@gh-sbom-tool]. The repository description is plain: "The SBOM tool is a highly scalable and enterprise ready tool to create SPDX 2.2 and SPDX 3.0 compatible SBOMs for any variety of artifacts. The tool uses the Component Detection libraries to detect components and the ClearlyDefined API to populate license information for these components." [@gh-sbom-tool]

A machine-readable inventory of components and dependencies inside a software artefact. For a Windows kernel driver, an SBOM lists the third-party static libraries linked into the PE, the open-source code paths bundled with the driver, and the versions of each, in a format (SPDX, CycloneDX) that automated tools can consume to answer "is any component of this driver subject to a known vulnerability?"

The piece that affects Windows drivers specifically is the Windows Hardware Compatibility Program SBOM requirement. The Microsoft Q&A entry on Hardware Dev Center and CRA compliance [@ms-qa-cra] is candid: "The WHCP SBOM requirement (Device.DevFund.Security.SoftwareBillofMaterials) has been deferred and will only be enforced starting in H2 2026." [@ms-qa-cra] The deferral aligns the WHCP rollout with the European Union's Cyber Resilience Act compliance window.

The EU Cyber Resilience Act sets phased compliance obligations for products with digital elements sold into the EU market. Among them is a requirement to produce a machine-readable SBOM that customers and regulators can inspect. Microsoft's WHCP SBOM mandate, scheduled for H2 2026, is the Windows-specific implementation of the same requirement, applied to kernel drivers submitted through the Hardware Dev Center. For regulated-industry IHVs, the WHCP gate and the CRA gate land at the same time and concern the same artefact [@ms-qa-cra].

There is a structural problem an SBOM does not solve on its own. If the SBOM ships separately from the driver, an attacker who controls the distribution path can substitute a clean-looking SBOM for a contaminated driver. The WHCP submission flow is expected to bind the SBOM cryptographically to the artefact it describes so that a recipient can verify the binding, but the public documentation for the binding mechanism is still light beyond the WHCP SBOM mandate itself [@ms-qa-cra] [@ms-qa-cra].

Dynamic analysis at submission time

The other axis of improvement is reactiveness. Today, the typical disclosure-to-enforcement cycle for a new BYOVD driver looks like this: vendor ships, attacker exploits, researcher discloses, Microsoft adds to the quarterly published list, Windows servicing pushes to clients. The latency is months. Two recent research programmes show how dynamic analysis at scale can compress it.

The first is the EURECOM/Politecnico di Milano NDSS 2026 paper on the authors' publication page [@eurecom-paper]. The team built a DRAKVUF-based instrumentation layer called Kernelmon and traced every kernel function executed by signed drivers under malware-loaded workloads [@eurecom-paper]. The numbers are unusually concrete: the paper PDF [@eurecom-paper-pdf] reports that the team "analyzed 8,779 malware samples that load 773 distinct signed drivers. It flagged suspicious behavior in 48 drivers, and subsequent manual verification led to the responsible disclosure of seven previously unknown vulnerable drivers" [@eurecom-paper-pdf]. The companion S3 blog post [@eurecom-s3-blog] corroborates the 48-flagged / 7-disclosed numbers and notes that one of the seven received CVE-2024-26506 [@eurecom-s3-blog]. The technique is dynamic: it runs the driver under a hypervisor, watches what its IOCTL handlers actually do, and flags patterns characteristic of the BYOVD class.

The second is Check Point Research's 2024 work [@cpr-byovd], which built a mass-hunt methodology around import-table signatures of risky kernel APIs and ran it across the global driver corpus. "Using the same methodology, we conducted a mass hunt for new drivers that may be vulnerable, uncovering thousands of potentially at-risk drivers." [@cpr-byovd] The technique is static: it asks what does the driver import? rather than what does it do under exercise? Combined, the two approaches cover complementary halves of the surface.

Neither currently gates Hardware Dev Center submissions. Both are candidates for the kind of submission-time check that would compress disclosure-to-enforcement latency from quarters to days.

Empirical patterns the defences have to recognise

Cisco Talos's BYOVD work, summarised in their Exploring vulnerable Windows drivers post [@talos-byovd], classifies the post-load payloads attackers actually run [@talos-byovd]. Three behaviour classes dominate: token-swap escalation that overwrites the access token in the _EPROCESS structure to reach SYSTEM; unsigned-code-loading that uses the kernel-write primitive to disable DSE or patch CI state; and EDR-killing that clears the kernel callback registrations endpoint detection products rely on. Each is a target for the dynamic analyses above, each is detectable by import-table heuristics, and each is what defenders see in the wild today.

The historical roots are old. The Microsoft Security blog tracing the Vulnerable & Malicious Driver Reporting Center is direct: "Multiple malware attacks, including RobinHood, Uroburos, Derusbi, GrayFish, and Sauron, have leveraged driver vulnerabilities (for example CVE-2008-3431, CVE-2013-3956, CVE-2009-0824, and CVE-2010-1592)." [@ms-vdrc-blog] The payload classes have stayed remarkably stable for fifteen years.

Note: The structural gap between signed and safe cannot close. It can be narrowed along three independent axes. Reactiveness: how long disclosure-to-enforcement takes (closeable by submission-time dynamic analysis along the lines of the EURECOM NDSS 2026 paper [@eurecom-paper] [@eurecom-paper] and Check Point's mass-hunt methodology [@cpr-byovd] [@cpr-byovd]). Coverage of unknown-bad signed drivers (extended by reputation-backed allowlists like Smart App Control and by WDAC enterprise policies). Visibility into binary contents (the H2 2026 WHCP SBOM mandate [@ms-qa-cra] and the SBOM-to-artefact binding the submission flow is expected to enforce [@ms-qa-cra]). Each axis closes a different blind spot. None substitutes for another.

Threats the stack cannot yet absorb

Three problems remain open and uncovered by the published roadmap. The Smart App Control cold-start window leaves small IHVs whose drivers have no cloud reputation to fall through to signature, and signature alone is exactly what we already established does not answer the question. BYOVD on HVCI-off environments, prevalent in older anti-cheat configurations and on enterprise machines with legacy ISV drivers, still admits the g_CiOptions-patching family from VTL0 because there is no VTL1 to keep the policy out of reach. And the shipped-vs-published block list gap, while operationally rational and individually closeable by a willing administrator, is a gap any default-on customer carries.

None of those closes by algorithmic improvement. Each closes only by widening the question.

What started as a yes/no signature check has become a continually expanding set of questions Windows asks before it will hand a driver the keys to ring zero. None of those questions is sufficient. All of them are necessary. And the next one is already being written into the WHCP submission flow.

12. What This Means in Practice

Three audiences, three things to do.

Administrators. Confirm the stack is on. Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard returns a SecurityServicesRunning array; a 2 in the array confirms HVCI. A DriverSiPolicy.p7b in %windir%\system32\CodeIntegrity\ confirms the in-box block list is deployed. If you can tolerate the compatibility risk, compile the published block-rules XML [@ms-driver-block-rules] into an App Control policy and deploy it (audit mode first) [@ms-driver-block-rules]. If you run Windows Server 2016, you have to deploy an explicit policy yourself because the in-box default does not apply there [@ms-driver-block-rules]. If you ship through the Hardware Dev Center, schedule the H2 2026 WHCP SBOM gate now [@ms-qa-cra]. Subscribe to the Vulnerable & Malicious Driver Reporting Center cadence for new disclosures [@ms-vdrc-blog].

Driver authors. Assume your IOCTL surface will be read by Check Point's import-table mass hunt [@cpr-byovd] and exercised by EURECOM's Kernelmon [@eurecom-paper] [@cpr-byovd] [@eurecom-paper]. Any handler that takes a user-supplied address and returns kernel data, or that dispatches a user-supplied function pointer, will end up on a block list on its current trajectory.

Researchers. The field is wide open. The undecidability result is real, but the practical gap between what current analyses detect and what is, in principle, detectable for any specific vulnerability class is large. The NDSS 2026 paper found seven CVE-worthy drivers in a corpus of 773. The next paper will find more.

Every layer is somebody's incident report

Every layer in the 2026 stack exists because the previous one lost to a named adversary. Sony BMG XCP retired advisory signing. Stuxnet retired the assumption that a valid chain is a safe chain. Capcom.sys retired the assumption that a safe chain is a safe driver. RTCore64.sys, gdrv.sys, and KProcessHacker retired the assumption that the BYOVD class would burn itself out. Each entry on DriverSiPolicy.p7b is somebody's incident report, recorded in the most permanent place Microsoft can put it -- the kernel loader's deny list.

Note: Windows 11 22H2 ships with a list of drivers Microsoft will not load. The next list will be longer. The story has been adversarial since 1996 and the trajectory does not reverse: every layer was added because the previous one met an attacker. The structural gap is undecidable; the engineering gap, narrowable; the work, unfinished.

Frequently Asked Questions

No. HVCI verifies the Authenticode signature at section-mapping time and enforces a write-xor-execute invariant on kernel memory; it does not analyse the driver's IOCTL surface. A signed driver with an unsafe IOCTL passes HVCI unchanged and proceeds to execute its handler in kernel mode with kernel privilege. That is what the Vulnerable Driver Block List is for: HVCI gates *who decides*; the block list gates *what gets decided*. See the Memory Integrity page [@ms-hvci-vbs] [@ms-hvci-vbs]. Yes. Microsoft publishes the source XML on the Microsoft-recommended driver block rules page [@ms-driver-block-rules] [@ms-driver-block-rules]. You can compile it into a binary App Control policy with the standard tooling and deploy it directly, picking up entries Microsoft holds back from the in-box list. Test in audit mode first because the published list is more inclusive than the shipped list and may flag drivers your environment depends on. Many defenders layer the LOLDrivers App Control policy [@gh-loldrivers] on top for community-curated coverage [@gh-loldrivers]. Windows Server 2016 does not enforce the block list by default, even when Memory Integrity is on. The block-rules page [@ms-driver-block-rules] calls this out explicitly [@ms-driver-block-rules]. If you administer Server 2016, deploy an explicit App Control policy to get the same coverage as the default-on 22H2 client. App Control for Business (the engine formerly known as WDAC) is a policy *you* author. You define what signers, hashes, and paths are allowed; you ship and enforce the policy yourself. Smart App Control is a Microsoft-authored policy bundled with cloud reputation lookups via the Intelligent Security Graph. SAC is the consumer-friendly front end; App Control is the enterprise back end. SAC's default policy ships at `%windir%\schemas\CodeIntegrity\ExamplePolicies\SmartAppControl.xml`. SAC is consumer-only and turns itself off after 48 hours on enterprise-managed devices, where the expectation is that the operator deploys an App Control policy directly. See the Smart App Control FAQ [@ms-sac-faq] and the App Control for Business overview [@ms-appcontrol] [@ms-sac-faq] [@ms-appcontrol]. Increasingly yes. Major anti-cheat vendors have shipped HVCI-compatible kernel components since around 2023, but a meaningful tail of older configurations still requires HVCI off. On those configurations, the `g_CiOptions`-patching technique TrustedSec describes [@trustedsec-gcioptions] is back in play because the policy variable is no longer protected behind VTL1 [@trustedsec-gcioptions]. Audit your gaming-rig population if you care about coverage. The in-box block list is Microsoft-curated with explicit compatibility holdbacks; the LOLDrivers catalogue [@loldrivers-io] is community-curated, considerably more inclusive (approximately 2,132 entries as of the source verification for this article), and ships with App Control deny policies, Sigma, YARA, ClamAV, and Sysmon detection content alongside the entries [@loldrivers-io] [@gh-loldrivers]. For threat hunting, use both. For enforcement, layer the LOLDrivers App Control policy on top of the in-box list if your environment can tolerate the compatibility risk. Check Point Research [@cpr-byovd] has documented the dual-use externality of any such public list -- attackers also read them -- but the defender net benefit of broader coverage outweighs the marginal attacker advantage on most environments [@cpr-byovd].