A proposal and demo for a fuzzing system that works with Rust through C code

I've implemented a demo for fuzzing Rust code and C code at the same time. I hope I can address #25386 (moved) with that by using cargo afl. Though I would like to have this system approved first before I write code for a PR.

Trac:
Username: debily

changed milestone to %Tor: unspecified

added 035-removed-20180711 Rust afl component::core tor/tor fuzzing milestone::Tor: unspecified parent::24265 priority::low reporter::debily reviewer::nickm severity::trivial status::needs-revision type::enhancement labels

Trac:
Username: debily

testlib.tar.gz

make install-depends && make run will start the fuzzer afl-gcc can be provided by setting AFL_CC

Trac:
Username: debily

Putting this feature in 0.3.5 for review.

Trac:
Status: new to needs_review
Milestone: N/A to Tor: 0.3.5.x-final

Trac:
Username: debily
Summary: A demo for a fuzzing system that works for Rust through C code to A proposal and demo for a fuzzing system that works with Rust through C code

Trac:
Cc: N/A to chelseakomlo

This probably won't fix #25386 (moved), but it is a pretty good start on #24265 (moved). What we really need eventually is a way for the same random fuzzer input to be sent to both a C function and a Rust function, both of which are supposed to behave identically (e.g. the parsers in src/or/protover.c and src/rust/protover/protover.rs).

Trac:
Cc: chelseakomlo to chelseakomlo, isis

Replying to isis:

This probably won't fix #25386 (moved), but it is a pretty good start on #24265 (moved). What we really need eventually is a way for the same random fuzzer input to be sent to both a C function and a Rust function, both of which are supposed to behave identically (e.g. the parsers in src/or/protover.c and src/rust/protover/protover.rs).

Well I could do a json dump of structures and compare them, though one can never be sure of correctness of used json libraries.

Trac:
Username: debily

Trac:
Reviewer: N/A to nickm

Setting as needs_revision per isis's comment above. This is a decent example of Rust fuzzing, but what we need is a feature to run the C and the rust in parallel, and compare their outputs. In many cases, the outputs will be strings, lists of strings, booleans, or some similar data structure, so the comparison shouldn't be too hard. For us to get the benefit of trace-aware fuzzing, we really need both of the implementations to run in the same process.

Additionally, it would be much more useful if this fuzzing could be done through the infrastructure currently in src/test/fuzz directory: That way, we could run this fuzzing not only with AFL, but also with llvm's libfuzzer, with google's OSS-Fuzz, and whatever else we wind up having in the future.

Trac:
Status: needs_review to needs_revision

Removing needs_revision tickets from 0.3.5 that seem to be stalled. Please move back if they are under active revision or discussion.

Trac:
Milestone: Tor: 0.3.5.x-final to Tor: unspecified
Keywords: fuzzing Rust afl deleted, Rust, fuzzing, afl, 035-removed-20180711 added

Trac:
Parent: #25386 (moved) to #24265 (moved)

mentioned in issue #27191 (moved)

moved to tpo/core/tor#26265 (closed)