The Linux Kernel Prepares For Rust 1.77 Upgrade (phoronix.com) 49
An anonymous reader shared this post from Phoronix:
With Linux 6.8 the kernel's Rust code was brought up to Rust 1.75 while new patches posted this weekend port the code over to Rust 1.76 and then the upcoming Rust 1.77...
With Rust 1.77 they have now stabilized the single-field "offset_of" feature used by the kernel's Rust code. Rust 1.77 also adds a "--check-cfg" option that the Rust kernel code will likely transition to in the future. This follows the Rust for Linux policy of tracking the upstream Rust version upgrades until there is a minimum version that can be declared where all used features are considered stable.
With Rust 1.77 they have now stabilized the single-field "offset_of" feature used by the kernel's Rust code. Rust 1.77 also adds a "--check-cfg" option that the Rust kernel code will likely transition to in the future. This follows the Rust for Linux policy of tracking the upstream Rust version upgrades until there is a minimum version that can be declared where all used features are considered stable.
Re: (Score:3)
Rust is only in certain driver modules.
I'm not certain if cpp is in any.
And yes, this does seem to be the case of giving
someone enough rope to hang themselves.
Re: Doomed to fail like slashDEAD (Score:2)
Who pays for it? Our clicks, just like everything else on the internet.
Re: (Score:3, Insightful)
The kernel doesn't use C++. As for C, every time you see a CERT advisory about the kernel (or any open source product) then there is a > 50% the issue was caused by the language - double free, null pointer, overflow etc. It should be very obvious why the kernel might want to adopt a safe programming language with comparable performance to C to reduce those issues.
Re: (Score:2)
OTOH, I used to make a 1MB /boot partition for linux, then 10MB, then 30MB, 100MB, 1GB, 3GB. Nowadays, I don't even bother to make a boot partition anymore. I wonder if the Rust code is going to make the kernel even more humongous although it shouldn't be a concern for most people anyway.
Re: (Score:2)
So, the Linux kernel image on my machine is about 14MB. That is pretty big, but not really why your boot partition had to grow. The initrd is like 120MB. That is where all the space is being used.
Re: (Score:2)
Thanks for that Sherlock! /s
That was my point, since Rust is only supposed to be in modules for now, how many of these modules will be required in initrd in order to boot if your using them for some stuff?
As a side note, I used to run everything compiled into the kernel, no module support at all. The mentality back then was that modules were a security risk. They still are in some way but it has become almost impossible to go without them nowadays.
I think Rust will add another level of complexity but oh wel
Re: (Score:2)
In terms of lines of code I don't know. I expect that someone will develop patterns in Rust for drivers and modules to utilize but the actual lines of code that go into those drivers & modules is probably the same or slightly less than the equivalent C. Rust is a pretty terse language, terser than C, and you don't need to split the code into headers and source.
In terms of run time performance and binary size I doubt it will make a huge difference. The rust compiler is a front end that spits out intermed
Re: (Score:2)
Sure, I tend to agree, we'll see! I am eagerly waiting for the first exploit from a Rust module made public, it will be popcorn time here on Slashdot! Overall, Rust should prevent some mistakes and security holes although. Again we'll see!
Re: (Score:3)
The issue is "caused" by C because that is what the kernel is (mostly) written in. The amount of security issues in the Linux kernel is approximately proportional to its size and approximately on par with any other project of that scale (perhaps lower due to "more eyes" on it), irrespective of what technology or language was used for the said project (consider, for example, the many projects written in Java, Python or any other of your choice of "memory safe" languages).
Everything has security issues and li
Re:Doomed to fail. (Score:5, Insightful)
It should be very obvious why the kernel might want to adopt a safe programming language with comparable performance to C to reduce those issues.
Rust is probably the wrong choice, though, due to its mega-complexity.
Re: (Score:2)
Mega complexity? Rust is a terse C like language and it is only "complex" in the sense that the compiler will kick your ass if you write unsafe code. I'm sure this does trip up some programmers. It is still vastly better than what C does, which is not to give a damn and generate code that will crash, race or whatever. I suspect most developers would prefer errors were caught during compilation rather than wasting hours trying to find them, or worse having customers find them in shipping products.
I also expe
Re: (Score:3)
What Rust are you referring to? Rust is anything but terse, it's what I image the offspring would look like if C++ and Perl had a one night stand. Is this terse and grokable?
use std::ops::Mul;
struct Factorial<T: Mul<Output=T> + Copy + From<u8>>(T);
impl<T: Mul<Output=T> + Copy + From<u8>> Factorial<T> {
fn new() -> Self {
Factorial(T::from(1))
}
Re: (Score:2)
This Rust.
fn factorial(n: u8) -> u32 {
(1..=n).fold(1, |acc, x| acc * x as u32)
}
fn main() {
println!("{}", factorial(5));
}
Rust is much more terse than C. But you can write C++ in it if you want.
Re: (Score:2)
Not just technically, but politically. Every single time I see a new article on Rust, I get a preemptive headache before I even start reading the comments.
Re: (Score:2)
there is a > 50% the issue was caused by the language - double free, null pointer, overflow etc.
Except that the "offset_of" it's referring to in TFS is used for *gasp* pointer arithmetic!
It should be very obvious why the kernel might want to adopt a safe programming language with comparable performance to C to reduce those issues.
Enabling the use of pointer arithmetic means that Rust is now less safe because it includes such features. /s
For those that can't figure out sarcasm, don't blame the tool for the actions of the idiot using it. If you need the language to "catch" you doing something stupid, perhaps you shouldn't be writing high security code in the first place. Stick with apps until you've gained enough experience.
Re: (Score:3)
Well that's a very special comment. Rust is safe by default but it still allows you to write unsafe blocks or invoke C where perhaps something can break. It still allows the majority of code which is not marked unsafe to be checked during compilation. It also means that if something does break in the small amount of unsafe code, that a developer has a far better idea where it happened.
And the arrogance of insinuating that you're some kind of Super Programmer immune to writing errors, or that the kernel deve
Re: (Score:2)
Rust is safe by default but it still allows you to write unsafe blocks or invoke C where perhaps something can break
I know [slashdot.org].
And the arrogance of insinuating that you're some kind of Super Programmer immune to writing errors, or that the kernel developers are likewise!
Only as arrogant as putting words in the mouths of others. I never made any such claims. Humans are human and humans make mistakes. The issue isn't that the language is "bad", but rather that humans use the language as an excuse not to learn from their mistakes.
A glance at the CVE database shows every C program, even some of the most reviewed on this planet is afflicted with errors directly caused by the language itself.
Nope. Those are errors caused by humans. A programming language cannot and does not create errors itself. If you as the programmer make a mistake, the computer executes that mistake very carefully. A fact that your own argument in favor of
Re: (Score:1)
Everything seems doomed to fail when you're fundamentally clueless about what is going on. Why did you even bother posting at all?
Re: It's nice to see Linux move into the 21st Cent (Score:1)
And if such motivated supporters see it's not so easy and some of the worst problems may get worse will they admit as such? Or will investors blame someone else like illegal marijuana, legal marijuana, 9/11, vapes, e- cigs, cryoto, Jan/6th....?
Re: (Score:2)
Re: (Score:3)
I wonder if there will be an initiative to gradually convert the bulk of the Linux kernel to Rust in order to take advantage of the superior security features and paradigm?
I would say no. Unless there is some pressing need like a security bug, kernel code should not be rewritten for the sake of being rewritten. If it works, leave it alone.
Re: (Score:2)
This is wrong on many levels but I'll single out the single most important reason why Rust will never be a good choice for an OS kernel, it contains hidden control flows.
Torvalds Speaks: Rust's Impact on the Linux Kernel (Score:3)
Meh (Score:2)
Someone will have to rip the Rust crud out of the kernel some day.
Or maybe replace that crud with some other, when the new trendy language will come out (and go, like most of them do).
Re:Meh (Score:5, Informative)
Re: (Score:1)
It's already bad enough as it is, to have many millions lines of code written in C (which is time proven and known and used by many), with some random code written in a language used by the 0.001% of the available engineering force.
Years ago a proposal like this would have gotten a pitchfork treatment on LKML.
Re: (Score:3)
Years ago a proposal like this would have gotten a pitchfork treatment on LKML.
And what part of the proposal would have gotten a pitchfork treatment? Every time I see the doom and gloom naysayers on Rust, they almost always misstate the actual proposal and status. New drivers can be written in Rust. That is the proposal. That does not mean Linus will auto-approve every new code that is written in Rust as some people have decried that code quality will go automatically down. That does not mean the entire kernel is being rewritten in Rust as some people have imagined. And this is somew
Re: (Score:1)
A bunch of code will go in to support that language, maybe a few drivers will get written, and then when the hype will vanish and a new Lust language will show up, so will the maintainers of the added crud.
Then we will be left with some unused junk written in a language that TIOBE won't even rate anymore, and someone will have to clean it up (and possibly rewrite some of the code written in it).
You can quote me on this
Re: (Score:2)
A bunch of code will go in to support that language, maybe a few drivers will get written, and then when the hype will vanish and a new Lust language will show up, so will the maintainers of the added crud.
1) You have asserted already that the code is crud. All code will be reviewed. 2) You do know that code does not stop working when maintainers leave right? Most code does not change unless there is a reason like bug fixes. 3) Maintainers vanishing is not unique to Rust. It happens right now in Linux with C. 4) This is open source; someone else can maintain code besides the original maintainer. 5)Again, C is not disappearing. If the need arises, the driver can be rewritten in C.
Then we will be left with some unused junk written in a language that TIOBE won't even rate anymore, and someone will have to clean it up (and possibly rewrite some of the code written in it).
1) Again, you assert that it i
Re: (Score:1)
The most frequent changes happen when there are internal code refactoring, and developers really enjoy go fixing dead (or on life support at the least) code.
Do you even know how Linux works?
Yeah, a git-blame with my name will likely pop up a few thousands LOC...
Re: (Score:2)
Code does not need to be changed only when there are bugfixes.
Read my statement again. "Most code does not change unless there is a reason like bug fixes." Code should not change unless there is a need. I did not say bug fixes are the ONLY need.
The most frequent changes happen when there are internal code refactoring, and developers really enjoy go fixing dead (or on life support at the least) code.
Again, code changes ARE reviewed in Linux. If someone is changing code just to change code, those changes are rejected in review. Code that is working is not changed unless there is a need. Not sure how to explain that any clearer to you.
Yeah, a git-blame with my name will likely pop up a few thousands LOC...
If you have experience, then why are all your comments as if you have never added Linux cod
Re: (Score:2)
My take is he got fed up with these morons and is currently giving the Rust fanatics enough rope to hang themselves. It is a pretty good hint that all Rust can be thrown out of the kernel easily.
Re: (Score:2)
The fact that it has to be "upgraded" to Rust 1.77 shows that they are busy hanging themselves already. That is the issue with all these fad languages is the constant maintenance cycle on existing code so you can continue to use it. Python being the worst of the worst in this regard.
Re: (Score:2)
Well, you can have stable things (i.e. suitable for production) and you can have stuff that is "new" and "innovative" but entirely unsuitable for production. Takes some real-world experience to understand that though, and many big-ego-small-skill coders lack that.
As to Python, it depends. If you are a bit more conservative in what you use, the only update you really need is to 3.x. On the other hand, Python is very much not a systems programming language, while Rust pretends to be.
Portability? (Score:3)
Kernel being C makes it very portable, how does Rust introduction affect it? I already faced Rust problems in one of my projects that is using Yokto and attempt to make Rust for it failed on the first try.
But perhaps this will make Rust environment ported more.
Re: (Score:2)
Kernel being C makes it very portable, how does Rust introduction affect it? I already faced Rust problems in one of my projects that is using Yokto and attempt to make Rust for it failed on the first try. But perhaps this will make Rust environment ported more.
The changes allow for Rust to be added for new drivers. So if your target platform does not use the driver that is written in Rust, it is not affected. Also there is no mandate that new drivers must use Rust. New drivers can still be written in C. There could be drivers for one platform written in C but in another written in Rust. It is not very portable but different drivers for different platforms is hardly a new thing in Linux.
Re: (Score:2)
Re: (Score:2)
Sure, I understand that in the core Rust is also based on C/C++ so wherever C/C++ compiler is ported to it 'may be' portable. But in practice it requires specific version of compiler and libraries which makes it much less portable. This is esp acute for niche custom builds. Granted, eventually it will be as good as C/C++.
Re: (Score:2)
There will not be any important kernel parts in Rust for exactly that reason. Most platforms the kernel runs on do not even have a Rust compiler that can target them.
With 2 watches you never know what time it is (Score:2)
Re: (Score:2)
Re: (Score:2)
A Microsoft VP presented how they are rewriting their kernel in Rust https://www.thurrott.com/windo... [thurrott.com] and it has since been deployed in a trial in Windows 11 (win32kbase_rs.sys) https://www.itpro.com/software... [itpro.com]
Apple is using Rust at low level, opinions are it's possible that it is ni the kernel given Apple has many teams and they can make this choice choice https://news.ycombinator.com/i... [ycombinator.com]