Rust Is Coming to The Linux Kernel and I'm Not Sure How to Feel

RUST IS COMING TO THE LINUX KERNEL AND THERES NOTHING WE CAN DO ABOUT IT.

To be clear, I'm not a full on Rustacean, nor am I a missionary of Rust pushing rust onto people who do not want it. BUT, I am a purveyor of code security and see the writing on the wall. Rust is more secure than C, and soon enough, it will become the norm.

What do you think about this? Leave a comment!

🏫 COURSES 🏫

🔥🔥🔥 SOCIALS 🔥🔥🔥

[drditup]

0:25 "I am not a Rust missionary"

3 videos later...

"rust and i are getting married".

Lol

[guilherme]

I prefer to see this as a test, and I hope Rust does well.

[rumplstiltztinkerstein]

Just thinking on how many security vulnerabilities are related to unsafe memory handling. I think it's a hard, but great decision on the long term.

[etopowertwon]

I'm super excited. I looked at top five CVE in linux, it's all use after free(and race conditions). That's something rust is explicitly designed against.

[Parker]

Rust got its 1.0.0 release in 2015, if memory serves. It gets a new edition every three years, and breaking changes are typically reserved for new edition releases. Cargo allows you to specify an edition, so as to ensure that old code doesn't become unusable due to breaking changes while still benefitting from compiler updates. Personally, I like that it's getting this trial run; it has excellent interop with C, promotes practices that would make for safer C code in general, and, when compiled in release mode, its various abstractions compile to exactly the same binary as doing things more manually. It might not work out, hence why currently it's only minor stuff that's going to be written in Rust, but if this does work out, it could open the door to more people being able to contribute to the kernel.

[fders]

I think it will be rough at first getting all the issues of standardizing and interfacing with C sorted out, but in the long run will be a great decision for improving security and stability.

[PhilfreezeCH]

Torvalds also reminded everyone that no, in kernel space Rust is not ‚safe‘ in the same way it is in user space. The kernel can‘t just panic and ‚crash gracefully‘. In fact this is often worse than just chugging along even though something didn‘t actually work properly.
This is not Torvalds bashing Rust (you just know he personally had to okay this decision anyway), it is more so telling Rust developers that they will have to learn to write a somewhat different kind of Rust if it runs in kernel space. Though I would assume most people doing this will probably come from C in kernel rather than from Rust in user space anyway.

[bowildmusic]

It boggles my mind that this misconception about C being unsafe still makes the rounds. The statistics around this statement are wrong, biased and often misread.

The amount of critical software written in C is huge in comparison to any other language, so naturally we get more CVEs related to C. In fact, if memory serves, C is getting LESS than it’s fair share of CVEs. Moreover, project specific security issues don’t get reported as often as when the code or project is shared, making CVEs a biased statistical pool.

[wtfdoiputhere]

I'm a toxic Rust missionary so please use Rust now now now now now now now now now

[Baile_an_Locha]

Regarding the safety of C++, this perception is based largely on legacy codebases that purport to be C++ but are actually not C++ at all. To my mind they are “C with classes”. A lot of low-level C++ developers in particular are suspicious of newer language features and of patterns like RAII. They avoid things like smart pointers and smart handles in the mistaken belief that they add overhead. They avoid lambdas because they haven’t bothered taking the time to see what the compiler actually does with lambdas. It’s as though they think that C++‘a zero-cost abstraction philosophy was abandoned some time in the early 00s and that modern language features are expensive. Some of them refuse to use const because they think it “clutters the code” (telling them that const is the default in Rust doesn’t sway opinions).

There are large low level C++ code bases where developers continue to write code in which resource lifetimes are managed by hand using the goto-exit pattern from C, even though a whole library of kernel-friendly RAII helpers is available to them.

Summary: the safety problem with C++ is largely caused by developers who couldn’t be bothered actually using the capabilities of the language.

[zactron]

I believe the initial scope is for this to be used for drivers, which are already their own domains of specialized knowledge (i.e., the kernel maintainer who approves the PR likely hasn't used the hardware the driver is for)

By moving to Rust, and if set up correctly at the interface, more code should be rejected at the compilation stage, well before it has to bother a maintainer with a PR.

Personally, I'm excited. There aren't many new C or C++ developers anymore. If Linux stays on C, there's the potential for there to not be enough devs who can work on Linux, let alone good devs.

[Jplaysterraria]

tl;dr: although I share your concerns, I think rust is more "production ready" and the developers behind RfL are taking your concerns heavily into consideration.

If I remember correctly, maintainers are allowed to reject Rust patches based on their preference (they might not want to deal with Rust code). AFAIK as long as people aren't obnoxious about it, rust should be able to stay in the kernel.

About compiler support, currently the Kernel uses Rust 1.62 (a specific commit) and all unstable features in use are documented and tracked, they won't update the compiler untill it is merged into Linux, and they have a plan about migrating unstable code. On another hand, the unstable features required by the kernel are being stabilized faster than they would in languages like C/C++ which are governed by a committee, ie. a feature required by the kernel (GATs) has been stabilized in the current rust beta 1.65 which should come out in November.

I'm biased because I've contributed to it, but I'm hopeful, as many people in the kernel community want something like Rust in the kernel (they'd much rather C implemented a lifetime tracking feature, but as stated before, committee languages are slow to change)

[DaTnkee]

I was watching Dlang for years as possible C replacement, and then Rust just came from nowhere, and it is in the Linux kernel.

[Tachi]

Rust goes against a lot of things important for kernel people, like ABI stability, low level memory handling, etc. Why don't we have a language with the same safety guarantees as Rust (borrow checker etc), but as simple and minimal as C?

To me, Rust seems more like an evolution of C++, not C.

[glennmiller]

Two old saws: If it ain't broke, don't fix it & Keep fixing it until it's broke. C/C++/Rust will all be with us for a very long time. I'm using Rust in my day-to-day just so I don't forget to drop something I've allocated, and it's a real timesaver for me. I remember those times after shipping events when all you did was worry the users would find a way to break things -- and they were uncanny in their ability to do just that.

[klikkolee]

Rust is two closely-related languages in a trenchcoat -- safe rust and unsafe rust. Safe rust provides dramatic benefits, but is incapable of solving some problems without using functions implemented in another language such as unsafe rust. Unsafe rust, meanwhile, is capable of absolutely everything, but requires the developer to accept additional responsibility. The ability to separate a problem into parts that can be done in safe rust and the parts that need unsafe rust without the need for additional tooling or loss of performance is a huge utility.

But there is a major problem with unsafe rust that no-one seems to care about -- it's woefully unclear what your additional responsibilities are. To consider an unsafe rust program sound, you must be absolutely confident that you have not written a program with undefined behavior. In a language like C, there is a specification which, while convoluted and obnoxious, provides enough information for you to deduce with certainty whether a program has undefined behavior. Rust has no such thing. Rust has a list of things that are definitely undefined behavior, but it has a massive warning at the top stating that the Rust language lacks the formal specification required to prove whether a program has other varieties of undefined behavior. The warning directs you to a book dedicated to unsafe rust, and while that book is informative, it does not in any way empower you to have the certainty needed to write substantial unsafe-rust programs. C has more landmines to avoid, but C has a map of the minefield.

A kernel is an environment where safe rust will often be unable to fully solve a problem, and it is also an environment where undefined behavior is absolutely catastrophic.

It tends to be that with effort, the division of safe and unsafe rust in a project can be skewed very heavily towards safe rust, leaving the unsafe rust simple enough that you may be able to assume that the rust language team would've discovered and documented forms of undefined behavior that unsafe rust code of that complexity can possibly encounter, but there will not be any certainty until unsafe rust grows up and gains a rigorous specification that rustc will be held to.

[Thvl]

The paradigm that learning Rust introduces alone turns people into better programmers by gently forcing them to think about safety and ownership of data at every step. I don't think Rust is mature enough to run the world on it yet, but it's a great launchpad towards the future.

[LiamDennehy]

If you're using a new featture in the language that may get pulled in the future, the problem is not that the feature gets pulled but the use of the experimental feature.
Besides, you can just fork it to keep the feature if it really matters or cannot be replaced.

[MattiaProcopio]

From what I read after the Linux conf, kernel devs are still very against dumping Rust into the kernel, questioning a lot of stuff (good) but also saying they would rather port some additional safety into C (bad)

I personally think the first couple of years will be hard but in yhe long term the kernel would hugely benefit by the Rust addition, it would definitely bring more people to work on it

[Dominik-K]

I'm very excited about that change myself, as it will make contribution to those parts of the kernel more possible for non-expert programmers. I am a bit worried about a transitional period, but the easier code safety checks make this pretty interesting