Some fuzzing improvements#12962
Conversation
We have poor coverage for this 'misc' sub-target, so let's make it more prominent.
Specifically: - drop the component_async target, now that that is its own thing - as a side-benefit, skip calling oracles::component_async::init() - improve and simplify the sub-target selection logic. Before, the majority of invocations of misc didn't do anything, because the input byte would select a non-existent sub-target. This is visible in the extremely low coverage of the misc.rs file, and consequently equally low utilization of the misc target on OSS-Fuzz
This adds a fairly expansive [dictionary](https://llvm.org/docs/LibFuzzer.html#dictionaries) for use by the `compile` and `instantiate` targets. I had Claude Opus generate the dictionary and checked it reasonably, but not terribly thoroughly. My understanding is that mistakes in it should be harmless, since the fuzzer should learn quickly not to use patterns that lead nowhere.
Subscribe to Label Actioncc @fitzgen DetailsThis issue or pull request has been labeled: "fuzzing"Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
| if enabled.is_empty() { | ||
| return; | ||
| } | ||
| let fuzzer = enabled[which as usize % enabled.len()]; |
There was a problem hiding this comment.
This means that the same fuzz input will execute different sub-fuzzers depending on which are enabled or disabled, which is something that we have tried to avoid in the past so that the corpus remains useful across different runs with different FUZZER=... env vars set.
Could we instead do something more similar to what we did before, but with clamping/moduloing/something the which_fuzzer discriminant?
| |bytes: &[u8]| { | ||
| let _ = run(bytes); | ||
| } |
There was a problem hiding this comment.
It may make sense to return Corpus::Reject if run returns an error here, since that is just a test-case-generation error, and exploring all test-case-generation errors instead of the fuzz target itself is not particularly useful.
https://docs.rs/libfuzzer-sys/latest/libfuzzer_sys/enum.Corpus.html
Do you mean that it chooses a bad Or literal |
2 participants
Together, these lead to a meaningful uptick in coverage from similarly-length local runs.
In particular,
component_asynctarget gave me 60% coverage ofruntime/component/concurrent, where OSS-Fuzz is at around 40%miscimprovements make all of the sub-targets covered, whereas currently on OSS-Fuzz, this target is virtually unused because, IIUC, most of the time it aborts immediately.I honestly don't know how useful the dictionary will be, but we should be able to see by observing behavior of the affected fuzzers.