Comparison or collaboration with DMF?

[hansmbakker]

Interesting work!

Could you say something how you envisioned this - do you aim to have it similar to https://github.com/microsoft/DMF? Have you considered looking at a collaboration with them?

[StephanvanSchaik]

Thank you for your interest!

Let me first start by pointing out my original motivation for this project, which is that some of my research requires kernel-level access and that I mostly prefer writing Rust over writing C or C++, even though I have worked with primarily C for more than ten years before using Rust for most of my projects. The reasoning behind this mostly boils down to that Rust gives me a peace of mind, as most code is safe and rather high-level code that gets checked by the borrow checker for any violations, allowing me to focus on the unsafe low-level parts that really require my attention.

In addition, I am way more familiar with operating system development and the Linux kernel, but a lot of the concepts present in the Windows Driver Framework translate well to other operating systems. In fact, for one of the projects where I needed to write a Linux kernel module, I worked on my fork of the linux-kernel-module-rust repository, which aims to provide a similar Linux kernel module framework in Rust. Of course, there are things that are very unique to how Microsoft Windows works, such as I/O Request Packets (IRPs) and the driver stack. However, this also means that I am not necessarily familiar with all the state-of-the-art in terms of Windows driver development, and I have to admit that I had not heard of DMF before, so it will be hard for me to compare this project with DMF specifically without reading more about DMF first.

One of the problems with driver writing on Microsoft Windows is that a lot of the functions exposed by WDF need to be called at the right IRQL (Interrupt Request Level), and that you otherwise risk running into deadlocks or other issues. Similarly, certain functions also assume that you have ownership over one or more of the arguments that get passed into the function (e.g. MmGetSystemAddressForMdlSafe assumes the current calling thread owns the MDL). Currently, the first set of issues are mostly solved thanks to static analysis. More specifically, there is a tool called Static Driver Verifier (SDV) to check if you driver's interaction with the kernel meets the right constraints at any given point in time. Unfortunately, I don't know whether there is a solution to this specific problem in Rust yet, as I haven't given this part too much thought myself yet.

However, the ownership problem can clearly be solved by using Rust thanks to its borrow checker. One of the examples where Rust really shines is the handling of IRPs. Currently, windows-kernel-rs is written such that you can handle the IRP within your driver and complete it, but there are other possible scenarios too. More specifically, IRPs are owned by the driver currently handling the IRP in the driver stack, and it can decide to complete it in the current layer or forward it to the next layer in the stack, i.e. transfer ownership of the IRP to the next layer. As you can see in one of the examples, we simply indicate how the IRP is handled by returning Completion::Complete. In the future, I would expect a Completion::Forward to forward the IRP to the next driver, as well as ways to handle the other scenarios with code that is less convoluted and less error-prone than using IoCallDriver, IoCompleteRequest, etc. directly.

Another area where Rust can also help quite a lot is concurrency. There is an initial implementation of FAST_MUTEX and EX_PUSH_LOCK that provides a Mutex and a RwLock respectively. Locking is then handled through the implementation of a MutexGuard which simply unlocks the mutex on drop. This is however not limited to Rust, as RAII is also typically employed in C++.

Finally, I am mostly focusing on ergonomics by taking care of the low-level details as much as is possible. The handling of IRPs is one such example. Another is the handling of direct input vs. direct output vs. buffered I/O, where windows-kernel-rs already takes care of the read/write buffers for you, so you don't have to necessarily worry about this aspect, and in general handling ioctls is pretty convenient when using windows-kernel-rs. Similarly, a lot of the structs provided by windows-kernel-rs already provide an implementation of Drop to automatically take care of cleaning up things for you.

I do want to stress that this repository is mostly the result of my experimentation with the WDF in Rust, and that this work has been made a lot easier thanks to the existing work from Matthias and Hussein Aitlahcen. Having said that, this framework already served me well for the project where I needed this, and while I do have some vision of what certain aspects of a driver framework for Microsoft Windows in Rust should look like, having more people think through some of the ideas is definitely helpful, especially given that I do not necessarily have the capacity to work on this project full-time myself. So collaboration and contributions are both definitely welcome.

[hansmbakker]

Hi, I totally get the reasoning for wanting to use Rust when developing native (driver) code. I see you're already developing reusable pieces - I think DMF is focused on taking that further into creating building blocks that can fulfil certain usecases (like creating a driver for a virtual HID device).

That's where I was wondering what the plans for windows-kernel-rs were, and whether any collaboration with DMF was sought (I am very much a beginner regarding driver development, so cannot contribute much I'm afraid, but I did try with DMF in the past - it felt quite useful to not have to build drivers from scratch, and I was wondering whether you were aware of that project)