Windows 11 Insider Preview Build 25905 brings a bit of Rust in the kernel

https://blogs.windows.com/windows-insider/2023/07/12/announcing-windows-11-insider-preview-build-25905/

by pjmlp • 3 years ago

104 51 3 years ago

blogs.windows.com

CodeCompost• 3 years ago

In the Windows GDI library no less, a source of many issues in the past.

bonzini• 3 years ago

That's not a coincidence...

TillE• 3 years ago

It'd be really exciting if they make a safe Rust API for kernel drivers. You can technically write a driver in Rust, but the bulk of your code will be interacting with the unsafe, complex C API, so it's a bit pointless.

pjmlp3• 3 years ago

It doesn't change the point being made in regards to safety, however Windows kernel drivers nowadays tend to use C++, not C.

There is even a template library for it, Windows Implementation Libray, WIL.

becurious• 3 years ago

WIL is user mode, for applications. Drivers will use Kernel Mode Driver Framework or User Mode Driver Framework. UMDF has a COM style API.

C++ has been usable in the Windows kernel for a long time but you need to make sure that code ends up in the correct PE segment types for pageable and non pageable code and that there are no hidden gotchas for features like exception unwinding and that new can use paged or non paged pool appropriately. Same for Rust: getting to a nostd etc that is compatible with kernel use.

I think there’s a strong case that many drivers could be written with either a user mode driver framework or a small VM. Most of the hardware devices I’ve worked with we just need fast transfers of data to user mode buffers so our application can handle it, and the code is mostly boilerplate framework code plus setting up device registers to set up DMA transfers. I don’t see why that couldn’t be handled with say an EBPF or WASM equivalent byte code.

martin8412• 3 years ago

You'd need some kind of formal model of the hardware for that to be feasible. A big part of doing driver development is writing strings of bits to hardware addresses over I2C, SPI, USB or other protocols.

None4U• 3 years ago

Maybe on the hardware side, but the way we communicate that to Windows can still be under Microsoft's control

eptcyka• 3 years ago

One could make the same point about any rust that ultimately interfaces with the system using libc - all Rust programs at one point were interfacing with a lot of C code.

A more serious counter argument is that Mozilla did exactly this with Rust in Firefox - and it seems to be a success, there's still lots of Rust in the browser and it seemingly is working.

Point being, using Rust for all of the things will probably be painfully cumbersome today, but writing up a complicated enough component with a well defined boundary with the rest of the kernel will probably prove immensely useful and won't be painfully cumbersome.

nikanj• 3 years ago

And that unsafe, complex C API communicates with an even sketchier system made of registers, IO ports and nasty hardware details. Providing a higher level API for a nastier backend has always been a core feature of operating systems and programming languages.

tialaramex2• 3 years ago

Almost nothing is still I/O ports because it's more portable to use MMIO and if you're going to offer MMIO why bother also doing I/O ports. But yes, as a vague outline you're correct.

steveklabnik2• 3 years ago

Some previous discussions on this:

* https://news.ycombinator.com/item?id=35729655

* https://news.ycombinator.com/item?id=35924008

terandle• 3 years ago

My favorite bit was they fixed Zune support

"In celebration of Marvel Studio’s Guardians of the Galaxy Volume 3, we temporarily re-launched Zune.net last month. We also took the opportunity to fix an issue that was causing some challenges in getting the original Zune drivers to install in Windows 11 with this build in the Canary Channel. So now it should be easier to use your (totally unsupported and still discontinued) Zune on Windows 11."

ChuckNorris89• 3 years ago

I didn't get the point of using a Zune in the latest Guardians movie. Why the product placement for a product that's long discontinued? Microfot won't make any money if people go on ebay and buy a used Zune out of nostalgia. Or it wasn't a product placement after all?

dudeinhawaii• 3 years ago

It wasn't a product placement any more than a Sony Walkman was a product placement...

It was a joke, like saying, "You're finally with the times. Drop your tape deck, here's a Zune!" It wouldn't have landed the same way with an iPod.

nwah1• 3 years ago

It is a joke.

coldtea2• 3 years ago

Why the product placement for a product that's long discontinued?

Not everything is a "product placement".

In this case it was a nostalgic, offbeat item, to funnily convey those things about the character that would use one, like the Walkman and music choice was in the first movie.

slenk• 3 years ago

Wait...will I actually be able to plug my ancient Zune back in? I am pretty sure I have the cable yet.

Just hard to tell what's sarcasm on the internet now.

coldtea2• 3 years ago

(totally unsupported and still discontinued) Zune

So much for the "iPod killer". And then for the Windows Phone "iPhone killer" that replaced it. The tech press is so predictably wrong, with BS clickbait headlines.

andrewstuart3• 3 years ago

If rust is complex and hard to learn, doesn’t this make it a bad idea for use in a kernel?

Shouldn’t readability/ understandability be a critical requirement for kernel code?

fndex• 3 years ago

One could argue that C++ is much more complex and hard to write correct code.

andrewstuart3• 3 years ago

Pointing at C++ as bad doesn’t address my point.

Kernel code should be easily readable and understandable, shouldn’t it?

If Rust is complex and hard to understand won’t that lead to the kernel source code becoming a giant kablooie of complexity?

Surely the relatively simple nature of C is what makes it suitable for large scale kernel development.

Maybe the answer for more secure kernel code is C with better security analysis tools?

aleph_minus_one• 3 years ago

One could argue that C++ is much more complex and hard to write correct code.

That is why in the Windows kernel, according to https://en.wikipedia.org/w/index.php?title=Windows_NT&oldid=..., C++ is rather avoided, and C is preferred for kernel code (for user-mode code, the priorities are reversed):

"Windows NT is written in C and C++, with a very small amount written in assembly language. C is mostly used for the kernel code while C++ is mostly used for user-mode code. Assembly language is avoided where possible because it would impede portability."

hn927268192• 3 years ago

It's two different concepts. 1) hard to learn 2) hard to read/understand

I would argue rust is hard to learn, and not hard to read or understand once you know it. In my opinion, for example:

Hard to learn, easy to read: Rust Easy to learn, hard to read: Perl Hard to learn, hard to read: C++ Easy to learn, easy to read: Python

Even if you don't agree exactly with my opinions, you could maybe see the distinction between (easy/hard to learn) and (easy/hard to read, once you learned it).

I also think that 99% of the difficulty in learning rust is learning how to get to a compiled state. Once the binary is built, you can make a lot more assumptions about it than other binaries (for example, locations of crashes, overflows, ownership, memory freeing can all be detexted). Compare that to c or c++ where getting to a compiled state is way easier, but the resulting binary segfaults or other issues.

Skunkleton• 3 years ago

Dunno if you can/should edit it, but at first glance I read that as C++ being easy to learn and easy to read.

LeFantome• 3 years ago

Formatting…

Hard to learn, easy to read: Rust

Easy to learn, hard to read: Perl

Hard to learn, hard to read: C++

Easy to learn, easy to read: Python

steveklabnik2• 3 years ago

If rust is complex and hard to learn

The problem with this assertion is that it says a lot of different things, some of which I'd believe to be true, and some of which I do not.

Shouldn’t readability/ understandability be a critical requirement for kernel code?

I don't think anyone is going to say "readability is not important," but the problem is that there's a looming question of "for whom"?

This is basically part of the issue here. You are making an incredibly broad generalization about a fairly complicated topic, one of which we don't even have a lot of evidence about, but many opinions.

tialaramex2• 3 years ago

"Hard to learn" ? Google found that when they trained engineers to write Rust the majority of engineers reported they were confident writing Rust in 2 months or less and a third reported they felt not merely confident but as productive as in other languages in that time. Google describes this as "in line" with numbers for other languages they've taught their engineers so apparently it's not especially "Hard to learn" compared to other languages used at Google.

https://opensource.googleblog.com/2023/06/rust-fact-vs-ficti...

ankurdhama• 3 years ago

I think its more like 90% of language is simple and easy to learn whereas the rest 10% is complex and hard to learn (depending on your experience). You can do a lot just by using 90% of the language. This applies to other programming languages as well - some parts are easy and some are complex.

jug• 3 years ago

Interesting Redstone build. That’s like Windows trunk, right? I wonder if the slew of unusually many and interesting updates is due to it eventually going to become Windows 12? They already have builds from that branch though (Gallium) although none as Insider Preview yet, so I’m unsure how it relates to these.

MikusR• 3 years ago

They will call it Windows 12. And make another arbitrary requirement change. Screwing people who ran the canary builds like they did with Windows 11.

badrabbit2• 3 years ago

Unpopular opinion, both MS and Linux should use Ada instead of Rust in the kernel. The rust language isn't stable enough and it does not force the programmer to do uncomfortable things to avoid logic errors (not memory or race condition). Ada had been tested for decades in life or death level critical systems and it is the better direction for the future.

worthless-trash• 3 years ago

I looked into Ada, have you written any ?

If I remember correctly, there is a safe dialect of Ada but it was difficult to setup on Linux. Is that still the case ?

badrabbit2• 3 years ago

I played with very little introductory programs only. SPARK is the formally verifiable subset of ada from what I recall but my suggestion was to use the ada (ada95?) supported by gcc which means there is no special setup needed other than configure gcc. Ada kernel modules have be written but I don't know if any were mainlined.

sgt• 3 years ago

Yeah but.. Ada is boring, isn't it? I'd like to hear some opinions on that. But in any case, Rust is exciting and new, and therefore it's being adopted. Who wants to be spending their spare time on boring tech? Risk higher, but more fun.

tjalfi• 3 years ago

The Spark Ada safety critical subset is memory safe, but Ada isn't. It's possible to write a kernel in Spark, but hard to believe that you'd get buy-in from other kernel developers. Ada doesn't eliminate use after free, race conditions, or dereferencing null pointers[0]. Rust addresses these, so it's hard to see Ada as an improvement.

[0] https://www.reddit.com/r/ada/comments/mme3jk/is_ada_memory_s...

rkagerer• 3 years ago

Can someone elaborate on when it's ok to editorialize titles like this?

In this case it's helpful. I've wanted to do similar in the past but been hesitant as was under the impression it breaks HN rules or etiquette.

Kye• 3 years ago

> "Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize."

Key bit: "unless it is misleading or linkbait"

Editing or even completely rewriting the title seems to be okay as long as it's accurate and not inciteful or opinionated. I've done it when there was no title or the title didn't say anything meaningful with no complaints.

Windows 11 Insider Preview Build 25905 brings a bit of Rust in the kernel

Related Stories