7 ms·
From the comment section: > To me the more salient questions are how long before (a) we get Rust in a core subsystem (thus making Rust truly _required_ instead
by yourdetect 10mo ago
From the comment section:
> To me the more salient questions are how long before (a) we get Rust in a core subsystem (thus making Rust truly _required_ instead of "optional unless you have hardware foo"), and (b) requiring Rust for _all_ new code.
Previously, the position was that C developers would not be forced to learn Rust.
And a few days ago a security vulnerability was found in the Rust Linux kernel code.
https://news.ycombinator.com/item?id=46309536 https://news.ycombinator.com/item?id=46309536
- AlotOfReading 10mo agoWhere did anyone promise that the Rust bits will never have security issues? That CVE was a fantastic demonstration of just how much better the situation is in Rust code and I don't think there's a realistic argument that the experiment has been anything other than successful.
- uecker 10mo agoWas it? It seems more a fantastic demonstration how the same type of errors can also occur in Rust code.
- jrimbault 10mo agoIn C this kind of issue is so common it wouldn't raise to the status of "CVE". People would just shrug and say "git gud".
- uecker 10mo agoThis is certainly not true. But also arguments about "common" are completely misleading as long as there is many orders of magnitude more C code than Rust code.
- Certhas 10mo agoMaybe you haven't been paying much attention in this space. Google found empirically that error density in _unsafe_ Rust is still much lower than in C/C++. And only a small portion of code is unsafe. So per LOC Rust has orders of magnitudes fewer errors than C/C++ in real world Android development. And these are not small sample sizes. By now more code is being written in Rust than C++ at Google: https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html https://security.googleblog.com/2025/11/rust-in-android-move... But don't take my word for it, you can hear about the benefits of Rust directly from GKH: www.youtube.com/watch?v=HX0GH-YJbGw There really isn't a good faith argument here. You can make mistakes in Rust? No one denies that. There is more C code so of course there are more mistakes in C code than in Rust? Complete red herring.
- yourdetect 10mo ago[flagged]
- uecker 10mo agoThat is is undefined behavior does not mean it is exploitable. But I also have not seen an argument why a data race should not be exploitable in this context.
- yourdetect 10mo agoI am very wary of going that route. If there is undefined behavior, the compiler is in principle allowed to do anything and everything, unless it promises something beyond what the language promises. One could then argue that a specific version of a specific compiler with specific settings in a specific case, after investigation of the generated assembly or inspection of what guarantees the compiler provides beyond the language, is not exploitable. But other settings of the compiler and other versions of the compiler and other compilers may have different guarantees and generation of assembly. The Linux kernel uses, as I understand it, a flag for GCC for C code that disables strict aliasing. That basically means that strict aliasing is no longer undefined behavior, as long as that flag is used. Basically a dialect of C.
- uecker 10mo agoIt is very common for C implementation to define undefined behavior and also common for C programs to rely on this. For this reason, I think it is very misleading to say that undefined behavior is automatically exploitable or even a bug.
- johncolanduoni 10mo agoAnd the kernel is infamous for being picky about the C compilers it can be successfully built with - clang couldn’t build a working kernel for a long time, and it was mostly relying on subtle GCCisms.
- 10mo ago
- rtpg 10mo ago> And a few days ago a security vulnerability was found in the Rust Linux kernel code. was it a security vulnerability? I'm pretty sure it was "just" a crash. Though maybe someone smarter than me could have turned that into something more. I have no dog in this race, I really like the idea of Rust drivers but can very much understand retiscience at getting Rust to be handling more core parts of the kernel, just because Rust's value seems to pay off way more in higher level code where you have these invariants to maintain across large code paths (meanwhile writing a bunch of doubly-linked lists in unsafe Rust seems a bit like busy work, modulo the niceties Rust itself can give you)
- taneliv 10mo ago> was it a security vulnerability? I'm pretty sure it was "just" a crash. It's a race condition resulting in memory corruption.[1][2] That corruption is shown to result in a crash. I don't think the implication is that it can result only in crashes, but this is not mentioned in the CVE. Whether it is a vulnerability that an attacker can crash a system depends on your security model, I guess. In general it is not expected to happen and it stops other software from running, and can be controlled by entities or software who should not have that level of control, so it's considered a vulnerability. [1] https://www.cve.org/CVERecord/?id=CVE-2025-68260 https://www.cve.org/CVERecord/?id=CVE-2025-68260 [2] https://lore.kernel.org/linux-cve-announce/2025121614-CVE-2025-68260-558d@gregkh/T/#u https://lore.kernel.org/linux-cve-announce/2025121614-CVE-20...
- uecker 10mo agoIt is entertaining to observe that how - after the bullshit and propaganda phase - Rust now slowly enters reality and the excuses for problems that did not magically disappear are now exactly the same as what we saw before from C programmers and which Rust proponents would have completely dismissed as unacceptable in the past ("this CVE is not exploitable", "all programmers make mistakes", "unwrap should never been used in production", "this really is an example how fantastic Rust is").
- simonask 10mo ago
- dannersy 10mo agoThere are lots of vulnerabilities in the C code, too. Should we remove C or do we accept that fact that no language is perfect since they are used by humans and continue to make improvements and use tools that help us along as time goes forward? The cherry picking for this one Rust vulnerability to the ~150 C vulnerabilities is such a weird take that I can't help but think people have some weird hatred of Rust.
- yourdetect 10mo ago> Should we remove C or Your post is curious, for the post I quoted basically argued for just that eventuality for all new code. Even as the new language introduces undefined behavior vulnerabilities. The promises as stated previously, and the goal as stated by that lwn.net post now, are starkly different. And the poster did not even wait until the new language has proven its worth. And then a UB CVE comes by in the code in the new language. What Linus wrote in the past: https://www.phoronix.com/news/Torvalds-On-Rust-Maintainers https://www.phoronix.com/news/Torvalds-On-Rust-Maintainers > So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: there's that "wall of protection" around C developers that don't want to deal with Rust issues in the promise that they don't have to deal with Rust. That both you and that lwn.net poster writes these things, is extraordinarily weird and strange.
- dannersy 10mo agoBut this sounds like hubris and user error, then, and not a language discussion at all?
- uecker 10mo agoI do not think it is weird. Every C bug was taken as clear evidence that we need to abandon C and switch to Rust. So the fact that there are also such bugs in Rust is - while obvious - also important to highlight. So it is not weird hatred against Rust, but hatred against bullshit. And considering that most of the code is C, your 150 C vulnerabilities is a meaningless number, so you still continue with this nonsense.
- kubb 10mo agoI think you’ve said the quiet part out loud by mentioning learning Rust. The learning seems to be the only legitimate issue that people have. But they avoid mentioning it because it sounds intellectually lazy.
- simonask 10mo agoAnd it is intellectually lazy.
- bitwize 10mo agoAs Rust's advantages over C continue to be proven, a shift in position to "suck it up, C devs" is to be expected.
- tormeh 10mo agoEh, these are highly skilled individuals that just don't like learning a new thing, no matter how useful. That attitude is a problem to be managed, but these people deserve a certain amount of respect. Anyone saying "suck it" or similar should get a grip.
- qingcharles 10mo agoAgree. As a dev I've had to pivot a dozen times in my career. If you're a dev you should be able to learn a new language fairly quickly, all the core elements are the same, just the vocabulary is a little different. Since nobody has "fixed" C to avoid these bugs, and we're not going to go as far as put Java or .Net in the kernel, then I think Rust is probably the best, most pragmatic solution we have right now.
- thegrim000 10mo agoWell yeah, that's the strategy. "You don't need to learn it or use it, we just want to do our own separate things with it over here" .. some time later .. "Oh yeah it's working good for us, we think it'd be useful to use it in these additional places, think about the benefits!" .. some time later .. "Now it's going to be core and required, either deal with it or get out" They know they could never jump straight to the last step without revolt, so they shove their foot in the door with fake promises and smiles and then slowly over time force the door all the way open until they eventually get what they wanted from the beginning.