C-lightning currently supports coverage-guided fuzz testing using LLVM's libfuzzer
when built with
The goal of fuzzing is to generate mutated -and often unexpected- inputs (
seeds) to pass
to (parts of) a program (
target) in order to make sure the codepaths used:
- do not crash
- are valid (if combined with sanitizers)
The generated seeds can be stored and form a
corpus, which we try to optimise (don't
store two seeds that lead to the same codepath).
Build the fuzz targets
In order to build the C-lightning binaries with code coverage you will need a recent clang. The more recent the compiler version the better.
Then you'll need to enable support at configuration time. You likely want to enable a few sanitizers for bug detections as well as experimental features for an extended coverage (not required though).
The targets will be built in
Run one or more target(s)
You can run each target independently. Pass
-help=1 to see available options, for
Otherwise, you can use the Python runner to either run the targets against a given seed corpus:
The latter will run all targets two by two
If you want to contribute new seeds, be sure to merge your corpus with the main one:
Write new fuzzing targets
In order to write a new target:
- include the
- fill two functions:
init() for static stuff and
run() which will be called
repeatedly with mutated data.
- read about what makes a good fuzz target.
A simple example is
fuzz-addr. It setups the
chainparams and context (wally, tmpctx, ..) in
bruteforces the bech32 encoder in