frewsxcv
To users who are following along who aren't familiar, this is not how all unions works. Presumably the commenter is talking about "trade unions" which is one of many types of unions.
Yes, actually you do.
yikes
Adopted Unicode Characters
The thread that handles all the resources (http://, chrome://, file://, etc):
https://github.com/servo/servo/blob/master/components/net/re...
And here's the file that handles HTTP requests:
https://github.com/servo/servo/blob/master/components/net/ht...
EDIT: I forgot to mention: It's possible to run AFL on uninstrumented code, it just won't be that smart about finding new code paths.
I ran AFL on rust-brotli for a week a couple weeks ago. It didn't find anything. I plan to try again soon! No one is safe from AFL.
https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...
https://github.com/BurntSushi/quickcheck#the-quickcheck-attr...
#[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`.
afl.rs uses a Rust compiler plugin to register the LLVM pass needed to instrument Rust programs so that AFL can run on them:
https://github.com/frewsxcv/afl.rs/blob/master/afl-plugin/li...
Compiler plugins in Rust are currently unstable, and as far as I know, are not on a path to stability in the near-term.
Coincidentally though, I am fuzzing a different Brotli library testing some unpushed afl.rs changes: https://github.com/dropbox/rust-brotli-no-stdlib
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.
Send me an email if you want to team up on this: [email protected]
https://github.com/briansmith/ring
If anyone is looking to contribute and wants a "good first task", here are some tasks:
https://github.com/briansmith/ring/issues?q=is%3Aopen+is%3Ai...
Help is greatly appreciated :)