Hacker News Reader

Hacker News

Comment by hardware2win | Hacker News Reader

Full thread

hardware2win

Weekly news of memory related CVE.

Keep using unsafe langs.

What will be there in next week? CVE in Chromium?

At this point betting sites should add category for that kind of games.

I do wonder what people of future will think about this:

"So they had research indicating that a lot of issues were related to memory, had technology which significantly reduces this issue, but they still kept doin mess for years?"

https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe...

https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...

https://www.chromium.org/Home/chromium-security/memory-safet...

Memory issues and JIT (browsers) are two things that are responsible for disgusting amount of security issues

View on HN

This is naive.

You cannot rewrite the entirety of the Linux kernel in another language overnight. You'd have years at least until it becomes production-ready. Not to mention the performance and memory use will be worse.

Certainly the situation can and should be better, but adopting this "it's so easy, how does nobody see it?" attitude helps no one.

I mostly agree, but I think I would have read the comment differently. I've seen C++ people have a strong distaste towards Rust for various reasons and don't exactly care too much about the "memory safety" part. Which is... unfortunate. So while it might be "beating a dead horse", the horse isn't even dead.

You're right.

People need to be aware how mem. safety affects security in critical software like Chromium or Microsoft's.

In fairness, a shitton of these issues would be solved by following C++ patterns like RAII, instead of the defer/gotos style the kernel seems to be proud of.

This is kernel space, not userspace.

Rusts memory safety is not a 100% protection here.

Rust's memory safety is never a 100% thing, but that is no argument, as long as it's a significant enough improvement...

Let me explain: in the kernel memory is not always simply "memory".

Sometimes writing to a memory you own has huge side effects. And that part is not handled by rust.

Perhaps instead we could train an ML model to find these use-after-free bugs?

>Not to mention the performance and memory use will be worse.

How much?

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.

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.

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.

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...

> 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.

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.

Okay, so switch to Redox?

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

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.

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

Well, also posted on LWN today for subscribers: A first look at Rust in the 6.1 kernel: https://lwn.net/Articles/910762/

(If you don't have a subscription, the article will become freely available to everyone on Oct 27th.)

tl;dr, it doesn't do anything interesting yet, but the infrastructure is getting there, and starting the process of evolving the kernel to using a safe language.

i can understand the argument for new code, but what do you want people to do, recode the entirety of the linux kernel in rust? the kernel is allowing rust for new drivers

Faster adoption

Raise awarness

Easy to sit on the sidelines and tell everyone else to do better, isn’t it?

It is, but remember that people's lives and freedom are on the stake

So go contribute code instead of demanding others do it?

Reply on news.ycombinator.com