Microsoft is turning Rust into a first-class language for developing secure Windows drivers

Alfonso Maruccia

Posts: 2,586   +973
Staff
In context: Rust is a general-purpose language designed for building fast and secure software. Its strong focus on memory safety aims to eliminate most memory-related bugs and security vulnerabilities. The language excels in web services and system software development and could soon play a key role in Windows development as well.

Microsoft began adopting Rust for core Windows programming a few years ago, praising the relatively new language as a key tool for reducing bugs and enhancing security. The company has now unveiled some of the work aimed at making Rust development easier and more effective for Windows driver projects.

In a recent blog post, Microsoft detailed the current state of Rust support for Windows drivers. Developers have traditionally used the Windows Driver Kit to write these scripts in C, with the WDK providing all the libraries and tools needed. Redmond is now working to give Rust developers the same advantage by porting the same libraries and headers to Rust.

Microsoft consolidated these tools into windows-drivers-rs, a GitHub repository containing Rust "crates" – packages managed by Cargo, Rust's build system and package manager. Developers can now use the tools to build Windows drivers.

The windows-drivers-rs repository provides all the resources developers need to build fully functional Rust drivers. These include a library for configuring Cargo build scripts (wdk-build), a global allocator (wdk-alloc), a set of macros to simplify interactions with WDK's direct bindings (wdk-macros), and more. With these crates, developers can already create kernel-mode and user-mode driver binaries that load and run on Windows 11.

Microsoft is also introducing the cargo-wdk project to simplify Rust driver development in Visual Studio. Programmers have long benefited from VS templates that speed up initial C development. The cargo-wdk extension provides VS users with empty driver projects pre-populated with all necessary linkage, build steps, and dependencies.

The Redmond tech giant says the long-term goal of cargo-wdk is to give Rust developers the same building tools and configuration options available to C programmers. The Cargo plugin will soon add more driver templates, code deployment to test machines, full ARM64 support, and additional features.

Developers are also planning to improve safety in Rust driver projects. The current windows-drivers-rs crates still require developers to write a significant amount of unsafe Rust code. The Windows Driver Framework team is collaborating with Rust experts to introduce safer abstractions. However, working with Windows kernel APIs presents a complex challenge, and addressing it will take time and require cooperation across multiple teams.

Permalink to story:

 
The performance margin is really low, or a point of contention.
Plus it's only a handful of savants who can squeeze out performance while tirelessly checking to ensure that the usual memory bugs in C++ are not overlooked.

*sigh*

Modern C++ is basically immune to any and all memory problems. It really comes down to avoiding the use of native C types in almost all instances. Don't use C-Arrays, use std::array, don't use C-pointers, use std::unique_ptr and std::shared_ptr (and if you *really* need it: std::weak_ptr). Use either iterators are one of the new "for" looping methods that avoid all the off by 1 errors. And so forth. These are all solved problems.

The problem is people keep using old C-language standards in their C++ programs, then wonder why things explode.
 
There is no real change to the performance. Those claims are very old. Rust is currently used in many Linux kernel modules without performance impact.

5% on average the last I bothered to check, but remember that's per instance of the code executing, so you can bleed performance fast if used in certain situations where a code block gets called repeatedly.
 
The fact that drivers are still mostly written in C in 2025 says a lot about how conservative low-level development is — Rust adoption here could be as big a shift as when we moved from assembly.
 
Wasn't Google going to rewrite Android in Rust a few years ago. They did state it would take a long time but is that still a thing?
 
*sigh*

Modern C++ is basically immune to any and all memory problems. It really comes down to avoiding the use of native C types in almost all instances. Don't use C-Arrays, use std::array, don't use C-pointers, use std::unique_ptr and std::shared_ptr (and if you *really* need it: std::weak_ptr). Use either iterators are one of the new "for" looping methods that avoid all the off by 1 errors. And so forth. These are all solved problems.

The problem is people keep using old C-language standards in their C++ programs, then wonder why things explode.
Go and broadcast your sighs to fellow C++ programmers. You desperately hang on to the ideal, best-practices fantasy to make a case for C++, but Rust was written from the ground up so that many (I did not say all) of such things don't need to be bothered with any more.
 
Go and broadcast your sighs to fellow C++ programmers. You desperately hang on to the ideal, best-practices fantasy to make a case for C++, but Rust was written from the ground up so that many (I did not say all) of such things don't need to be bothered with any more.
And the problem with that is it *always* bleeds some amount of performance, especially as features get added. Then the language becomes too slow and someone makes a new language that's really just a minimal set of the one that comes before. Rinse and Repeat.
 
And the problem with that is it *always* bleeds some amount of performance, especially as features get added. Then the language becomes too slow and someone makes a new language that's really just a minimal set of the one that comes before. Rinse and Repeat.
Is that already happening with Rust or just catastrophism in mindset?
 
Is that already happening with Rust or just catastrophism in mindset?
Its something I've seen happen multiple times in my lifetime, so it's a pretty good bet the same thing will happen again.

I still remember the days when Ada was supposed to solve all those memory management pitfalls; it was abandoned because it became too hard to use because it ended up being too restrictive. Ditto for other languages which have come and gone; they're competitive when they remain a strict minimal set of the C syntax; it's once you start adding the more complex features where the languages restrictions start causing either performance problems or development headaches.
 
Back