5 ms·

Damn! If I'm correctly informed, this is before Linux is doing it (actually shipping rust code, not having the infrastructure in place).

therein 3y ago
I feel like there is a way more vibrant driver developer community for Windows anyway. It could be the architecture for kernel drivers Windows has or that many people use it for malware and game cheat development. I have a fond attachment to all the tools you have in your disposal once loaded into the kernel space on Windows. win32kbase.sys being at a certain memory location for all processes, KeUserModeCallback etc. all around really fun and interesting to hack with. Doing DKOM on PEB, TEB of kernel processes or user processes to do things you shouldn't be able to do like call win32 apis from kernel pretending to be a process to draw things using GDI etc. Even though I primarily am a Linux user and I prefer using Linux on a daily basis, dabbling in Linux kernel development failed to create this feeling of awe and infinite possibilities (and exploitability) in my mind. I guess my point is, Windows Kernel development in Rust excites me. Same with Linux would be very cool but it doesn't create the same feeling of wonder in me. Perhaps that's why this is happening first.
- dilawar 3y ago
  https://github.com/SubconsciousCompute/poc-windows-rust-filter https://github.com/SubconsciousCompute/poc-windows-rust-filt... We have been playing with Rust and minifilter for Windows. Its almost there. Microsoft has been working on rust driver kit.
dagmx 3y ago
Not surprising. Linux is one of the few monolithic kernels. It’s kind of a worst case scenario for adding in a new language to as a result, since it can’t be added in a very isolated way.
- kijiki 3y ago
  > Not surprising. Linux is one of the few monolithic kernels. This is an amusing claim, given that Microsoft's first use of Rust in the NT kernel is in win32k.sys, which is the in-kernel code that used to live in userspace back when NT was actually a microkernel. So pre-NT4, which was released in 1996.
  - pjmlp 3y ago
    Windows still follows a microkernel like architecture with LPC across subsystems, and nowadays kernel runs on its own sandbox, while a select set from drivers are also sanboxed. Then there are the whole set of userspace drivers, including graphics. How are those X Windows driver crashes holding on?
    - atq2119 3y ago
      The kernel/user space split in graphics drivers is pretty much the same between Linux and Windows, and has been this way for many, many years.
gjsman-1000 3y ago
Windows under the hood with the NT Kernel is actually regarded among some experts as technically superior to Linux with the driver model and personalities subsystem; it’s just that the stuff above the kernel isn’t so great…
- waboremo 3y ago
  The one place microsoft's advertising branch can't get to!
  - photonbeam 3y ago
    For now Syscalls powered by MSNBC
  - streakfix 3y ago
    Their scheduler is pure bullcrap. It favors cpu intensive applications, meaning it's good for gaming but horrible for every other use case
    - pjmlp 3y ago
      I would agree, if we would still be talking about Windows NT 4.0 or Windows 2000.
    - PaulRobinson 3y ago
      That makes sense if your main target use case is desktops where a small number of CPU-intensive apps are running, right? And even in many server apps where you have one main app being the reason the server is booted, this makes broad sense. Don’t get my wrong, but me and I bleed Unix-like systems and have done for decades, but what you’re saying actually makes sense for MS as a design decision…
    - AlexSW 3y ago
      How so? I believe I understand Windows' thread scheduler and this conclusion isn't obvious to me at all; from my understanding it seemed perfectly reasonable.
TazeTSchnitzel 3y ago
It's easier for Windows to do it because it only targets a small number of architectures (maybe only x86-64 and AArch64 these days?), and only Microsoft need to be able to build it. The Linux kernel has a huge number of targets and the build system needs to be solid for a huge number of people.
jeroenhd 3y ago
Windows does a lot of things in the kernel that Linux lets userspace handle. Part of that is the way UI is dealt with: for Windows UI is part of the core system, whereas on Linux it's a userspace tool you can install if you really fancy it. There's also the advantage of being able to add Rust to the build pipeline without someone complaining that you broke the build for their TI-83+ calculator because there's no Rust compiler for that platform. Windows deals with amd64, x86, aarch64, and maybe some simple 32 bit ARM, but that's about it. Nobody is going to care about support for MIPS or Power9 or Motorola 6800 or SPARC or Xtensa.

therein 3y ago

I feel like there is a way more vibrant driver developer community for Windows anyway. It could be the architecture for kernel drivers Windows has or that many people use it for malware and game cheat development. I have a fond attachment to all the tools you have in your disposal once loaded into the kernel space on Windows. win32kbase.sys being at a certain memory location for all processes, KeUserModeCallback etc. all around really fun and interesting to hack with. Doing DKOM on PEB, TEB of kernel processes or user processes to do things you shouldn't be able to do like call win32 apis from kernel pretending to be a process to draw things using GDI etc. Even though I primarily am a Linux user and I prefer using Linux on a daily basis, dabbling in Linux kernel development failed to create this feeling of awe and infinite possibilities (and exploitability) in my mind. I guess my point is, Windows Kernel development in Rust excites me. Same with Linux would be very cool but it doesn't create the same feeling of wonder in me. Perhaps that's why this is happening first.

dilawar 3y ago
https://github.com/SubconsciousCompute/poc-windows-rust-filter https://github.com/SubconsciousCompute/poc-windows-rust-filt... We have been playing with Rust and minifilter for Windows. Its almost there. Microsoft has been working on rust driver kit.

dagmx 3y ago

Not surprising. Linux is one of the few monolithic kernels. It’s kind of a worst case scenario for adding in a new language to as a result, since it can’t be added in a very isolated way.

kijiki 3y ago
> Not surprising. Linux is one of the few monolithic kernels. This is an amusing claim, given that Microsoft's first use of Rust in the NT kernel is in win32k.sys, which is the in-kernel code that used to live in userspace back when NT was actually a microkernel. So pre-NT4, which was released in 1996.
- pjmlp 3y ago
  Windows still follows a microkernel like architecture with LPC across subsystems, and nowadays kernel runs on its own sandbox, while a select set from drivers are also sanboxed. Then there are the whole set of userspace drivers, including graphics. How are those X Windows driver crashes holding on?
  - atq2119 3y ago
    The kernel/user space split in graphics drivers is pretty much the same between Linux and Windows, and has been this way for many, many years.

gjsman-1000 3y ago

Windows under the hood with the NT Kernel is actually regarded among some experts as technically superior to Linux with the driver model and personalities subsystem; it’s just that the stuff above the kernel isn’t so great…

waboremo 3y ago
The one place microsoft's advertising branch can't get to!
- photonbeam 3y ago
  For now Syscalls powered by MSNBC
- streakfix 3y ago
  Their scheduler is pure bullcrap. It favors cpu intensive applications, meaning it's good for gaming but horrible for every other use case
  - pjmlp 3y ago
    I would agree, if we would still be talking about Windows NT 4.0 or Windows 2000.
  - PaulRobinson 3y ago
    That makes sense if your main target use case is desktops where a small number of CPU-intensive apps are running, right? And even in many server apps where you have one main app being the reason the server is booted, this makes broad sense. Don’t get my wrong, but me and I bleed Unix-like systems and have done for decades, but what you’re saying actually makes sense for MS as a design decision…
  - AlexSW 3y ago
    How so? I believe I understand Windows' thread scheduler and this conclusion isn't obvious to me at all; from my understanding it seemed perfectly reasonable.

TazeTSchnitzel 3y ago

It's easier for Windows to do it because it only targets a small number of architectures (maybe only x86-64 and AArch64 these days?), and only Microsoft need to be able to build it. The Linux kernel has a huge number of targets and the build system needs to be solid for a huge number of people.

jeroenhd 3y ago

Windows does a lot of things in the kernel that Linux lets userspace handle. Part of that is the way UI is dealt with: for Windows UI is part of the core system, whereas on Linux it's a userspace tool you can install if you really fancy it. There's also the advantage of being able to add Rust to the build pipeline without someone complaining that you broke the build for their TI-83+ calculator because there's no Rust compiler for that platform. Windows deals with amd64, x86, aarch64, and maybe some simple 32 bit ARM, but that's about it. Nobody is going to care about support for MIPS or Power9 or Motorola 6800 or SPARC or Xtensa.