influxdata / influxdata/influxdb

Restart fuzz-testing effort in rust

Open
#24,502 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
31.7k
Forks
3.7k
Avg merge
13h 37m
Merged PRs (30d)
8

Description

Hey team, I'm aware that you are likely busy with other work, is now a bad time to discuss the potential to restart the fuzz-testing effort?

__Use case:__
Fuzz-testing is very useful tool in discovering edge-cases and bugs that wouldn't otherwise be captured by the unit-testing suite.

__Proposal:__
1. Fuzz tests are rewritten using cargo-fuzz. I've got a proof of concept in #24501, to demonstrate what this would look like.
2. Port of the [google/oss-fuzz](https://github.com/google/oss-fuzz/blob/master/projects/influxdb/project.yaml#L2) configs to match the new rust build rather than the old golang build.

__Current behaviour:__
- No fuzz testing is currently being done (beyond ad-hoc RNG based fuzzing).
- The google/oss-fuzz influxdb [builds are broken](https://oss-fuzz-build-logs.storage.googleapis.com/index.html#influxdb) and have been since 2020.

__Desired behaviour:__
Continuous fuzzing fully re-enabled using google/oss-fuzz.

__Alternatives considered:__
- Continue using the [ad-hoc RNG based fuzzer's](https://github.com/influxdata/influxdb/blob/bb6a5c0bf6968117251617cda99cb39a5274b6dd/arrow_util/src/bitset.rs#L362-L403). These fuzzer's can often be hard to read, and typically operate in open-loop limiting the acheivable performance compared to a coverage-driven closed-loop fuzzer like libfuzzer. The nice thing is that the original RNG fuzzers can fairly easily be ported over to use libfuzzer instead, so they certainly weren't wasted effort.
- Continue using the [proptest style fuzzers](https://github.com/influxdata/influxdb/blob/main/cache_system/src/addressable_heap.rs#L557-L568), while the ergonomics/readability of these fuzzer's is significantly better they don't use coverage driven feedback, which limits the overall fuzzing performance.

Contributor guide

Open the contributing guide

Research direction

Start with proof of concept PR #24501, then inspect the existing fuzzers in arrow_util/src/bitset.rs and cache_system/src/addressable_heap.rs. Review the referenced oss-fuzz project configuration and determine the required Rust cargo-fuzz and continuous-build changes. Done means coverage-driven fuzzing is restored and the google/oss-fuzz builds succeed.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
testing-qa
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.