You're the first one in this thread to bring up the idea of rewriting the linux kernel in rust... the rest of us are just having a productive discussion on the degree to which a language solves a problem.
Agreed, the hope is that the combination of Rust + a rewrite, you'd be in a MUCH better place than where we are now.
I think an interesting question is, why are there so many contributors to the Linux Kernel in comparison to something like glibc? Both, I'd argue, are equally foundational.
Since you appear to me to be referring to my comment (as I'm the only top-level comment to mention Rust) let me quote some of my comment, with emphasis added to phrases I used to indicate that I was presenting was my opinion, not presenting my opinion as fact, and indeed not suggesting a rewrite in Rust (which you appear to have incorrectly inferred.)
This is, in my opinion, a rather generous interpretation
of events ... What I see when reading this is a system
(the Linux kernel and surrounding infrastructure like the C
language) that is very poorly designed. ... I'm not trying to suggest the kernel should be rewritten in Rust.
If one cannot mention their opinion on this site what indeed is the point of the site? Furthermore, your response is typical of what I've seen to shutdown discussion of kernel development: to suggest the author is an idiot and cannot possibly understand the complexities involved, and if they did they would follow the established development procedures. Do you believe the current state of kernel development is perfect? If not, if one cannot discuss problems how will one ever improve? In this particular case it seems to be a well studied class of bug (use-after-free). Why do you suggest that the many years of work on tools and other methods to address this problem should be ignored?
It's a fun idea and many people have had it first thing when they heard of Rust... So why did no one do it?
Quite simply: No one is going to rewrite the Linux Kernel in Rust. It is far too big and also you are not solving any real issues either. Rust only protects you from a small fraction of errors and while for an application like a browser, this can be a big gain, I would argue that it is negligible for a kernel in general. Reasons being that all the device IO, component interaction, privilege escalations, logical errors, hardware errors, firmware errors/bugs all can NOT be addressed by rust. Even for a browser, Rust is only a band-aid. The amount of logical errors and security holes in something as complex as a modern web-browser is more than enough of an attack surface. No need for a rouge pointer to weird memory.
What is MUCH more viable though is a project to compartmentalize the Linux Kernel into HVMs. I forgot the name but there are efforts to put nearly everything into its own HVM. Which means if the printer driver goes nuts, it can't really do anything to your system except not print anymore. If your graphics driver goes nuts, well then you won't see anything... And so on.
This means, almost no code rewrites and still MUCH higher protection than RUST. Rust does not compartmentalize. If any of your system components is fucked, your whole system is still fucked. That is why it's pointless to rewrite a kernel because of a language. You need to compartmentalize it...
Look at QubesOS for an early user-space effort. Would be nice to have a Qubes-Kernel too.
Writing an operating system is hard and laborious. There are many bugs beyond memory and there are already many tools the Linux team uses to make it safer. That you can make a better, more stable version of the Linux kernel with rust is still to be proven. Not arguing that the language is not better than C or that, if Linux was being started today, it wouldn't be a more sensible pick. But the language is just one component among many others that make such a projects successful.
I would actually be very surprised if there was anything nearly as good as Linux written in rust already. I'm not sure why a company would invest the huge amount of resources to get it done by now and, unless the language had some really unprecedented productivity, I don't think a community led protect would've had it finished by now.
The point of this LPC session was how to incrementally introduce Rust in the existing Linux kernel, with all its existing drivers and syscalls and similar. A rewrite would indeed be a daunting and problematic proposition.
There are kernels written in Rust, such as Redox, but those are separate projects, and that's not what this conference session or article are talking about.
Standing reminder: the Rust project is not a fan of rabid Rust over-evangelism (e.g. "Rewrite It In Rust", "Rust Evangelism Strike Force"), and sees it as damaging and unhelpful. We discourage that kind of thing wherever we see it. We're much more in favor of a measured, cautious approach.
Go ahead and rewrite 30+ million lines of C code in Rust, LMAO.
It's not going to happen, Rust support is being added for new code, not specifically to rewrite the kernel.
Would the world be a better place if Linux, the BSD kernel behind OS X, and the Windows kernel were all rewritten in Rust? (I don't think it would be dramatically better overnight.)
You have no proof that writing a Linux-like kernel in Rust would result in fewer bugs, or even that it is feasible at all (what with writing even linked lists being difficult).
Not OP but the reason I dislike Rust for OS/kernel development is that it's just too damn complicated. Kernels should be written in more conservative languages.
There are mainstream efforts to do the legwork to allow Linux kernel modules to be written in Rust and a fair few core system libraries (the most obvious example being librsvg) and applications have undergone Rust rewrites. And of course there's Redox OS which a full OS entirely written in Rust, and it only contains a few hundred lines of unsafe code (which, given how Rust works is the only really key code that needs to be audited for memory safety).
The reason that more things aren't yet written in Rust is because these things take time, and there is lots of inertia to switching languages for established projects (one big roadblock to such rewrites is that maintainers need to be familiar enough with Rust).
Rust is still a research language. And using more than one language for a kernel/drivers, is that really a good idea? Anyone trying to fix/debug things in the kernel now has to learn Rust.
reply