# Rust in the Windows Kernel: A Field Guide to the 2024-2026 Memory-Safety Refit
> Rust ships in the Windows 11 kernel today. A primary-sourced field guide to what actually shipped from BlueHat IL 2019 through 24H2 in 2026, and what did not.
*Published: 2026-05-23*
*Canonical: https://paragmali.com/blog/rust-in-the-windows-kernel-a-field-guide-to-the-2024-2026-me*
*License: CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/*
---
**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](/blog/wdac--hvci-code-integrity-at-every-layer-in-windows/), 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)](/blog/control-flow-integrity-on-windows-cfg-xfg-and-the-cet-shadow/) 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 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.
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](/blog/pluton-a-tpm-on-silicon-microsoft-can-patch/), 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`, `Vec`, `String`, and `Arc` 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](/blog/inside-azure-confidential-vms-sev-snp-intel-tdx-and-the-para/) -- 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].
### 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.
**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`:
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 [@windows-drivers-rs].
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) [@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].
= 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.