diff options
Diffstat (limited to 'FUZZING.md')
| -rw-r--r-- | FUZZING.md | 47 |
1 files changed, 35 insertions, 12 deletions
@@ -13,9 +13,9 @@ CC=clang CXX=clang++ cmake -GNinja -DFUZZ=1 .. In order for the fuzz tests to link, the linker needs to find libFuzzer. This is not commonly provided and you may need to download the [Clang source code](http://llvm.org/releases/download.html) and do the following: ``` -cd llvm-3.7.0.src/lib -clang -c -g -O2 -std=c++11 Fuzzer/*.cpp -IFuzzer -ar q libFuzzer.a *.o +svn co http://llvm.org/svn/llvm-project/llvm/trunk/lib/Fuzzer +clang++ -c -g -O2 -std=c++11 Fuzzer/*.cpp -IFuzzer +ar ruv libFuzzer.a Fuzzer*.o ``` Then copy `libFuzzer.a` to the top-level of your BoringSSL source directory. @@ -23,18 +23,41 @@ Then copy `libFuzzer.a` to the top-level of your BoringSSL source directory. From the `build/` directory, you can then run the fuzzers. For example: ``` -./fuzz/cert -max_len=4000 -jobs=32 -workers=32 ../fuzz/cert_corpus/ +./fuzz/cert -max_len=3072 -jobs=32 -workers=32 ../fuzz/cert_corpus/ ``` -The `max_len` argument is often important because, without it, libFuzzer defaults to limiting all test cases to 64 bytes, which is often insufficient for the formats that we wish to fuzz. The arguments to `jobs` and `workers` should be the number of cores that you wish to dedicate to fuzzing. +The arguments to `jobs` and `workers` should be the number of cores that you wish to dedicate to fuzzing. By default, libFuzzer uses the largest test in the corpus (or 64 if empty) as the maximum test case length. The `max_len` argument overrides this. + +The recommended values of `max_len` for each test are: + +| Test | `max_len` value | +|------------|-----------------| +| `cert` | 3072 | +| `client` | 20000 | +| `pkcs8` | 2048 | +| `privkey` | 2048 | +| `server` | 4096 | +| `spki` | 1024 | +| `read_pem` | 512 | + +These were determined by rounding up the length of the largest case in the corpus. There are directories in `fuzz/` for each of the fuzzing tests which contain seed files for fuzzing. Some of the seed files were generated manually but many of them are “interesting” results generated by the fuzzing itself. (Where “interesting” means that it triggered a previously unknown path in the code.) -Here are the recommended values of `max_len` for each test. +## Minimising the corpuses + +When a large number of new seeds are available, it's a good idea to minimise the corpus so that different seeds that trigger the same code paths can be deduplicated. + +In order to minimise all the corpuses, build for fuzzing and run `./fuzz/minimise_corpuses.sh`. Note that minimisation is, oddly, often not idempotent for unknown reasons. + +## Fuzzer mode + +When `-DFUZZ=1` is passed into CMake, BoringSSL builds with `BORINGSSL_UNSAFE_FUZZER_MODE` defined. This modifies the library, particularly the TLS stack, to be more friendly to fuzzers. It will: + +* Replace `RAND_bytes` with a deterministic PRNG. Call `RAND_reset_for_fuzzing()` at the start of fuzzers which use `RAND_bytes` to reset the PRNG state. + +* Modify the TLS stack to perform all signature checks (CertificateVerify and ServerKeyExchange) and the Finished check, but always act as if the check succeeded. + +* Treat every cipher as the NULL cipher. -| Test | `max_len` value | -|-----------|-----------------| -| `privkey` | 2048 | -| `cert` | 3072 | -| `server` | 1024 | -| `client` | 4096 | +This is to prevent the fuzzer from getting stuck at a cryptographic invariant in the protocol. |