| Age | Commit message (Collapse) | Author |
|---|
|
If we do not shade JaCoCo internally but only when preparing the agent
deploy jar, Jazzer tests themselves can't be instrumented with JaCoCo as
our patched version is incompatible with the one used by coverage tools.
|
|
|
|
The toolchain is only enabled in the CI by default as users should use
the same compiler toolchain for compiling the Jazzer driver as they use
to compile their JNI libraries. However, if they are only interested in
fuzzing pure Java libraries, they can pass --config=ci on the CLI to use
the toolchain, which greatly simplifies the build on macOS.
A significant complication arises because the ASan runtime library can't
be linked statically on macOS. To make the tests pass, it needs to be
exported from the toolchain and the driver has to conditionally depend
on it explicitly.
A further patch to the toolchain is required to ensure compatibility
with Ubuntu 21.04.
|
|
Also moves the quote command args patch upstream.
|
|
libFuzzer does not quote the arguments it passes to child processes during merge
and fork, which leads to arguments being lost if passing multiple jvm_args with
delimiter ';'.
This commit adds a libFuzzer patch that properly quotes all arguments as well as
a test that fails if quoting is not appropriate.
|
|
The new --coverage_report option triggers a coverage report to be
written on fuzzer exit.
The report is generated with the JaCoCo analyzer. The information about
observed coverage IDs is obtained from libFuzzer and combined with the
coverage obtained during fuzzerInitialize as well as the current run.
|
|
|
|
These have been integrated into the fork.
|
|
The JVM frequently calls strcmp/memcmp/..., which fills up the table of
recent compares with entries that are either duplicates of values
already reported by the bytecode instrumentation or JDK-internal strings
that are not relevant for fuzzing.
This commit adds an ignorelist to the C stdlib interceptors that filters
out calls from known JVM libraries. If the fuzz target has not yet
loaded a native library, all such callbacks are ignored, which greatly
improves fuzzer performance for string-heavy targets. E.g.,
JsonSanitizerDenylistFuzzer takes < 1 million runs now when it used to
take over 3 million.
|
|
|
|
Building libFuzzer from source is easy and has multiple advantages:
* The clang distributed with XCode on macOS does not include libFuzzer.
* Applying a small patch to libFuzzer will allow us to replace the
--wrap linker feature, which is not supported on platforms other than
Linux.
|
|
This reverts commit 71ac55c6fc9d808bcc8a8e8d895f7f20141bec86.
|
|
* Replace uses of quick_exit and at_quick_exit
quick_exit is not supported on macOS, but can easily replaced by a call
to _Exit after running our cleanup manually.
* Run buildifier --lint=fix -r .
* Build libFuzzer from source
Building libFuzzer from source is easy and has multiple advantages:
* The clang distributed with XCode on macOS does not include libFuzzer.
* Applying a small patch to libFuzzer will allow us to replace the
--wrap linker feature, which is not supported on platforms other than
Linux.
* Replace -Wl,--wrap with a source code patch
* Pin non-native rules_python
* Print exit code on test failure
* Do not intercept JVM-internal C stdlib calls
The JVM frequently calls strcmp/memcmp/..., which fills up the table of
recent compares with entries that are either duplicates of values
already reported by the bytecode instrumentation or JDK-internal strings
that are not relevant for fuzzing.
This commit adds an ignorelist to the C stdlib interceptors that filters
out calls from known JVM libraries. If the fuzz target has not yet
loaded a native library, all such callbacks are ignored, which greatly
improves fuzzer performance for string-heavy targets. E.g.,
JsonSanitizerDenylistFuzzer takes < 1 million runs now when it used to
take over 3 million.
|
|
We are currently deriving edge coverage instrumentation from basic block
instrumentation via the AFL XOR-technique. This has several downsides:
* Different edges can be assigned the same position in the coverage map,
which leads to underreported coverage.
* The coverage map needs to be large enough for collisions to be
unlikely (on the order of num_edges^2). In addition to being wasteful,
it is also hard to determine the correct size given that we don't know
the number of edges.
In addition to the design limitations, the current implementation
additionally does not take into account that most Java method
invocations can throw exceptions and thus need to be instrumented.
These issues are resolved by switching to true LLVM-style edge coverage
instrumentation. The new coverage instrumentation is based on a lightly
patched version of the JaCoCo internals.
Note:
//agent/src/test/java/com/code_intelligence/jazzer/instrumentor:coverage_instrumentation_test
is not passing for this commit. It will be fixed with the next commit.
|
|
|
