| Age | Commit message (Collapse) | Author |
|---|
|
Sort direct dependencies before transitive ones.
|
|
|
|
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.
|
|
@libjpeg_turbo can again be built with rules_foreign_cc master.
|
|
|
|
|
|
The fork at
https://github.com/CodeIntelligenceTesting/llvm-project-jazzer
is a clearer way to manage our patches to libFuzzer.
|
|
|
|
Fuzz targets may use the ASM libraries or JaCoCo themselves, which
can lead to dependency version conflicts.
To counter this, we shade all our external dependencies into the
com.code_intelligence.jazzer.third_party.* package using bazel_jar_jar
when we build the instrumentor library.
The seemingly simpler approach of applying jar shading directly to the
jazzer_agent_deploy.jar does not work as jarjar is unable to handle
some of the Kotlin runtime files in the resulting jar.
|
|
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.
|
|
|
|
The uploaded jar previously did not contain any class files and lacked
required POM fields.
|
|
|
|
* Update dependencies
* Fail if changed Maven deps are not repinned
* Extract ASM API version into Instrumentor
|
|
Google's Maven repository does not offer most of our dependencies, which
makes Bazel print quite a few warnings while downloading.
|
|
|
