Microsoft inches toward Rusty Windows drivers, production use still a no-no
- Reference: 1757006112
- News link: https://www.theregister.co.uk/2025/09/04/rust_windows_drivers/
- Source link:
Senior software engineer Nate Deisinger has [1]reported on the current state of Rust for developing Windows drivers. The news is mixed. On the plus side, Deisinger said that Rust crates (packages) exist for creating valid Windows 11 drivers using WDM (Windows Driver Model), KMDF (kernel-mode driver framework), or UMDF (user-mode driver framework). WDM is the older, low-level approach, while KMDF and UMDF are the higher-level abstractions that most developers use.
That said, Deisinger warned that 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, though there is still the benefit of safety guarantees for business logic code.
[2]
The WDF (Windows Driver Frameworks, including both KMDF and UMDF) team is working on safe Rust abstractions that would enable developers to reduce the amount of unsafe code blocks, according to Deisinger. There is also work underway to use Rust in the Windows kernel itself, some of which shipped in Windows 11 24H2.
[3]
[4]
There is TPM a cargo extension called cargo-wdk too, which is evolving to be a capable tool for developing drivers in Rust. For example, typing "cargo wdk new --kmdf" will create a KMDF driver template. Future plans for cargo-wdk include ARM64 support, automatic installation of dependencies, and driver deployment to test machines.
[5]Gitpod reinvents itself as Ona in pivot to AI agent platform
[6]'Huge architectural change' to JetBrains ReSharper cuts Visual Studio freezes
[7]Laravel inventor tells devs to quit writing 'cathedrals of complexity'
[8]Google and Zed push protocol to pry AI agents out of VS Code's clutches
Given all this work, can developers actually ship drivers written in Rust? Not easily. The [9]GitHub repository states that the project is in early stages and is "not yet recommended for production use."
Two years ago, a member of the Windows networking team [10]asked what the blockers were. In January of this year, a maintainer said that "the statement in the readme still stands" but that developers are free to use the code as they want, provided that they go through the normal procedures to get production drivers signed by Microsoft.
One of the tests for this requires analysis by GitHub's CodeQL tool. This now supports Rust in public preview since [11]version 2.22.1 , released in July, but the [12]docs for analyzing drivers with CodeQL state that 2.21.4 is the most recent version "validated for use with WHCP [Windows Hardware Compatibility Program]."
[13]
For now, therefore, production use may be difficult. Deisinger promised to publish more information about submitting Rust drivers to WHCP "over the coming months."
It was back in 2019 that Microsoft Research [14]posted about the company's intention to use Rust to eliminate memory-safety issues, and it was in 2022 that Azure CTO Mark Russinovich [15]said it was time to "halt starting any new projects in C/C++ and use Rust for those scenarios where a non-GC language is required."
Four years on, and it is nearly possible to do that for a Windows driver.®
Get our [16]Tech Resources
[1] https://techcommunity.microsoft.com/blog/windowsdriverdev/towards-rust-in-windows-drivers/4449718
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aLoL-b6Z1kHBdbAQgqzYXAAAANg&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aLoL-b6Z1kHBdbAQgqzYXAAAANg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aLoL-b6Z1kHBdbAQgqzYXAAAANg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://www.theregister.com/2025/09/03/gitpod_rebrands_as_ona/
[6] https://www.theregister.com/2025/09/03/jetbrains_resharper_update/
[7] https://www.theregister.com/2025/09/01/laravel_inventor_clever_devs/
[8] https://www.theregister.com/2025/08/28/google_zed_acp/
[9] https://github.com/microsoft/windows-drivers-rs
[10] https://github.com/microsoft/windows-drivers-rs/discussions/11
[11] https://github.blog/changelog/2025-07-02-codeql-2-22-1-bring-rust-support-to-public-preview/
[12] https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/static-tools-and-codeql
[13] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/devops&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aLoL-b6Z1kHBdbAQgqzYXAAAANg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[14] https://msrc.microsoft.com/blog/2019/07/a-proactive-approach-to-more-secure-code/
[15] https://www.theregister.com/2022/09/28/is_it_time_to_retire_c/
[16] https://whitepapers.theregister.com/
Re: Barking up the wrong tree as usual.
Indeed. Drivers providing userland with bypasses around the protections for the kernel and hardware is most definitely missing the point of what a driver, operating system and indeed the whole CPU is supposed to be about!
Comparisons
Interesting that Windows is now actively using Rust in the kernel, but still WIP for drivers, whilst Linux is the other way round (AFAIK).
Presumably, Windows kernel is gradually going to switch over from C to Rust. It'd be really interesting to see metrics for how quickly they can progress this. Anecdotal evidence for user-land stuff is that Rust development can be pretty quick. If Rust brings to OS kernel (re)writing the same kind of "speed of development" oft claimed by high level languages like Java, C# for applications, the conversion from C to Rust in the Windows kernel could be rather more rapid than one might imagine.
I wish the Linux kernel community would move towards Rust quicker than they are. There is of course the well-reported internal political challenges with doing that. I fear more now than ever that not making such a transition will render Linux massively out-of-date security wise, if not in fact then in philosophy. Presently the philosophy seems akin to saying "I can win this (security) battle with bow and arrows", which is indeed possible. But if the competition are using BFYAYA guns, they're probably going to win more battles, more of the time.
Re: Comparisons
>> I wish the Linux kernel community would move towards Rust quicker than they are.
Unless you, and I do mean YOU, are offering to rewrite working C code in Rust, and then take on its maintenance, you don't really have a finger in this pie. It's all very well wishing that something would happen, but what that usually means is somebody else doing the work.
Re: Comparisons
The Rust usage in the kernel is infinitesimal and highly non-critical. Not very sexy or interesting. More a footnote than anything else.
IMHO the kernel isn't the most interesting part to use Rust. It rarely changes and has been scrutinized and tested to death so you can more or less assume it's faultless. The biggest problems lie in code that is frequently updated, like Windows Services, .NET, IIS etc.
I personally don't see the usage of C, C++ or even assembler as a problem in a microkernel. It's very small (several thousands of lines of code) and once it's debugged and verified it rarely changes. So Microsoft would do much better rewriting the monolithic kernel into a microkernel and testing this out on Azure.
But...but...but...
Can't they just get the Magic AI Copilot to rewire the entire Windows code base into Rust? Pretty sure that would be a cinch for the God Tier AI to do in a few minutes. After all it's what these assholes, sorry, expert CEO's keep telling us.
Re: But...but...but...
Gee, how long has there been a fantasy about computers programming themselves?
I can find this version of it from 1956: [1]The_Last_Question
Thanks for pointing out praying to the Rust god is just a variation on a theme.
[1] https://en.wikipedia.org/wiki/The_Last_Question
Unsafe
You will ALWAYS need unsafe blocks for code that accesses low-level hardware since it's beyond the scope of Rust's memory model. Having said that there's still plenty of code inside a device driver where Rust would be a benefit.
I'm wondering what Microsoft is doing with Rust in userspace programs. Still very few updates on its usage in new Windows UI, for example.
Barking up the wrong tree as usual.
Most vulnerable drivers are vulnerable because the design exposes APIs that do dangerous things to anybody that happens to be able to load the driver. (I'm looking at _YOU_ DELL, HP, ASUS! ... and many many others...) an actual _exploit_ is rare and kind of a 'meh' issue when the design level problems are a bigger issue.