Comment by Sharlin
7 days ago
Around 70% of security vulnerabilities are about memory safety and only exist because software is written in C and C++. Because most vulnerabilities are in newly written code, Google has found that simply starting writing new code in Rust (rather than trying to rewrite existing codebases) quickly brings the number of found vulnerabilities down drastically.
You can't just write Rust in a part of the codebase that's all C/C++. Tools for checking the newly written C/C++ code for issues will still be valuable for a very long time.
You actually can? A Rust-written function that exports a C ABI and calls C ABI functions interops just fine with C. Of course that's all unsafe (unless you're doing pure value-based programming and not calling any foreign code), so you don't get much of a safety gain at the single-function level.
If you're going to swap out one function in a chain of functions for a Rust version, you're destroying your codebase. You simply can't replace one tiny piece of code in a large codebase with a version in a different language. Doing so would be insane.
C ABI is not C++ ABI. People often write C/C++ but they're completely different languages. C++ is much higher level and modern. C++ is closer to Rust than it is to C.
I find this interesting.
Curl's Daniel Stenberg claimed during his NDC talk that vulnerabilities in this project are 8 years old on average.
I wonder where the disconnect comes from.
It comes from all his reporters being teenagers in developing countries with older models, and people using SOTA models who know how to qualify a potential vulnerability having much bigger fish to fry than curl. curl is a meaningful target, but it's in nobody's top tier.
And to a good approximation all real world Rust uses unsafe everywhere.
So we now have a new code base in an undefined language which still has memory bugs.
This is progress.
No, this is false. For Rust codebases that aren't doing high-peformance data structures, C interop, or bare-metal stuff, it's typical to write no unsafe code at all. I'm not sure who told you otherwise, but they have no idea what they're talking about.
It's the classic "misunderstanding" that UB or buggy unsafe code could in theory corrupt any part of your running application (which is technically true), and interpreting this to mean that any codebase with at least one instance of UB / buggy unsafe code (which is ~100% of codebases) is safety-wise equivalent to a codebase with zero safety check - as all the safety checks are obviously complete lies and therefore pointless time-wasters.
Which obviously isn't how it works in practice, just like how C doesn't delete all the files on your computer when your program contains any form of signed integer overflow, even though it technically could as that is totally allowed according to the language spec.
3 replies →
Our experiences are different.
Good developers only write unsafe rust when there is good reason to. There are a lot of bad developers that add unsafe anytime they don't understand a Rust error, and then don't take it out when that doesn't fix the problem (hopefully just a minority, but I've seen it).
The parent comments references real world data from Google: https://security.googleblog.com/2024/09/eliminating-memory-s...