23 ms·
Linux kernel drivers in Rust might become an option in the future
- deleted 7y ago[deleted]
- shmerl 7y agoNice development! Would be interesting to see something like amdgpu rewritten in Rust.
- mkl 7y agoWhy? Throwing away something useful and reimplementing it again the same from scratch seems like a silly waste of time.
- Avamander 7y agoSlowly rewriting it to Rust does sound beneficial (I wouldn't be seeing memory leaks) but I don't think the c(++)/Rust interop is good and seamless enough for that?
- shmerl 7y agoDepends on the code base.
- Thiez 7y agoStrictly speaking Rust doesn't prevent memory leaks. You can easily create cycles in reference counted types, or `std::mem::forget` something. No use of unsafe required either. That said as long as you don't build graphs with reference counted types it's hard to leak memory by accident.
- frozenport 7y agoWell played.
- ufmace 7y agoSounds 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. I mean, I personally think Rust is cool and all that, but come on, who does that?
- gameswithgo 7y agoThis particular linux thing wouldn't involve rewriting anything in Rust.
- cryptonector 7y agoI don't know why you got downvoted. This is about new drivers. I suppose some existing drivers might later get rewritten, but that's later, when there's been more experience with it. In any case, FF shows that rewriting a complex C/C++ codebase in Rust bit by bit is feasible, though again, that doesn't seem to be the intent in this case.
- anaphor 7y agoCorrect me if I'm wrong, but these drivers wouldn't be merged into the kernel tree itself, right? They would be written as modules. I doubt any of the core developers would feel comfortable reviewing Rust code at this time.
- nwmcsween 7y agoAbout zero chance of rust drivers being merged into the kernel now or in the near future.
- notyourday 7y agoFF shows that new language advocates are as usual out to lunch. It is as if everyone forgot the time when the Netscape ruled the web but some clowns decided they want to rewrite it and make it more awesome driving its market share to nearly zero and company out of business. Mozilla should have continued to re-iterate on FF code, slowly but surely improving it rather than going "Oh look, we can make it soooo much better with this new awesome language" P.S. The really funny part is that it is basically the exactly same project that is engaging in another "rewrite" just with different corporate owners.
- kev009 7y agoJohannes Lundberg wrote a thesis on doing this with FreeBSD and has a framework https://github.com/johalun/rustkpi https://github.com/johalun/rustkpi https://kth.diva-portal.org/smash/get/diva2:1238890/FULLTEXT01.pdf%EF%BB%BF https://kth.diva-portal.org/smash/get/diva2:1238890/FULLTEXT...
- geofft 7y agoWe're working on it: https://github.com/fishinabarrel/linux-kernel-module-rust https://github.com/fishinabarrel/linux-kernel-module-rust 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). We gave a talk about it last week at Linux Security Summit, I'll submit it once the recording is up :) Slides are at https://ldpreload.com/p/kernel-modules-in-rust-lssna2019.pdf https://ldpreload.com/p/kernel-modules-in-rust-lssna2019.pdf .
- raverbashing 7y agoLooks interesting and definitely promising Though it would probably make sense to make the API more "Rust like" and avoid things like the multiple cstr!() Some things are definitely trickier than others, for example how to deal with the different options of kmalloc if it's rust that's allocating memory
- geofft 7y agoFeedback is definitely welcome! Re cstr see https://github.com/fishinabarrel/linux-kernel-module-rust/issues/16 https://github.com/fishinabarrel/linux-kernel-module-rust/is... and https://github.com/fishinabarrel/linux-kernel-module-rust/pull/133 https://github.com/fishinabarrel/linux-kernel-module-rust/pu... . What we have now is definitely better than b"foo\0" but not the best possible thing. I think there's work upstream on custom / multiple allocators; we'll plug the various kmalloc(GFP_FOO) flags into that once it exists. It is super beneficial to use the standard library's collections and third-party crates that use them.
- zaphirplane 7y agoFor those like I was, wondering why a framework is required to write out of tree Linux modules in rust It’s to auto create rust bindings. Link between rust crates and kernel build system
- geofft 7y agoHalf that, and half to create safe interfaces that feel like native Rust ("ergonomic") and not like you're writing C in Rust. For instance, the kernel wants you to define a character device by passing a struct with a bunch of C function pointers for how to read, write, seek, ioctl, etc. on the device. Rust has a trait / interface system that's a good match for this use case, so in src/chrdev.rs we define a Rust trait with all these methods, and we have a helper function to create the C struct with FFI-safe function pointers that call the various methods on the Rust trait. The broad goal is that you don't need to use the "unsafe" keyword to write kernel modules that don't access memory directly themselves (filesystems, network protocols, etc.: device drivers might still need unsafe code where actually talking to the device, but it should be as little as possible). That means the interface used by kernel modules can't involve any unwrapped C functions or raw C pointers.
- michaelangerman 7y agoSome important links that motivated this story... https://hub.packtpub.com/rust-is-the-future-of-systems-programming-c-is-the-new-assembly-intel-principal-engineer-josh-triplett/ https://hub.packtpub.com/rust-is-the-future-of-systems-progr... https://lwn.net/Articles/797558/ https://lwn.net/Articles/797558/
- abcdabcd987 7y agoCheck out the HotOS'19 paper from our lab :) https://danyangzhuo.com/papers/HotOS19-Stone.pdf https://danyangzhuo.com/papers/HotOS19-Stone.pdf
- std_throwaway 7y agoWouldn't modern C++ be better suited than Rust because it's closer to C? 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.
- _pmf_ 7y ago> Wouldn't modern C++ be better suited than Rust because it's closer to C? I think the point is that it would be worse because it's closer to C.
- the_duke 7y agoI'll bite. C++ has quite a few powerful features that Rust doesn't have, including better platform support, but Rust has a lot of things going for it that would make it well suited to kernel development: * no exceptions, and language features and a type system that is set up for explicit error handling - the kernel would need to disable C++ exceptions anyway, making error handling just as cumbersome as in C. * the ML inspired type system helps to write correct code (eg sum types) * the language is not riddled with UB and legacy C support induced cruft. You can opt in to unsafety with `unsafe` blocks, but these can be tightly scoped to where it's necessary and can be especially scrutinized Especially in the context of a kernel, the increased safety guarantees are worth a lot.
- majewsky 7y agoOn the flipside, the kernel developers are a group of people with a detailed understanding of what makes C unsafe, and how to watch out for it in code reviews. I'm not saying that every bug gets caught in code review, not by a long shot, but the kernel developers as a group don't have any experience with reviewing Rust code, let alone reviewing it for unsafe or undefined behavior. We're still pretty early in Rust's lifecycle, and there is still a lot to be learned about what `unsafe` can really break, especially at-a-distance. The UCG WG is doing this work in [1], but I can understand if the kernel developers want to hold off on using Rust for more central parts of the kernel until this work is farther ahead. [1] https://github.com/rust-lang/unsafe-code-guidelines https://github.com/rust-lang/unsafe-code-guidelines
- ajxs 7y agoIf 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.
- WilliamEdward 7y agoHe also said that most of the issues with writing kernels have nothing to do with choice of programming language, but instead hardware compatibility. Neither Rust nor anything else could help this.
- ajxs 7y agoHere's the source of the original quote: https://www.infoworld.com/article/3109150/linux-at-25-linus-torvalds-on-the-evolution-and-future-of-linux.html https://www.infoworld.com/article/3109150/linux-at-25-linus-... Admittedly, kernel and driver development are different things. The original quote was to do with kernel development. "That's not a new phenomenon at all. We've had the system people who used Modula-2 or Ada, and I have to say Rust looks a lot better than either of those two disasters. I'm not convinced about Rust for an OS kernel (there's a lot more to system programming than the kernel, though), but at the same time there is no question that C has a lot of limitations. ...I don't think you actually solve any of the really hard kernel problems with your choice of programming language. The big problems tend to be about hardware support (all those drivers, all the odd details about different platforms, all the subtleties in memory management and resource accounting), and anybody who thinks that the choice of language simplifies those things a lot is likely to be very disappointed." I disagree with him about Ada, for what it's worth, but the overall point is correct. The real problems of kernel development aren't things a borrow checker will help with. A big part of developing a kernel takes place before management of heap memory is even relevant. All this being said. For user-space applications, Rust has a lot to offer.
- swfsql 7y agoI read that slightly differently. I read that as: "even after putting the shoes on, the marathon still needs to be run". So yes, lifting reasoning burden away from eg. function interfaces (owning vs uniquely borrowing vs shared borrowing), lifetime problems (and so on), precisely enables everyone to put/spend more "effort" on the remaining difficulties.
- reacweb 7y agoAt 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.
- agumonkey 7y agoPardon the slightly fanboyish comment, but I fail to remember a single negative response regarding Rust. Considering its domain I'm more than impressed.
- colechristensen 7y agoI don't know much about rust but it seems like most of what I hear comes from fans so I end up doubting everything I hear.
- agumonkey 7y agoIt's just going in many places with a good reception tone. Consider this, cpp was roasted by Linus (IIRC), but there rust is considered an option for drivers.
- nindalf 7y agoNot a comment on Rust, but this sort of thinking appears strange. You hear "X is good" from 7-8 people. You dismiss these people as fans lacking objectivity. If you now hear "X has shortcomings" from 2-3 other people, do you now tell yourself "Yes I knew it all along. X isn't as good as the fans said it was" or do you think "Yeah, now that I have other opinions I can say that the majority of people think X is good and therefore it's probably good". If it's the first, that's just confirmation bias. If it's the second, that's better but I don't get it - why does the mere presence of a contradicting opinion make the first opinion more valid? In any case wouldn't you be better off trying X first hand and forming your own opinion?
- vardump 7y agoI think we should just evaluate Rust based on its merits. Ignore fanboys and ignore the opposite as well. 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. Some possible questions and measures to consider below. I'm sure there's a lot more to add on this list. 1) Stability. Other than for development, unstable kernels are a no go. Can possible negative effects be mitigated? 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. 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? 4) How does it affect runtime performance? Average case. Bloat issues? Any pathologic cases? Any benefits? 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? 6) <Your consideration here or above>
- StavrosK 7y agoIsn't this exactly what they're doing?
- vardump 7y agoI hope so, that's the impression I got. Other than that, I hope the discussion here has less of that "Playstation vs. Xbox" tone we're all familiar with.
- gmueckl 7y agoIn this vain, what about other options like beterC (a very capable runtime-less D subset)? What about allowing Ada into the kernel? The fact they are focussing their evaluation on rust only is already an indication that they are playing the fanboy game to some extent. There are other languages out there that improve over C and can be used for systems programming.
- nindalf 7y agoExisting languages in the Linux kernel - https://www.openhub.net/p/linux/analyses/latest/languages_summary https://www.openhub.net/p/linux/analyses/latest/languages_su... 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.
- cesarb 7y ago> with a bit of C++ (2%) That sounded strange to me, since the dislike of C++ within the Linux kernel is well-known, so I took a quick look. All uses I found were on user space tools, not in the kernel itself, and all of them (except for a "check if this compiles" test file) are in C++ because they have to call into libraries with a C++-only API (LLVM and Qt).
- labawi 7y agoAFAIK kernel itself is only coded in C and assembly. Shell, python, perl and make are for building and tools. Linux kernel does not support c++ (its exceptions, RTTI etc). Only c++ I found was related to perf tool, 6 of 7 cpp files had test in their name.
- non-entity 7y agoI 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.
- stef-13013 7y agoDid you talk about that to Linus :):) ?
- megous 7y agoYeah, 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. If I also need clang and rust for all the platforms, and learn rust, for some questionable benefits... That would make things hard.
- josteink 7y ago> If I also need clang and rust for all the platforms, and learn rust, for some questionable benefits I can see the arguments against needing 2 different C-compiler toolchains, not to mention how this may limit target platform-support to the minimum subset supported by both compilers... But to argue that Rust only provides "questionable benefits" is really not reasonable. Even the hipster Javascript crowd has discovered that providing more information to a/the compiler (Typescript) almost unconditionally provides higher code-quality and better results. When will the C-crowd do the same? When will they shed their "I know better than any machine"-like elitism?
- megous 7y agoRead it as "Questionable benefits in the context of the kernel."
- w8rbt 7y agoI think setuid executables would be a good place for rust or go, but I have reservations about the kernel itself.
- 693471 7y agoCan you imagine running latest vanilla kernels and needing to compile a development Rust compiler just so you can build your kernel? Insane
- zelly 7y agoin 2025 npm will be a dependency for your kernel build
- known 7y agoGive it as an exercise to college grads
- youdontknowtho 7y agoLooking 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.
- roca 7y agoNothing's ever perfect but there is empirical evidence that Rust code is far less vulnerable than C or C++ code. For example this list of bugs found via fuzzing: https://github.com/rust-fuzz/trophy-case https://github.com/rust-fuzz/trophy-case Almost none of those bugs were security-sensitive. Compare to similar lists for C and C++ projects, e.g. http://lcamtuf.coredump.cx/afl/ http://lcamtuf.coredump.cx/afl/.
- youdontknowtho 7y agoI get it. Languages are where major security gains are going to be made. Everyone knows that. That being said, the proselytizing is obnoxious.
- roca 7y agoThat's fair. I'm probably guilty of that sometimes. Personally, I find it obnoxious when people start new projects in C code because they're comfortable with the language and unwilling to learn something better, and those projects contribute to the toxic cesspool of vulnerable software that is undermining civilization.
- youdontknowtho 7y agoSure, but the toxic cesspool that is undermining civilization has less to do with software and more to do with the way that we have organized civilization. I can understand what you mean, though. It's really lame to hear "that's how we've always done it". My personal opinion, however, is that language's like Rust are still taking the wrong approach because we should be making the computers manage the memory for us. Much of the guarantees from Rust's type system could also be gained by more advanced garbage collection or designing hardware in conjunction with garbage collectors to get around some of the thornier issues in that field. If you could take out the perceived drawbacks of garbage collection, then there isn't a reason to do manual memory management. That's my personal soapbox, though, and I could go on. Cheers.
- jstewartmobile 7y agoThis is running MO for comp sci: adding loads of complexity for a minor gain. 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. Somebody's going to say "Oh, you're exaggerating. It's not that bad in Redox." Redox doesn't have to integrate with 28 years of kernel written in C.
- roca 7y agoRust borrow-checking doesn't depend on a closed-world assumption. Federico converted librsvg to Rust and it worked fine.
- jstewartmobile 7y ago"Foreign functions are assumed to be unsafe so calls to them need to be wrapped with unsafe {} as a promise to the compiler that everything contained within truly is safe. C libraries often expose interfaces that aren't thread-safe, and almost any function that takes a pointer argument isn't valid for all possible inputs since the pointer could be dangling, and raw pointers fall outside of Rust's safe memory model." https://doc.rust-lang.org/nomicon/ffi.html https://doc.rust-lang.org/nomicon/ffi.html
- wtetzner 7y agoNot sure what you're getting at. Rust can't catch all bugs, so it's not worth having it to catch the ones it can?
- jstewartmobile 7y agoIt is right there in black-and-white: 28 years of C to be interfaced with -> more FFI -> more unsafe blocks -> less that Rust can verify. I don't think there will be enough left outside of unsafe blocks to justify a second toolchain here. If the kernel were also in Rust, it would be a different story.
- acd 7y agoCould 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. 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?
- deleted 7y ago[deleted]
- zelly 7y agoC++ written with -pedantic -Wall, smart pointers, and clang static analysis tools, ASan, valgrind, etc. enabled is just as safe as Rust. Change my mind.
- jjtheblunt 7y agoDoes C++ do any setup of signal handling, differently than Rust (which, I am guessing, doesn't)?
- bvinc 7y agoAre smart pointers thread safe?
- mlindner 7y agoValgrind is runtime... You're not going to catch a double free that you don't hit on the common path. Not to mention race conditions in memory accesses.
- jjtheblunt 7y agoGenuine question: who restricts the sourcecode language in which a kernel driver is written? 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?