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: (Score:2)
They use the same excuse for windows.
Re: (Score:2)
Re: (Score:2)
Yup, been hearing that forever. There's always an excuse for bad code.
Re: (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: (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: (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: (Score:2)
Re: (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: (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 i
Re: (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: (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: (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: (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: (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: (Score:2)
Re: (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
Re: (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
Re: (Score:2)
Re: (Score:1)
Re: (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: (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: (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 speci
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: (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: (Score:2)
Can you normalize these numbers by some metric that accounts for the size of the deployment, and possibly bug age?
Re: (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: (Score:2)
Amen!
Re: (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 ...
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: (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 aga
Re: (Score:1)