Google Supports Getting Rust Into The Linux Kernel

[cl333r]

Linus does not and Rust developers agree with his reasoning. Once the voiced issues are resolved, it may be greenlit.

I was wondering myself. For example Rust's answer to aliased mutability is to crash and thus crash the whole kernel, this is the same as when a cop sees any random human shoots him instantly on the premise that "security is very important - a human can be a terrorist - thus needs to be killed asap".
This crazy logic is supported by all of the Rust community, I'm glad Linus is hiliting Rust's crazy approaches to programming.

[kpedersen]

"security is very important - a human can be a terrorist - thus needs to be killed asap".

So now we know that Skynet was written in Rust.

Obviously it also had a bunch of watchdog daemons to restart any subsystems that did abort for "safety"

[birdie]

I was wondering myself. For example Rust's answer to aliased mutability is to crash and thus crash the whole kernel, this is the same as when a cop sees any random human shoots him instantly on the premise that "security is very important - a human can be a terrorist - thus needs to be killed asap".
This crazy logic is supported by all of the Rust community, I'm glad Linus is hiliting Rust's crazy approaches to programming.

It's not crazy, it is sound for user space applications but not so much for the kernel.

[Almindor]

I was wondering myself. For example Rust's answer to aliased mutability is to crash and thus crash the whole kernel, this is the same as when a cop sees any random human shoots him instantly on the premise that "security is very important - a human can be a terrorist - thus needs to be killed asap".
This crazy logic is supported by all of the Rust community, I'm glad Linus is hiliting Rust's crazy approaches to programming.

Can you link this? The closest I know of is the LLVM bug that keeps popping up forcing rustc to disable aliasing optimizations.

[cl333r]

Can you link this? The closest I know of is the LLVM bug that keeps popping up forcing rustc to disable aliasing optimizations.

It's part of Rust's core features [1], you can fake a workaround by using RefCell<> but it only moves the check of the borrowing rules to runtime and when detected (the moment you call borow_mut() and it detects a borrowing violation - which in Rust sounds like "It's a human - kill him - he could be a terrorist") the program crashes - there's no mechanism to get back your code and "allow" the program to run. There's also a clusterfuck of libraries and horrible techniques in Rust to kinda avoid it but none really does. Granted rare code has deep enough tree-dependencies to actually trigger the crash, but I had to manage dynamically a mutable (HTML) tree and as the code base widened it started crashing at runtime when calling borrow_mut(), and the user made special libraries designed to workaround this don't solve the problem, they just mutate it or involve more limitations.

Btw, "unsafe" Rust doesn't allow one to circumvent this rule.
But again, normally people don't run into this because usually the code doing this is usually not deep enough to trigger it, mine was because I created a lib exposing an API to manage an HTML (xml) tree.

[1] https://doc.rust-lang.org/book/ch15-...utability.html

[ssokolow]

It's part of Rust's core features [1], you can fake a workaround by using RefCell<> but it only moves the check of the borrowing rules to runtime and when detected (the moment you call borow_mut() and it detects a borrowing violation - which in Rust sounds like "It's a human - kill him - he could be a terrorist") the program crashes - there's no mechanism to get back your code and "allow" the program to run.

In other words "Bad coders use C incorrectly in userspace. Therefore, C is unsuitable for the Linux kernel."

RefCell::try_borrow and RefCell::try_borrow_mut for non-panicking RefCell use have existed since 2016 and RefCell is a standard library construct, not a lang item.

If you don't like RefCell, you can construct your own wrapper around the UnsafeCell primitive that instructs the compiler to allow aliasing. Just prepare to get dubbed a source of untrustworthy dependencies if someone runs the Miri runtime analyzer's data race detector on your code and it trips because you had an overblown estimation of when you knew better than the compiler.

Fun fact: while at Mozilla I heard multiple anecdotes of [very intelligent] Firefox developers thinking they had found a bug in Rust's borrow checker because they thought it was impossible for a flagged error to occur. However, after sufficient investigation the result was always (maybe with an exception or two because Mozilla adopted Rust very early) that the Rust compiler was correct and the developer's assertions about how code could behave was incorrect. In these cases, the Rust compiler likely prevented hard-to-debug bugs or even exploitable security vulnerabilities. I remember one developer exclaiming that if the bug had shipped, it would have taken weeks to debug and would likely have gone unfixed for years unless its severity warranted staffing.

-- https://gregoryszorc.com/blog/2021/0...professionals/

[cynical]

It's part of Rust's core features [1], you can fake a workaround by using RefCell<> but it only moves the check of the borrowing rules to runtime and when detected (the moment you call borow_mut() and it detects a borrowing violation - which in Rust sounds like "It's a human - kill him - he could be a terrorist") the program crashes - there's no mechanism to get back your code and "allow" the program to run.

That is the point of Rust. You should be following the rules because although you believe you can manage aliased mutable references yourself, evidence shows that humans are actually fallible and not good at that kind of reasoning.

[reba]

"security is very important - a human can be a terrorist - thus needs to be killed asap"

Well, I actually quite agree here. Misbehaving code HAS to be shot down to prevent further corruptions later down the line or in areas where the reason for failure has been obscured so much you'll never find the reason why it tripped at this place.

"Fail Early" and "Fail Hard (or at least very very loud)" are programming rules I established in all my projects. It served everyone well and improved the software quality so much we could aquire several new projects from the customer and reduced maintainance time so much we had the capacity to develop these without stocking up more personel..
Trying to be clever and "correct" invalid data or unexpected behaviour is a stairway to hell (this's why I dislike browsers checking HTML so sloppy and "use strict" being so late to the game).

The problem I see is, when Rust modules will be added to the kernel, they get all the blame for crap that gets handed to them and which makes them assert or panic loudly. IMHO this is the only reaction they can show: fail hard and fail loud. Otherwise the offender cannot be found. And when the Rust modules get the blame because they're "so fragile" or "so petulant" it simply is an indicator of something going wrong elsewhere and for the first time it actually shows itself because Rust can be and should be used as a very hard mistress. Code Must Not Fail. Every failing code, every piece of data that gets manged but passed along has gotten one step too far in the program's path. In a heterogenous environment Rust is a great debugger and demands highly from surrounding code. Maybe this is why some are afraid of it?

[cl333r]

RefCell::try_borrow and RefCell::try_borrow_mut for non-panicking RefCell use have existed since 2016 and RefCell is a standard library construct, not a lang item.

I don't need it to either panic or not, but to return me the value I need.

If you don't like RefCell, you can construct your own wrapper around the UnsafeCell primitive that instructs the compiler to allow aliasing. Just prepare to get dubbed a source of untrustworthy dependencies if someone runs the Miri runtime analyzer's data race detector on your code and it trips because you had an overblown estimation of when you knew better than the compiler.

Thanks, but no thanks. I can do this much easier with C++.

[billyswong]

Trying to be clever and "correct" invalid data or unexpected behaviour is a stairway to hell (this's why I dislike browsers checking HTML so sloppy and "use strict" being so late to the game).

HTML is indeed sloppy but it is a necessary evil. There are (or maybe were) cases where an HTML document can be partially transmitted and then truncated due to network error. XHTML attempted to handle such cases as "invalid file" and show nothing to users. Meanwhile every other HTML engines fulfill users by showing the webpage as much as possible. It is human nature that users want the HTML way. We shall think of the design / implementation of HTML as a high-level ECC.