5 ms·

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 gen

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-llvm-pass.so.cc 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.

cm3 10y ago
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.
- steveklabnik 10y ago
  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.
  - cm3 10y ago
    Hallelujah. This has been a pain point for anyone who tried to build rustc on non-tier1 platforms (musl as host, etc.).
    - steveklabnik 10y ago
      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.
      - cm3 10y ago
        Will we maybe also get official musl-host builds accessible via rustup and automatically fetched on such a platform?
        steveklabnik 10y ago
        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?
        cm3 10y ago
        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.
        steveklabnik 10y ago
        rustc itself loads stuff as a shared library, in my understanding.
      - cm3 10y ago
        Speaking of non-tier1, is there support for static linking libc when building on/for FreeBSD?
        steveklabnik 10y ago
        I am not sure, but I don't think so right now. I don't know how FreeBSD and MUSL interact.
jdright 10y ago
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?
- frewsxcv 10y ago
  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/24 https://github.com/frewsxcv/afl.rs/issues/31 https://github.com/frewsxcv/afl.rs/issues/31 https://github.com/frewsxcv/afl.rs/pull/46 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`.
- frewsxcv 10y ago
  Also worth mentioning the Rust library 'quickcheck' that does something similar to what you're suggesting: https://github.com/BurntSushi/quickcheck#the-quickcheck-attribute https://github.com/BurntSushi/quickcheck#the-quickcheck-attr...

cm3 10y ago

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.

steveklabnik 10y ago
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.
- cm3 10y ago
  Hallelujah. This has been a pain point for anyone who tried to build rustc on non-tier1 platforms (musl as host, etc.).
  - steveklabnik 10y ago
    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.
    - cm3 10y ago
      Will we maybe also get official musl-host builds accessible via rustup and automatically fetched on such a platform?
      - steveklabnik 10y ago
        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?
        cm3 10y ago
        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.
        steveklabnik 10y ago
        rustc itself loads stuff as a shared library, in my understanding.
    - cm3 10y ago
      Speaking of non-tier1, is there support for static linking libc when building on/for FreeBSD?
      - steveklabnik 10y ago
        I am not sure, but I don't think so right now. I don't know how FreeBSD and MUSL interact.

jdright 10y ago

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?

frewsxcv 10y ago
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/24 https://github.com/frewsxcv/afl.rs/issues/31 https://github.com/frewsxcv/afl.rs/issues/31 https://github.com/frewsxcv/afl.rs/pull/46 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`.
frewsxcv 10y ago
Also worth mentioning the Rust library 'quickcheck' that does something similar to what you're suggesting: https://github.com/BurntSushi/quickcheck#the-quickcheck-attribute https://github.com/BurntSushi/quickcheck#the-quickcheck-attr...