Comment by cratermoon
4 years ago
> I'm glad that I'm working in a time where I can build all of my parsers and attack surface in Rust and just think way, way less about this.
I'm beginning to worry that every time Rust is mentioned as a solution for every memory-unsafe operation we're moving towards an irrational exuberance about how much value that safety really has over time. Maybe let's not jump too enthusiastically onto that bandwagon.
Not just memory safety. Rust also prevents data races in concurrent programs. And there are a few more things too.
But these tricks have the same root: What if we used all this research academics have been writing about for decades, improvements to the State of the Art, ideas which exist in toy languages nobody uses -- but we actually industrialise them so we can use the resulting language for Firefox and Linux not just get a paper into a prestigious journal or conference?
If ten years from now everybody is writing their low-level code in a memory safe new C++ epoch, or in Zig, that wouldn't astonish me at all. Rust is nice, I like Rust, lots of people like Rust, but there are other people who noticed this was a good idea and are doing it. The idea is much better than Rust is. If you can't do Rust but you can do this idea, you should.
If ten years from now people are writing unsafe C and C++ like it's still somehow OK, that would be crazy.
Imagine it's 1995, you have just seen an Internet streaming radio station demonstrated, using RealAudio.
Is RealAudio the future? In 25 years will everybody be using RealAudio? No, it turns out they will not. But, is this all just stupid hype for nothing? Er no. In 25 years everybody will understand what an "Internet streaming radio station" would be, they just aren't using RealAudio, the actual technology they use might be MPEG audio layer III aka MP3 (which exists in 1995 but is little known) or it might be something else, they do not care.
> If ten years from now people are writing unsafe C and C++ like it's still somehow OK, that would be crazy.
It's 26 years after Java was released. Java has largely been the main competitor to C++. I don't see C++ going away nor do I see C going away. And it's almost always a mistake to lump C and C++ developers together. There is rarely an intersection between the two.
I think you do not understand how short 10 years is. There are tons of people still running computers on Sandy Bridge.
> I think you do not understand how short 10 years is. There are tons of people still running computers on Sandy Bridge.
Ten years is about the time since C++ 11. I may be wrong, but I do not regret my estimate.
Well, Zig isn't memory safe (as implemented today; they could add a GC), so it's not a good example of a Rust alternative in this domain. But I agree with your overall point, and would add that you could replace Zig with any one of the dozens of popular memory safe language, even old standbys like Java. The point is not to migrate to one language in particular, but rather to migrate to languages in which memory errors are compiler bugs instead of application bugs.
Zig isn't memory safe but it's still leaps and bounds above C.
I have to admire the practicality of the approach they've been taking.
I could have sworn I'd read that Zig's ambition was to be memory safe. Given ten years I don't find that impossible. Indeed I gave C++ the same benefit of the doubt on that timeline. But, when I just searched I couldn't find whatever I'd seen before on that topic.
6 replies →
> Well, Zig isn't memory safe (as implemented today; they could add a GC), so it's not a good example of a Rust alternative in this domain.
While the first part of the sentence is mostly true (although the intention is to make safe Zig memory safe, and unsafe Rust isn't safe either), the second isn't. The goal isn't to use a safe language, but to use a language that best reduces certain problems. The claim that the best way to reduce memory safety problems is by completely eliminating all of them regardless of type and regardless of cost is neither established nor sensical;. Zig completely eliminates overflows, and, in exchange for the cost of eliminating use-after-free, makes detecting and correcting it, and other problems, easier.
I remain unconvinced that race proof programs are nearly as big a deal as memory safety. Many classes of applications can tolerate panics and its not a safety or security issue. I don't worry about a parser or server in go like I would in C.
(I realize that racing threads can cause logic based security issues. I've never seen a traditional memory exploit from on racing goroutines though.)
A Race in Go is Undefined Behaviour. All bets are off, whatever happens, no matter how strange, is OK.
If you have a race which definitely only touches some simple value like an int and nothing more complicated then Go may be able to promise your problem isn't more widespread - that value is ruined, you can't trust that it makes any sense (now, in the future, or previously), but everything else remains on the up-and-up. However, the moment something complicated is touched by a race, you lose, your program has no defined meaning whatsoever.
1 reply →
I've seen Qt Creator segfault due to the CMake plugin doing some strange QStringList operations on an inconsistent "implicitly shared" collection, that I guess broke due to multithreading (though I'm not sure exactly what happened). In RSS Guard, performing two different "background sync" operations causes two different threads to touch the same list collections, producing a segfault. (These are due to multiple threads touching the same collection/pointers; racing on primitive values is probably less directly going to lead to memory unsafety.)
Apparently in Golang, you can achieve memory unsafety through data races: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m... (though I'm not sure if a workaround has been added to prevent memory unsafety).
I take that bet about C being pretty prominent in 10 years from now.
A language and a memory access model are no panacea. 10 years is like the day after tomorrow in many industries.
> also prevents data races in concurrent programs.
I have another neat trick to avoid races. Just write single threaded programs. Whenever you think you need another thread, you either don't need it, or you need another program.
You do realize that data races can happen between multiple programs as well, when shared resources are used? Which is pretty much a requirement for many things.
4 replies →
> If ten years from now people are writing unsafe C and C++ like it's still somehow OK, that would be crazy.
I mean to be clear, modern C++ can be effectively as safe as rust is. It requires some discipline and code review, but I can construct a tool-chain and libraries that will tell me about memory violations just as well as rust will. Better even in some ways.
I think people don't realize just how much modern C++ has changed.
It must have changed a shitload in the last 2-3 years if that's the case. What tools are you referring to? I'm pretty familiar with C++ tooling but I haven't paid attention for a little while.
3 replies →
What’s with the backlash against Rust? It literally is “just another language”. It’s not the best tool for every job, but it happens to be exceptionally good at this kind of problem. Don’t you think it’s a good thing to use the right tool for the job?
It is good to keep in mind that the Rust language still has lots of trade-offs. Security is only one aspect addressed by Rust (another is speed), and hence it is not the most "secure" language.
For example, in garbage collected languages the programmer does not need to think about memory management all the time, and therefore they can think more about security issues. Rust's typesystem, on the other hand, can really get in the way and make code more opaque and more difficult to understand. And this can be problematic even if Rust solves every security bug in the class of (for instance) buffer overflows.
If you want secure, better use a suitable GC'ed language. If you want fast and reasonably secure, then you could use Rust.
A thing to remember about GC is that it solves only one very important resource. Memory.
If your program loses track of which file handles are open, which database transactions are committed, which network sockets are connected, GC does not help you at all for those resources, when you are low on heap the system automatically looks for some garbage to get rid of, but when you are low on network sockets, the best it could try is hope that cleaning up garbage disconnects some of them for you.
Rust's lifetime tracking doesn't care why we are tracking the lifetime of each object. Maybe it just uses heap memory, but maybe it's a database transaction or a network socket. Either way though, at lifetime expiry it gets dropped, and that's where the resource gets cleaned up.
There are objects where that isn't good enough, but the vast majority of cases, and far more than under a GC, are solved by Rust's Drop trait.
8 replies →
> Rust's typesystem, on the other hand, can really get in the way and make code more opaque and more difficult to understand.
I don't disagree with the premise of your post, which is that time spent on X takes away from time spent on security. I'll just say that I have not had the experience, as a professional rust engineer for a few years now, that Rust slows me down at all compared to GC'd languages. Not even a little.
In fact, I regret not choosing Rust for more of our product, because the productivity benefits are massive. Our rust code is radically more stable, better instrumented, better tested, easier to work with, etc.
I don't think this is a good take. Go, Java, Rust, Python, Swift; they all basically eliminate the bug class we're talking about. The rest is ergonomics, which are subjective.
"Don't use Rust because it is GC'd" is a take that I think basically nobody working on memory safety (either as a platform concern or as a general software engineering concern) would agree with.
It's unusually or suspiciously "hyped". Not to the extent as the other sibling exaggerated to, but enough for it to be noticeable and to rub people the wrong way, myself included. It rubs me the wrong way because something feels off about the way it's hyped/pushed/promoted. It's like the new javascript in the programming world. And if we allow it (like we did with JS), it'll overtake way too much mindshare with the unfortunate detriment and neglect of all others.
> What’s with the backlash against Rust?
What's with the hyping of Rust as the Holy Grail as the solution to everything not including P=NP and The Halting Problem?
No serious and good programmer is hyping Rust as the "Holy Grail". You are seeing things due to an obvious negative bias. Link me 100x HN comments proving your point if you like but they still mean nothing. I've worked with Rust devs for a few years and all were extremely grounded and practical people who arrived at working with it after a thorough analysis of the merits of a number of technologies. No evangelizing to be found.
Most security bugs/holes have been related to buffer [over|under]flows. Statistically speaking, it makes sense to use a language that eliminates those bugs by the mere virtue of the program compiling. Do you disagree with that?
15 replies →
I'm a security professional so it's based on being an experienced expert, not some sort of hype or misplaced enthusiasm.
The article we are commenting on is about targeted no-interaction exploitation of tens of thousands of high profile devices. I think this is one of the areas where there is a very clear safety value (not just theoretical).
Whole classes of bugs -- the most common class of security-related bugs in C-family languages -- just go away in safe Rust with few to no drawbacks. What's irrational about the exuberance here? Rust is a massive improvement over the status quo we can't afford not to take advantage of.
> how much value that safety really has over time
Billions and billions of dollars. Large organizations like Microsoft and Google have published numbers on the proportion of vulns in their software that are caused by memory errors. As you can imagine, a lot of effort is spent within these institutions to try to mitigate this risk (world class fuzzing, static analysis, and pentesting) yet vulns continue to persist.
Rust is not the solution. Memory-safe languages are. It is just that there aren't many such languages that can compete with C++ when it comes to speed (Rust and Swift are the big ones) so Rust gets mentioned a lot to preempt the "but I gotta go fast" concerns.
… it is a solution for every memory-unsafe operation, though?
No. Rust cannot magically avoid memory-unsafe operations when you have to deal with, well, memory. If I throw a byte stream at you and tell you it is formatted like so and so, you have to work with memory and you will create memory bugs.
It can however make it extremely difficult to exploit and it can make such use cases very esoteric (and easier to implement correctly).
That's totally untrue, unless you are using a really weird definition of "memory safety". A rust program that doesn't make use of the unsafe keyword will not have memory safety bugs. We've had programming languages for decades that are able to happily process arbitrary bytestreams with incredibly buggy code without ever actually writing to a memory region not reachable through pointers allocated by the ordinary program execution.
A Java program can't write over the return address on the stack.
7 replies →
That's not memory-unsafety. Memory-safety means avoiding bugs like buffer overflow, ROP, etc.
Language absolutism.
There's literally zero evidence that a program written in Rust is actually practically safer than one written in C at the same scale. And there won't be any evidence of this for some time because no Rust program is as widely deployed as an equivalent highly used C program.
That's not true, actually. There is more than "literally zero" evidence. I don't feel like finding it for you, but at minimum Mozilla has published a case study showing that moving to Rust considerably reduced the memory safety issues they discovered. That's just one example, I believe there are others.
There are likely many other examples of, say, Java not having memory safety issues. Java makes very similar guarantees to Rust, so we can extrapolate, using common sense, that the findings roughly translate.
Common sense is a really powerful tool for these sorts of conversations. "Proof" and "evidence" are complex things, and yet the world goes on with assumptions that turn out to hold quite well.
Not sure what your last sentence means - without evidence, there are cases when we guess right, and those when we guess wrong. Are you just choosing to ignore the latter?
The Mozilla case study is not a real world study. It simply looks at the types of bugs that existed and says "I promise these wouldn't have existed if we had used Rust". Would Rust have introduced new bugs? Would there be an additional cost to using Rust? We don't know and probably never will. What we care about is preventing real world damage. Does Rust prevent real world damage? We have no idea.
1 reply →
I’d wager Dropbox’s Magic Pocket is up there with equivalent C/C++ based I/O / SAN stacks:
https://dropbox.tech/infrastructure/extending-magic-pocket-i...