Jazzer brings modern fuzz testing to the JVM(blog.code-intelligence.com) |
Jazzer brings modern fuzz testing to the JVM(blog.code-intelligence.com) |
We also have a blogpost that talks about the most interesting technical aspects of Jazzer: https://blog.code-intelligence.com/engineering-jazzer
Additionally, Jazzer provides a hooking framework that can be used to implement domain-specific sanitizers for logic bugs. See https://blog.code-intelligence.com/engineering-jazzer#user-c... for an example. Part of the reason for open-sourcing Jazzer has been to get the discussion started on what kind of "sanitizers" are needed to unlock the full potential of Java fuzzing.
> The trampoline first pushes an address pointing to the addr & 0xFFF-th entry in a "sled" of 0xFFF=4096 ASM ret instructions to the (native) stack and then performs a direct jump (also called a "tail call") to the sanitizer callback.
0xFFF=4095 ;)
This project seems to do just that by calling __sanitizer_cov_trace_cmp4. In retrospect, this seems like the obvious solution, and quite brilliant of this project to do that!
In fuzz testing, the mutations are seeded into the inputs. Depending on the fuzzing approach, those might be seeded from random, patterns, application behavior, etc. Jazzer is based on libFuzzer, meaning that it's feedback-loop is based on which coverage metrics are reported during run-time.
Integrating important JVM projects is work in progress ;-)
Openjdk 16 has https://openjdk.java.net/jeps/389 But it's not obvious if it improve performance
https://blog.code-intelligence.com/the-magic-behind-feedback...
Our coverage instrumentation does not rely on JNI calls, only the libFuzzer callbacks do, so the overhead shouldn't be too substantial. It's certainly not a proper benchmark, but one core on my laptop can fuzz the more non-trivial examples at around 10,000 exec/s. We are also working on some further performance improvements.