4 ms·

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

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 2y ago
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 2y ago
  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/ https://github.com/microsoft/windows-drivers-rs/ [1] https://github.com/microsoft/windows-drivers-rs/blob/main/examples/sample-kmdf-driver/src/lib.rs https://github.com/microsoft/windows-drivers-rs/blob/main/ex...
- haileys 2y ago
  `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.
  - AndrewGaspar 2y ago
    lol yep, you're 100% right.
queuebert 2y ago
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 2y ago
  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.
  - queuebert 2y ago
    I see your point, but it makes it hard for Rust programmers to grok the code, as all caps denotes a constant. Even enums are camel case.
    - haileys 2y ago
      This is pretty normal for Rust code that FFIs to external libraries. There's a lot more complexity in writing FFI code - you have to think very carefully about everything you do. Case convention is a triviality here.
  - dwattttt 2y ago
    I believe Rust has added the ability to mark FFI functions as safe to call at their definition site (https://blog.rust-lang.org/2024/10/17/Rust-1.82.0.html#safe-items-with-unsafe-extern https://blog.rust-lang.org/2024/10/17/Rust-1.82.0.html#safe-...) That way functions can be marked as accurate/"ok" to call in safe code by the author of the bindings. They could absolutely not be safe; in that case, the binding author is in error marking it so.
  - taurknaut 2y ago
    > that should presumably mean an API surface that's native to the language. It reads pretty naturally to me as referring to the implementation of the driver.
- magicalhippo 2y ago
dwattttt 2y ago
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 2y ago
  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.
  - gpm 2y ago
    If you look at the readme they have > wdk: Safe idiomatic bindings to APIs available in the Windows Development Kit (WDK) And then if you look at that crate they've only implemented dbg_break, print, spinlock, and timer. I'd take this as a sign that the bindings are a work in progress. If you're going to write your driver in Rust... honestly I'd recommend just writing the `wdk` crate bindings you need for your driver and probably even upstreaming them. Wrapping FFI bindings in safe abstractions is usually pretty easy - but it's definitely the case that without them rust doesn't give you much. This sample is using `wdk_sys` bindings directly without wrapping them... which is basically never the recommended way of interacting with the FFI in rust.

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 2y ago

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 2y ago
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/ https://github.com/microsoft/windows-drivers-rs/ [1] https://github.com/microsoft/windows-drivers-rs/blob/main/examples/sample-kmdf-driver/src/lib.rs https://github.com/microsoft/windows-drivers-rs/blob/main/ex...
haileys 2y ago
`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.
- AndrewGaspar 2y ago
  lol yep, you're 100% right.

queuebert 2y ago

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 2y ago
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.
- queuebert 2y ago
  I see your point, but it makes it hard for Rust programmers to grok the code, as all caps denotes a constant. Even enums are camel case.
  - haileys 2y ago
    This is pretty normal for Rust code that FFIs to external libraries. There's a lot more complexity in writing FFI code - you have to think very carefully about everything you do. Case convention is a triviality here.
- dwattttt 2y ago
  I believe Rust has added the ability to mark FFI functions as safe to call at their definition site (https://blog.rust-lang.org/2024/10/17/Rust-1.82.0.html#safe-items-with-unsafe-extern https://blog.rust-lang.org/2024/10/17/Rust-1.82.0.html#safe-...) That way functions can be marked as accurate/"ok" to call in safe code by the author of the bindings. They could absolutely not be safe; in that case, the binding author is in error marking it so.
- taurknaut 2y ago
  > that should presumably mean an API surface that's native to the language. It reads pretty naturally to me as referring to the implementation of the driver.
magicalhippo 2y ago

dwattttt 2y ago

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 2y ago
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.
- gpm 2y ago
  If you look at the readme they have > wdk: Safe idiomatic bindings to APIs available in the Windows Development Kit (WDK) And then if you look at that crate they've only implemented dbg_break, print, spinlock, and timer. I'd take this as a sign that the bindings are a work in progress. If you're going to write your driver in Rust... honestly I'd recommend just writing the `wdk` crate bindings you need for your driver and probably even upstreaming them. Wrapping FFI bindings in safe abstractions is usually pretty easy - but it's definitely the case that without them rust doesn't give you much. This sample is using `wdk_sys` bindings directly without wrapping them... which is basically never the recommended way of interacting with the FFI in rust.