In my opinion, there are more reasons to rewrite Rust code in C.
Why you should, actually, rewrite some of it in Rust
51–60 of 300 posts
Re: Why you should, actually, rewrite some of it in Rust
#52The author focuses on rewriting low-level media decoders in Rust. I have bit of experience in this area. I've been slowly working on an MPEG2 binary subtitle decoder in Rust: https://github.com/emk/subtitles-rs A while back, I ran my subtitle decoder through "cargo fuzz", and I was pleasantly surprised at the results: Close to half a billion fuzz runs found 5 runtime panics, all of which were detected by Rust before…
> Close to half a billion fuzz runs found 5 runtime panics, all of which were detected by Rust before they could compromise security. If I'd written this code in C, several of those errors would have been exploitable. Wouldn't the apples-apples comparison be fuzzing a C program? If AFL would catch the same bugs, Rust isn't better than C in this case.
The difference is not in what was caught by AFL, but what wasn't (and also, what would have happened in C had AFL not been run).
Re: Why you should, actually, rewrite some of it in Rust
#53Is this article "Use Rust" or "Stop using C"? I mean both are reasonable arguments that get made often on here, but the one doesn't necessarily follow from the other.
I think its a little bit of both. Primarily it is aimed at legacy software. IMO not a lot of new code is written in legacy C, so we have a problem with having a ton of dependencies written in a way that may not be the safest or most reliable (from recent experiences). The authors suggestion is to rewrite parts of those applications that tend to be buggy (mostly I/O parts) in Rust.
I really hate to see the naysayers comment on this article without even having read it. I think the author made a very good point.
Re: Why you should, actually, rewrite some of it in Rust
#54Why Rust? Why not Idris? Why not Haskell? Or you know, why rewrite it at all? You could instead try and use a safe C implementation (such as gcc/clang with the sanitisers or something like https://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html ), but to be frank if I was to rewrite my programs I would use a truly modern language like the ones that I mentioned above.
No GC, higher performance than either. Most other safe languages have more overhead than Rust. As for why not use sanitizers and such: That's an ongoing cost of using the sanitizer. Rewriting in Rust is a one-time cost, and can be done incrementally.
How about Ada/SPARK then?
Re: Why you should, actually, rewrite some of it in Rust
#55Sigh. This again. Not all security vulnerabilities are due to pointer arithmetic or out of bounds execution or pick-your-rust-is-better-idiom. Heartbleed is a great example. It wasn't caused by an error with how C handles memory or strings or anything else. It was caused by failing to validate untrusted input. Rust isn't going to help you with that. Could the affected parts be re-written in a way where the boundary c…
> Rust isn't going to help you with that.
As I noted elsewhere in this thread ( https://news.ycombinator.com/item?id=14753692 ), I've actually been working on a low-level media decoder in Rust. Compared to my earlier work in C (the xmlrpc-c library, for example), my Rust code has stood up very well to heavy fuzzing. My xmlrpc-c code, on the other hand, was written with ridiculous levels of paranoia, and it has been the subject of multiple CVEs thanks to a third-party XML parser I used.
So in terms of practical engineering reality, Rust seems to make a big difference. And even more importantly, it means I can trust other people's libraries a bit more.
Rust's practical advantages seem to be:
1. Runtime bounds checks! I wouldn't have thought that this was the most important thing, but when fuzzing, it's the last line of defense against quite a few potential exploits.
2. Debug-mode checks for integer overflow. Rust defines integer overflow as an error, and debug builds will actually check for it. This turns out to work really well with fuzzers.
3. The borrow checker. In my experience, this is actually less useful than (1) and (2) above in terms of preventing security bugs. But it does help.
So as somebody who's written parsers for untrusted data in both C and Rust, I definitely found that Rust helped me a lot. Of course, Rust can't help with some forms of stupidity, such as writing a bad custom memory allocator and using it to handle key material. OpenSSL's problems go well beyond the ordinary hazards of C.
Re: Why you should, actually, rewrite some of it in Rust
#56Or even better, Haskell!
the cool thing about rust is that you can use it for real-time programming, one example being DSP/audio. it often means no locks, nothing blocking, no dynamic allocation (malloc and most other allocators do not provide upper bounds of execution time), no recursion, and others. haskell is not tailored for that. of course there are other domains for which haskell is top-nocth and rust falls flat.
Minor nit: I believe that you can get memory allocators that provide upper bounds of execution time. But it won't be the default allocator in most languages. Also, you need an allocator that cannot ever fail to return a valid block. Even if you have all that, it still makes it much harder to prove that your worst-case timing is fast enough.
So, yeah, no allocations in situations like that. Allocate at start-up, and re-use your buffers (for that kind of code).
Re: Why you should, actually, rewrite some of it in Rust
#57Sigh. This again. Not all security vulnerabilities are due to pointer arithmetic or out of bounds execution or pick-your-rust-is-better-idiom. Heartbleed is a great example. It wasn't caused by an error with how C handles memory or strings or anything else. It was caused by failing to validate untrusted input. Rust isn't going to help you with that. Could the affected parts be re-written in a way where the boundary c…
So your argument is that because rust doesn't solve all problems people shouldn't strongly consider replacing C code with it, even though rust avoids entire classes of critical bug types in C?
I happen to like rust, though I would not suggest that it is the only solution to the classes of problems it avoids. I would, however, suggest that people very strongly consider using languages that avoid the problems that rust avoids whenever possible. Like, literally any time you're considering writing C or C++, at least strongly consider rust or another much safer option.
Re: Why you should, actually, rewrite some of it in Rust
#58Or write in Haskell in the first place.
Good Haskell code is rather fast, but that's beside the point. For many projects, the only measure of goodness should be how nimbly one can then use and experiment with one's code. In Haskell, like Lisp before it, one ends up with a language to use one's code. Like writing a Mathematica package and getting all of Mathematica for free, only better.
Re: Why you should, actually, rewrite some of it in Rust
#59Earlier quoted context omitted.
Formal verification is not the same as a security audit. With formal verification you can prove that something is bug-free. > They find issues in libCURL and openSSL that have existed for years Neither of them are formally verified. https://github.com/seL4/seL4 however is formally verified.
Please, step away from "formal verification" and come back to world the rest of us devs work in. I have never seen a formally verified piece of software even once. I don't know if its too hard to do to real software or if C doesn't allow for it, or if it is just too expensive. The simple matter is that is not an option for the vast majority of projects. Unless you can make it practical, I assert it has no place in a…
Worse: "It's amazing how many bugs there can be in a formally verified piece of software." I forget who said it, but it's been a long time. (Maybe in connection with formal verification of an OS? Does anyone remember?)
Formal verification only works if the formal verification was mistake-free. (And how are you going to prove that? With a formal verification? It's turtles all the way down...) Also, it only works for the aspects that were formally verified. Heartbleed, for example, could be regarded as a flaw in the specification; formally verifying that the code matches the spec won't save you from that.
Re: Why you should, actually, rewrite some of it in Rust
#60Sigh. This again. Not all security vulnerabilities are due to pointer arithmetic or out of bounds execution or pick-your-rust-is-better-idiom. Heartbleed is a great example. It wasn't caused by an error with how C handles memory or strings or anything else. It was caused by failing to validate untrusted input. Rust isn't going to help you with that. Could the affected parts be re-written in a way where the boundary c…
I agree that there are technical limitations, but I think those should be sought to be overcome. I disagree with your implicit assertion that all languages are equal (or close enough). If it is possible to make a class of error completely disappear then it should be done when not cost prohibitive, and languages can be designed such that there is no cost to avoid certain errors.
Sure one boundary error could have been detected in any language, but there will always be fewer in a language that simply disallows them. Consider how infrequently Gotos are used now there are no longer errors with setting state before a jmp/goto, because modern constrol flow tools function, case, inheritance, generics and others tools have strong semantics with good implementations that work well and reduce complexity.
Unfortunately language adoption is not a pure meritocratic affair. Bad languages can stick around for far too long because of external factors. Consider that Ada never had real use outside the DoD when it was shiny and new. That group isn't exactly known for evangelizing. The Rust community has better marketing strategy and has chosen a highly meritocratic approach to language design.