diff --git a/docs/.gitignore b/docs/.gitignore new file mode 100644 index 0000000..2629954 --- /dev/null +++ b/docs/.gitignore @@ -0,0 +1,3 @@ +vendor/ +_site/ +.bundle/ diff --git a/docs/Gemfile b/docs/Gemfile new file mode 100644 index 0000000..7434b39 --- /dev/null +++ b/docs/Gemfile @@ -0,0 +1,2 @@ +source "https://rubygems.org" +gem 'github-pages', group: :jekyll_plugins diff --git a/docs/Gemfile.lock b/docs/Gemfile.lock new file mode 100644 index 0000000..2056105 --- /dev/null +++ b/docs/Gemfile.lock @@ -0,0 +1,282 @@ +GEM + remote: https://rubygems.org/ + specs: + activesupport (6.0.4) + concurrent-ruby (~> 1.0, >= 1.0.2) + i18n (>= 0.7, < 2) + minitest (~> 5.1) + tzinfo (~> 1.1) + zeitwerk (~> 2.2, >= 2.2.2) + addressable (2.8.0) + public_suffix (>= 2.0.2, < 5.0) + coffee-script (2.4.1) + coffee-script-source + execjs + coffee-script-source (1.11.1) + colorator (1.1.0) + commonmarker (0.17.13) + ruby-enum (~> 0.5) + concurrent-ruby (1.1.9) + dnsruby (1.61.7) + simpleidn (~> 0.1) + em-websocket (0.5.2) + eventmachine (>= 0.12.9) + http_parser.rb (~> 0.6.0) + ethon (0.14.0) + ffi (>= 1.15.0) + eventmachine (1.2.7) + execjs (2.8.1) + faraday (1.6.0) + faraday-em_http (~> 1.0) + faraday-em_synchrony (~> 1.0) + faraday-excon (~> 1.1) + faraday-httpclient (~> 1.0.1) + faraday-net_http (~> 1.0) + faraday-net_http_persistent (~> 1.1) + faraday-patron (~> 1.0) + faraday-rack (~> 1.0) + multipart-post (>= 1.2, < 3) + ruby2_keywords (>= 0.0.4) + faraday-em_http (1.0.0) + faraday-em_synchrony (1.0.0) + faraday-excon (1.1.0) + faraday-httpclient (1.0.1) + faraday-net_http (1.0.1) + faraday-net_http_persistent (1.2.0) + faraday-patron (1.0.0) + faraday-rack (1.0.0) + ffi (1.15.3) + forwardable-extended (2.6.0) + gemoji (3.0.1) + github-pages (218) + github-pages-health-check (= 1.17.2) + jekyll (= 3.9.0) + jekyll-avatar (= 0.7.0) + jekyll-coffeescript (= 1.1.1) + jekyll-commonmark-ghpages (= 0.1.6) + jekyll-default-layout (= 0.1.4) + jekyll-feed (= 0.15.1) + jekyll-gist (= 1.5.0) + jekyll-github-metadata (= 2.13.0) + jekyll-mentions (= 1.6.0) + jekyll-optional-front-matter (= 0.3.2) + jekyll-paginate (= 1.1.0) + jekyll-readme-index (= 0.3.0) + jekyll-redirect-from (= 0.16.0) + jekyll-relative-links (= 0.6.1) + jekyll-remote-theme (= 0.4.3) + jekyll-sass-converter (= 1.5.2) + jekyll-seo-tag (= 2.7.1) + jekyll-sitemap (= 1.4.0) + jekyll-swiss (= 1.0.0) + jekyll-theme-architect (= 0.2.0) + jekyll-theme-cayman (= 0.2.0) + jekyll-theme-dinky (= 0.2.0) + jekyll-theme-hacker (= 0.2.0) + jekyll-theme-leap-day (= 0.2.0) + jekyll-theme-merlot (= 0.2.0) + jekyll-theme-midnight (= 0.2.0) + jekyll-theme-minimal (= 0.2.0) + jekyll-theme-modernist (= 0.2.0) + jekyll-theme-primer (= 0.6.0) + jekyll-theme-slate (= 0.2.0) + jekyll-theme-tactile (= 0.2.0) + jekyll-theme-time-machine (= 0.2.0) + jekyll-titles-from-headings (= 0.5.3) + jemoji (= 0.12.0) + kramdown (= 2.3.1) + kramdown-parser-gfm (= 1.1.0) + liquid (= 4.0.3) + mercenary (~> 0.3) + minima (= 2.5.1) + nokogiri (>= 1.10.4, < 2.0) + rouge (= 3.26.0) + terminal-table (~> 1.4) + github-pages-health-check (1.17.2) + addressable (~> 2.3) + dnsruby (~> 1.60) + octokit (~> 4.0) + public_suffix (>= 2.0.2, < 5.0) + typhoeus (~> 1.3) + html-pipeline (2.14.0) + activesupport (>= 2) + nokogiri (>= 1.4) + http_parser.rb (0.6.0) + i18n (0.9.5) + concurrent-ruby (~> 1.0) + jekyll (3.9.0) + addressable (~> 2.4) + colorator (~> 1.0) + em-websocket (~> 0.5) + i18n (~> 0.7) + jekyll-sass-converter (~> 1.0) + jekyll-watch (~> 2.0) + kramdown (>= 1.17, < 3) + liquid (~> 4.0) + mercenary (~> 0.3.3) + pathutil (~> 0.9) + rouge (>= 1.7, < 4) + safe_yaml (~> 1.0) + jekyll-avatar (0.7.0) + jekyll (>= 3.0, < 5.0) + jekyll-coffeescript (1.1.1) + coffee-script (~> 2.2) + coffee-script-source (~> 1.11.1) + jekyll-commonmark (1.3.1) + commonmarker (~> 0.14) + jekyll (>= 3.7, < 5.0) + jekyll-commonmark-ghpages (0.1.6) + commonmarker (~> 0.17.6) + jekyll-commonmark (~> 1.2) + rouge (>= 2.0, < 4.0) + jekyll-default-layout (0.1.4) + jekyll (~> 3.0) + jekyll-feed (0.15.1) + jekyll (>= 3.7, < 5.0) + jekyll-gist (1.5.0) + octokit (~> 4.2) + jekyll-github-metadata (2.13.0) + jekyll (>= 3.4, < 5.0) + octokit (~> 4.0, != 4.4.0) + jekyll-mentions (1.6.0) + html-pipeline (~> 2.3) + jekyll (>= 3.7, < 5.0) + jekyll-optional-front-matter (0.3.2) + jekyll (>= 3.0, < 5.0) + jekyll-paginate (1.1.0) + jekyll-readme-index (0.3.0) + jekyll (>= 3.0, < 5.0) + jekyll-redirect-from (0.16.0) + jekyll (>= 3.3, < 5.0) + jekyll-relative-links (0.6.1) + jekyll (>= 3.3, < 5.0) + jekyll-remote-theme (0.4.3) + addressable (~> 2.0) + jekyll (>= 3.5, < 5.0) + jekyll-sass-converter (>= 1.0, <= 3.0.0, != 2.0.0) + rubyzip (>= 1.3.0, < 3.0) + jekyll-sass-converter (1.5.2) + sass (~> 3.4) + jekyll-seo-tag (2.7.1) + jekyll (>= 3.8, < 5.0) + jekyll-sitemap (1.4.0) + jekyll (>= 3.7, < 5.0) + jekyll-swiss (1.0.0) + jekyll-theme-architect (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-cayman (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-dinky (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-hacker (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-leap-day (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-merlot (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-midnight (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-minimal (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-modernist (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-primer (0.6.0) + jekyll (> 3.5, < 5.0) + jekyll-github-metadata (~> 2.9) + jekyll-seo-tag (~> 2.0) + jekyll-theme-slate (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-tactile (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-theme-time-machine (0.2.0) + jekyll (> 3.5, < 5.0) + jekyll-seo-tag (~> 2.0) + jekyll-titles-from-headings (0.5.3) + jekyll (>= 3.3, < 5.0) + jekyll-watch (2.2.1) + listen (~> 3.0) + jemoji (0.12.0) + gemoji (~> 3.0) + html-pipeline (~> 2.2) + jekyll (>= 3.0, < 5.0) + kramdown (2.3.1) + rexml + kramdown-parser-gfm (1.1.0) + kramdown (~> 2.0) + liquid (4.0.3) + listen (3.6.0) + rb-fsevent (~> 0.10, >= 0.10.3) + rb-inotify (~> 0.9, >= 0.9.10) + mercenary (0.3.6) + mini_portile2 (2.6.1) + minima (2.5.1) + jekyll (>= 3.5, < 5.0) + jekyll-feed (~> 0.9) + jekyll-seo-tag (~> 2.1) + minitest (5.14.4) + multipart-post (2.1.1) + nokogiri (1.12.2) + mini_portile2 (~> 2.6.1) + racc (~> 1.4) + nokogiri (1.12.2-x86_64-linux) + racc (~> 1.4) + octokit (4.21.0) + faraday (>= 0.9) + sawyer (~> 0.8.0, >= 0.5.3) + pathutil (0.16.2) + forwardable-extended (~> 2.6) + public_suffix (4.0.6) + racc (1.5.2) + rb-fsevent (0.11.0) + rb-inotify (0.10.1) + ffi (~> 1.0) + rexml (3.2.5) + rouge (3.26.0) + ruby-enum (0.9.0) + i18n + ruby2_keywords (0.0.5) + rubyzip (2.3.2) + safe_yaml (1.0.5) + sass (3.7.4) + sass-listen (~> 4.0.0) + sass-listen (4.0.0) + rb-fsevent (~> 0.9, >= 0.9.4) + rb-inotify (~> 0.9, >= 0.9.7) + sawyer (0.8.2) + addressable (>= 2.3.5) + faraday (> 0.8, < 2.0) + simpleidn (0.2.1) + unf (~> 0.1.4) + terminal-table (1.8.0) + unicode-display_width (~> 1.1, >= 1.1.1) + thread_safe (0.3.6) + typhoeus (1.4.0) + ethon (>= 0.9.0) + tzinfo (1.2.9) + thread_safe (~> 0.1) + unf (0.1.4) + unf_ext + unf_ext (0.0.7.7) + unicode-display_width (1.7.0) + zeitwerk (2.4.2) + +PLATFORMS + ruby + x86_64-linux + +DEPENDENCIES + github-pages + +BUNDLED WITH + 2.2.16 diff --git a/docs/_config.yml b/docs/_config.yml new file mode 100644 index 0000000..164f534 --- /dev/null +++ b/docs/_config.yml @@ -0,0 +1,40 @@ +# Welcome to Jekyll! +# +# This config file is meant for settings that affect your whole blog, values +# which you are expected to set up once and rarely edit after that. If you find +# yourself editing this file very often, consider using Jekyll's data files +# feature for the data you need to update frequently. +# +# For technical reasons, this file is *NOT* reloaded automatically when you use +# 'bundle exec jekyll serve'. If you change this file, please restart the server process. + +# Site settings +# These are used to personalize your new site. If you look in the HTML files, +# you will see them accessed via {{ site.title }}, {{ site.email }}, and so on. +# You can create any custom variable you would like, and they will be accessible +# in the templates via {{ site.myvariable }}. +title: ClusterFuzz Lite +description: Documentation for ClusterFuzz Lite +baseurl: "/clusterfuzzlite" # the subpath of your site, e.g. /blog +url: "" # the base hostname & protocol for your site, e.g. http://example.com + +# Build settings +markdown: kramdown +remote_theme: pmarsceill/just-the-docs +search_enabled: true + +ga_tracking: UA-88024544-5 + +aux_links: + "ClusterFuzzLite on GitHub": + - https://github.com/google/clusterfuzzlite + +# Exclude from processing. +exclude: + - Gemfile + - Gemfile.lock + - node_modules + - vendor/bundle/ + - vendor/cache/ + - vendor/gems/ + - vendor/ruby/ diff --git a/docs/advanced/adding_ci_support.md b/docs/advanced/adding_ci_support.md new file mode 100644 index 0000000..e50e442 --- /dev/null +++ b/docs/advanced/adding_ci_support.md @@ -0,0 +1,12 @@ +--- +layout: default +parent: Advanced Topics +grand_parent: ClusterFuzzLite +title: Adding Support for a New CI +nav_order: 1 +permalink: /advanced-topics/adding-ci-support/ +--- + +# Adding Support for a New CI + +TODO diff --git a/docs/advanced/architecture.md b/docs/advanced/architecture.md new file mode 100644 index 0000000..880ed29 --- /dev/null +++ b/docs/advanced/architecture.md @@ -0,0 +1,12 @@ +--- +layout: default +parent: Advanced Topics +grand_parent: ClusterFuzzLite +title: Architecture +nav_order: 1 +permalink: /advanced-topics/architecture/ +--- + +# Architecture + +TODO diff --git a/docs/advanced_topics.md b/docs/advanced_topics.md new file mode 100644 index 0000000..8c4d089 --- /dev/null +++ b/docs/advanced_topics.md @@ -0,0 +1,10 @@ +--- +layout: default +parent: ClusterFuzzLite +title: Advanced Topics +has_children: true +nav_order: 4 +permalink: /advanced-topics/ +--- + +# Advanced topics diff --git a/docs/build_integration.md b/docs/build_integration.md new file mode 100644 index 0000000..2194eb8 --- /dev/null +++ b/docs/build_integration.md @@ -0,0 +1,272 @@ +--- +layout: default +parent: ClusterFuzzLite +title: Build Integration +has_children: true +nav_order: 2 +permalink: /build-integration/ +--- +# Build integration +{: .no_toc} + +- TOC +{:toc} +--- + +## Prerequisites +ClusterFuzzLite supports statically linked +[libFuzzer targets]({{ site.baseurl }}/reference/glossary/#fuzz-target) on +Linux. + +We re-use the [OSS-Fuzz](https://github.com/google/oss-fuzz) toolchain to make +building easier. If you are familiar with this, most of the concepts here are +exactly the same, with one key difference. Rather than checking out the source +code in the [`Dockerfile`](#dockerfile) using `git clone`, the `Dockerfile` +copies in the source code directly during `docker build`. + +Before you can start setting up your new project for fuzzing, you must do the following: +- [Integrate]({{ site.baseurl }}/advanced-topics/ideal-integration/) one or more [fuzz targets]({{ site.baseurl }}/reference/glossary/#fuzz-target) + with the project you want to fuzz. For examples, see TODO. +- [Install Docker](https://docs.docker.com/engine/installation) + [Why Docker?]({{ site.baseurl }}/faq/#why-do-you-use-docker) + + If you want to run `docker` without `sudo`, you can + [create a docker group](https://docs.docker.com/engine/installation/linux/ubuntulinux/#/create-a-docker-group). + + **Note:** Docker images can consume significant disk space. Run + [docker-cleanup](https://gist.github.com/mikea/d23a839cba68778d94e0302e8a2c200f) + periodically to garbage-collect unused images. + +- Clone the OSS-Fuzz repo: `git clone https://github.com/google/oss-fuzz.git` + +## Generating an empty build integration + +Build integrations consist of three configuration files: +* [./clusterfuzzlite/project.yaml](#projectyaml) - provides metadata about the project. +* [./clusterfuzzlite/Dockerfile](#dockerfile) - defines the container environment with information +on dependencies needed to build the project and its [fuzz targets]({{ site.baseurl }}/reference/glossary/#fuzz-target). +* [./clusterfuzzlite/build.sh](#buildsh) - defines the build script that executes inside the Docker container and +generates the project build. + +These must live in the `.clusterfuzzlite` directory in the root of your +project's source code checkout. + +You can generate empty versions of these files with the following command: + +```bash +$ cd /path/to/oss-fuzz +$ export PATH_TO_PROJECT= +$ python infra/helper.py generate $PATH_TO_PROJECT --external +``` + +Once the configuration files are generated, you should modify them to fit your +project. + +## project.yaml {#projectyaml} + +This configuration file stores project metadata. The following attributes are +supported: + +- [language](#language) + +### language + +Programming language the project is written in. Values you can specify include: + +* `c` +* `c++` +* [`go`]({{ site.baseurl }}//getting-started/new-project-guide/go-lang/) +* [`rust`]({{ site.baseurl }}//getting-started/new-project-guide/rust-lang/) +* [`python`]({{ site.baseurl }}//getting-started/new-project-guide/python-lang/) +* [`jvm` (Java, Kotlin, Scala and other JVM-based languages)]({{ site.baseurl }}//getting-started/new-project-guide/jvm-lang/) + +## Dockerfile {#dockerfile} + +This integration file defines the Docker image for your project. +Your [build.sh](#buildsh) script will be executed in inside the container you +define. +For most projects, the image is simple: +```docker +FROM gcr.io/oss-fuzz-base/base-builder # base image with clang toolchain +RUN apt-get update && apt-get install -y ... # install required packages to build your project +COPY . $SRC/ # checkout all sources needed to build your project +WORKDIR $SRC/ # current directory for the build script +COPY ./clusterfuzzlite/build.sh fuzzer.cc $SRC/ # copy build script into src dir +``` +TODO: Provide examples. + +## build.sh {#buildsh} + +This file defines how to build binaries for [fuzz targets]({{ site.baseurl }}/reference/glossary/#fuzz-target) in your project. +The script is executed within the image built from your [Dockerfile](#Dockerfile). + +In general, this script should do the following: + +- Build the project using your build system with OSS-Fuzz's compiler. +- Provide OSS-Fuzz's compiler flags (defined as [environment variables](#Requirements)) to the build system. +- Build your [fuzz targets]({{ site.baseurl }}/reference/glossary/#fuzz-target) + and link your project's build with `$LIB_FUZZING_ENGINE` (libFuzzer). + +Resulting binaries should be placed in `$OUT`. + +Here's an example from Expat +([source](https://github.com/google/oss-fuzz/blob/master/projects/expat/build.sh)): + +```bash +#!/bin/bash -eu + +./buildconf.sh +# configure scripts usually use correct environment variables. +./configure + +make clean +make -j$(nproc) all + +$CXX $CXXFLAGS -std=c++11 -Ilib/ \ + $SRC/parse_fuzzer.cc -o $OUT/parse_fuzzer \ + $LIB_FUZZING_ENGINE .libs/libexpat.a + +cp $SRC/*.dict $SRC/*.options $OUT/ +``` + +If your project is written in Go, check out the [Integrating a Go project]({{ site.baseurl }}//getting-started/new-project-guide/go-lang/) page. + +**Note:** +1. Make sure that the binary names for your [fuzz targets]({{ site.baseurl }}/reference/glossary/#fuzz-target) contain only +alphanumeric characters, underscore(_) or dash(-). Otherwise, they won't run. +1. Don't remove source code files. They are needed for code coverage. + + +### Temporarily disabling code instrumentation during builds + +In some cases, it's not necessary to instrument every 3rd party library or tool that supports the build target. Use the following snippet to build tools or libraries without instrumentation: + +``` +CFLAGS_SAVE="$CFLAGS" +CXXFLAGS_SAVE="$CXXFLAGS" +unset CFLAGS +unset CXXFLAGS +export AFL_NOOPT=1 + +# +# build commands here that should not result in instrumented code. +# + +export CFLAGS="${CFLAGS_SAVE}" +export CXXFLAGS="${CXXFLAGS_SAVE}" +unset AFL_NOOPT +``` +TODO: Figure out if we should include this AFL code. + +### build.sh script environment + +When your build.sh script is executed, the following locations are available within the image: + +| Location| Env Variable | Description | +|---------| ------------ | ---------- | +| `/out/` | `$OUT` | Directory to store build artifacts (fuzz targets, dictionaries, options files, seed corpus archives). | +| `/src/` | `$SRC` | Directory to checkout source files. | +| `/work/`| `$WORK` | Directory to store intermediate files. | + +Although the files layout is fixed within a container, environment variables are +provided so you can write retargetable scripts. + +In case your fuzz target uses the [FuzzedDataProvider] class, make sure it is +included via `#include ` directive. + +[FuzzedDataProvider]: https://github.com/google/fuzzing/blob/master/docs/split-inputs.md#fuzzed-data-provider + +### build.sh requirements {#Requirements} + +Only binaries without an extension are accepted as targets. Extensions are reserved for other artifacts, like .dict. + +You *must* use the special compiler flags needed to build your project and fuzz targets. +These flags are provided in the following environment variables: + +| Env Variable | Description +| ------------- | -------- +| `$CC`, `$CXX`, `$CCC` | The C and C++ compiler binaries. +| `$CFLAGS`, `$CXXFLAGS` | C and C++ compiler flags. +| `$LIB_FUZZING_ENGINE` | C++ compiler argument to link fuzz target against the prebuilt engine library (e.g. libFuzzer). + +You *must* use `$CXX` as a linker, even if your project is written in pure C. + +Most well-crafted build scripts will automatically use these variables. If not, +pass them manually to the build tool. + +See the [Provided Environment Variables](https://github.com/google/oss-fuzz/blob/master/infra/base-images/base-builder/README.md#provided-environment-variables) section in +`base-builder` image documentation for more details. + +## Fuzzer execution environment + +For more on the environment that +your [fuzz targets]({{ site.baseurl }}/reference/glossary/#fuzz-target) run in, and the assumptions you can make, see the [fuzzer environment]({{ site.baseurl }}/further-reading/fuzzer-environment/) page. + +## Testing locally + +You can build your docker image and fuzz targets locally, so you can test them +before running ClusterFuzzLite. +1. Run the same helper script you used to create your directory structure, this time using it to build your docker image and [fuzz targets]({{ site.baseurl }}/reference/glossary/#fuzz-target): + + ```bash + $ cd /path/to/oss-fuzz + $ python infra/helper.py build_image $PATH_TO_PROJECT --external + $ python infra/helper.py build_fuzzers $PATH_TO_PROJECT --sanitizer
--external + ``` + + The built binaries appear in the `/path/to/oss-fuzz/build/out/$PROJECT_NAME` + directory on your machine (and `$OUT` in the container). Note that + `$PROJECT_NAME` is the name of the directory of your project (e.g. if + `$PATH_TO_PROJECT` is `/path/to/systemd`, `$PROJECT_NAME` is systemd. + + **Note:** You *must* run your fuzz target binaries inside the base-runner docker + container to make sure that they work properly. + +2. Find failures to fix by running the `check_build` command: + + ```bash + $ python infra/helper.py check_build $PATH_TO_PROJECT --external + ``` + +3. If you want to test changes against a particular fuzz target, run the following command: + + ```bash + $ python infra/helper.py run_fuzzer --external --corpus-dir= $PATH_TO_PROJECT + ``` + +4. We recommend taking a look at your code coverage as a test to ensure that +your fuzz targets get to the code you expect. This would use the corpus +generated from the previous `run_fuzzer` step in your local corpus directory. + + ```bash + $ python infra/helper.py build_fuzzers --sanitizer coverage $PATH_TO_PROJECT + $ python infra/helper.py coverage $PATH_TO_PROJECT --fuzz-target= --corpus-dir= --external + ``` + +You may need to run `python infra/helper.py pull_images` to use the latest +coverage tools. Please refer to +[code coverage]({{ site.baseurl }}/advanced-topics/code-coverage/) for detailed +information on code coverage generation. + +**Note:** Currently, ClusterFuzzLite only supports AddressSanitizer (address) +and UndefinedBehaviorSanitizer (undefined) configurations. +Make sure to test each +of the supported build configurations with the above commands (build_fuzzers -> run_fuzzer -> coverage). + +If everything works locally, it should also work on ClusterFuzzLite. If you +check in your files and experience failures, review your +[dependencies](https://google.github.io/oss-fuzz/further-reading/fuzzer-environment/). + +## Debugging Problems + +If you run into problems, the +[Debugging page](https://google.github.io/oss-fuzz/advanced-topics/debugging/) +lists ways to debug your build scripts and +[fuzz targets]({{ site.baseurl }}/reference/glossary/#fuzz-target). + +## Efficient fuzzing + +To improve your fuzz target ability to find bugs faster, please read +[this section](https://google.github.io/oss-fuzz/getting-started/new-project-guide/#efficient-fuzzing). + +TODO(metzman): We probably want a TOC for lang-specific guides (which we still need to add). diff --git a/docs/clusterfuzzlite.md b/docs/clusterfuzzlite.md new file mode 100644 index 0000000..bc23ec8 --- /dev/null +++ b/docs/clusterfuzzlite.md @@ -0,0 +1,25 @@ +--- +layout: default +title: ClusterFuzzLite +has_children: true +nav_order: 8 +permalink: / +--- + +# ClusterFuzzLite +ClusterFuzzLite is a lightweight, easy-to-use, fuzzing infrastructure that is +based off [ClusterFuzz]. ClusterFuzzLite is designed to run on [continuous integration] (CI) +systems, which means it is easy to set up and provides a familiar interface for +users. +Currently CIFuzz fully supports [GitHub Actions]. However ClusterFuzzLite is +designed so that supporting new CI systems is trivial and core features can be +used on any CI system without any additional effort. + +See [Overview] for a more detailed description of how ClusterFuzzLite works and +how you can use it. + +[continous integration]: https://en.wikipedia.org/wiki/Continuous_integration +[fuzzing]: https://en.wikipedia.org/wiki/Fuzzing +[ClusterFuzz]: https://google.github.io/clusterfuzz/ +[GitHub Actions]: https://docs.github.com/en/actions +[Overview]: {{ site.baseurl }}/overview/ diff --git a/docs/overview.md b/docs/overview.md new file mode 100644 index 0000000..6c61c88 --- /dev/null +++ b/docs/overview.md @@ -0,0 +1,30 @@ +--- +layout: default +parent: ClusterFuzzLite +title: Overview +nav_order: 1 +permalink: /overview/ +--- + +# Overview + +ClusterFuzzLite makes fuzzing more valuable by: +* Fuzzing continuously. +* Catching bugs before they land in your codebase by fuzzing pull + requests/commits. +* Providing coverage reports on which code is fuzzed. +* Managing your corpus, pruning it daily or a specified-interval. + +ClusterFuzzLite supports [libFuzzer], [AddressSanitizer], and +[UndefinedBehavior]. +ClusterFuzzLite is modular, so you can decide which features you want to use. +Using ClusterFuzzLite entails two major steps: +1. [Integrating with ClusterFuzzLite's build system] so ClusterFuzzLite can + build your project's fuzzers. +2. [Running ClusterFuzzLite]. + +[libFuzzer]: https://libfuzzer.info +[AddressSanitizer]: https://clang.llvm.org/docs/AddressSanitizer.html +[UndefinedBehaviorSanitizer]: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html +[Integrating with ClusterFuzzLite's build system]: {{ site.baseurl }}/build-integration/ +[Running ClusterFuzzLite]: {{ site.baseurl }}/running-clusterfuzzlite/ diff --git a/docs/running-clusterfuzzlite/generic.md b/docs/running-clusterfuzzlite/generic.md new file mode 100644 index 0000000..c40b73a --- /dev/null +++ b/docs/running-clusterfuzzlite/generic.md @@ -0,0 +1,17 @@ +--- +layout: default +parent: Running ClusterFuzzLite +grand_parent: ClusterFuzzLite +title: Running ClusterFuzzLite in a Generic Environment +nav_order: 2 +permalink: /running-clusterfuzzlite/generic/ +--- + +# Running ClusterFuzzLite in a Generic Environment +TODO: Rename run_cifuzz.py to run_clusterfuzzlite.py + +This page describes how to run clusterfuzzlite using the run_clusterfuzzlite.py +script, a low level script that is used by CI systems to run ClusterFuzzLite. +This guide is useful if you want to run ClusterFuzzLite outside of CI or if you +want to run it on a CI system that isn't supported yet. +TODO diff --git a/docs/running-clusterfuzzlite/github_actions.md b/docs/running-clusterfuzzlite/github_actions.md new file mode 100644 index 0000000..690213e --- /dev/null +++ b/docs/running-clusterfuzzlite/github_actions.md @@ -0,0 +1,12 @@ +--- +layout: default +parent: Running ClusterFuzzLite +grand_parent: ClusterFuzzLite +title: GitHub Actions +nav_order: 1 +permalink: /running-clusterfuzzlite/github-actions/ +--- + +# GitHub Actions + +TODO diff --git a/docs/running_clusterfuzzlite.md b/docs/running_clusterfuzzlite.md new file mode 100644 index 0000000..476f9cb --- /dev/null +++ b/docs/running_clusterfuzzlite.md @@ -0,0 +1,101 @@ +--- +layout: default +parent: ClusterFuzzLite +title: Running ClusterFuzzLite +has_children: true +nav_order: 3 +permalink: /running-clusterfuzzlite/ +--- +# Running ClusterFuzzLite +{: .no_toc} + +- TOC +{:toc} +--- + +## Overview +TODO: add a diagram. + +Once your project's fuzzers can be built and run by the helper script, it is +ready to be fuzzed by ClusterFuzzLite. +The exact method for doing this will depend on the how you are running +ClusterFuzzLite. For guides on how to run ClusterFuzzLite in your particular +environment (e.g. GitHub Actions) see the subguides. +The rest of this page will explain concepts configuration options and that are +agnostic to how ClusterFuzzLite is being run. + +## ClusterFuzzLite Tasks + +ClusterFuzzLite has the concept of tasks which instruct ClusterFuzzLite what to +do when running. + +### Code Review Fuzzing + +TODO(metzman): Work on a generic name for CIFuzz/PR fuzzing. + +One of the core ways for ClusterFuzzLite to be used is for fuzzing code that is +in review that was just commited. +This use-case is important because it allows ClusterFuzzLite to find bugs before +they are commited into your code and while they are easiest to fix. +To use Code Review Fuzzing, set the configuration option `clusterfuzzlite-task` +to `code-review`. +If you are familiar with OSS-Fuzz's CIFuzz, this task is similar to CIFuzz. +Running other ClusterFuzzLite tasks enhances ClusterFuzzLite's ability to do +Code Review Fuzzing. + +If [Batch Fuzzing] is enabled, Code Review Fuzzing will report only newly +introduced bugs and use the corpus developed during batch fuzzing. +If [Code Coverage Reporting] is enabled, Code Review Fuzzing will try to only +run the fuzzers affected by the code change. + +### Batch Fuzzing + +ClusterFuzzLite can also run in a batch fuzzing mode where all fuzzers are run +for a long amount of time. Unlike Code Review Fuzzing, this task is not meant to +be interactive, it is meant to be long-lasting and generally is more similar to +fuzzing in ClusterFuzz than Code Review Fuzzing. Batch Fuzzing allows +ClusterFuzzLite to build up a corpus for each of your fuzz targets. This corpus +will be used in Code Coverage Reporting as well as Code Review Fuzzing. + +### Corpus Prune + +If multiple Batch Fuzzing tasks are run concurrently then we strongly recommend +running a pruning task as well. This task is run according to some set schedule +(once a day is probably sufficient) to prune the corpus of redundant testcases, +which can happen if multiple Batch Fuzzing jobs are done concurrently. + +### Code Coverage Report + +The last task ClusterFuzzLite offers is Code Coverage Reports. This task will +run your fuzzers on the corpus developed during Batch Fuzzing and will generate +an HTML report that shows you which part of your code is covered by batch +fuzzing. + +## Configuration Options + +Below are some configuration options that you can set when running +ClusterFuzzLite. +We will explain how to set these in each of the subguides. + +`language`: (optional) The language your target program is written in. Defaults +to `c++`. This should be the same as the value you set in `project.yaml`. See +[this explanation]({{ site.baseurl }}//getting-started/new-project-guide/#language) +for more details. + +`fuzz-time`: Determines how long ClusterFuzzLite spends fuzzing your project in +seconds. The default is 600 seconds. + +`sanitizer`: Determines a sanitizer to build and run fuzz targets with. The +choices are `'address'`, and `'undefined'`. The default is `'address'`. + +`task`: The task for ClusterFuzzLite to execute. `code-review` +by default. See [ClusterFuzzLite Tasks] for more details on how to run different +tasks. +TODO(metzman): change run_fuzzers_mode to this. + +`dry-run`: Determines if ClusterFuzzLite surfaces bugs/crashes. The default +value is `false`. When set to `true`, ClusterFuzzLite will never report a +failure even if it finds a crash in your project. This requires the user to +manually check the logs for detected bugs. + +TODO(metzman): We probably want a TOC on this page for subguides.