Rust in Linux: Maturing with Support from Cisco, Samsung, Canonical (zdnet.com) 44
ZDNet shares on update on "Rust in Linux: Where we are and where we're going next," citing a talk at the Linux Plumbers Conference in Richmond, Virginia by Linux/Rust developer Miguel Ojeda:
In brief, Rust Linux is continuing to mature and is getting strong support from developers and vendors, such as Cisco, Samsung, and Canonical... Rust is taking the steps it needs to become — along with C — a fully-fledged member of the Linux language toolchain... That's not to say that we're ready to retire C for Rust just yet. In fact, that day is unlikely ever to come. But Rust is definitely on its way to becoming an important language for Linux development...
As for the day-to-day work that's required to make Rust fully integrated with Linux, the "official" website of the initiative is now the self-explanatory Rust for Linux. This site is your one-stop source for all things Rust on Linux... However, the move forward has not been straightforward. Rust on Linux developers have discovered some problems along the way. For example, while deadlocks, when two or more threads are waiting on the other to finish, are safe in Rust, because they don't result in undefined behavior, they're not safe in the Linux kernel. The programmers are working on fixing this issue...
A related issue is that there's growing interest in backporting Rust support into long-term support (LTS) versions of Linux, specifically 5.15 and 6.1. Some people are especially showing interest in the super LTS Linux 6.1 kernel. However, Linux doesn't generally allow backports into LTS Linuxes. So, if you really, really want fully featured Rust support in an older LTS kernel, you're going to need to pay for it in one way or the other. Another general rule that Rust developers have decided they're going to try to "break" is the rule against duplicate drivers. Usually, no one wants anyone wasting time reinventing the wheel, but some maintainers are open to the idea of experimenting with Rust, by starting simple with a driver they're already familiar with...
These movements are small steps forward, but they're all critical for making Rust equal to C as a Linux programming language.
As for the day-to-day work that's required to make Rust fully integrated with Linux, the "official" website of the initiative is now the self-explanatory Rust for Linux. This site is your one-stop source for all things Rust on Linux... However, the move forward has not been straightforward. Rust on Linux developers have discovered some problems along the way. For example, while deadlocks, when two or more threads are waiting on the other to finish, are safe in Rust, because they don't result in undefined behavior, they're not safe in the Linux kernel. The programmers are working on fixing this issue...
A related issue is that there's growing interest in backporting Rust support into long-term support (LTS) versions of Linux, specifically 5.15 and 6.1. Some people are especially showing interest in the super LTS Linux 6.1 kernel. However, Linux doesn't generally allow backports into LTS Linuxes. So, if you really, really want fully featured Rust support in an older LTS kernel, you're going to need to pay for it in one way or the other. Another general rule that Rust developers have decided they're going to try to "break" is the rule against duplicate drivers. Usually, no one wants anyone wasting time reinventing the wheel, but some maintainers are open to the idea of experimenting with Rust, by starting simple with a driver they're already familiar with...
These movements are small steps forward, but they're all critical for making Rust equal to C as a Linux programming language.
Support from Cisco (Score:5, Funny)
Boy, if there's one company I think of when I think of secure code, it's Cisco.
Re:Support from Cisco (Score:-1)
Re:Support from Cisco (Score:2)
They use the same excuse for windows.
Re:Support from Cisco (Score:2)
Re:Support from Cisco (Score:2)
Yup, been hearing that forever. There's always an excuse for bad code.
Re:Support from Cisco (Score:2)
Exactly. Fuckers trying to hide that they cannot do right or are unwilling to do things right because that makes them less profit.
Re:Support from Cisco (Score:2)
Except that with Windows it is even more obvious that this is just a blatant application of the "Big Lie" propaganda technique.
Re:Support from Cisco (Score:0)
Uh huh, yeah, sure. Just looking at the hundreds of hardcoded credentials vulnerabilities in the CERT database over the years show how often it happens.
Cisco never learns from its mistakes and is doomed to repeat them... over and over and over again. I couldn't think of a company I'd rather keep the hell away from Linux kernel development, even more so that Microsoft or Oracle.
Re:Support from Cisco (Score:3)
> Boy, if there's one company I think of when I think of secure code, it's Cisco.
Who do you think of when you think of a company that should be doing work to make its code more secure?
Re:Support from Cisco (Score:2)
Re:Support from Cisco (Score:2)
Indeed. These fuckers must be _placing_ backdoors (and doing it incompetently) for all the high-profile security vulnerabilities they are having. At this time Cisco is a huge problem and a solution for nothing.
Rust-y Linux: The New Shiny Old Thing (Score:3)
Re:Rust-y Linux: The New Shiny Old Thing (Score:0)
Windows 95 did not come with a native Twitter/X client.
So if you're trying to de-Elon your car, installing Windows 95 ain't such a bad option. I would recommend air-gapping it though - Microsoft haven't released a security upgrade in a while.
Duplicate drivers, well it's your car buddy - don't give the keys to the Mrs and you be fine.
Re:Rust-y Linux: The New Shiny Old Thing (Score:2)
unnecessary
You're losing this argument. You know that, right? You're losing it because your opposition has an endless supply [cvedetails.com] of ammo.
Endless. As in, it's never going to end: it's just you and your hang ups, pissing up a rope, forever.
Enjoy.
Re: Rust-y Linux: The New Shiny Old Thing (Score:3)
You misunderstand why they're doing it. When I'm trying to get a better mastery of a language, I'll often rewrite some older, fully working code that did something I hadn't yet done in the newer language. This is actually a good way to find features, quirks, shortcuts, or overall better ways of modeling problems. Doesn't necessarily mean it will replace the old code, unless it offers a compelling reason to do so. In my case, that's typically because the rust code I wrote runs a hell of a lot faster, which itself is often because rust makes a concurrency and parallelization a hell of a lot more easier and practical. (The "fearless concurrency" provided by the borrow checker really shines here.)
Re: Rust-y Linux: The New Shiny Old Thing (Score:3)
How much would you say is because you're now more experienced now than when you wrote the earlier code?
Just curious.
Re: Rust-y Linux: The New Shiny Old Thing (Score:2)
Between 80 and 99.9% usually. The rest of the improvement is from lack of pressure to get it out of the door asap.
Rust in Linux (Score:2)
Anyone actually believe it will happen? I mean, in a non-token manner. I'm sure it'll be out in 2024, which will also be the year of Linux on the desktop. Amirite?
Re:Rust in Linux (Score:2)
Hang on, what, can you say that again? I was distracted turning on my portable cold fusion generator to charge my flying car.
Re:Rust in Linux (Score:2)
Yes, I believe it, I have a couple of machines that have been running Linux for so long that they all have rust.
Re:Rust in Linux (Score:2)
I do not think so except for some stunts that the big-ego-small-skills Rust community needs to tell itself it is doing great. Say, some irrelevant drivers or the like. Far too many scenarios where you compile a kernel will need to work in the absence of a rust compiler.
Deadlocks in Rust are solved how? (Score:3)
"... while deadlocks, when two or more threads are waiting on the other to finish, are safe in Rust, because they don't result in undefined behavior ..."
Which I read to mean "the deadlock will be detected and signaled for cleanup automatically"... How?
I saw the link on "deadlocks" in the original text about avoiding them with correct use of mutexes, but that's just "write code that won't cause this issue". I've glanced at Rust a bit ago, but beyond more explicit labels of how arguments are used I didn't see a ton that looked special or different.
Re:Deadlocks in Rust are solved how? (Score:2)
Re:Deadlocks in Rust are solved how? (Score:2)
Yeah, I don't get this either. Any sane threading library will have a function that allows you to time out if you can't acquire a lock. If you don't use that on something that might stay locked forever, it's your fault.
Safety (Score:2)
Puts the normally vigilant to sleep with false sense of security. Once we get it in there we can fix it all right up. We really need to get it in there so it's like it was never not in there. Zealotry convinces the unwitting that it's a good idea because it's a good idea. Anyway I can see and name a crusade when I see one.
Rust Documentation (Score:1)
I would love to read something succinct about how Rust handles locking and pointers.
All I can find is long books that go into uninteresting detail or short articles that tell me how good Rust is.
For memory, my impression is that Rust is like Visual Basic, you use lots of dynamic arrays rather than things like linked list. Plus maybe smart pointers with counters. (Plus the trivial case like a string object with an unshared pointer to an array of characters.)
For locking, if you use shared memory there is a deep problem. The only really good solution is ACID as used in databases, which involves locking, guaranteed serializable, deadlock detection with rollback etc. using transactions, but is too heavy for a kernel. ACID copies data, it is pointers that are hard.
Re:Rust Documentation (Score:2)
ACID copies data, it is pointers that are hard.
I see in Rust threads a common pattern. Someone expresses difficulty in handling stuff that would normally be okay for a C pointer, there are arguments back and forth before eventually you get to choose between: The Rust Way which is complicated and will likely involve much re-architecting and Just Clone It (tm) where you just make copies of everything and forget about trying to wrestle the borrow checker.
Now, to be clear I'm not denigrating Rust here, that's just a common theme on Rust threads. If anything I'm denigrating the common responses to "I can't do X in rust..."
Re:Deadlocks in Rust are solved how? (Score:2)
Re:Deadlocks in Rust are solved how? (Score:1)
Re:Deadlocks in Rust are solved how? (Score:3)
"... while deadlocks, when two or more threads are waiting on the other to finish, are safe in Rust, because they don't result in undefined behavior ..."
Which I read to mean "the deadlock will be detected and signaled for cleanup automatically"... How?
Having done a bit of Rust (not much), I believe this means deadlocks are acceptable according to the Rust ethos/compiler, since they don't result in a horribly broken execution such as you would get by overwriting the stack pointer. The program (or those threads) won't continue, but the program is still working as you programmed it.
Re:Deadlocks in Rust are solved how? (Score:2)
Rust does not make deadlocks safe (they cannot be). Rather, it disallows some ways of structuring your code and will then refuse to compile your code until you've written it in a way that the compiler can prove that a deadlock (or memory error, or other types of error) cannot occur. That can sometimes make Rust code much harder to write, but the benefit is that you can be much more aggressive at using threads because you don't have to "play it safe because of the risk of errors".
Re:Deadlocks in Rust are solved how? (Score:2)
I haven't done anything with Rust, and probably won't ever do anything that low level, but, as far as I understand it, by having language features that allow avoiding explicit mutexes most of the time, hidden in the bowels of unsafe code of useful and (mostly) cost-free abstractions. For when you need it, a sentinel is introduced that forces programmers to deal with the failure case (leaking and so on, but no undefined execution) or allow the program to crash.
At the low level of the kernel, with extra special requirements, you probably can still do some mitigation with typing, but it's a bit beyond me.
Please stop (Score:1)
I assume the next step is Python in the kernel and we can have the slowest most insecure OS in the world.
Seriously, search the CVE databases and look for Rust projects. It's worse than even Java.
It's buggy, easy to accidentally write insecure code, bloated, slow, and difficult to maintain. Why Rust? It sucks. It's being pushed by inexperienced children as the hot new thing because they don't know what they are doing.
Re:Please stop (Score:3)
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust
There are 423 CVE Records that match your search.
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=java
There are 2683 CVE Records that match your search.
Re:Please stop (Score:2)
Can you normalize these numbers by some metric that accounts for the size of the deployment, and possibly bug age?
Re:Please stop (Score:2)
Indeed, data taken out of context. IMHO, don't fix what isn't broken and stable! There are much risk in introducing new stuff and rewriting stuff. New bugs, vulnerabilities and other problems are always introduced as well.
Re:Please stop (Score:2)
Amen!
Re:Please stop (Score:2)
Counting CVEs is about the most simplistic and the most dumb and irrelevant metric that can be applied here. Obviously some nil with was going to do it ...
Re:Please stop (Score:0)
Counting CVEs is about the most simplistic and the most dumb and irrelevant metric that can be applied here.
Correct.
Obviously some nil with was going to do it ...
Indeed. It is inevitable. Someone will always look for something, anything, that fits their argument, however specious, and run with it, in the hopes that nobody will notice and thus fall for it.
Rust cancels hexs B00B,BABE... (Score:1)
Intentionally written in decimal rather than hex const PROBLEMATIC_CONSTS: &[u32] = &[ 184594741, 2880289470, 2881141438, 2965027518, 2976579765, 3203381950, 3405691582, 3405697037, 3735927486, 4027431614, 4276992702, ];
Translated 0xB00B135 0xABADBABE 0xABBABABE 0xB0BABABE 0xB16B00B5 0xBEEFBABE 0xCAFEBABE 0xCAFED00D 0xDEADBABE 0xF00DBABE 0xFEEDBABE
Cisco? That is not good (Score:2)
With their history of backdoored products, they will probably just try to get backdoors into the kernel.
Rust equal to C? Wishful thinking. (Score:4, Interesting)
People wanted to put C++ code in Linux, but Linus didn't let them. Then, Linus relented and allowed Rust, as a replacement for the never-happened C++ - in - Linux. That's the whole reason for the existence of Rust in Linux.
Rust is designed to compete with C++ , not with C.
Re:Rust equal to C? Wishful thinking. (Score:2)
To be fair, writing kernel code in C++, where you want to keep things as close to the metal as humanly possible, ideally writing assembler if the damn thing wasn't so hard to trace... Is not the best of ideas.
In kernel space you can't use a ton of the features C++ brings to the table without incurring significant performance problems. Often times memory is constrained, and just invoking an iterator can allocate four bytes of memory extra. "Bruh who cares about 4 bytes don't you have two gigs spare?" and again, no you do not. Modern CPUs have L1, L2, L3 cache and keeping within the limits of these caches massively reduce memory paging and thus massively reduce the time spent waiting for, say, L3 calls.
When you are writing code that should fit within 16 kb of L1 cache, all of a sudden memory usage becomes very important. This is not to say C is the proper tool everywhere within the kernel though.
Re:Rust equal to C? Wishful thinking. (Score:1)