Coverage-based fuzzing for block processing, (de)serialization #2300
Closed
1 task
Labels
A-rust
Area: Updates to Rust code
C-security
Category: Security issues
I-heavy
Problems with excessive memory, disk, or CPU usage
I-panic
Zebra panics with an internal error message
Motivation
We currently test block (de)serialization and processing to a degree with structured property-based testing and unit testing. Structured proptests utilize test data that is correct, up to a point. While this is useful testing, we do want to cover more edge cases and abstraction/assumption mismatches.
This ticket is a lower priority, because block headers are fixed-length and reasonably simple.
Solution
We'd like to set up a coverage-based fuzzing harness to exercise block (de)serialization and processing. Fuzzing helps find logic and correctness bugs, even in a memory-safe language like Rust.
cargo-fuzz is the defacto standard tool, it wraps libFuzzer and has support for other fuzzing libraries, and builds well into a cargo crate/workspace.
They have a handy book to get started. There is also recent support for something closer to proptests, with structure-aware fuzzing.
auto-fuzz-test exists, but may collide with our use of
proptest::Arbitrary
or make code difficult to parse for humans.We should at least:
Block
implementations ofZcashDeserialize
,From
, etcWe can run this coverage are purely part of our CI, or we can consider integrating our fuzzing harnesses into oss-fuzz, for free, continuous fuzzing.
Alternatives
Keep pushing non-coverage-guided random data though code paths with our proptest framework. This may get us less bang for our buck.
Related Work
Merging the coverage data from coverage-based fuzzing with the rest of our test coverage data is possible, as they use the same llvm internals under the hood,
but may be annoyingshould be easy with CodeCov, could be considered out of scope for this ticket.#2298 is very similar.
The text was updated successfully, but these errors were encountered: