I'm really happy about the inclusion of Rust in the linux kernel. Not because it is Rust but because it shows that we can evolve. And I hope in a thousand years we aren't still stuck on C or Rust but "moved on" to even better things. It would make me quite hypothetically sad if in a thousand years we were still using tools designed by hackers in the infancy of computer science.
I'm really tired of the cargo culted idea that Rust is a silver bullet and C hasn't evolved since the 1970s. Neither of those things are true.
The vast majority of people spouting opinions on Rust don't even write systems software, and have never even compiled a kernel driver. Linux, systemd, grub are all written in C and continue to have fewer flaws than trivial userland applications that allow for privilege escelation. The kernel core is incredibly high quality C, and time would be better spent working on the actual kernel security model. Dennis Ritchie himself wrote a paper about the deficiencies of the Unix security model which was designed for a trusting and shared computing environment.
But of course updating the API surface isn't as sexy as writing in a new cool programming language.
Cargo culting this notion that Rust is good because it is a security silver bullet is both ignorant AND dangerous because it moves the focal point away from the areas that actually need work to make Linux more secure. It's also completely asinine to assume that poorly written Rust will have fewer flaws than expertly written C that has been vetted for literally decades.
Iterative improvement has ALWAYS been the answer over throw everything away and start fresh. C tooling has gotten better over the decades, the C standard has evolved, and people will continue to successfully write secure and performant applications in C.
Edit:
Also are you upset that people still use hammers in 2022? I guess if we aren't throwing away all of our tools instead of improving on their design we aren't really seeing any *Progress*
> Also are you upset that people still use hammers in 2022? I guess if we aren't throwing away all of our tools instead of improving on their design we aren't really seeing any Progress
Have you seen the hammers available in 2022? Not shitty $10 at the DIY store hammers, the kind professionals use? They're making hammers out of Titanium. They're engineering the hammers to produce the best trade offs between striking force and rebound, to deliver a tool that's more effective but hurts less to use for a full day's work.
People have continued to fail to write secure and performant applications in C at an unacceptable rate.
> It's also completely asinine to assume that poorly written Rust will have fewer flaws than expertly written C that has been vetted for literally decades.
No one is advocating for writing the kernel in “poorly-written Rust”. This whole post is one giant, obvious straw man.
Nobody is claiming Rust is a silver bullet, least of all Rust itself which is quite explicit about this.
What it does, however, is assure that an unsafe-free program will not contain any of a certain class of bugs, including invalid memory accesses or data races.
At the same time, it is an objective fact that a huge proportion of serious exploits and vulnerabilities are caused by exactly this kinds of bugs, no matter how much people like you go "just write correct code bro". Formal verification is the way forward and Rust is an excellent first step.
As a bonus, even if you wrapped your whole program in `unsafe`, Rust is a miles better systems programming language than C, in terms of features (imho of course).
> Linux, systemd, grub are all written in C and continue to have fewer flaws than trivial userland applications that allow for privilege escelation.
Obviously you have never experienced or oversaw what goes in the linux kernel mailing list.
Yes, for the average user Linux is rock solid, but behind the curtains lies the countless sweats of kernel contribuitors fighting the bugs, regressions, memory leaks and crashes.
> The vast majority of people spouting opinions on Rust don't even write systems software, and have never even compiled a kernel driver.
I have done this. I don't anymore, but my entry into the software world was exploitation of C code and I was particularly interested in the Linux kernel. I'm not really an expert on it, but I've certainly worked with many. Here's an example of some of the work my company has done, which I was not the main driver for but was involved [0]. You'll note the zero days and n days in the Linux kernel. I really don't think compiling a kernel driver is very hard, uncommon, or relevant experience here.
We also attacked Firecracker, a Rust project, and I'd say I'm quite experienced in the language.
> Linux, systemd, grub are all written in C and continue to have fewer flaws
If by "Linux" you mean the Linux kernel, absolutely not, and I can't imagine anyone informed would say that. Linux has tons of bugs all the time.
> The kernel core is incredibly high quality C, and time would be better spent working on the actual kernel security model
A few things:
1. This isn't a zero sum game. Some people are working on making existing kernel code safer, some people are working on Rust, some people are working on new approaches to access control.
2. If an attacker can exploit the kernel your security model doesn't matter, they'll bypass the thing enforcing it.
3. Rewriting the entire kernel's privilege concept is a sort of hilarious ask since it's completely counterproductive (there are tons of powerful access mechanisms in the kernel already) and would be extremely costly.
> It's also completely asinine to assume that poorly written Rust will have fewer flaws than expertly written C that has been vetted for literally decades.
lol sorry, this just really gets me. The Linux kernel is not expertly written C, nor is it being vetted for decades. That's just... so wrong. The kernel codebase is riddled with flaws that are often exploitable. You're just... so so wrong on this.
Further, auditing Rust code for memory safety errors is trivial compared to C. As we showed in our post on Firecracker we could basically just "grep forunsafe" and then manually trace the code from that point.
> Iterative improvement has ALWAYS been the answer over throw everything away and start fresh.
No one is throwing anything away, you obviously are very confused about what Rust in the kernel means.
> and people will continue to successfully write secure and performant applications in C.
At first glance, this is a hilarious statement, but it ultimately makes me sad that developers are so ignorant about computer security that they'd feel ok saying something so obviously wrong to anyone who knows wtf they're talking about.
> Also are you upset that people still use hammers in 2022? I guess if we aren't throwing away all of our tools instead of improving on their design we aren't really seeing any Progress
>As can be seen, these patches are slowly building the in-kernel Rust code up so that real functionality can be implemented in Rust, but this process has some ground to cover yet. It's not clear whether more Rust code will be proposed for 6.2, or whether this is the full set. The pace of change may seem slow to developers who would like to start doing real work in Rust, but it does have the advantage of moving in steps that can be understood — and reviewed — by the kernel community. The Rust-for-Linux work has been underway for a few years already; getting up to full functionality may well take a while longer yet.
If I'm writing my own out of tree Rust module (for the sole purpose of fun), I wonder how hard it would be to bring in external no-std crates?
Rust as a language feels unusually high level for something running in kernelspace, although it never really sacrifices any control. But I wonder how far we can reasonably go in making kernelspace feel like userspace, by importing more of the language's 'vocabulary types', and maybe a few of the best utility crates for comfort.
But besides people having fun out of tree, the kernel has plenty of fundamental complexity that can't very well be reduced. That tends to be the good complexity, the meat of it.
What I would like to see is things that aren't essential complexity becoming nicer.
Simple cultural things like better error messages when the tooling fails, or documentation becoming more common rather than the exception. None of this is guaranteed to magically happen just because there's a bit of infrastructure where Make can call rustc. But here's to hoping =)
So few people actually do their development/testing in truly-sandboxed environments that I don't think that there's actually much of a difference in practice between malicious code running in userspace vs malicious running in kernelspace ( https://xkcd.com/1200/ ). Of course, I'd love if sandboxed dev environments became more usable and widespread.
I expect it to be possible in near future that you develop, say, a web server in Rust in userspace, and with a few changes run it in kernelspace, with improved performance.
Not a kernel hacker, but if it's just for fun, I don't know if you'd need to limit yourself to no_std crates. Allocation is supported (if it wasn't, then Rust's stdlib wouldn't be adding fallible allocation APIs to support the kernel usecase (and even if crates in the wild aren't using these APIs and abort on OOM, again, this is just for fun)). Meanwhile, I feel like OS-specific stuff performed by libstd (e.g. threads, networking) must surely be supportable somehow, since the OS is right there and all its facilities still exist, even if you might need to adjust codegen to account for the difference between kernelspace and userspace (I assume you would need to compile against a specific target?).
Although Rust for Linux has its own alloc, that isn't really alloc. It is like if you wanted Coke and got Pepsi, if you just wanted fizzy brown beverage you're fine, but if you actually cared this isn't OK.
Rust's String (the mutable owned string type from alloc) implements AddAssign meaning you can write fname += ".txt" and that works, but Rust for Linux doesn't allow that. This is just a really obvious example, there are many other differences
You can't use methods that may panic on OOM like Vec::push or Box::new. This means that close to 100% of crates that use the stdlib won't be usable in the kernel without modifications.
> I wonder how hard it would be to bring in external no-std crates
Wasn't this a thing that would not happen at all? at least that is what I remember from previous discussions. Another question would be how do you avoid an explosion of crates with different versions for each module.
This is more a question of policy than mechanism - I'd imagine at least a provisional policy is in place, but the only to be found somewhere in the relevant kernel mailing lists.
Rust is a manual memory managed language, it literally has nothing inexpressible that C could do. Hell, C is a “higher level” language in that it doesn’t have any way for SIMD instructions.
To add something concrete, you can manually free memory as well based on some dynamic property if you wish.
Depends on what kind of problems you you find interesting, but since it's so close to the metal, and since people want their kernel to be fast, there tends to be a lot of clever algorithms, intricate locking, architecture-specific considerations, dealing with the hardware, all sorts of pretty interesting things you wouldn't usually find in regular business logic.
Take filesystem code for example. It can sound like a conceptually simple and well trodden topic, but if you try writing one there's a pretty large design space and tons of interesting problems to try to solve. And then because of concurrency and the need for performance, there can be very intricate locking to the point it can be challenging to hold the whole model in your head all at once (you can have truncates, writes, mmap, all sorts of very different operations in flight in parallel that interract in funny ways).
Or memory models. Reading memory-barriers.txt is a lesson in humility, I believe you can count on your fingers and toes the number of people in this world who can truly claim intimate familiarity with all the corner-cases and details implied by the model in that little text file =)
But take practically any big subsystem of the kernel, and there tends to be plenty of interesting domain-specific problems and challenges.
I believe they're referring to the essential complexity of the domain. An operating system has some "lower bound" on how complex it can be, which is rather high.
But some stuff doesn't _have_ to be hard. Like OP said, there's no inherent reason for error messages and failures to be cryptic or documentation to be sparse. The system could be more transparent or modular, easier to debug/analyze, etc.
I think there's an example in GCC vs Clang here, but I'm not qualified to comment.
Not the OP, but I would assume that necessary complexity is at least where the complexity mirrors whatever real world complexity it is implementing, thinking particularly of protocol stacks like usb, networking, etc.
What does the relatively slow pace of Rust integration mean for the Apple Silicon GPU driver, which appears to be largely functional at this point but is written in Rust? Will the developers have to maintain a separate kernel branch with more robust Rust support for an extended period?
I don't think pace is slow. I am actually surprised how fast it is going. Code review is a good practice, and I think Rust patches are being reviewed nearly as fast as possible.
> The merge window for the 6.1 release brought in basic support for writing kernel code in Rust — with an emphasis on "basic". It is possible to create a "hello world" module for 6.1, but not much can be done beyond that. There is, however, a lot more Rust code for the kernel out there; it's just waiting for its turn to be reviewed and merged into the mainline. Miguel Ojeda has now posted the next round of Rust patches, adding to the support infrastructure in the kernel.
It's all a balance. Rust is simpler than C++, and the complexity it adds relative to C pays for itself pretty significantly in correctness (C++ is more complex and provides fewer/weaker correctness guarantees). Moreover, there aren't many systems languages to choose from--at least not many that are not super-niche. Even Ada is pretty niche with little mindshare/enthusiasm.
I think there is a question of "Wait till when?" Its not like these kind of languages pop up all the time, let alone get adoption. Rust checks most of the important boxes, and the few it doesn't do well they are working on.
The kernel internally makes no promises about ABI even in C, why would that change for Rust?
For userspace, Rust doesn't export anything new to userspace. The kernel APIs remain as they were, and Linus has the same view as ever about whether it's OK to break userspace.
I mean how do they plan to interop between C and Rust code. Either in the same library or across shared libraries (if written in Rust, what does it export on the API surface such that C code can call into it)?
> The kernel internally makes no promises about ABI even in C
There might be two different definitions of “ABI” in this thread.
The kernel indeed makes no promises regarding e.g. the order in which structure members are declared or the stability of that order from version to version.
It probably can be said, though, to promise (through its interaction with the C compiler) that if you take a structure declaration as it appears in the source code, then in a normally-compiled kernel that structure will be laid out in a manner that’s predictable and most probably even described in a human-readable document. Those rules usually have not changed for decades (even if I sometimes wish they were different).
As far as I know, unless you ask for that specifically, the Rust compiler does not promise any of that, the only documentation for what it will do by default is the source code, and it is free to change the rules from version to version with no notice.
This is a good development and shows that there is appetite to move on to new, safer languages.
What would be even better, IMHO, would be to bring full software fault isolation (SFI) into the kernel and move to a model where many kernel services are implemented as Wasm modules.
Readit News
The vast majority of people spouting opinions on Rust don't even write systems software, and have never even compiled a kernel driver. Linux, systemd, grub are all written in C and continue to have fewer flaws than trivial userland applications that allow for privilege escelation. The kernel core is incredibly high quality C, and time would be better spent working on the actual kernel security model. Dennis Ritchie himself wrote a paper about the deficiencies of the Unix security model which was designed for a trusting and shared computing environment.
But of course updating the API surface isn't as sexy as writing in a new cool programming language.
Cargo culting this notion that Rust is good because it is a security silver bullet is both ignorant AND dangerous because it moves the focal point away from the areas that actually need work to make Linux more secure. It's also completely asinine to assume that poorly written Rust will have fewer flaws than expertly written C that has been vetted for literally decades.
Iterative improvement has ALWAYS been the answer over throw everything away and start fresh. C tooling has gotten better over the decades, the C standard has evolved, and people will continue to successfully write secure and performant applications in C.
Edit:
Also are you upset that people still use hammers in 2022? I guess if we aren't throwing away all of our tools instead of improving on their design we aren't really seeing any *Progress*
Have you seen the hammers available in 2022? Not shitty $10 at the DIY store hammers, the kind professionals use? They're making hammers out of Titanium. They're engineering the hammers to produce the best trade offs between striking force and rebound, to deliver a tool that's more effective but hurts less to use for a full day's work.
People have continued to fail to write secure and performant applications in C at an unacceptable rate.
No one is advocating for writing the kernel in “poorly-written Rust”. This whole post is one giant, obvious straw man.
What it does, however, is assure that an unsafe-free program will not contain any of a certain class of bugs, including invalid memory accesses or data races.
At the same time, it is an objective fact that a huge proportion of serious exploits and vulnerabilities are caused by exactly this kinds of bugs, no matter how much people like you go "just write correct code bro". Formal verification is the way forward and Rust is an excellent first step.
As a bonus, even if you wrapped your whole program in `unsafe`, Rust is a miles better systems programming language than C, in terms of features (imho of course).
An it definitely did have its fair share of dangerous issues [1] which would likely not happen if a safer language were used to write it.
1: https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
Obviously you have never experienced or oversaw what goes in the linux kernel mailing list.
Yes, for the average user Linux is rock solid, but behind the curtains lies the countless sweats of kernel contribuitors fighting the bugs, regressions, memory leaks and crashes.
I have done this. I don't anymore, but my entry into the software world was exploitation of C code and I was particularly interested in the Linux kernel. I'm not really an expert on it, but I've certainly worked with many. Here's an example of some of the work my company has done, which I was not the main driver for but was involved [0]. You'll note the zero days and n days in the Linux kernel. I really don't think compiling a kernel driver is very hard, uncommon, or relevant experience here.
We also attacked Firecracker, a Rust project, and I'd say I'm quite experienced in the language.
> Linux, systemd, grub are all written in C and continue to have fewer flaws
If by "Linux" you mean the Linux kernel, absolutely not, and I can't imagine anyone informed would say that. Linux has tons of bugs all the time.
> The kernel core is incredibly high quality C, and time would be better spent working on the actual kernel security model
A few things:
1. This isn't a zero sum game. Some people are working on making existing kernel code safer, some people are working on Rust, some people are working on new approaches to access control.
2. If an attacker can exploit the kernel your security model doesn't matter, they'll bypass the thing enforcing it.
3. Rewriting the entire kernel's privilege concept is a sort of hilarious ask since it's completely counterproductive (there are tons of powerful access mechanisms in the kernel already) and would be extremely costly.
> It's also completely asinine to assume that poorly written Rust will have fewer flaws than expertly written C that has been vetted for literally decades.
lol sorry, this just really gets me. The Linux kernel is not expertly written C, nor is it being vetted for decades. That's just... so wrong. The kernel codebase is riddled with flaws that are often exploitable. You're just... so so wrong on this.
Further, auditing Rust code for memory safety errors is trivial compared to C. As we showed in our post on Firecracker we could basically just "grep forunsafe" and then manually trace the code from that point.
> Iterative improvement has ALWAYS been the answer over throw everything away and start fresh.
No one is throwing anything away, you obviously are very confused about what Rust in the kernel means.
> and people will continue to successfully write secure and performant applications in C.
At first glance, this is a hilarious statement, but it ultimately makes me sad that developers are so ignorant about computer security that they'd feel ok saying something so obviously wrong to anyone who knows wtf they're talking about.
> Also are you upset that people still use hammers in 2022? I guess if we aren't throwing away all of our tools instead of improving on their design we aren't really seeing any Progress
Terrible analogy.
[0] https://www.graplsecurity.com/blog
Even Modula-2, released in 1978, has safety features that are yet to be part of C23, about 40 years later.
Me too, I agree.
Rust as a language feels unusually high level for something running in kernelspace, although it never really sacrifices any control. But I wonder how far we can reasonably go in making kernelspace feel like userspace, by importing more of the language's 'vocabulary types', and maybe a few of the best utility crates for comfort.
But besides people having fun out of tree, the kernel has plenty of fundamental complexity that can't very well be reduced. That tends to be the good complexity, the meat of it. What I would like to see is things that aren't essential complexity becoming nicer.
Simple cultural things like better error messages when the tooling fails, or documentation becoming more common rather than the exception. None of this is guaranteed to magically happen just because there's a bit of infrastructure where Make can call rustc. But here's to hoping =)
Rust's String (the mutable owned string type from alloc) implements AddAssign meaning you can write fname += ".txt" and that works, but Rust for Linux doesn't allow that. This is just a really obvious example, there are many other differences
Wasn't this a thing that would not happen at all? at least that is what I remember from previous discussions. Another question would be how do you avoid an explosion of crates with different versions for each module.
It feels like it sacrifices control wrt when you allocate and free-memory.
I understand it's deterministic in rust, but it's not explicitly controllable - or at least I've seen it be.
To add something concrete, you can manually free memory as well based on some dynamic property if you wish.
Take filesystem code for example. It can sound like a conceptually simple and well trodden topic, but if you try writing one there's a pretty large design space and tons of interesting problems to try to solve. And then because of concurrency and the need for performance, there can be very intricate locking to the point it can be challenging to hold the whole model in your head all at once (you can have truncates, writes, mmap, all sorts of very different operations in flight in parallel that interract in funny ways).
Or memory models. Reading memory-barriers.txt is a lesson in humility, I believe you can count on your fingers and toes the number of people in this world who can truly claim intimate familiarity with all the corner-cases and details implied by the model in that little text file =)
But take practically any big subsystem of the kernel, and there tends to be plenty of interesting domain-specific problems and challenges.
But some stuff doesn't _have_ to be hard. Like OP said, there's no inherent reason for error messages and failures to be cryptic or documentation to be sparse. The system could be more transparent or modular, easier to debug/analyze, etc.
I think there's an example in GCC vs Clang here, but I'm not qualified to comment.
I don't think pace is slow. I am actually surprised how fast it is going. Code review is a good practice, and I think Rust patches are being reviewed nearly as fast as possible.
Just to be clear, I agree--"relative" is the key word!
It is slow if you're currently using Rust to develop a driver.
I thought they liked C for its simplicity.
Why would they adopt the modern version of C++? (a language they, or at least Linus, look down upon)
Shouldn't they wait for a language with Rust's safety guarantees but with a more minimal feature set?
The kernel internally makes no promises about ABI even in C, why would that change for Rust?
For userspace, Rust doesn't export anything new to userspace. The kernel APIs remain as they were, and Linus has the same view as ever about whether it's OK to break userspace.
There might be two different definitions of “ABI” in this thread.
The kernel indeed makes no promises regarding e.g. the order in which structure members are declared or the stability of that order from version to version.
It probably can be said, though, to promise (through its interaction with the C compiler) that if you take a structure declaration as it appears in the source code, then in a normally-compiled kernel that structure will be laid out in a manner that’s predictable and most probably even described in a human-readable document. Those rules usually have not changed for decades (even if I sometimes wish they were different).
As far as I know, unless you ask for that specifically, the Rust compiler does not promise any of that, the only documentation for what it will do by default is the source code, and it is free to change the rules from version to version with no notice.
What would be even better, IMHO, would be to bring full software fault isolation (SFI) into the kernel and move to a model where many kernel services are implemented as Wasm modules.