Earlier quoted context omitted.
> but Rust is pushing into domains where C and C++ dominated in the past. I think it's also a big sign that the linux kernel adopted rust and not c++. (only for small parts but still)
A not inconsiderable part of why is that Rust for Linux did the work. When C++ people say they think there should be C++ in Linux, their proposal usually begins by proposing that it "should" be possible to just compile Linux as C++ software. This doesn't work because C isn't just "C++ but old", and they rapidly lose interest. Which of course also feeds into Linus' semi-fair claim that not allowing C++ keeps out the l…
How memory safety CVEs differ between Rust and C/C++
161–170 of 270 posts
Re: How memory safety CVEs differ between Rust and C/C++
#162Earlier quoted context omitted.
I'm a / used to be a C++ programmer for 10 years. I've been lucky enough to work in a company that aims to adopt Rust. I have been working on Rust projects in the embedded space that runs on real-world devices right now for 3.5 years. Slowly but surely, not going into "rewrite every single thing now in Rust" but one component at a time when the project justifies it. So, tell me what compiler option disables non-moder…
Enable sanitizers on test suites and fuzzers. Enable warnings and WError Use clang tidy and other static analyzers Actually use a modern compiler and enable the safety features they ship with Most of these things have solutions that would take years of work in an existing project so it isn't done And it takes significantly more effort to write good modern C++ code than Rust code So Rust wins But I don't like writing…
This was always a pain point in C++ embedded space, to be fair.
Re: How memory safety CVEs differ between Rust and C/C++
#163There can be made very good arguments why C is less safe than Rust, but null pointer dereferences which are perfectly safe everywhere except on weird platforms (and usually could be made safe even there by turning on a compiler flag) seems a very misleading argument. And as as the Cloudflare incident showed, a Rust unwrap can have equally bad consequences. (or as Ariane 5 showed, a safe overflow in Ada can have explo…
For the first issue of complexity, the reply is along the lines of show me the code and then either nitpicking that to pieces or explaining in several paragraphs how the behavior is perfectly reasonable and in fact quite easy to understand. Beginners get intimidated, professionals don’t have time to write novels on HN. Complexity in Rust is systemic. It’s little things accumulating and amplifying each-other that add up to having to spend significant time just designing types to satisfy the static analyzer. Many Rust programmers seem to see the type system as a hammer to be used liberally, an predilection also known in the C++ metaprogramming community.
On the second topic (also present in this thread) the counter-argument is that other languages do it too and nothing bad happened so far. The former is not valid, because Rust is uniquely bad in its competitor group and security by waiting is not a valued approach.
Re: How memory safety CVEs differ between Rust and C/C++
#164Earlier quoted context omitted.
> In general on a system where you trap when accessing the zero page, this optimization should be safe and a null pointer dereferences should (safely) trap. If you mean that C compiler writers "should" prioritise sanity over high scores on microbenchmarks, then I agree. However in practice they do not and this optimization is not remotely safe.
Do you have any evidence for this? On GCC it should be safe. (EDIT: what is not safe is indexing into a null pointer. For this you need to be safe you need -fsanitize=null)
Re: How memory safety CVEs differ between Rust and C/C++
#165Earlier quoted context omitted.
This is true, but security teams often work on tooling dedicated to reduce the n. of CVEs so that a company can keep compliance. That is in fact part of compliance itself to have an automated/reliable processo to tackle CVEs...
Which compliance regime are you referring to that cares about CVE counts as a metric?
You need to fix also moderate/low CVEs within a certain time frame.
So CVE count becomes relevant, because the target is zero, although it doesn't mandate "zero CVEs" but that's finally what the desired outcome is.
It's basically unrealistic to ignore that number, because it's unlikely that you have a steady 1000 CVEs (that are being continuously fixed and new ones discovered), but more like "a few exceptions".
Re: How memory safety CVEs differ between Rust and C/C++
#166Earlier quoted context omitted.
Do you have any evidence for this? On GCC it should be safe. (EDIT: what is not safe is indexing into a null pointer. For this you need to be safe you need -fsanitize=null)
I don't understand your comment - dereferencing a null pointer is unsafe, in the sense that it does not reliably crash but may do other things, as we saw in the kernel case we're talking about. Yes that particular case was only exploitable if you mapped the zero page, but given how all-bets-are-off a situation it created (where extremely experienced programmers thought they knew what the code did, thought it was safe…
We are talking about an extremely simple straightforward API with an obvious contract. It's good enough for this function to reliably surface almost all wrong uses with a segfault immediately. Wrong use will result in segfaults and otherwise bugs and crashes. The goal is not to work when used wrong but to work when used right. You cannot save the world from scratch in every little function. You still have a job to get done, and you have to move on.
Re: How memory safety CVEs differ between Rust and C/C++
#167Earlier quoted context omitted.
If these hardened libraries were as good, we wouldn't have blog posts like this[1], from the android team last year. > We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code Maybe the android team could have gotten the same benefits by simply auditing and modernising their C++ code? I'm not convinced. Google has some amazing engine…
There’s a few things happening here. First of all, Rust is default safe. In C++ developers always trade performance for safety, in Rust they just swallow the penalty (which is often still performant enough). C++ code will often not be as memory safe as it could because someone decided to not use particular checks (like compiler-driven integer overflow checks). Secondly, Android C++ code is not particularly high quali…
The borrow checker runs at compile-time, not run-time. Safety doesn't slow down your code except in a few small, specific ways like array bounds checks and UTF8 validity checking - but these checks also happen in unsafe rust too. The overhead is also mitigated by some of rust's other choices increasing performance. (For example, rust uses noalias everywhere, has larger codegen units by default and a better, faster standard library).
There was a really great analysis a few months ago looking at the performance impact of rust, C++ and hardened C++. They patched the compiler to see what happened when all runtime safety aspects were removed - and the result was about a 2-3% improvement. Measurable for sure, but nothing to write home about.
https://github.com/yugr/rust-slides/blob/ae3f5cc12d49e61f8f6...
> Secondly, Android C++ code is not particularly high quality, [..] Thirdly, it has a massive target on its back and is under attack by pretty much everyone.
Most code isn't particularly high quality. But I suspect google has better resources and processes than most C++ dev teams. As for security - just about all code is a target now that LLMs can find vulnerabilities so easily. I want all the software on my computer to be hardened against attacks that can be found and exploited in under $5 of compute.
> [Rust is] also quite ugly, people complain about its complexity and is unfortunately suffering from dependency explosion. I hope it’s a stepping stone to something better.
As Stroustrup once said, "There are only two kinds of languages: the ones people complain about and the ones nobody uses." It's a good sign that people are complaining about it. But otherwise I agree - I look forward to seeing how rust's borrow checker inspires new languages going forward. There's a lot more good ideas in the programming language space that we haven't scratched.
Re: How memory safety CVEs differ between Rust and C/C++
#168Earlier quoted context omitted.
> Rust's standard library is incredibly thin (intentionally so). As a result, you need to use the crate ecosystem. This comes with some downsides. This is no different than C++. C++ standard library made so many compromises in the name of ABI compatibility almost none of the library is actually usable for any use case. So people start to quickly add things like boost, abseil, folly, Qt, asio, imgui, doctest etc. Ther…
That's not really true at all though, even in very complex software it's pretty rare to have more than ~10 external dependencies in a C++ project. People tend to roll their own a lot more, partly because dependency management is a lot more painful and fragmented. Boost is effectively an extended standard library, as is abseil, but the language has got much better at incorporating back features since C++ 2011, but eve…
I have not yet looked at any C++ code base > 1 milliom lines where I did not find at least 3 copies of zlib. Often just the compression or decompression function copy and pasted into a random file. Which version? No idea. Was it patched? Likely. Is there any documentation on how to update this? Absolutely not. Was it easy to find? No, some specialists even rename the functions so that users linking to the system zlib do not get into symbol conflicts. I have heared way to often that it is so much simpler to just copy a class over from abseil, or whatever other library than to depend on it.
Sure, you do not see dependencies, the functionality those provide are still there somewhere though -- either hidden away or in the form of reimplementations. You just do not know... and what you do not know about you can not maintain.
Re: How memory safety CVEs differ between Rust and C/C++
#169Earlier quoted context omitted.
I don't understand your comment - dereferencing a null pointer is unsafe, in the sense that it does not reliably crash but may do other things, as we saw in the kernel case we're talking about. Yes that particular case was only exploitable if you mapped the zero page, but given how all-bets-are-off a situation it created (where extremely experienced programmers thought they knew what the code did, thought it was safe…
May. If. If. If. In case. We are talking about an extremely simple straightforward API with an obvious contract. It's good enough for this function to reliably surface almost all wrong uses with a segfault immediately. Wrong use will result in segfaults and otherwise bugs and crashes. The goal is not to work when used wrong but to work when used right. You cannot save the world from scratch in every little function.…
Or you can take all of 10 minutes to put sanity-check assertions at the start of all your public-facing API functions, eliminating a source of security bugs, get on with your life, and worry about the performance implications as and when it becomes a problem (hint: it's never going to become a problem).
Re: How memory safety CVEs differ between Rust and C/C++
#170There can be made very good arguments why C is less safe than Rust, but null pointer dereferences which are perfectly safe everywhere except on weird platforms (and usually could be made safe even there by turning on a compiler flag) seems a very misleading argument. And as as the Cloudflare incident showed, a Rust unwrap can have equally bad consequences. (or as Ariane 5 showed, a safe overflow in Ada can have explo…
Arguably less bad than silently corrupting your data and forcing you to do CAPTCHA everywhere.
Which is what the parallel Perl(?) component was doing at the time.
Rust solution gave a clear signal something was wrong, the other solution was slowly annoying everyone and pushing them away.