Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

unhandledexpression.com

Post reply on HN
Print view View original

111–120 of 300 posts

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

#111

Post by eridius »

bandook_raja wrote: post #84
ekidd wrote: post #73

Earlier quoted context omitted.

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

It's a pointless comparison. Fuzzers don't catch everything. What's important is the type of issue that the fuzzers do reveal, because that gives a hint as to how severe the uncaught issues may be.

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

#112

Post by lilyball »

falcolas wrote: post #19

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

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

Yes, it would. In Rust, the server would have crashed when it overran the buffer instead of sending that potentially-secret memory back to the client. Heartbleed is a great example of why rewriting in Rust is good.

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

#113

Post by jcelerier »

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…

You would get 2. and 3. as runtime panic in C if you used sanitizers.

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

#114

Post by hsivonen »

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.

With Rust, a panic occurs right away when the fuzzer develops input that performs e.g. out of bounds access. With C, it's possible to go wrong a little but not enough to segfault or to go wrong enough that by accident the access looks valid (for an unintended valid memory address) to a sanitizer.

In that sense, fuzzing Rust is more certain to make the bad things actually be caught than with C where there's a chance that the fuzzer developed input that caused UB but the UB didn't happen to be caught by the mechanisms that are supposed to discover bad events during fuzzing.

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

#116

Post by pornel »

I've been programming in C for 17 years. Now I'm writing (and rewriting) image processing and encoders in Rust and I love it.

It's not just memory safety. Rust has sweet error handling — the syntax is almost as noise-free as exceptions, but code flow is as predictable as error codes. In Rust I handle rare error cases that I wouldn't have bothered with in C (and thus my Rust programs fail in orderly fashion instead of running with garbage values).

Runtime arithmetic overflow checks have saved me many times. Knowing I have this safety net I can be cavalier about using smaller integer types.

I don't have to free memory explicitly, and yet peak mem usage is as minimal as it can be, and I did not have a leak yet.

And the whole ecosystem is fantastic compared to C. There's a culture of having unit tests. Ease of using dependencies via Cargo, and the zero-cost abstractions, help having dependencies broken down into small and focused libraries.

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

#117

Post by pjmlp »

falcolas wrote: post #19

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

> If memory safety and correctness was so truly valued above everything else, we'd be seeing a lot more Ada than we do today.

The problem was that many companies had certain problems paying for Ada compilers and rather used the free C compiler delivered with their OS SDK.

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

#118

Post by ZoFreX »

steveklabnik wrote: post #110
ZoFreX wrote: post #105

Earlier quoted context omitted.

I think it's fair to say that anyone releasing software written in Rust on Debian right now has extra work to do, and is likely to be treading new ground.

Totally! That's far different than "no major package manager accepting or even ready to accept programs written in Rust yet", though. Oh, I thought of something better than just the compiler: https://github.com/burntsushi/ripgrep#installation * homebrew * chocolatey * arch * gentoo * fedora * RHEL/CentOS * Nix All have at least one Rust program packaged :)

For RHEL/Centos/Fedora (the only ones there I would call "major") you have to enable a separate repo, which isn't really the same as being in the official repos.

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

#119

Post by santaclaus »

pornel wrote: post #116

I've been programming in C for 17 years. Now I'm writing (and rewriting) image processing and encoders in Rust and I love it. It's not just memory safety. Rust has sweet error handling — the syntax is almost as noise-free as exceptions, but code flow is as predictable as error codes. In Rust I handle rare error cases that I wouldn't have bothered with in C (and thus my Rust programs fail in orderly fashion instead of…

> Rust has sweet error handling

I feel like a lot of the cool things in Rust get obscured in the never ending safety dance. There is some rad stuff in Rust compared to its closest competitors (C and C++) -- cleaner error handling, a standard package manager, no aliasing -- I want to hear about what else Rust can do for me! More safety guarantees, ehhh, I'll take them but they aren't a huge win in our work.

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

#120

Post by pjmlp »

ekidd wrote: post #55
falcolas wrote: post #19

Sigh. 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 t…

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

C.A.R Hoare talking in 1981 about how their Algol compiler customers reacted to the proposal of turning off bounds checking.

"Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."

The mainstream adoption of UNIX and with it, C, made many without the knowledge of how computing outside AT&T walls since the dawn of computing looked it, to cargo cult ideas that were proven wrong elsewhere.

But given that victorious get to re-write history and UNIX got adopted by the enterprise, those OSes written in safer systems programming languages get forgotten.

The recent example was to learn about PL/8 and how IBM used it, in a compiler framework similar to LLVM, to do the research that lead to RISC.

http://rsim.cs.illinois.edu/arch/qual_papers/compilers/ausla...

Imagine that! The RISC computer was designed using an OS written in a system programming language using Algol safety checks, including bounds checking, in the 70's.

EDIT: Added a link to the PL/8 research paper.

Post reply on HN