[UncleMeat]

You obviously cannot rewrite things in another language overnight. But I do wish that the industry saw this as an emergency rather than something ranging from "well, we will get to it when we get to it" to "ugh, I'm tired of these people talking about memory safety - don't you know that you can write correct C programs?"

The linux kernel in particular is perhaps the single most important piece of software on the planet. And we vulns like this all the time. Hundreds per year. And there's billions more lines of C and C++ out there handling all sorts of untrusted input.

The path off C and C++ is complicated as shit. Interop with Rust is messy and there aren't effective tools for automatic translation. Carbon is barely a language at this point (they don't even have a compiler) and doesn't yet provide safety. The story for the other alternative languages isn't any better. But I really wish the industry was throwing billions at this across dozens of major companies and open source organizations.

[ff317]

Rust is not a panacea. You can't just claim that this one emergency project somehow solves all the future bugs. Would Linux being rewritten in mostly-Rust help with some classes of memory bugs some of the time? Sure. Would there be a lot of other tradeoffs to consider, are there risks, would there still be plenty of kernel CVEs going forward? Yes to all of these.

[UncleMeat]

Rust is absolutely not a panacea. Other kinds of vulns can absolutely exist. But vulns caused by memory-safety errors are so incredibly common in Linux and other critical software that it should be embarrassing. If we could get to a world where all of our kernel-level vulns were logical errors rather than UAFs I would weep with joy.

I'm not saying that using memory-safe languages (or a different kernel design that at least isolates bugs like this) fixes security forever. I'm saying that it would dramatically increase the cost of developing an exploit for the world's most important piece of software.

I'll even soften my request. Let's forget about memory safety. Let's just talk about regression tests. How the fuck is it possible for a vuln to regress in the kernel because nobody added a test when it was first fixed? This is a disaster. Everybody has just somehow decided that the current state of things is tolerable and I feel like I'm taking crazy pills.

[galangalalgol]

If we can't even get people to put static analysis in their pipelines how are we going to get them to switch to rust? If everyone that used c++ for instance built in clang and g++ both, ran cppcheck and clang tidy, and ran both asan and ubsan, we still wouldn't get rid of all the memory bugs rust eliminates by simply compiling, unless you have 100% code and branch coverage to make sure *san are doing their jobs.

The easiest path to sanity is probably rust, but we can't even get static analysis to be a norm...

[UncleMeat]

> If we can't even get people to put static analysis in their pipelines how are we going to get them to switch to rust?

I don't know. Somehow we need to shift industry culture. The good news is that this has been done. In the past, things we now take for granted like source control and unit tests weren't norms. Maybe someday tools like static analysis, fuzzing, and considerations for memory safety will be industry norms. I hope so.

[IshKebab]

Nobody is claiming Rust would prevent all bugs, just a huge proportion of them. At least 70%, I would argue even more.

But yes it should also be accompanied by better security architecture, i.e. not running network drivers in a monolithic kernel.

[yjftsjthsd-h]

Okay, so switch to Redox?

[surajrmal]

Perhaps it's time to reduce our dependence on the Linux kernel then.

[UncleMeat]

I think that's a possibility too. This is also hard as hell. Android seems to have some long term strategy with Fuchsia but that's been in progress for what seems like forever. And webservers basically don't have an alternative right now.

[heavyset_go]

Most of the other options are written in C or C++ themselves.