Afl.rs: Fuzzing Rust code with american-fuzzy-lop

Post by steveklabnik » Mon, Jun 20, 2016, 5:25 PM UTC

cm3 wrote: post #57

steveklabnik wrote: post #50

Earlier quoted context omitted.

We are always interested in adding more platforms. I don't remember if there are any open issues with a MUSL host; I vaguely remember something about compiler plugins?

I suppose the issues you're referring to are with statically linked against musl executables. I wouldn't expect any such issue with musl just as the host, where you can run rustc on alpine and voidlinux, just not necessarily statically.

Post by eddyb » Mon, Jun 20, 2016, 5:38 PM UTC

pslam wrote: post #58

ekidd wrote: post #7

Randomly looking at the "Trophy Case", it looks like most of these errors are run-time "panics". We can break Rust errors down into three main categories: 1. Compile-time errors. This includes most memory-related errors, which are mostly caught by the borrow checker. These are very serious errors, often with ugly security consequences. Rust's big selling point is that it can catch many different kinds of errors at co…

> 2. Run-time panics. This includes "index out of bound" errors, integer overflow errors (in debug builds only), and assertions inserted by the programmer. This is Rust's second line of defense, so to speak. I still argue, to every Rust user I meet, that they should turn on overflow checking in Release builds too. I strongly disagree with the idea that it's a Debug feature only. If it's not always on, then it's not a…

Post by [deleted] » Mon, Jun 20, 2016, 5:58 PM UTC

pjmlp wrote: post #35

Manishearth wrote: post #34

Earlier quoted context omitted.

> Every time someone posts a cool Rust library, most of the time it makes use of nightly. Examples? Examples that aren't tools, that is. The main example I can think of is serde, and that works on stable (just works better on nightly). What's wrong with nightly for using tooling? You don't have to keep updating, you can pin to a nightly from a particular date. You can use rustup.rs to switch to stable locally if you…

Many companies let their IT control what toolchains one is allowed to use. Usually it is set in stone and only updated every few IT upgrade cycles. What the devs get on their machines is that and nothing more.

Post by yazaddaruvala » Mon, Jun 20, 2016, 6:11 PM UTC

Manishearth wrote: post #40

pjmlp wrote: post #35

Earlier quoted context omitted.

Many companies let their IT control what toolchains one is allowed to use. Usually it is set in stone and only updated every few IT upgrade cycles. What the devs get on their machines is that and nothing more.

Good, install rustup.rs, with one date-pinned nightly, and stable. Freeze the rustup.rs install directory. Done?

Post by kbenson » Mon, Jun 20, 2016, 6:27 PM UTC

pslam wrote: post #68

ekidd wrote: post #60

Earlier quoted context omitted.

> I still argue, to every Rust user I meet, that they should turn on overflow checking in Release builds too. Yeah, I remember when the debug-mode overflow checks were added right before Rust 1.0. There wasn't enough time remaining to thoroughly measure the performance impact of these checks in release mode or to implement compiler optimizations to reduce the cost. So IIRC, the decision was made to allow integer over…

> if the performance cost can be made low enough I think that's the wrong way to look at it. How about instead: "Checks can be disabled if the safety cost is worth the performance increase" The "performance case" is a false baseline. You never had that performance in the first place, because your code didn't work.