Wedson Almeida Filho is a Microsoft engineer who has been prolific in his contributions to the Rust for the Linux kernel code over the past several years. Wedson has worked on many Rust Linux kernel features and even did a experimental EXT2 file-system driver port to Rust. But he’s had enough and is now stepping away from the Rust for Linux efforts.
From Wedon’s post on the kernel mailing list:
I am retiring from the project. After almost 4 years, I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense, so it’s best to leave it up to those who still have it in them.
…
I truly believe the future of kernels is with memory-safe languages. I am no visionary but if Linux doesn’t internalize this, I’m afraid some other kernel will do to it what it did to Unix.
Lastly, I’ll leave a small, 3min 30s, sample for context here: https://youtu.be/WiPp9YEBV0Q?t=1529 – and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code."
The kernel is mostly written in C, by C developers… understandably they’re rather refactor C code to make it better instead of rewritting everything in the current fancy language that’ll save the world this time (especially considering proponents of said language always, at every chance they get, sell it as C is crap, this is better).
Linux is over 30yo and keeps getting better and more stable, that’s the power of open-source.
Lots of categories which Rust doesn’t prevent, and in the kernel you’ll end up with a lot of
unsafeRust, so it can’t guarantee memory-safety in all cases.The biggest items on the graph are all out of bounds accesses, use-after-free and overflows. It is undeniable that memory safe languages help reducing vulnerabilities, we know for decades that memory corruption vulnerabilities are both the most common and the most severe in programs written in memory-unsafe languages.
Unsafe rust is also not turning off every safety feature, and it’s much better to have clear highlighted and isolated parts of code that are unsafe, which can be more easily reviewed and tested, compared to everything suffering from those problems.
I don’t think there is debate here, rewriting is a huge effort, but the fact that using C is prone to memory corruption vulnerabilities and memory-safe languages are better from that regard is a fact.
Maybe when you build some little application or whatever. When building the most used kernel in the world, there are probably some considerations that very few people can even try to understand.
No idea what you’re being downvoted. Just take a look at all the critical CVSS scored vulnerabilities in the Linux kernel over the past decade. They’re all overwhelmingly due to pitfalls of the C language - they’re rarely architectural issues but instead because some extra fluff wasn’t added to double check the size of an int or a struct etc resulting in memory corruption. Use after frees, out of bounds reads, etc.
These are pretty much wiped out entirely by Rust and caught at compile time (or at runtime with a panic).
The cognitive load of writing safe C, and the volume of extra code it requires, is the problem of C.
You can write safe C, if you know what you’re doing (but as shown by the volume of vulns, even the world’s best C programmers still make slip ups).
Rust forces safe® code without any of the cognitive load of C and without having to go out of your way to learn it and religiously implement it.
They’re being downvoted because it’s a silly comment that is basically unrelated and also extremely unhelpful. Everyone can agree that C has footguns and isn’t memory safe, but writing a kernel isn’t memory safe. A kernel written in Rust will have tons of unsafe, just look at Redox: https://github.com/search?q=repo%3Aredox-os%2Fkernel unsafe&type=code That doesn’t mean it isn’t safer, even in kernel space, but the issues with introducing Rust into the kernel, which is already written in C and a massive project, are more nuanced than “C bad”. The religious “C bad” and “C good” arguments are kinda exactly the issue on display in the OP.
I say this as someone who writes mostly Rust instead of C and is in favor of Rust in the kernel.
The difference is that now you have a scope of where the memory unsafe code might be(unsafe keyword) and you look there instead of all the C code.
I agree and think that should be helpful, but I hesitate to say how much easier that actually makes writing sound unsafe code. I’d think most experienced C developers also implicitly know when they’re doing unsafe things, with or without an
unsafeblock in the language – although I think the explicitunsafeshould likely help code reviewers and tired developers.It is possible to write highly unsafe code in Rust while each individual
unsafeblock appears sound. As a simple example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=6a1428d9cae5b9343b464709573648b4 [1] Run that onDebugandReleasebuilds. Notice the output is different? Don’t take that example as some sort of difficult case, you wouldn’t write this code, but the concepts in it are a bit worrisome. That code is a silly example, but each individualunsafeblock appears sound when trying to reason only within the block. There is unsafe behavior happening outside of theunsafeblocks (thedo_some_thingsfunction should raise eyebrows), and the function we ultimately end up in has no idea something unsafe has happened.Unsafe code in Rust is not easy, and to some extent it breaks abstractions (maybe pointers in general break abstractions to some extent?).
noaliasesin that playground code rightly assumes you can’t have a&refand&mut refto the same thing, that’s undefined behavior in Rust. Yet to understand the cause of that bug you have to look at all function calls on the way, just as you would have to in C, and one of the biggest issues in the code exists outside of anunsafeblock.[1]: If you don’t want to click that link or it breaks, here is the code:
fn uhoh() { let val = 9; let val_ptr: *const usize = &val; do_some_things(val_ptr); println!("{}", val); } fn do_some_things(val: *const usize) { let valref = unsafe { val.as_ref().unwrap() }; let mut_ptr: *mut usize = val as *mut usize; do_some_other_things(mut_ptr, valref); } fn do_some_other_things(val: *mut usize, normalref: &usize) { let mutref = unsafe { val.as_mut().unwrap() }; noaliases(normalref, mutref); } fn noaliases(input: &usize, output: &mut usize) { if *input < 10 { *output = 15; } if *input > 10 { *output = 5; } } fn main() { uhoh(); }
The cognitive load of writing safe C, and the volume of extra code it requires, is the problem of C.
Oh no, i’m having a meltdown with all the cognitive load…
Build all the fancy tools you want. At the end of the day if you put a monkey at the wheel of a Ferrari you’ll still have problems.
Nice that Rust is memory-safe, use it if you want, but why the insistence on selling Rust via C is crap? Doesn’t earn you any points.
How about rustaceans fork the kernel and once it’s fully Rust-only then try and get it to be used instead of the current one… win-win, eh?
Yes a monkey. All the vulnerabilities that have happened over the decades are just bad c programmers. So the question is are there any good c programmers?
It’s not just about bad/good C programmers. It’s also about how much of the context, the given C programmer has read to make sure they know enough of what they are doing.
No matter how good one is at Programming, they need to make sure to read and remember what is happening in relevant parts of code, while making their one off contribution.
That’s where the part of “leaving it to the computer” comes in. Hence, the usefulness of code checkers and even better if the compiler itself enforces the stuff. As long as the rules are good enough.
Let’s just hope we are not jumping to another language 20 years down the line.
Someone stubbed a toe here.
I honestly like the cognitive load. Just not when I am at the workplace, having to deal with said load, with the office banter in the background and (not so) occasionally, being interrupted for other stuff.
And my cognitive load is not even about the memory allocations, most of the time.Off topic:
I think, if one is seriously learning programming from a young age, it is better to start with C, make a project, big enough to feel the difficulty and understand what the cognitive load is all about and get used to it, hence increasing their mental capability. Then learn the memory safe language of their choice.
I never made a big enough project in C, but you can get to feel the load in C++ too.I’m not insisting anything; stating C is not a memory-safe language isn’t a subjective opinion.
Note I’m not even a Rust fan; I still prefer C because it’s what I know. But the kernel isn’t written by a bunch of Lewis Hamiltons; so many patches are from one-time contributors and the kernel continues to get inundated with memory safety bugs that no amount of infrastructure, testing, code review, etc is catching. Linux is written by monkeys with a few Hamiltons doing their best to review everything before merging.
Linus has talked about this repeatedly over the past few years at numerous conferences and there’s a reason he’s integrating Rust drivers and subsystems (and not asking them to fork as you are suggesting) to stop the kernel stagnating and to begin to address the issues like one-off patches that aren’t maintained by their original author and to start squashing the volume of memory corruption bugs that are causing 2/3rds of the kernel’s vulnerabilities.
the kernel continues to get inundated with memory safety bugs that no amount of infrastructure, testing, code review, etc is catching.
I’d say this is the issue to fix. It’s not easy but if anything curl has proven it can be done efficiently.
Yeah, let’s see what Bagder has to say about this:
C is unsafe and always will be
The C programming language is not memory-safe. Among the 150 reported curl CVEs, we have determined that 61 of them are “C mistakes”. Problems that most likely would not have happened had we used a memory-safe language. 40.6% of the vulnerabilities in curl reported so far could have been avoided by using another language.
Rust is virtually the only memory-safe language that is starting to become viable.
https://daniel.haxx.se/blog/2023/12/13/making-it-harder-to-do-wrong/
Memory safe language that’s becoming viable … as a proper replacement of C.
There are many other memory safe languages out there. Just not ones most would like to pull in to the kernel…
having to go out of your way to learn it and religiously implement it.
Look! I painted the mona lisa in ketchup.
deleted by creator
such a weird dichotomy in Windows – secure kernel space and privacy-nightmare user space … “we’re the only ones allowed to steal your data”
deleted by creator
Agree. I’m an absolutely awesome software dev myself - and I know C by heart (being my favorite language after assembler). However, with age comes humility and the ability to recognize that I will write buggy code every now and then.
Better the language saves me when I can’t, in security critical situations.
Even if you manage to keep all memory accesses in your memory, while writing the code, there’s a good chance you’ll forget something when reviewing another person’s MR. That’s probably the main problem creator.
Still, a language that you are familiar with, is better than a new language that you haven’t finished reading the specifications of. And considering that adding new maintainers comes with a major effort of verifying trustworthiness, I get how it would be harder to switch.
C is crap for anything where security matters.
True for people misusing it. If you want to argue the ease of mis-use, it’s a fun talk.
Yea, it’s not C that is crap, but that it has zero guard rails. Like blaming a knife for not having a guard… Is it a bad knife without a guard? Depends on how sharp it is. The guard is orthogonal to the knife’s purpose, but might still be important when the knife is used.
Just because something doesn’t help prevent accidents does not mean it cannot serve its actual purpose well, unless its actual purpose is safety.
I think most people would agree with you, but that isn’t really the issue. Rather the question is where the threshold for rewriting in Rust vs maintaining in C lies. Rewriting in any language is costly and error-prone, so at what point do the benefits outweigh that cost and risk? For a legacy, battle-tested codebase (possibly one of the most widely tested codebases out there), the benefit is probably on the lower side.
Hmm… I admit I didn’t follow the video and who was speaking very well and didn’t notice hostility that others seem to pick up on. I’ve worked with plenty of people who turn childish when a technical discussion doesn’t go their way, and I’ve had the luxury of mostly ignoring them, I guess.
It sounded like he was asking for deeper specification than others were willing or able to provide. That’s a constant stalemate in software development. He’s right to push for better specs, but if there aren’t any then they have to work with what they’ve got.
My first response here was responding to the direct comparison of languages, which is kind of apples and oranges in this context, and I guess the languages involved aren’t even really the issue.
Part of the hostility was the other maintainer misunderstanding the presenter, going on a diatribe about how the kernel Rust maintainers are going to force the C code to become unrefactorable and stagnate, and rudely interrupting the presenter with another tangent whenever he (the presenter) tried to clarify anything.
An unpleasant mix of DM railroading and gish galloping, essentially.
I wouldn’t quite call it a strawman, butthe guy was clearly not engaging in good faith. He made up hypothetical scenarios that nobody asked about, and then denigrated Rust by attacking the scenarios he came up with.Edit: I was thinking of the wrong fallacy. It is a strawman, yes.
He made up hypothetical scenarios that nobody asked about, and then denigrated Rust by attacking the scenarios he came up with.
This seems to be the textbook description of a strawman argument.
Wait, yeah. I was thinking of ad hominem when i wrote that, sorry. Correct, that is a strawman.
If the timeline is long enough then it’s always worth the refactor.
Some next level deaf going on. That’s not what was being discussed.
The defensiveness proves just how out of touch and unqualified to comment some people are.
Most reasonable people say c is good, rust is better
This sounds exactly like the type of nontechnical nonsense they’re complaining about: attacking a strawman (“they’re trying to prevent people from refactoring C code and making them rewrite everything in the current fancy language”) even after explicitly calling out that that was not going to happen (“and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code”).
They said it wasn’t going to happen but their plan will result in it happening, how do you square that?
You tell me how it will result in it happening. Who even has the power to force people to learn Rust?
Linus and GKH, if they merge something that breaks every time C programmers change a kernel API
And where did you find that they will do that?
Better in what ways? Rust’s strong points are not to just make a program more stable, but more secure from a memory standpoint and I don’t think Linux keeps improving on that
at every chance they get, sell it as C is crap, this is better
For ‘sendmail’ values of $C, this resembles another argument. Also, of course for $C=sysvinit.
From other discussions I’ve seen, the guy stepping down was frustrated by having C code rejected that made lifetime guarantees more explicit. No rust involved. The patch was in service of rust bindings, but there was 0 rust code being reviewed by maintainers.
old white man scared of losing their jobs or their commits going insigificant…who cares. Lets move on.
Losing their jobs? Uh what?
Lemmy comment not mentioning the race of someone challenge (IMPOSSIBLE)
the guy speaking off camera in the linked 3min 30s of the video is Ted Ts’o, according to this report about the session.
You can’t teach old dogs new tricks.
You actually can. And it’s not that hard. I had a 14 year old German shepherd mix, who learned several new tricks before her death. I taught a partially blind 79 year old to use a computer, general internet, and email, and was communicating with her [via email] for a number of years before she lost the rest of her vision.
Old dogs, as it were, absolutely can learn new tricks.
Sorry, I just don’t like this idiom, because it puts people in a box in which they do not belong.
Many years ago at work, when PCs started to spread, I taught a 60 years old lady how to use one. She never saw a PC before yet she learned pretty well, and I saw much younger people not learning.
Being willing to learn doesn’t depend on age, it’s a mindset, either you have it or you don’t, and if you do have it, it will last your entire life.
That’s very wholesome to hear! :) Thank you for sharing. I’m glad it’s not the case.
You can, but you can’t turn a 30 year project on a dime. They’re understandably frustrated that newcomers keep coming and screaming RUST RUST RUST RUST RUST
yeah but this isn’t newcomers making noise. This is seasoned devs making meaningful contributions, and getting reactionary responses
My grandpa taught himself to text when he was 89. He just wrote a translation table:
A = 2
B = 22
C = 222
D = 3
…
The comments from that article are some of the most vitriolic I’ve ever seen on a technical issue. Goes to prove the maintainer’s point though.
Some are good for a laugh though, like assertions that Rust in the kernel is a Microsoft sabotage op or LLVM is for grifters and thieves.
People are dumb as hell, it’s fucking open source, go maintain the c fork, and let the those who want to improve the fucking shit cve producing codebase make a rust fork. And see which one people will use, and we all know that the rust fork will have wider adoption, it’s a no brainer.
No one is forcing them to maintain the Linux kernel, no one is telling them to stop writing patches, they can’t because you can download the code and work on it as you like.
It’s people who know they will be irrelevant because they spent decades producing shit software, and they can’t even be bothered to learn a new language to improve stability and security for the whole fucking userbase. Give me a break, what a bunch of whiners.
No because it is buggy and have a bunch of security flaws.
This is such a dumb take. For as much as I’d like to have a safer language in the kernel you need the current developers, the “big heads” at least because they have a lot of niche knowledge about their domains and how they implementation works (regardless of language) People shouldn’t take shit like this from the ext4 developer, but it doesn’t mean we should start vilifying all of them.
This guy’s concerns are real and valid but were expressed with the maturity of a lunatic child, but they are not all like this.
If anything, the constant coddling of a few aging individuals within the kernel and the protection of their comforts is why Linux has been so slow to adopt technologies and paradigms that developers are begging for.
Linus complains of dev burnout starving the kernel of contributors, but the processes and technologies driving kernel development are antiquated, and the very suggestion of change is either discarded or makes you the target of a public shaming by Linus himself.
I agree with your views. But I have to give praise to Linus for bringing Rust into the kernel.
Yes and the big heads in this case don’t want to share that knowledge, because why? Because they are treating the kernel like their pet project that they own and control, and they don’t wanna lose that control, rather looking at the bigger picture.
It’s kinda obvious that rust is the way forward as google has clearly shown, so why are they gatekeeping?
Yes I agree but the solution for a project so big and critical is not to fork. How do you maintain all of it while at the same time adding support to Rust?
There’s no solution, they need not only to accept that rust is going to be part of the kernel but also that it’s a good thing. Otherwise how do you cooperate efficiently.
And also if they are so big brained, should be easy to learn rust then, I mean I’m pretty small brained and I know rust.
“There’s no compromise, I’M RIGHT AND YOU’RE WRONG!”
no wonder everyone hates rustphiles
What compromise? Half code should be in rust?
What does this even have to do with rust developers, The language rust gives us the ability to have more compile time checks, and why is that a bad thing. Do you like security issues in your OS because some dev forgot to handle pointers correctly?
The only compromise Rust programmers would accept is C programmers learn Rust so when they break Rust code they can fix it.
Can we have a vegan rust sub, please?
When did they refuse to share knowledge?
That was what he was talking about at the conference, he literally asked for help about how things work, so he could write better APIs that they are more comfortable using.
But the response was we don’t want to write rust.
So what’s the solution that doesn’t involve C programmers writing Rust?
There’s is no other way, C is a security issue - do you understand?
So you want to force C programmers to write Rust or GTFO.
Unix -> Linux -> Ferrix?
Nobody can maintan a fork of the linux kernel on their own or even with a team. It’s a HUGE task.
There already is rust in part of the linux kernel. It’s not a fork.
But I agree with your first statement, people are dumb as hell, me included lol
No shit
What is so hard to understand, C Is a fucking security issues?
The sad thing is, there are other languages better at replacing C/C++ due to closer resemblance, except they’re rarely used due to lack of trendy technology that is being hyped in Rust. D lost a lot of ground due to its maintainers didn’t make it an “immutable by default” language at the time when functional programming paradigm was the next big thing in programming (which D can still do, as long as you’re not too fussy about using
consteverywhere).It was never about replacing C with a new language for the sake of novelty, it was about solving the large majority of security vulnerabilities that are inherent in memory-unsafe languages.
If Rust were to implode tomorrow, some other memory-safe language would come along and become equally annoying to developers who think they’re the first and only person to suggest just checking the code really hard for memory issues before merge.
if you were right they’d replace it with Java.
Rust’s memory safety is at compile-time. Java relies on a virtual machine and garbage collector. Nothing wrong with that approach but there’s a reason Rust is used in kernels and Java is used in userspace apps.
Java was invented 20 years sooner.
Arch people tell you “I use arch BTW”
Rust people make PRs rewriting your code in rust.
Rust people are worse.
I feel like the time to hide information behind YouTube links is over. Feels like a link to a paywall article at this point.
Totally
The video attached is a perfect example of the kind of “I’m not prepared to learn anything new so everyone else is wrong” attitude that is eating away at Linux like a cancer.
If memory safety isn’t adopted into the kernel, and C fanaticism discarded, Linux will face the same fate as the kernels it once replaced. Does the Linux foundation want to drag its heels and stuff millions into AI ventures whilst sysadmins quietly shift to new kernels that offer memory safety, or does it want to be part of that future?
If Linux gets rewritten in Rust it will be a new kernel, not Linux. You can make new kernels, even in Rust but they aren’t Linux. You can advertise them at Linux conferences but you can’t force every Linux dev to work on your new Rust kernel.
Isn’t Linux still Linux even though probably a lot of the original code is gone? Why would slowly rewriting it whole, or just parts, in Rust make it stop being Linux?
Ship of Theseus
Isn’t Linux still Linux even though probably a lot of the original code is gone?
The Kernel of Theseus.
Indeed :)
Linux is whatever the Linux Mark Institute says it is.
Is a single line of code in the kernel completely unchanged since its birth?
Nobody is proposing rewriting the whole kernel in Rust.
There is no “your” new rust kernel. There is a gigantic ship of Theseus that is the Linux kernel, and many parts of it are being rewritten, refactored, removed an added all the time by god knows how many different people. Some of those things will be done in rust.
Can we stop reacting to this the way conservatives react to gay people? Just let some rust exist. Nobody is forcing everyone to be gay, and nobody is forcing everybody to immediately abandon C and rewrite everything in rust.
the crew on the Ship of Theseus would like a word with you. Because if you strip out every subsystem and replace them with a different language, everyone would still call it Linux and it would still work as Linux.
Linux isn’t “a bunch of C code” it’s an API, an ABI, and a bunch of drivers bundled into a monorepo.
Linux is a development ecosystem. If everyone agrees to switch to Rust it can switch to Rust with continuity. But they won’t.
I admit I’m biased towards C-languages out of sheer personal preference and limited exposure to Rust but I am wondering, are there any major technical barriers to Rust replacing these languages in it’s current form anymore?
I know there has been a lot of movement towards supporting Rust in the last 6 years since I’ve become aware of it, but I also get flashbacks from the the early 00’s when I would hear about how Java was destined to replace C++, and the early 2010’s when Python was destined to replace everything only to realize that the hype fundamentally misunderstood the use case limitations of the various languages.
Its mainly a matter of stabilizing existing features in the language - there are rust modules in the linux kernel as of 6.1 but they have to be compiled with the nightly compiler.
Rust is a very slow moving , get it right the first time esque, project. Important and relatively fundamental stuff is currently and has been useable and 99% unchanging for years but hasnt been included in the mainline compiler.
Also certain libraries would be fantastic to have integrated into the standard library, like tokio, anyhow, thiserror, crossbeam, rayon, and serde. If that ever happens though itll be in like a decade.
Oh and try blocks.
I see. Thanks for the explanation.
I am no visionary but if Linux doesn’t internalize this, I’m afraid some other kernel will do to it what it did to Unix.
Maybe that’s not a bad thing? If you ask me the GNU people are missing a trick. Perhaps if they rewrote Hurd in Rust they could finally shed that “/Linux”.
They will write kernel in Ada
GNU isn’t punchy though; as soon as any punchy word get’s associated with them, people will use that word instead, and we’ll just get GNU/Thermite or GNU/Abson or something.
Easy, GNU->GUN
Gun! Unix? Not!
Are the version numbers going to be mm or caliber?
Gotta be mm to make sense unfortunately, Linux-GUN 7.62.11
Who was the guy that had a lot of pauses with mmmmmm when talking?
