Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Coverage-based fuzzing for block processing, (de)serialization #2300

Closed
1 task
Tracked by #3247 ...
teor2345 opened this issue Jun 14, 2021 · 1 comment
Closed
1 task
Tracked by #3247 ...

Coverage-based fuzzing for block processing, (de)serialization #2300

teor2345 opened this issue Jun 14, 2021 · 1 comment
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

Comments

@teor2345
Copy link
Contributor

teor2345 commented Jun 14, 2021

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:

  • Have a test harness for shoving random bytes into Block implementations of ZcashDeserialize, From, etc

We 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 annoying should be easy with CodeCov, could be considered out of scope for this ticket.

#2298 is very similar.

@teor2345 teor2345 added A-rust Area: Updates to Rust code S-needs-triage Status: A bug report needs triage P-Low C-security Category: Security issues I-panic Zebra panics with an internal error message I-heavy Problems with excessive memory, disk, or CPU usage labels Jun 14, 2021
@mpguerra mpguerra removed the S-needs-triage Status: A bug report needs triage label Jun 21, 2021
@teor2345
Copy link
Contributor Author

teor2345 commented Mar 1, 2022

This is a useful test, but it's not urgent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
None yet
Development

No branches or pull requests

2 participants