From a25d2fcc96396f7524289e02056de437d3a6e8f0 Mon Sep 17 00:00:00 2001 From: Kostya Serebryany Date: Wed, 16 Nov 2016 11:16:27 -0800 Subject: Update ideal_integration.md --- docs/ideal_integration.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'docs/ideal_integration.md') 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 -- cgit v1.2.3