Hacker News Reader

Comment by uecker | Hacker News Reader

The question is to what extend this is true - given that Rust programmers also make stupid mistakes (e.g. https://rustsec.org/advisories/RUSTSEC-2023-0080.html) that look exactly like C bugs. Not that I think Rust does not have advantages in terms of safety, but probably not as much as some people seem to believe when making such arguments. The other question is at what cost it comes.

View on HN

Granted, there are plenty of people who don't understand these issue very well who think "Rust = no bugs". Of course they're wrong. But that said, this CVE is an interesting example of just how high the bar is that Rust sets for correctness/security. The bug is that, if you pass 18446744073709551616 as the width argument to this array transpose function, you get undefined behavior. It's not clear whether any application has ever actually done this in practice; the CVE is only about how it's possible to do this. In most C libraries, on the other hand, UB for outrageous size/index parameters would be totally normal, not even a bug, much less a CVE. If an application screwed it up, maybe you'd open a CVE against the application.

Many exploits work because an attacker tweaks the circumstances to some unlikely situation.

> Many exploits work because an attacker tweaks the circumstances to some unlikely situation.

True, but I think you're ignoring his/her point which is: Many languages, if the problem is UB, won't seek to fix the underlying problem. Their answer is: "Don't do that." Whereas Rust doesn't shirk it's responsibility in those situations, to fix the what is, here, even a theoretical issue.

By "many languages ... do" I assume you mean the people involved. Once you see more Rust code, you will see more such issues, more unmaintained libraries with such issues, and more programmers that do not care all that much, because they are not enthusiastic members of the Rust community caring a lot about memory safety, but people doing some job.

BTW are you Martin Uecker?

Yes

I'd argue that he addresses this with the two paragraphs immediately preceding the one quoted above:

> As someone who has seen almost EVERY kernel bugfix and security issue for the past 15+ years (well hopefully all of them end up in the stable trees, we do miss some at times when maintainers/developers forget to mark them as bugfixes), and who sees EVERY kernel CVE issued, I think I can speak on this topic.

The majority of bugs (quantity, not quality/severity) we have are due to the stupid little corner cases in C that are totally gone in Rust. Things like simple overwrites of memory (not that rust can catch all of these by far), error path cleanups, forgetting to check error values, and use-after-free mistakes. That's why I'm wanting to see Rust get into the kernel, these types of issues just go away, allowing developers and maintainers more time to focus on the REAL bugs that happen (i.e. logic issues, race conditions, etc.)

> I'm all for moving our C codebase toward making these types of problems impossible to hit, the work that Kees and Gustavo and others are doing here is wonderful and totally needed, we have 30 million lines of C code that isn't going anywhere any year soon. That's a worthy effort and is not going to stop and should not stop no matter what.

> But for new code / drivers, writing them in rust where these types of bugs just can't happen (or happen much much less) is a win for all of us, why wouldn't we do this?

This is a false tradeoff. The big win for Rust in the kernel is for new code. Bug density and impact is highest in newer code (it may, according to recent research, actually decay exponentially). There's no serious suggestion that existing code get forklifted out for new Rust code, only that the project create a streamlined affordance for getting new drivers into the kernel in Rust rather than C.

Rust doesn't claim to protect you from integer overflow bugs, so I'm not sure what you're trying to prove by linking to that security advisory.

But it does protect against memory leaks, use-after-free, and illegal memory access. C does not.

> The other question is at what cost it comes.

I think I trust the kernel developers to decide for themselves if that cost is worth it. They seem to have determined it is, or at least worth it enough to keep the experiment running for now.

Greg K-H even brings this up directly in the linked email, pointing out that he has seen a lot of bugs and security issues in the kernel (all of them that have been found, when it comes to security issues), and knows how many of them are just not possible to write in (safe?) Rust, and believes that any pain due to adopting Rust is far outweighed by these benefits.

> But it does protect against ... illegal memory access

To be clear, the linked CVE is an example of illegal memory access as a result of integer overflow. Of course, the buggy code involves an unsafe block so ... everything working as advertised. It's certainly a much higher bar for safety and correctness than C ever set.

Are these people on the room with us right now? Come on, man. This is a horrible argument to make. Rust has these problems happen exceptionally rarely, in clearly marked places, and when they get fixed they strengthen all the code that relies on it. In C you have these bugs happen every hundred lines of code. It’s not even worth comparing. This is the programming equivalent of bringing up shark attacks versus car crashes.

Sorry, that is not obvious to me. I agree that Rust has an advantage. Still to me it seems there is a chain of arguments where each argument contains a bit of exaggeration: Improving safety in Linux kernel code is super extremely important, memory safety is the most important aspect, Rust gives you basically full memory safety, etc. Each such statement is true to some extend but exaggerated in my opinion. At the same time alternatives to improving safety in C code are downplayed and it is presented has hopelessly bad. So if I take into account all these aspects, then overall I find the full story not as convincing anymore.

If I understand correctly, this particular issue that you've linked to can only trigger a buffer overflow because the implementation of transpose() is written in unsafe Rust.

Yes. So what? That doesn't count then?

Pretty much, yeah, because the whole point of unsafe Rust is to drop all the usual safety guarantees, at which point it's explicitly no safer than any other language with dangling pointers.

I get the point of unsafe. But if people replace C code with Rust code using unsafe, then the argument that this "eliminates a whole class of issues" is wrong. It is as simple as this.

Good point made. To what extent is there really an advantage over very mature projects and veteran maintainers? Even if this could be proven, is it really enough of a difference to justify the continual drama and disruption? Well, it's at least entertaining and paying the bills.

https://www.cve.org/CVERecord/SearchResults?query=rust

Some of these CVEs only exist because Rust takes security seriously. There was a filesystem bug: https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html

This impacted C++'s standard library as well, but since the standard says it's undefined behavior, they said "not a bug" and didn't file CVEs.

Nobody believes that Rust programs will have zero bugs or zero security vulnerabilities. It's that it can significantly reduce them.

To me, this attitude of the rust community is another benefit of rust: there is a general commitment that idiomatic rust code handles and exposes when things can go wrong.

Just skimming the first few entries:

- most often are ub in binding code between rust and language x

- if not binding code the severity is often below 5, which is most often not a bug that will affect you

- exceptions are code with heavy async usage and user input handling (which rust never advertises to fix and is common in all languages, even ones with gc)

Reply on news.ycombinator.com