When to use memory safe languages
verdagon.dev
verdagon.dev
Rust itself has had more CVEs in the past 18 months than Postfix (written in C) has had in the past 18 years [1].
So it must be more nuanced than you're claiming.
EDIT: Postfix is somewhere in the region of 1,000x to 10,000x more popular than rust - it's hard to compare a compiler to a mail transfer agent but the MTA is in the more risky use case and yet fares better despite having more sysadmins deploying it than there are rust developers.
[1] https://www.cvedetails.com/vulnerability-list/vendor_id-1902...
https://www.cvedetails.com/vulnerability-list/vendor_id-8450...
This is not what you'd expect for an alleged developer rocket ship after 10+ years. It doesn't compare favourably with C++ at 10 years old, or Java, or Go, or...
Millions of lines of Rust are shipping in Firefox, so we could count CVEs in Firefox attributable to Rust. I agree this is annoying, but someone should do this.
I point out Rust in Firefox is an order of magnitude (10x) larger than rustc or deno.
A closer comparison might be Python, which took a long time to reach its potential, and I see Rust on the same trajectory, with high-profile teams now adopting it, like AWS.
- the complexity of the code base
- the attack surface
- the amount of effort to find the CVEs
That said - 2 & 3 in your list seem like they'd lend further weight to Postifx rather than Rust in this scenario. Postfix is a network service forced to accept any and all input from remote attackers. Postfix has been around longer and has marketed itself as secure, that's meant it's attracted the attention of capable attackers keen to demonstrate their prowess.
I think the rust code base is more complex than postfix though. Postfix's architecture borders on a work of art.
It's not at all a direct refutation of the GP's claim.
For example: https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html
The C++ stdlib is affected by the same issue, but they don't consider it a security bug, because the API doesn't claim to be safe of race conditions. Rust doesn't explicitly claim that either, but the Rust community has a higher bar for correctness around these things, so it gets a CVE.
Prior discussion here:
https://news.ycombinator.com/item?id=30461036
https://www.reddit.com/r/cpp/comments/s8ok0h/possible_toctou...
In other words--a library can't be blamed for being insecure if it never makes any security promises in the first place. Rust libraries make stronger and more explicit guarantees, and the code is encapsulated in a much smaller region of the program, so it is easier to prove that they are in violation of their contract; but it emphatically does not mean that it results in more end to end vulnerabilities. Claiming that Rust simply isn't used in enough, or critical enough, places yet to have real exploits like C programs do is pretty naive, as it's started to be used in places like Android's bluetooth stack.
In fact, in practice there's even more of a gap than this--most C and C++ programs don't report CVEs even for reliably reproducible instance of UB unless you can demonstrate a full end to end attack chain, and many won't even fix or prioritize them if they consider it "benign" UB (what this means is anyone's guess!). Even projects like Chrome that actually care about security often won't upgrade UB bugs to CVEs if they believe (erroneously or not) that other hardening mechanism in the program will prevent it from being used as part of an RCE chain. Applying the same standards people typically do to C and C++ projects (an end to end exploit chain), I'm not sure whether there would be a single known Rust CVE in any widely used program.
Basically: the standard of evidence for a CVE in your average C or C++ program is astronomically high, while in Rust it is extremely low. Any attempt to decide which language is practically safer by counting CVEs (which is in any case bad methodology) needs to have awareness of this fact if it's trying to actually measure anything real.
There is of course a small handful of answers like accessing memory-mapped buffers for hardware access, but these are fractional percentage exceptions, not things to bend your language choice around. They're fractional percentage exceptions even in programs where that's the primary use case; you're still better off using an "unsafe" function to do your little bit of magic, then using the memory safety everywhere else.
And... it's not like C is a nice language. By modern standards, C is just terrible. Unpleasant. Poor affordances that lead to bad designs, where you end up giving up on the right answer because it's just so darned hard so let's just take some shortcuts. Spikes everywhere you walk, knives everywhere you touch. Missing basic features to any modern language like closures, and if you do bash them in they come with so many caveats that they're hardly recognizable.
If you are still someone who learned C 30 years ago and still think it's just somehow incomparably amazing and nothing can compare, please, spend some time with a couple of other system languages long enough to come to fluency, then re-evaluate. All the other languages have been polishing for decades now, and they've straight-up passed C for all language-related purposes. Yea verily these ~25 years ago when I started in this industry there were still cases to be made that C or the C++ of the time was still necessary to get the performance you needed, but those days have passed. The only remaining place I can understand using it are those fringes where it's just the only choice, and even then, the newer languages are marching along and if I were stuck in those industries I'd be trying to get on board as quickly as possible.
The teams you refer to are working in areas where every exploit is a huge risk, places like a browser or an OS kernel. There is a reason Rust originated among people working on a browser. What you describe is correct for them. But the article has several examples of other applications where the tradeoffs are different.
Another example: LLVM is written in C++, but that's basically fine. A memory safety exploit in clang might be annoying, but it's not a vector for taking over people's machines like a browser is. A safety exploit in clang's output is where the real risks lie, but memory safety of clang itself doesn't help there.
No one is stopping anyone from writing a compiler backend/optimizer in rust, yet it hasn't happened.
But there are many C++ compiler codebases that do have it, such as: every major JS/Wasm VM (V8, SpiderMonkey, JSC), Binaryen, etc. Those do run in environments where parallel compilation matters a lot, unlike LLVM (which assumes parallelism in the build system, as you compile to object files).
But this isn't an issue for most LLVM languages, which either assume parallelism in the build system, or they get enough benefit from ThinLTO (which is the parallelism LLVM does support at the link stage).
Hrm, is LLVM no longer used for shader compilation? I think most people wouldn't like it if compiling a shader could delete your home directory.
I strongly prefer Rust these days, though it has poor support for certain advanced use cases.
- Don't use malloc.
- For long-lived allocations, use per-type arrays.
- In a game, we might have an array for all Ships, an array for all Missiles, and an array for all Bases.
- For temporary allocations, one can also use an arena allocator.
- For temporary allocations whose pointers don't escape, one can also use the stack.
- All unions must be tagged 11 and treated as values.
- Always use bounds checking.
The author then gives a list of tools like ASAN to perform various analyses (static and dynamic) to help further increase safety.
What I did not see, however, was one of the simplest and most effective suggestions for MMM programs:
Never free.
For someone who writes mostly in GC languages this was a great read and can recommend.
Even with switching to <your_safe_language> let’s not loose awareness of what is possible to strengthen current approaches.
The compiler can only partially verify that the application is not crossing the streams by passing memory from one allocator subsystem into another.
Also, memory unsafe languages are sometimes safer on some other dimension than the most obvious memory safe alternative. For instance, it is trivial to write C++ code that provides constant, non-null references (in the absence of UB), but completely impossible to express those invariants in the Java type system.
First: cyclic structures (just leaks).
Second: wrong refcounts leading to UAF (use-after-free), in minor cases leaks.
There are generally four approaches to memory safety:
[...]
Reference counting (RC), like in Swift, Nim, Lobster, etc.
> A weak reference is a reference that doesn’t keep a strong hold on the instance it refers to, and so doesn’t stop ARC from disposing of the referenced instance. [0]
[0] https://docs.swift.org/swift-book/LanguageGuide/AutomaticRef...
Although the thought of forbidding arbitrary references feels a little restrictive to me - it would be placing the burden of keeping a tree of references onto the programmer. I don't know how well that works in practice. Perhaps trying out some of the mentioned languages would be insightful.
Memory leaks (and more generally resource leaks) are not generally considered memory safety issues.
After all, that's basically what an advanced GC manages for you: you leak memory, and it tries to clean up after you. But whether it does is entirely up to it and its configuration (nothing precludes disabling it and leaking all the memory, there's nothing actionable at the language level).
As such, people often don't include protection from memory leaks as a criterion for 'memory safety'. It's possible to explicitly leak memory in the safe subset of Rust (e.g. Box::leak). It's also possible to 'leak' memory in GC'd languages too by keeping old references around you'll never use, although this example is just arguing semantics even more.
I see.
Although that definition of safety feels a little wrong to me, I can't think of any security issue that could be caused by a memory leak. Perhaps OOM killer butchering random processes on the system, bringing it to some vulnerable state? But then again - that's a system failure, as any well-behaved process might as well use more memory than is available.
If killing a process leaves the system in an unsafe state, that’s probably not the fault of the OOM killer. (What if the killed process was slow to start, or failed an assert and exited instead?)