We're working on it: <a href="https://github.com/fishinabarrel/linux-kernel-module-rust" rel="nofollow">https://github.com/fishinabarrel/linux-kernel-module-rust</a><p>Check out the demo in PR #122, which lets you create three boolean sysctls and a character device that prints the state of those sysctls in JSON (using serde).<p>We gave a talk about it last week at Linux Security Summit, I'll submit it once the recording is up :) Slides are at <a href="https://ldpreload.com/p/kernel-modules-in-rust-lssna2019.pdf" rel="nofollow">https://ldpreload.com/p/kernel-modules-in-rust-lssna2019.pdf</a> .
Johannes Lundberg wrote a thesis on doing this with FreeBSD and has a framework <a href="https://github.com/johalun/rustkpi" rel="nofollow">https://github.com/johalun/rustkpi</a><p><a href="https://kth.diva-portal.org/smash/get/diva2:1238890/FULLTEXT01.pdf%EF%BB%BF" rel="nofollow">https://kth.diva-portal.org/smash/get/diva2:1238890/FULLTEXT...</a>
Sounds like the start of something good. Though the comments feel a bit weird. Maybe it's just a strange day for some reason, but I feel like today, I've seen an awful lot of comments from people pushing rewriting things in Rust who know absolutely nothing about the code they're asking about or the problem domain it runs in.<p>I mean, I personally think Rust is cool and all that, but come on, who does that?
If I recall correctly, Torvalds already addressed the hype around this ( totally not new ) idea by pointing out that memory errors really make up only tiny part of the intricacies of building a kernel. This idea predates Rust, and for better or worse will probably outlive it.
Yeah, I would not like this becomming required. Now, it's still fairly manageable to keep developing and building my own kernels. You need binutils/gcc for your host platforms, and that's about all. And I have 3 architectures I build for.<p>If I also need clang and rust for all the platforms, and learn rust, for some questionable benefits... That would make things hard.
I think we should just evaluate Rust based on its merits. Ignore fanboys and ignore the opposite as well.<p>In other words, Rust is just another tool. Regard it as one without subjective emotions either way. Be constructive, don't only look for faults, but also ways how to overcome them. But don't close your eyes from them either. Acknowledging weaknesses is the first step to improvement.<p>Some possible questions and measures to consider below. I'm sure there's a lot more to add on this list.<p>1) Stability. Other than for development, unstable kernels are a no go. Can possible negative effects be mitigated?<p>2) Security is often what Rust is expected to bring on the table. So is Rust actually more secure in the environment kernel requires? This could be tested by "clean-room" reimplementing something that is historically known to have many security issues.<p>3) Are there showstoppers for kernel builds? Interoperability, build performance, architectures unsupported by Rust, etc. If so, could these be mitigated? Conversely, is there something positive Rust could provide?<p>4) How does it affect runtime performance? Average case. Bloat issues? Any pathologic cases? Any benefits?<p>5) What other unexpected it brings on the plate? Both benefits and disadvantages. For example, could Rust types also be used to catch errors other than memory related, like invalid states?<p>6) <Your consideration here or above>
Check out the HotOS'19 paper from our lab :) <a href="https://danyangzhuo.com/papers/HotOS19-Stone.pdf" rel="nofollow">https://danyangzhuo.com/papers/HotOS19-Stone.pdf</a>
Some important links that motivated this story...<p><a href="https://hub.packtpub.com/rust-is-the-future-of-systems-programming-c-is-the-new-assembly-intel-principal-engineer-josh-triplett/" rel="nofollow">https://hub.packtpub.com/rust-is-the-future-of-systems-progr...</a><p><a href="https://lwn.net/Articles/797558/" rel="nofollow">https://lwn.net/Articles/797558/</a>
Could we have universal standardized hardware interfaces for basic functionality of hardware devices? For example at least get the same programming interface for basic functionality of Wifi chips. Then one could have more accelerated drivers which makes use of all the specific hardware features of chips.<p>Network chips has started to offer a common programming api as far as I understand Switch Abstraction Interface (SAI). Could one do this for more different than network hardware classes?
Existing languages in the Linux kernel - <a href="https://www.openhub.net/p/linux/analyses/latest/languages_summary" rel="nofollow">https://www.openhub.net/p/linux/analyses/latest/languages_su...</a><p>Unsurprisingly it's mostly C (95.6%) with a bit of C++ (2%) and Assembly (1.6%) and tiny bits of make (0.2%), shell scripts (0.3%), Python (0.1% and Perl (0.2%). I'd guess it'd be at least half a decade before Rust cracks 1% here.
Genuine question: who restricts the sourcecode language in which a kernel driver is written?<p>I'm thinking machine opcodes in a .o file, to be linked wherever, are only of a concern if they're doing function call linkages (and maybe kernel space vs user space transition bookkeeping) improperly?
C++ written with -pedantic -Wall, smart pointers, and clang static analysis tools, ASan, valgrind, etc. enabled is just as safe as Rust. Change my mind.
I have Rust on a long backlist of things to check out, but the idea of writing kernel drivers in something other than C is interesting to say the least.
This is running MO for comp sci: adding loads of complexity for a minor gain.<p>Compile-time borrow-checking works for self-contained applications--the compiler has a complete picture of what's going on. Move that model inside kernel space--where blobs are being mutated across separately compiled modules, different chipsets (CPU/DMA/GPU), sometimes even in parallel--might as well wrap the whole thing in a big `unsafe` block.<p>Somebody's going to say "<i>Oh, you're exaggerating. It's not that bad in Redox.</i>" Redox doesn't have to integrate with 28 years of kernel written in C.
Pardon the slightly fanboyish comment, but I fail to remember a single negative response regarding Rust. Considering its domain I'm more than impressed.
Looking forward to enough Rust adoption that people stop seeing it as a magic bullet. Once it's in large scale use and there are still errors that lead to security problems maybe people will get over themselves.
Wouldn't modern C++ be better suited than Rust because it's closer to C?<p>I know that old C++ got some bad reputation in the past but I think it's time to reconsider that with the changes that started with C++11. The only area where Rust really is better is the management of lifetimes and its associated higher memory safety.
At the beginning, C was a handy language with some traps and pitfalls. Thanks to standardization committees and insane optimizers, it has become a minefield of undefined behaviors and security issues. Linux is coded in C because of the "C is the desert island language". This should change and I dream to see something that will replace C at least in the kernel.