Hacker News new | ask | show | jobs
by frewsxcv 3658 days ago
Author here.

AFL is coverage-guided fuzz testing (fuzz testing that relies on code coverage).

Someone (not me) wrote an "LLVM pass" that loops through the generated LLVM IR for any LLVM-compiled program and injects the necessary AFL instrumentation such that AFL can work on it:

https://github.com/mirrorer/afl/blob/master/llvm_mode/afl-ll...

Since Rust uses LLVM when compiling a binary, all afl.rs does is incorporate this instrumentation and AFL just needs to be run on the resulting binary.

There are multiple versions of LLVM though. Rust is compiled using a specific version of LLVM. Since the LLVM pass above is reading the generated LLVM that Rust produces, the versions can't be too far off otherwise the LLVM pass might see some unrecognized symbols.

The README in the project suggests just compiling Rust which also compiles LLVM, then you'll have a version of LLVM that is guaranteed to be the same when you setup the instrumentation.

I think it might be sufficient to update the documentation to suggest the user of afl.rs just download and use LLVM 3.8 since this is the major version that Rust uses internally. I need to do more testing to confirm this will work for everyone, then I can update (and greatly simplify) the README.

2 comments

Not sure about this, but isn't this something that could be integrated into rustc (or cargo at least) to be something ready to use as bench/test?
This is what I'm striving for:

    #[fuzz]
    fn test_fuzz(bytes: Vec<u8>) {
        ...
    }
This would live alongside other test cases and everytime fuzzing is desired, one could just do `cargo fuzz`. Relevant issues and a pull request:

https://github.com/frewsxcv/afl.rs/issues/24 https://github.com/frewsxcv/afl.rs/issues/31 https://github.com/frewsxcv/afl.rs/pull/46

There's still a little more work to do though. Mainly, I want to compile AFL as a part of the workflow (see the afl-sys crate in the repo) so the user doesn't need to manually install AFL to use `cargo fuzz`.

Also worth mentioning the Rust library 'quickcheck' that does something similar to what you're suggesting:

https://github.com/BurntSushi/quickcheck#the-quickcheck-attr...

Thanks, because the way which snapshots of LLVM and rustc are required to build a certain rustc release does not make it an easy to use solution for common Rust users. It'd be great if an existing LLVM 3.8 can be leveraged.
Note that with 1.10, the way we do rustc snapshots is changing: it will build with 1.9. And then 1.11 will build with 1.10, etc. so that will help a bit.
Hallelujah. This has been a pain point for anyone who tried to build rustc on non-tier1 platforms (musl as host, etc.).
Even on those platforms, it's helpful for distros, who only want one package, not a separate bootstrapping package. I'm real glad we're doing it.
Will we maybe also get official musl-host builds accessible via rustup and automatically fetched on such a platform?
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?
Speaking of non-tier1, is there support for static linking libc when building on/for FreeBSD?
I am not sure, but I don't think so right now. I don't know how FreeBSD and MUSL interact.