| Age | Commit message (Collapse) | Author |
|---|
|
Regular Bazel tests now verify that there are no ktlint findings and
`./format.sh` only formats those files that need fixing. This speeds up
format script runs.
|
|
While these linking flags are no-ops for shared libraries on Linux, on
macOS without the deprecated `-undefined dynamic_lookup` flag symbols are
missing without it.
|
|
|
|
|
|
If a corpus file is not exactly consumed by the mutator a warning is
displayed during a fuzzing run.
|
|
Use the experimental mutator framework in JUnit tests if mutators for
all test parameters can be created and the experimental mutator flag is
set.
|
|
|
|
|
|
Autofuzz did not use the current test instance to invoke the test
function, rather it created it's own ones. This conflicts with other
junit plugins which manipulate the current test instance, e.g. inject
objects or execute other setup code.
|
|
Add a test that verifies that crash files are created in the base
directory in case no test resource directory is present.
|
|
The transitive dependency on org.junit.platform:junit-platform-launcher
removes the requirement to specify it manually in every project.
|
|
No distinction of the invocation type is required anymore. Fuzz tests
invoked via the CLI should behave the same as if they were invoked in
JUnit tests.
|
|
As instrumenting Mockito can cause instrumentation cycles it's now
ignored. Instrumenting Byte Buddy itself could cause similar issues,
hence, it's now ignored as well.
Lastly, the whole JUnit package is ignored due to other sub-packages
that could distract the fuzzer and slow down startup.
|
|
|
|
We also report a security issue when calling any inherited method.
Reporting a finding in a static block makes jaz.Zer unsuitable for
the regression test mode with JUnit. When performing regression
tests, jaz.Zer will be loaded only once for all the test cases. Having
the reporting logic only in a static block results in all other tests
using jaz.Zer either failing since the class could not be initialized,
or passing if jaz.Zer is disabled by the first test loading it.
|
|
The new runner uses the JUnit launcher API to run `@FuzzTest`s using
JUnit, which provides support for Jupiter extensions even when running
these tests from the command line.
The new runner renders the `@FuzzTest` logic in `FuzzTargetFinder`
obsolete. This commit removes it.
|
|
The `args` on the tests were ignored and are thus replaced with
`fuzzer_args`.
Instrumentation includes are added since the tests depend on unshaded
Jazzer third-party classes which should not be instrumented.
|
|
These tests reproducibly fail on Windows due to high memory usage.
|
|
This ensures compatibility with non-trivial test class constructors and
test instance post processing, which is common with mocking frameworks
such as Mockito.
|
|
|
|
Kotlin's integral types have `compareTo` methods that are compiled to
calls into one of two `compare` overloads from the
`kotlin.jvm.internal.Intrinsics` class:
1. `public static int compare(long thisVal, long anotherVal)`
2. `public static int compare(int thisVal, int anotherVal)`
|
|
This makes it possible to run fuzz tests alongside unit tests without
having the instrumentation applied by the agent interfere with unit
tests, e.g. by throwing unexpected exceptions.
|
|
|
|
|
|
Instead of implementing fuzzing runs as a custom JUnit test engine, this
commit implements it within the JUnit Jupiter platform instead.
The main benefit of this approach is the full and effortless
interoperability with lifecycle hooks such as `@BeforeAll` and
`@AfterAll`. The new implementation is also significantly shorter and
automatically avoids inconsistencies such as
https://github.com/CodeIntelligenceTesting/jazzer/issues/539 and
https://github.com/CodeIntelligenceTesting/jazzer/issues/543.
The new implementation models fuzzing as a single invocation of the
`@ParameterizedTest` used for the regression test with fake arguments
named `Fuzzing...`. The registered `InvocationInterceptor` is then used
to replace the invocation with the actual fuzzing run.
In this way, `@FuzzTest` methods invoke `@BeforeEach` hooks once before
fuzzing starts. Having the invocation represented as a single invocation
parametrized test should make this behavior less surprising.
Fixes #543
|
|
|
|
The "driver" and the "agent" used to be separate components of Jazzer
that were written in different languages (C++ and Java), but this is no
longer the case: They are now mostly implemented in Java and deployed as
a single jar. The natural separation into Java packages rather than
top-level directories fits this architecture better.
This commit has been produced by moving the directory contents,
replacing `//(agent|driver)/` with `//`, running `buildifier -r .` and
manually editing non-BUILD occurences (e.g. .bazelrc, format.sh as well
as runfiles paths).
|
|
The test frequently timed out and generally took a long time to
complete. Leaking larger chunks led to crashes in the native
instrumentation agent.
Instead, we now allocate a huge (~16 GB) array, which should fail
instantly.
|
|
|
|
|
|
The `deploy_env` attribute of `java_export` silently ignores
`java_binary` targets. Instead, `java_library` targets have to be
supplied to this attribute.
|
|
`java_export` targets build deploy jars that bundle all implicit
dependencies. Since `java_binary`'s `deploy_env` attribute excludes
entire Bazel targets rather than individual classes, this doesn't work
if only intend to bundle parts of `java_export` target - in this case,
the fuzz target API but not the hook API.
Instead, we revert the main `api` target an ordinary `java_library` and
verify correct contents right on the jar we deploy to Maven.
|
|
|
|
|
|
|
|
|
|
|
|
Now that we no longer link sanitizers statically, we no longer get weird
warnings without lld and thus don't have to force using it.
|
|
Fuzzing native libraries with ASan and UBSan using the Java driver is
made possible by the generated launcher script, which this commit
uses to preload the Jazzer hooks and native sanitizer runtime libraries
into a JVM running Jazzer started as a subprocess.
Since the sanitizer instrumentation applied at compile time and the
runtime libraries must be kept in sync, the preload approach allows
users to fuzz native libraries without building the Jazzer launcher from
source for the first time. Jazzer will automatically pick the libraries
corresponding to `CC` (if set) or `clang` in `PATH`.
While the existing native_fuzzer_hooks.c can be reused almost unchanged
for this purpose on Linux, macOS requires mimicking the interposing
logic used by ASan to hook libc funtions at runtime. This commit
extracts these platform-specific hooking techniques into preprocessor
macros.
Further complications arise because macOS codesigning prevents library
insertion into `/bin/sh` via `DYLD_INSERT_LIBRARIES` and generally
requires all libraries to be preloaded into the `java` process to be
codesigned - users may have to click through Gatekeeper warnings to
allow this. This requires removing the signatures in CI, where we can't
simulate these clicks.
Tests fail on macOS 11 for unclear reasons, so we raise the minimum
version to 12, which hase been out for almost a year by now. They also
fail with JDK 8, which can't be reproduced locally - these tests are
skipped in CI.
|
|
|
|
|
|
The new name doesn't use fuzzing terminology and is more fitting now
that we also write crashing inputs into this directory.
|
|
It is not clear that the default seed corpus location needs to be
overridden - we should stick to conventions for as long as possible.
|
|
|
|
|
|
Speculative fix for flaky macOS runs of this test.
|
|
Before this commit:
```
//driver/src/test/java/com/code_intelligence/jazzer/junit:AutofuzzTest_fuzzing FLAKY, failed in 3 out of 10 in 301.8s
Stats over 10 runs: max = 301.8s, min = 26.4s, avg = 124.0s, dev = 118.9s
```
After this commit:
```
//driver/src/test/java/com/code_intelligence/jazzer/junit:AutofuzzTest_fuzzing PASSED in 82.4s
Stats over 20 runs: max = 82.4s, min = 14.3s, avg = 32.6s, dev = 14.5s
```
|
|
|
|
New logic in the FuzzTargetTestWrapper verifies that:
1. stack traces correspond to findings;
2. stack traces contain no frames for Jazzer-internal classes.
This makes it possible to verify that findings are produced as expected
even in cases where the reproducer doesn't reproduce the finding (e.g.,
because it comes from a hook). This caught the issue with UBSan fuzzing
fixed in a previous commit.
|
|
|
