From 6916d4c9a03116626397e4f9cc0dc91073c1f042 Mon Sep 17 00:00:00 2001 From: inferno-chromium Date: Wed, 16 Nov 2016 08:59:35 -0800 Subject: [PATCH] Update ideal_integration.md --- docs/ideal_integration.md | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/docs/ideal_integration.md b/docs/ideal_integration.md index eb5cc1532..6840b5d97 100644 --- a/docs/ideal_integration.md +++ b/docs/ideal_integration.md @@ -1,15 +1,17 @@ # Ideal integration with OSS-Fuzz -OSS projects have different build and test systems and so we can not expect them +OSS projects have different build and test systems. So, we can not expect them to have a unified way of implementing and maintaining fuzz targets and integrating -them with OSS-Fuzz. However we will still try to give recommendations on the preferred ways. +them with OSS-Fuzz. However, we will still try to give recommendations on the preferred ways. Here are the 4 stages of integraion (starting from the easiest) that will make automated fuzzing -simple and efficient. +simple, efficient and catch regressions early on in the development cycle. ## Stage 1: Fuzz Target The code of the [fuzz target(s)](http://libfuzzer.info/#fuzz-target) should be part of the project's source code repository. All fuzz targets should be easily discoverable (e.g. reside in the same directory, or follow the same naming pattern, etc). +This makes it easy to maintain fuzzer and minimizes breakages that can arise as source code changes over time. + Examples: [boringssl](https://github.com/google/boringssl/tree/master/fuzz), [SQLite](https://www.sqlite.org/src/artifact/ad79e867fb504338), @@ -23,11 +25,12 @@ Examples: ## Stage 2: Seed Corpus -The seed corpus should be available in revision control (same or different as the source code). +The seed corpus should be available in revision control (can be same or different as the source code). 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 huge impact on the efficiency of fuzzing . +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. +Adding past crash inputs to seed corpus helps to create a good regression suite for testing. Examples: [boringssl](https://github.com/google/boringssl/tree/master/fuzz), @@ -35,26 +38,25 @@ Examples: ## Stage 3: Regression Testing -The fuzz targets should be regularly tested (not necessary fuzzed!) as a part -of the project's regression testing process. +The fuzz targets should be regularly tested (not necessary fuzzed!) as a part of the project's regression testing process. One way to do so is to link the fuzz target with a simple driver (e.g. [this one](https://github.com/llvm-mirror/llvm/tree/master/lib/Fuzzer/standalone)) -that runs the provided inputs and use this driver with the seed corpus. -If possible, use the [sanitizers](https://github.com/google/sanitizers) during regression testing. +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) ## 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. +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 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 flags so that the build command for a `foo_fuzzer.a` looks like this: `CC="clang $FUZZER_FLAGS" CXX="clang++ $FUZZER_FLAGS" make_or_whatever_other_command foo_fuzzer.a`. -In this case linking the target with e.g. libFuzzer will look like "clang++ foo_fuzzer.a libFuzzer.a". -This will allow to have minimal OSS-Fuzz-specific configuration and thus be more robust. +In this case, linking the target with e.g. libFuzzer will look like "clang++ foo_fuzzer.a libFuzzer.a". +This will allow to have minimal OSS-Fuzz-specific configuration and thus be more robust.