Hacker News new | ask | show | jobs
by IshKebab 44 days ago
It's because they verified the bugs using AddressSanitizer so by construction it was only ever going to find C++ bugs.
1 comments

But there is AddressSanitizer for Rust and for C too right? As I understand it AddressSanitizer consumes LLVM IR, so from its point of view some C, C++ or Rust is all the same, and presumably also if you are a famous Russian streamer and you hand wrote LLVM IR instead of using a real programming language that too?
Yes I was including C in "C++". I dunno how much C Firefox uses.

And I presume you can run AddressSanitizer with Rust but given Rust is memory safe by default, it's only going to find issues in `unsafe` code which is a tiny tiny fraction of most code. Google had a blog post a few months ago where they managed to put some actual numbers on this, because they almost shipped one Rust memory safety bug.

The lesson for other projects is very different if the reason these are all C++ bugs is just "We didn't ask Mythos for the bugs in Rust" versus if the difference is that asking Mythos for similar bugs in the Rust is futile because it won't find any.

Some of this is tempered if the pattern is that Mythos finds bugs mostly in dusty old C++ but the rates are much, much lower in newer C++, the reverse of Google's earlier finding for human researchers.

> The lesson for other projects is very different if the reason these are all C++ bugs is just "We didn't ask Mythos for the bugs in Rust" versus if the difference is that asking Mythos for similar bugs in the Rust is futile because it won't find any.

The answer is both of those. They didn't ask for bugs in the Rust code because it wouldn't have found any. They've explicitly set it up to only look for memory safety bugs. It's not going to find any in a memory safe language.

As long as the memory-safe subset of Rust is used exclusively.
Not exclusively, just the vast majority of the time. Which it is.

Read this: https://blog.google/security/rust-in-android-move-fast-fix-t...

Exactly the same as using the memory-safe subset of Python or Java.

> It's not going to find any in a memory safe language.

I mean, it's not supposed to find any in the unsafe language either, but that's why it was used.

Firefox not only uses unstable Rust features (via the exemption mechanism the same way Linux does it, trained professionals, closed course, do not attempt at home) it also presumably has some volume of its own explicitly unsafe Rust and so there's no reason this could not be checked, and what makes the difference here is whether it was or was not.

> I mean, it's not supposed to find any in the unsafe language either, but that's why it was used.

No it is supposed to find them in C++, because we all know humans are infallible and it's super easy to write memory errors in C++.

The whole point of Rust is that the borrow checker is infallible (pretty much anyway).

> it also presumably has some volume of its own explicitly unsafe Rust

"Some volume" is so tiny as to be irrelevant. There's no point going to this effort if Rust memory safety vulnerabilities are 1000 times less frequent than in C++.

That number is not made up. See https://blog.google/security/rust-in-android-move-fast-fix-t...