Hacker News Reader

Comment by dharmab | Hacker News Reader

Based on early days of Rust in the Linux kernel, the segmentation of safe and unsafe code can significantly reduce the surface area within a kernel.

View on HN

I realize this is beating a dead horse, but it really is a shame that microkernels didn't win for human-facing Unix systems. This issue was recognized and basically solved decades ago, and we're still almost there.

Yeah, I've wondered a bit if the Spectre class of vulnerabilities was discovered a couple decades sooner if it would have changed the course of history there.

Hurd any day now, right?

I do wonder what this landscape could have looked like if all of the effort had gone behind a Mach-based microkernel. I read all of the back and forth between Tanenbaum and Torvalds. At the time, I was just so excited to see "free and open" winning.

I should specify that the XNU Kernel from Darwin/OSX took a lot of my attention when it first premiered.

Hurd works in the same sense that OpenBSD works. It has very limited hardware support so you'll likely have to run it in a VM, but it does work.

If you're willing to split your workload into VMs in the first place I think application-level segmentation like Qubes starts to become a more interesting idea that microkernels.

There is a lot of flexibility that you get from microkernels outside of isolation that you don't get from virtual machines. I'm not suggesting use one GNU/Hurd VM for one application (similar to what you would get with Qubes). I'm suggesting using one GNU/Hurd VM for many applications.

This is true for server systems too. I've often had problems which were ultimately only solvable by rebooting large fleets of servers.

Had the servers been running microkernels instead, updating services without full restarts would have been trivial in almost all cases.

It's just a better approach overall. I curse the path dependency that led to the current situation.

I consider servers to be human-facing systems. I more meant to account for the fact that L4 is used in Qualcomm modems and Minix is used for Intel ME. I would not consider either of those as human-facing.

They might win in the long term. Linux is moving in a micro-kernel direction with things such as netmap, io_uring, DPDK and SPDK.

What's the uptake of Rust as far as Linux kernel dev goes? Is it being positively welcomed and seeing a rise in usage or is it still at PoC stage? Any ongoing rewrites of important subsystems?

So far 61 files [0], vs 52k for C, so about 0.1%.

[0]: https://github.com/search?q=repo%3Atorvalds%2Flinux++languag...

It may not be much at the moment, but the thing that I find encouraging is that there seems to be very little pushback against it; the sanity of the Rust approach is very much accepted now.

Most of the interesting work is not yet upstreamed. A particularly interesting example is the Apple Sillicon GPU driver in Asahi Linux.

Last I checked still very early days with most of the work/experimentation happening in the driver space. However, it doesn't seem like its facing a lot of resistence and Torvalds seems reasonably positive about it atm.

I mean it's obvious why it works. The less code that has to be heavily scrutinized for memory issues, the more the few people that can scrutinize such code can focus on the parts that still need that level of scrutiny.

That was the most brilliant part of Rust lang design, when I thought about it.

There will always need to be unsafe ops in highest performance, low level coding.

But in the vast majority of use cases, there only need to be a few.

So huge security win being able to isolate those vs "somewhere in the entire codebase."

Do you rewrite the Linux kernel as-is in Rust or try something new? Would/should a Linux in Rust look the same?

As other commenters have said, you can do it a bit at a time, converting non-core kernel code to Rust at the edges. Another route to memory (and other) safety would be the C -> WASM -> C route that effectively rewrites/transpiles code to operate within its own sandbox, which also has the advantage that it could at some later date support modules written in languages other than C.

Reply on news.ycombinator.com