[AndrewGaspar]

The code here looks to be essentially C with different syntax - every function marked unsafe, all resources manually managed. Sorry to be blunt, but what's the point of this?

[AndrewGaspar]

And I don't know how I missed this, but attempting to use the `UNICODE_STRING` returned in `string_to_ustring` is a guaranteed use after free. If you're interested in writing Windows kernel code, this is not the place to start.

[AndrewGaspar]

I'm glad to see that Microsoft is investing in Rust bindings for WDK[0], but browsing the repo, there's really no point in using this over C since they haven't bothered to invest in safe, Rust native bindings. The kmdf example[1] is like 50% "SAFETY:" comments because they're stuck using the straight C bindings for every WDK API.

[0] https://github.com/microsoft/windows-drivers-rs/

[1] https://github.com/microsoft/windows-drivers-rs/blob/main/ex...

[haileys]

`boost_write` doesn't appear to validate the length of the user supplied buffer before casting and dereferencing either, so that's a kernel-mode OOB read. Not sure how exploitable this actually is though.

[dwattttt]

It's unfortunate: a simple example is effectively all plumbing, and those would touch all the (unsafe) native interfaces.

A driver that actually does something interesting would be able to have unsafe interfaces at the boundary, and more typical Rust code inside.

[AndrewGaspar]

Yeah, I totally get that, but I suppose my argument would be is if you're going to bother writing your driver in Rust, until there are more mature Rust bindings for the OS interfaces, you might as well only write your most safety-sensitive business logic in Rust, and then write all the interfacing with the OS in C.

[queuebert]

Also a ton of ALL CAPS TYPES. Are we seriously throwing out all of the standard Rust naming conventions to adopt the ancient Windows naming-as-typing crap?

[AndrewGaspar]

That doesn't bother me per-se - those all caps names are pretty much all directly from the standard C bindings, and it makes sense to preserve that naming for the sake of having that 1:1 mapping with the ground truth C definition.

The actual issue here is that this "simple driver in Rust" is having to touch those direct C bindings at all - if Microsoft is going to advertise that they have support for writing drivers in Rust, that should presumably mean an API surface that's native to the language.

[magicalhippo]

In Delphi the Windows types are declared as-is, ie with all caps, but then most of them are aliased to more Pascal-like names.

So you can use TRect and TPoint and pass those to PtInRect[1] which expects RECT and POINT respectively.

[1]: https://learn.microsoft.com/en-us/windows/win32/api/winuser/...