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

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 ^[1]. 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 ^[2]. 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 ^[3].

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

The Check Point Research write-up tells the story tightly ^[3]. 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 ^[5]. The bugcheck code is SYSTEM_SERVICE_EXCEPTION ^[2].

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 ^[3].

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 ^[6]. 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" ^[7]. It had not moved in a decade despite /GS stack cookies, Data Execution Prevention (DEP), ASLR, CFG, Hypervisor-protected Code Integrity, and Intel CET ^[8]. Mark Russinovich repeated the number at RustConf 2025 in Seattle: "about 70% over the past two decades" ^[9].

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 ^[10]. 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.

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 ^[11]. 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 ^[12]. 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 ^[13]. 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 ^[14]. 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 ^[15]. 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 ^[16]. All three are forms of Control-Flow Integrity, and all three by construction defend the control-flow graph only.

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" ^[8].

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

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 ^[18]. The structural fix shows up in the data when it ships.

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 ^[19]. 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" ^[20]. 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 ^[21]. 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 ^[22]. 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" ^[23]. 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.

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 ^[20]. February 2021: Microsoft joins the Rust Foundation as a founding member ^[21]. 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 ^[22]. 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 ^[24].

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 ^[25]. 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 ^[25].

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 ^[25]. 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 ^[25].

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" ^[4]. 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 ^[26]. 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" ^[27]. It also pins LLVM 17 explicitly, because LLVM 18 introduced an ARM64 bindgen bug that breaks WDK header binding generation ^[27]. 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" ^[28]. 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" ^[29]. 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 ^[30]. 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 ^[9]. 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 ^[6]. 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 ^[9]. 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" ^[30].

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 ^[18]. The headline curve looks like this.

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 ^[18]. 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.

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 ^[27]. 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 ^[27]. 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 ^[31].

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.

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 ^[25]. 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 ^[4].

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 ^[25]. Russinovich at RustConf 2025 framed the team size and timeline: "Two Microsoft developers did it in six months -- 154,000 lines of code" ^[9]. 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 ^[27]. 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 ^[31]. The companion samples repository microsoft/Windows-rust-driver-samples provides Rust ports of the canonical Windows Driver Samples for KMDF and UMDF ^[26].

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 ^[32]. Hyperlight is Microsoft's Azure-side micro-VMM for very-low-latency function execution, with cold-start times in the low millisecond range ^[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 ^[29].

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 ^[27]. 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 ^[9]. 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 ^[30]. 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 ^[34]. 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 ^[34]. 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 ^[18]. 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 ^[35]. 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 ^[36]. The CHERIoT RTOS lives at microsoft/cheriot-rtos ^[37]. 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.

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 ^[9].

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 ^[18] -- 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 ^[37]) is the explicit acknowledgement that Microsoft is investing in both layers because neither alone closes the question.

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 ^[25]. 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 ^[27]. 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" ^[29]. 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 ^[3]. 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 ^[23]. 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 ^[6]. 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 ^[38], and that is the direction Russinovich has framed as preferred over LLM-only approaches.

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 ^[18]. 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:

// 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 ^[2]. The Rust v0 name mangling scheme starts with _R and uses a Punycode-derived encoding for non-ASCII characters ^[41]; 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 ^[3]. The toolchain is reproducible on a research VM.

10.2 For Windows driver developers evaluating Rust#

The setup recipe for windows-drivers-rs:

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

// 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 ^[27]. The WHCP certification path is not yet greenlit for production third-party Rust drivers ^[29]. 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 ^[3]; 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 ^[29]. 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 ^[42].

11. Frequently Asked Questions#

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.