Why you should, actually, rewrite some of it in Rust • Hacker News Board

Re: Why you should, actually, rewrite some of it in Rust

#81

Post by anp » Wed, Jul 12, 2017, 4:59 PM UTC

rurban wrote: post #74

ekidd wrote: post #26

The 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…

I don't agree with the underlying thesis: In 15 years, I'll be heartbroken if we're still facing an endless stream of security updates and remote root compromises when all these projects were rewritten in a popular but unsafe language: Rust. There do exist fast and SAFE language out there. With guaranteed memory safety, null pointer safety, concurrency safety, dead-lock freedom, race freedom, and even with normal syn…

Can you be specific about which languages you include in the category of "fast and SAFE"?

Re: Why you should, actually, rewrite some of it in Rust

#82

Post by vertex-four » Wed, Jul 12, 2017, 4:59 PM UTC

yjftsjthsd-h wrote: post #45

ekidd wrote: post #26

The 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 point here is that a runtime panic is not an exploitable event - at the very worst, it's a DoS as it usually results in the program exiting.

AFL isn't even nearly guaranteed to catch everything, but what it's shown here is that the program contained bugs which would've resulted in an exploitable event in C. The program probably contains more bugs, but following this pattern, it's more likely that they result in panics in most of the worst cases, not exploitable events.

Re: Why you should, actually, rewrite some of it in Rust

#83

Post by [deleted] » Wed, Jul 12, 2017, 4:59 PM UTC

rurban wrote: post #74

ekidd wrote: post #26

The 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…

I don't agree with the underlying thesis: In 15 years, I'll be heartbroken if we're still facing an endless stream of security updates and remote root compromises when all these projects were rewritten in a popular but unsafe language: Rust. There do exist fast and SAFE language out there. With guaranteed memory safety, null pointer safety, concurrency safety, dead-lock freedom, race freedom, and even with normal syn…

[deleted]

Re: Why you should, actually, rewrite some of it in Rust

#84

Post by bandook_raja » Wed, Jul 12, 2017, 4:59 PM UTC

ekidd wrote: post #73

yjftsjthsd-h wrote: post #45

Earlier quoted context omitted.

> 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.

> If AFL would catch the same bugs, Rust isn't better than C in this case. You can find a list of my vobsub bugs in the Rust Fuzz Trophy Case: https://github.com/rust-fuzz/trophy-case They are: 1. The shift overflow: This was harmless in both C and Rust, I believe. 2. The arithmetic overflow: This was a runtime panic in Rust, resulting in a clean crash. In C, this might have been exploitable with a complex enough att…

I think you aren't understanding what parent comment is trying to say. No one is saying rust isn't better than C in some respects, instead, you were comparing Rust + Fuzzing with C and he implied that you should at least use C + AFL if you want to compare properly otherwise it's just BS.

Re: Why you should, actually, rewrite some of it in Rust

#85

Post by dikaiosune » Wed, Jul 12, 2017, 5:00 PM UTC

ZoFreX wrote: post #72

Is it really the time, yet, to start advocating for rewrites in Rust? Worth considering for new projects, definitely. Using to write new components of existing projects, maybe. But rewriting existing work? I'm concerned if we start pushing that too much too early, the initial friction will burn people. You only get one first impression. For anyone who thinks "yes, now is the time" I have questions for you: Have you r…

I believe Firefox as of recent versions requires a Rust compiler to be available, and that's a pretty bread-and-butter application to have in your distro's package repository.

Re: Why you should, actually, rewrite some of it in Rust

#86

Post by dikaiosune » Wed, Jul 12, 2017, 5:00 PM UTC

nercury wrote: post #79

While I am avid supporter of Rust, I can't help but feel this post is not right. If Rust is so much better, why not prove it by writing software in Rust, instead of words. After all, if Rust is so much better, the result will speak for itself.

In this case it seems the author is writing about the concrete results they've already obtained, not about something abstract.

Re: Why you should, actually, rewrite some of it in Rust

#87

Post by youdontknowtho » Wed, Jul 12, 2017, 5:00 PM UTC

"Rewrite it in Rust" is the new "Stallman was right" thread.

Its an echo chamber of fandom. Over time I've come to despise "evangelism" or any kind. I'm sure Rust is great. I just don't think it's news every time a Rust fan says that its great.

YouTube lectures of people actually using it? That would be interesting. Interviews of people actively porting a large C project to Rust. That would be interesting.

Rehashing its feature sheet? Not so much.

Re: Why you should, actually, rewrite some of it in Rust

#88

Post by vertex-four » Wed, Jul 12, 2017, 5:02 PM UTC

rurban wrote: post #74

ekidd wrote: post #26

The 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…

I don't agree with the underlying thesis: In 15 years, I'll be heartbroken if we're still facing an endless stream of security updates and remote root compromises when all these projects were rewritten in a popular but unsafe language: Rust. There do exist fast and SAFE language out there. With guaranteed memory safety, null pointer safety, concurrency safety, dead-lock freedom, race freedom, and even with normal syn…

So what's your language of choice that is not eventually built on unsafe code?

Re: Why you should, actually, rewrite some of it in Rust

#89

Post by bandook_raja » Wed, Jul 12, 2017, 5:03 PM UTC

anp wrote: post #81

rurban wrote: post #74

Earlier quoted context omitted.

I don't agree with the underlying thesis: In 15 years, I'll be heartbroken if we're still facing an endless stream of security updates and remote root compromises when all these projects were rewritten in a popular but unsafe language: Rust. There do exist fast and SAFE language out there. With guaranteed memory safety, null pointer safety, concurrency safety, dead-lock freedom, race freedom, and even with normal syn…

Can you be specific about which languages you include in the category of "fast and SAFE"?

D? GC is optional so don't even :D

Re: Why you should, actually, rewrite some of it in Rust

#90

Post by dikaiosune » Wed, Jul 12, 2017, 5:05 PM UTC

snakeanus wrote: post #54

SAI_Peregrinus wrote: post #50

Earlier quoted context omitted.

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?

Please correct me if I'm wrong, but don't Ada/SPARK's memory safety guarantees only hold when all memory is pre-allocated? My memory is that dynamic allocations aren't visible to the proof system (this may be in plain Ada without SPARK, now that I think of it).