| Age | Commit message (Collapse) | Author |
|---|
|
An instance of FuzzedDataProviderImpl can now be one of the following:
* backed by an automatically created native copy of a Java array that is
freed by `close()`;
* backed by a preexisting native array whose lifetime is managed
elsewhere.
All instances now maintain their own internal, non-global state and can
thus be used concurrently.
|
|
Checking the bounds in Java allows for better error messages and we
reduce the binary size of the driver JNI library by almost 200 kiB.
|
|
Two `LOG(ERROR)` usages are converted to ordinary prints, one
`LOG(INFO)` usage is dropped without replacement since the
`JAVA_FUZZER_CLASSPATH` variable isn't even documented.
|
|
With most of the driver rewritten in Java, we were barely using any
C++14/17 features anymore. By reverting to C++11, we get better
compatibility for our upcoming Maven version of Jazzer and a simplified
build structure by no longer having to transition our cc_library
targets.
|
|
|
|
For the case of Java-only fuzzing, which only requires the JNI shared
library and no driver binary, this change is a pure refactoring.
Fuzzing native libraries requires some structural changes since loading
libFuzzer from a shared library has implications on the behavior of the
dynamic linker:
1. __sanitizer_set_death_callback now has to be looked up via dlsym
since it isn't contained in the same object as libFuzzer itself
anymore.
2. All sanitizer hooks and libc functions to hook have to be defined in
the driver executable. They delegate to the real hooks defined in the
shared library as soon as it has been loaded.
|
|
|
|
This ensures that the fuzz target is found even if Driver is loaded by
a custom class loader.
|
|
Makes `--keep_going` a proper uint64 flag as it was before the Java
rewrite and ensures that the default value defined in Java is honored.
|
|
With -Xmx512m, the ExampleOutOfMemoryFuzzer ran into this failure on
macOS:
==19173== ERROR: libFuzzer: out-of-memory (used: 961Mb; limit: 911Mb)
|
|
The reduce function was misused - prev was always the first CLI
argument, not an empty Optional.
|
|
The condition was inverted.
|
|
This is necessary for a pure Java driver as we can no longer set -Xmx in
that situation. It is also much cleaner than hand-tuning -Xmx, but we
still keep the max heap size in the native driver for backwards
compatibility with existing crashing inputs.
|
|
|
|
|
|
Ensures that Ctrl+C works even with `--nohooks`.
|
|
Centralizes all options parsing in Opt.
|
|
|
|
This functionality is needed to launch Jazzer in an already running JVM.
|
|
|
|
|
|
This makes runtime a java_library, which compiles much faster than a
kt_jvm_library.
|
|
We are already patching libFuzzer anyway and will continue to do so for
the foreseeable future. Thus, we might as well get rid of the highly
complex and architecture-dependent trampoline hack.
|
|
In the newest version, libFuzzer no longer exits when no coverage is
attained during the first two executions, so replaying coverage is no
longer needed. According to the newly added test, replaying the coverage
actually wasn't effective.
|
|
We never deleted the local reference to the byte[] array passed to the
fuzz target.
|
|
|
|
This commit gets rid of the last dependency between the native driver
and the (future) JNI shared library.
|
|
One logging call is turned unconditional, the other one is removed as it
seems rarely useful - the feature is best-effort anyway.
|
|
Achieved by inlining the flags into jvm_tooling, which is the only
remaining consumer of these flags.
|
|
Inline the remaining single constant into jvm_tooling.cpp.
|
|
By using LLVMFuzzerRunDriver, we can remove the LibfuzzerDriver class
and replace it by:
* a real main function that preprocesses arguments for libFuzzer and
starts a JVM;
* everything else turned into a proper library with no dependency on our
custom JVM class.
This will allow us to turn everything except the main function into a
JNI shared library, opening up the possibility to launch Jazzer from an
already running JVM.
|
|
The chunking logic is moved out of FuzzTargetRunner and
ReproducerTemplate becomes a proper instantiable class that collects the
fixed information required to produce Java reproducers.
|
|
|
|
This decouples jvm_tooling from libfuzzer_callbacks.
|
|
Test uses of JVM methods have been replaced with the equivalent standard
JNI function.
|
|
|
|
Simplifies the replayer and allows us to Javaify the FuzzedDataProvider
test.
|
|
This is mostly a faithful Java rewrite of the original native code,
with a few changes believed not to cause any serious backwards
compatibility concerns:
* Emit an empty line to stderr rather than stdout before the Java
exception. DEDUP_TOKEN does not have to appear at the beginning of a
line to be picked up by libFuzzer, so this seems more consistent.
* Simplify the logic around dedup tokens to also emit them with hooks
set to false, but not by default.
* Do not emit the escape character when splitting a list-valued argument
on a separator - this appeared to be a design bug.
* Use the same "split on unescaped separator" function for all
splitting.
The native tests have been replaced by a single comprehensive Java test.
|
|
|
|
|
|
The new argument can be used to selectively disable both custom and and
built-in hooks.
Also mentions the OS-dependent separator in agent flag descriptions.
|
|
We no longer use dlsym in the driver and thus don't have to link with
-ldl.
|
|
Coverage reports can be generated via:
bazel run //bazel/coverage
Due to https://github.com/bazelbuild/bazel/pull/15166, coverage
collection does not yet encompass tests that end with a native sanitizer
report.
Temporarily updates .bazelversion to an unreleased version of Bazel that
includes required coverage fixes.
|
|
|
|
We need to delete each local reference created in native code separately
to prevent memory leaks, even if they refer to the same Java object.
|
|
|
|
Otherwise this finding will stick around and cause dedup token
computation for every subsequent run, even if that run would otherwise
produce no finding.
|
|
The honeypot class jaz.Zer is needed to successfully execute reproducers
of deserialization issues. It's moved to the API artifact to be
available on the classpath.
Furthermore, reproducers not necessarily reproduce the found issue,
e.g. due to global state that leads to different behavior. To take that
into account the reproducer check is relaxed.
|
|
|
|
|
