diff options
| author |  Kostya Serebryany <konstantin.s.serebryany@gmail.com> | 2016-11-16 11:16:27 -0800 |
|---|---|---|
| committer |  GitHub <noreply@github.com> | 2016-11-16 11:16:27 -0800 |
| commit | a25d2fcc96396f7524289e02056de437d3a6e8f0 (patch) | |
| tree | 5d890f4bad77b6ee628d3ab4c77111ccd6266075 /docs/ideal_integration.md | |
| parent | 459050ec5a2d92e47e8d067b31016eed495128a6 (diff) | |
Update ideal_integration.md
Diffstat (limited to 'docs/ideal_integration.md')
| -rw-r--r-- | docs/ideal_integration.md | 7 |
1 files changed, 4 insertions, 3 deletions
diff --git a/docs/ideal_integration.md b/docs/ideal_integration.md index 6840b5d9..a7219b21 100644 --- a/docs/ideal_integration.md +++ b/docs/ideal_integration.md @@ -29,7 +29,7 @@ The seed corpus should be available in revision control (can be same or differen The seed corpus should be maintained by the project owners and extended every time a bug found by the fuzz target is fixed. Inputs that trigger important parts of the code are also welcome. -The quality of the seed corpus has a huge impact on the fuzzing efficiency as it allows the fuzzer to discover new code paths easily. +The quality of the seed corpus has a huge impact on the fuzzing efficiency as it allows the fuzzer to discover new code paths easily. The ideal corpus is a minimial set of intputs that provides maximal code coverage. Adding past crash inputs to seed corpus helps to create a good regression suite for testing. Examples: @@ -44,14 +44,15 @@ One way to do so is to link the fuzz target with a simple driver that runs the provided inputs and use this driver with the seed corpus created in previous step. It is recommended use the [sanitizers](https://github.com/google/sanitizers) during regression testing. -Examples: [SQLite](https://www.sqlite.org/src/artifact/d9f1a6f43e7bab45) +Examples: [SQLite](https://www.sqlite.org/src/artifact/d9f1a6f43e7bab45), +[openssl](https://github.com/openssl/openssl/blob/master/fuzz/test-corpus.c) ## Stage 4: Build support A plethora of different build systems exist in the open-source world. And the less OSS-Fuzz knows about them, the better it can scale. An ideal build integration for OSS-Fuzz would look like this: -* For every fuzz target in the project, there is a build rule that builds `foo_fuzzer.a`, +* For every fuzz target `foo` in the project, there is a build rule that builds `foo_fuzzer.a`, an archive that contains the fuzzing entry point (`LLVMFuzzerTestOneInput`) and all the code it depends on, but not the `main()` function * The build system supports changing the compiler and passing extra compiler |