Developers interested in leveraging Rust for Windows driver development are now equipped with enhanced tools and sample code, although the journey toward production readiness remains challenging. Senior software engineer Nate Deisinger has provided insights into the current landscape of Rust in this domain, revealing a blend of progress and hurdles.
Current Developments in Rust for Windows Drivers
On the positive side, Deisinger highlighted the availability of Rust crates designed to facilitate the creation of valid Windows 11 drivers through various frameworks, including WDM (Windows Driver Model), KMDF (Kernel-Mode Driver Framework), and UMDF (User-Mode Driver Framework). While WDM represents the traditional, low-level approach, KMDF and UMDF offer higher-level abstractions that are more commonly adopted by developers.
However, there is a caveat. Deisinger cautioned that even with these crates, developers must still utilize unsafe blocks when interacting with the Windows operating system. This necessity somewhat undermines the inherent safety advantages that Rust provides, although it does retain safety guarantees for business logic code.
The WDF (Windows Driver Frameworks) team is actively pursuing the development of safe Rust abstractions aimed at minimizing the reliance on unsafe code blocks. Additionally, there are ongoing efforts to integrate Rust into the Windows kernel, with some advancements already included in the recent Windows 11 24H2 release.
Emerging Tools and Future Prospects
Among the evolving tools is a cargo extension known as cargo-wdk, which is becoming a robust resource for Rust driver development. For instance, executing the command cargo wdk new –kmdf generates a KMDF driver template. Future enhancements for cargo-wdk are set to include ARM64 support, automated dependency installation, and streamlined driver deployment to testing environments.
Despite these advancements, the question remains: can developers successfully ship drivers written in Rust? The answer is not straightforward. The GitHub repository for the project indicates that it is still in its early stages and is “not yet recommended for production use.” A member of the Windows networking team raised concerns about potential blockers two years ago, and as of January this year, a maintainer reiterated that while the project is not ready for production, developers are welcome to experiment with the code, provided they adhere to the standard procedures for obtaining Microsoft driver signatures.
One of the prerequisites for this process involves analysis using GitHub’s CodeQL tool, which has recently introduced support for Rust in public preview since version 2.22.1. However, the documentation for driver analysis with CodeQL states that version 2.21.4 remains the most recent version validated for use with the Windows Hardware Compatibility Program (WHCP).
Looking Ahead
Given these complexities, achieving production readiness for Rust-written drivers appears to be a formidable task at this time. Deisinger has committed to sharing further information regarding the submission of Rust drivers to WHCP in the upcoming months.
Reflecting on the broader context, Microsoft Research first announced its intention to utilize Rust to address memory-safety challenges back in 2019. In 2022, Azure CTO Mark Russinovich emphasized the need to transition away from C/C++ for new projects, advocating for Rust in scenarios where a non-GC language is essential. As we approach four years since these discussions began, the prospect of deploying a Windows driver written in Rust is tantalizingly close to becoming a reality.
