Greg KH on Rust in the Kernel: “Why Wouldn’t We Want That?”

[0:00] Rust for Linux has been a pretty hot topic recently, with a lot of drama surrounding it. So much so that the founder of Asahi Linux stepped down as the lead of the Apple Silicon work within the kernel, and then even as the lead of Asahi Linux itself. There have been reports of people within the kernel being hostile with those who want to implement things using the Rust language instead of the heavily customized C language that the Linux kernel is historically used. There have been claims of sabotage from the Rust side and claims of overreacting

[0:26] from some in the kernel side, and it’s just, it’s a bit of a mess. This week, though, there was a very interesting post made by Greg Kroah-Hartman, or Greg KH, to the Linux kernel mailing list, making a very compelling argument for Rust and the kernel. For those unfamiliar with Greg, Greg KH is the maintainer of the stable branch

[0:44] of the Linux kernel, so he’s, you know, one of the big top dogs of Linux. Greg says, as someone who’s seen almost every kernel bug fix and security issue for the past 15 plus years, well, hopefully all of them end up in the stable trees. We do miss some of the times when maintainers, developers forget to mark them as bug fixes.

[1:01] And someone who sees every kernel CVE issued, I think I can speak on this topic. This is Greg, not me. The majority of bugs, quantity, not quality or severity, we have are due to the stupid little corner cases in C that are totally gone in Rust. Things like simple overwrites of memory, not that Rust can catch all of these by far, error path cleanups, forgetting to check error values, and use after free mistakes. That’s why I’m wanting to see Rust get into the kernel and these types of issues just go away, allowing developers and maintainers more time to focus on the real bugs that happen, such as logic issues, race conditions, etc. I’m all for moving our C codebase towards making these types of problems impossible to hit. The work that Keys and Gustavo and others are doing here is wonderful and totally needed. We have 30 million lines of C code that isn’t going anywhere any year soon.

[1:56] That’s a worthy effort and is not going to stop and should not stop no matter what. But for new code slash drivers, writing them in Rust where these types of bugs just can’t happen or happen much, much less is a win for all of us. Why wouldn’t we do this? C++ isn’t going to give us any of that any decade soon. and the C++ Language Committee issues seem to be pointing out that everyone better be abandoning that language as soon as possible if they wish to have any code base that can be maintained for any length of time.

[2:26] Wow, that’s some strong words. Rust also gives us the ability to define our in-kernel APIs in ways that make them almost impossible to get wrong when using them. We have way too many difficult, tricky APIs that require way too much maintainer review just to ensure that you got this right. That is a combination of both how our APIs have evolved over the years, how many different ways can you expect, can you use a struct CDEV in a safe way, and how C doesn’t allow us to express APIs in a way that makes them easier slash safer to use. Forcing us maintainers of these APIs to rethink them is a good thing, as it is causing them us to clean them up for everyone. See users included already making Linux better overall. And yes, the Rust bindings look like magic to me in places, someone with very little Rust experience, but I’m willing to learn and work with the developers

[3:16] who have stepped up to help out here. Rust isn’t a silver bullet that will solve all of our problems, but it sure will help in a huge number of places. So for new stuff going forward, why wouldn’t we want that? Linux is a tool that everyone else uses to solve their problems. And here we have developers that are saying, hey, our problem is that we want to write code for our hardware that just can’t have all of these types of bugs automatically.

[3:37] Why would we ignore that? Yes, I understand our overworked maintainer problem being one of those people myself, but here we have people actually doing the work. Yes, mixed language code bases are rough and hard to maintain.

[3:50] But we are kernel developers. We’ve been maintaining and strengthening Linux for longer than anyone ever thought was going to be possible. We’ve turned our development model into a well-oiled engineering marvel, creating something that no one else has ever been able to accomplish.

[4:05] Adding another language really shouldn’t be a problem. We’ve handled much worse things in the past, and we shouldn’t give up wanting to ensure that our project succeeds for the next 20 plus years.

[4:17] We’ve got to keep pushing forward when confronted with new good ideas and embrace the people offering to join us in actually doing the work to help make sure that we all succeed together.

[4:29] Thanks, Greg KH. So in my opinion, this is awesome. This is a great message from Greg. It’s a very compelling argument. And I think it’s very important that this is being said because there’s the drama that’s happening around Rust for Linux is kind of interesting because it does seem like some people just don’t want to learn a new language and other people are trying to push a language that you know has merit and it feels like a you know one pushing like a brick wall and that sort of stuff so i hope that this kind of thing can be taken care of and the you know the linux kernel is more open to rust because there is a lot of people in the kernel project who are very open to Rust, not only Greg K.H., but many others who have specifically gone on to, keynotes and stuff talking about it, and there have been many quotes from various different developers. I think that ultimately what we need to have happen is that.

[5:28] This Rust becomes part of the Linux kernel and Greg KH says that it should be used going forward. And I think that’s a great way to do it. You’re not going to be able to transition Linux from C to Rust overnight. It would take forever, obviously. So to transition very slowly to a point where it just eventually becomes Rust based or maybe not fully Rust based, but, you know, a combination of the two and have some things that are C for like legacy purposes or whatever. I think that would be fantastic. And I hope any of the people who are part of the Rust development crew or the projects that were related to Rust and Rust for Linux would see this and potentially consider coming back. You know, if they’re burned out, I get it. But I hope at some point they could return and participate because, for example, Hector Martin has done a lot of amazing work starting the Asahi Linux project, which a lot of people thought was a waste of time. I don’t know why they would think that but i think it’s awesome that they would do it because.

[6:29] Because all the effort that Hector Martin did as well as the asahi linux team which of course is still working and they actually introduced a new system of like they’re having a council of multiple people which i think is a really good idea instead of just having one person at the top having multiple people this can be fantastic so i think that the asahi linux project is you know it’s still good to go it’s still being developed and all that but it would be really cool to see Hector come back as well as the other people who have left the projects and stuff based on all this stuff. It’s been happening for quite a while and a lot has unfortunately happened and I hope we can get back to a state where you know we can all just get along. If you like this kind of content and would like to get more from me then be sure to check out this video because I’m not really sure what this is. This is the almighty algorithm choosing this video and I hope it’s a good one. I mean, it’s going to be a good one. I made it automatically. It’s a good one, right? But at the same time, I have no idea what it is. So fingers crossed people.