Comment by jacquesm
5 years ago
Rewriting the Linux kernel in rust would be a rehash of why we ended up with Linux in the first place: rewriting an older OS from scratch.
I would love to see a solid implementation of a real micro kernel based OS based on a message passing core in Rust to become a viable alternative to the now 50 year old Unix architecture. This would give us a possibility of some real progress on the security and process scheduling front, both of which are severely lacking in the Unix model.
Why do people implicitly assume that micro kernels are the best OS design?
In fact, micro kernels have a lot of issues and limit the possibilities of what an OS can do! One of the most important issues is they prevents resource sharing in a rich and efficient way between the components of the kernel. They make building rich relationships between kernel data structures and kernel subsystems very messy, complicated, impracticable and very inefficient.
Micro kernels are delusional and people should stop implicitly assuming their superiority.
Historically, one of the main arguments against microkernels is that having a kernel that's broken up into a lot of threads that each have their own hardware-enforced memory protection and use message passing to communicate with each other is dreadfully inefficient. All those context switches are expensive, and copying all that data around when you send messages is expensive.
Rust's memory model largely makes those isolated address spaces unnecessary, and sending a message at runtime basically amounts to copying a pointer. So, with these performance issues resolved, I think it makes sense to look at microkernels again. The reasons why Linus was opposed to writing Linux as a microkernel in the 90's don't necessarily still apply now in 2021.
There may some things the Linux kernel does that can't be efficiently expressed using a message-passing style, but I don't know if that's actually true or not.
> Rust's memory model largely makes those isolated address spaces unnecessary,
I think you're confusing several concepts. Rust's "memory model" is the C++11 memory model. Maybe you meant the borrow checker and the distinction between shared and exclusive references? Yes, those make it much harder to accidentally screw up other parts of your address space, but it's downright trivial to do it on purpose – you just need an unsafe block and std::ptr::write.
There's nothing about Rust that could replace isolated address spaces. Rust is typically compiled to native machine instructions, there's no sandbox or virtual machine that will protect different modules from each other.
10 replies →
This is a limitation of the memory model, not the microkernel. If you had a single hardware-protected address space, kernel modules could share resources freely.
But this does argue against message passing, since such systems preferentially try to use messages over sharing whenever it's possible.
Message passing at first seems interesting and neat and useful. It is for some cases. But it comes at a cost of complexity and latency.
Just in case you don't know about it: https://redox-os.org/ could be interesting to you :)
Mach's internals didn't follow the Unix model, and was by almost any metric a failure.
There have been several other "real micro kernel based OS based on a message passing core", and they too, by almost any metric, have been a failure.
Process scheduling in Linux in 2021 is far, far ahead of anything in any other OS, ukernel or MP-based. The idea that there hasn't been progress in this area is really completely absurd. In fact, the general idea that Linux follows "the now 50 year old Unix architecture" is also pushing the boundaries quite a lot.
Meanwhile, the world runs on QnX. The fact that you don't realize it and don't see it is testimony to its success.
I know that QnX is widespread, but far more devices run Android than QnX. It's a bit of a philosophical debate whether the software that runs most smartphones "runs the world" more or less than the stuff covered by QnX, but I'd say that's its a bit of a stretch to just give the win to QnX :)
But you're right, QnX is the one (probably the only?) micro-kernel that has seen widespread adoption. Almost all of it has been in the context of embedded systems, which doesn't invalidate the substantial success, but it does leave QnX as the exception that proves the rule. It also leaves QnX as yet another example of the general failure of microkernels as general purpose computing platforms. QnX design is excellent for the contexts where it is deployed, but there's a reason you don't run it on PCs, tablets, data crunchers, smartphones and many other sorts of computing contexts.
1 reply →
> "real micro kernel based OS based on a message passing core", and they too, by almost any metric, have been a failure.
BeOS wasn't half bad. The failure was probably mostly commercial. It is true that they moved their networking stack into the kernel, but it's not entirely clear to me that they had to do that, it was just the most expedient way to get acceptable performance and stability given the (programmer-time) resourcing constraints of the project.
> BeOS wasn't half bad. The failure was probably mostly commercial.
Fair point. You could probably say this of other attempted microkernels too, to be even fairer. But that doesn't really change the fundamental point that just cooking up "a better OS design" doesn't lead to it being successful. There's a lot more in play that "mere quality".
2 replies →
BeOS wasn't a microkernel.
2 replies →
Mach is of course doing quite well and moving back towards being microkernel-y as hardware gets fast enough to support it and Apple needs a better security story.
Written properly, a monolithic kernel in Rust would provide many of the benefits of a microkernel, due to the memory safety. It'd be much along the same lines as Microsoft Research's Midori, with software isolation instead of hardware isolation.
It would be wide open to specially crafted drivers, it's the equivalent of client side security (or maybe that should be 'compile time security'). Memory safety is something only process space isolation can bring.
Fuchsia and QNX provide a lot of what you want.
https://en.wikipedia.org/wiki/QNX
https://en.wikipedia.org/wiki/Fuchsia_(operating_system)
https://lobste.rs/s/p8bizb/getting_know_fuchsia_google_s_ope...
I think I'm aware of QnX ;) (I wrote a clone).
I believe someone is building something like that on top of sel4, which gives even stronger correctness guarantees than Rust, even though it's C.