
Windows Kernel-Mode Drivers Written in Rust - adamnemecek
https://github.com/pravic/winapi-kmd-rs
======
nickpsecurity
This is a neat project but with a caveat: Microsoft has solid, verification
tools for C drivers but Rust doesn't have the equivalent. The tools are
especially important for finding behavioral problems at the interface between
the driver itself and Windows.

So, my suggestion for production by Rust developers is to simultaneously
develop the driver in Rust and a C subset. Keep the two logically equivalent.
Rust's checker will catch problems in C program possibly. More importantly,
Microsoft's analysis tools will probably catch problems in both if it's a
logical error. Should result in some pretty robust drivers.

~~~
colejohnson66
As someone who's never worked with the Windows kernel, I'm curious about the
tools you mention. How do I get them?

~~~
ekr
I think the most significant are the SAL version 2 annotations. This is a nice
introduction :
[https://www.cs.cmu.edu/~fp/courses/15122-f10/lectures/25-sal...](https://www.cs.cmu.edu/~fp/courses/15122-f10/lectures/25-sal.pdf).

Basically, there's an additional step after compilation, called code analysis,
which runs this static verification. I think it's implemented on top of the Z3
theorem prover.

~~~
cpeterso
Here's a list of the driver code analysis warnings. I wonder how many of these
could be codified as compile-time checks in the winapi-kmd-rs library. For
example, the KIRQL type is a u8 in winapi-kmd-rs, but the code analysis
warnings the valid IRQL range is 0–31.

[https://msdn.microsoft.com/en-
us/library/windows/hardware/ff...](https://msdn.microsoft.com/en-
us/library/windows/hardware/ff550572\(v=vs.85\).aspx)

------
aidanhs
This looks very cool, definitely something I'm tempted to play with (having
never done any dev in this area before).

However, the feedback loop for debugging drivers on Windows seems quite manual
([https://msdn.microsoft.com/en-
us/library/windows/hardware/mt...](https://msdn.microsoft.com/en-
us/library/windows/hardware/mt269367\(v=vs.85\).aspx#Section4_Install)). On
Linux I'd have SSH at my disposal - are there any best practices for speeding
up this copy/install process? Cygwin sshd could be an option, off the top of
my head?

~~~
Sanddancer
First step I'd say is to import your certificate into the the debugged
computer, so it doesn't warn you every time you re-upload the driver [1].
Second, use powershell remoting [2]. Pretty much all of the other steps can be
established and automated with a powershell remote connection. I'm in fact
surprised that microsoft hasn't updated that page to use powershell, because
driver debugging is a task where it could be invaluable in helping.

[1] [https://blog.jourdant.me/ps-installing-drivers-from-
untruste...](https://blog.jourdant.me/ps-installing-drivers-from-untrusted-
publishers/)

[2] [https://technet.microsoft.com/en-
us/library/dd819505.aspx](https://technet.microsoft.com/en-
us/library/dd819505.aspx)

------
TillE
Judging from the screenshot it even works on Windows XP. This is really
impressive, since Windows kernel drivers typically have to be written in plain
old C.

~~~
wyldfire
It's just the kind of area Rust does really well in. From a certain point of
view, Rust can produce executables that are pretty much "written in plain old
C" in that they can provide linkage that works like C linkage, don't
necessarily need heap/GC, don't necessarily need big std library presuming
userspace context.

I'd wager you could do something similar with D (soon if not now), since its
no-std support is catching up w/Rust's.

~~~
CyberShadow
I have a "framework" (really just a build tool and some examples) for bare-
bones Win32 support for D[1]. I haven't tried writing kernel drivers with it
though.

I used it to create a few Fallout 4 mods[2]. Avoiding the stdlib was not
necessary there, but I didn't want the bloat. One interesting application of
D's metaprogramming has been automatically recursively instrumenting the
DirectX COM API just from the D interface definitions[3] (not IDLs).

    
    
      [1]: https://github.com/CyberShadow/SlimD
      [2]: https://github.com/CyberShadow/csfo4
      [3]: https://github.com/CyberShadow/csfo4/blob/master/dxlog/d3d11.d

------
justanotheratom
It is very nice to see this effort. I have one suggestion - integrate with WDF
APIs instead of the lower level and legacy WDM APIs.

~~~
poizan42
"Legacy" is as much said. It still forms the basis interface that is used by
WDF. Also you still need to use the WDM directly if you are writing a
filesystem driver.

Besides that, the WDF source is available under a MIT license, so it might
make more sense to just port it to Rust.

