-
-
Notifications
You must be signed in to change notification settings - Fork 324
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Full libfuzzer shimming (for cargo-fuzz libfuzzer alternative and other use cases) #981
Conversation
LibAFL/fuzzers/libafl_atheris/src/lib.rs Line 107 in d2985c5
Can we add support for the run FN and replace most of atheris, too? |
I'm unfamiliar with this aspect of the libfuzzer functionality. I'm sure we can replace it, though. |
It's a way for the target to start fuzzing at another point in time, so an own main, instead of using libfuzzer's main. We can probably move all code to this method and call this fn from a weak main |
See this issue for the run method, too |
libafl_targets/src/sancov_cmp.c
Outdated
|
||
void __sanitizer_cov_trace_pc_indir(uintptr_t Callee) { | ||
// unused | ||
// TODO implement |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reading through the documentation at https://clang.llvm.org/docs/SanitizerCoverage.html#tracing-pcs-with-guards it looks like this is pretty straight forward, we just want a portion of the coverage map for indirect branches and then map them as feedback.
Also, it looks like the function is called __sanitizer_cov_trace_pc_indirect(void *callee)
in newer compilers (or in some versions and the docs are old?) so maybe we want to export both
9887e0e
to
ddf796d
Compare
// take a page out of libfuzzer's book: static define __sancov_lowest_stack | ||
// since we don't support it yet | ||
// TODO support it | ||
MAYBE_THREAD_LOCAL uintptr_t __sancov_lowest_stack; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Support can be as easy as exposing this value to rust via an fn
- then we can build an observer that observes stack depth of a run, quasi for free
ddf796d
to
db60f2d
Compare
e9ca5b4
to
96800bf
Compare
eea1d3a
to
c6e5112
Compare
Hi, Am I holding it wrong? (Compiling to a |
Hey, thanks for giving this a go. Try building it from within libafl_libfuzzer_runtime directly instead? It sounds like what your doing should work, so if you're still having issues I can investigate with you in Discord. Also, make sure you're building with the same toolchain as your default (e.g., avoid |
Building |
072a665
to
9603940
Compare
60ed625
to
b4cc3fb
Compare
10f4099
to
e36f5a6
Compare
This is probably just an error on my part... mimalloc doesn't play well with being linked separately. |
Option<StdState<_, _, _, _>>, | ||
SimpleRestartingEventManager<_, StdState<_, _, _, _>, _>, | ||
) = match SimpleRestartingEventManager::launch(monitor, &mut shmem_provider) { | ||
// The restarting state will spawn the same process again as child, then restarted it each time it crashes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i guess if you launch the manager everytime, then the timestamp is not preserved across restarts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe fix this after merging/open an issue?
error[E0133]: call to unsafe function is unsafe and requires unsafe function or block
--> libafl/src/schedulers/probabilistic_sampling.rs:192:13
|
192 | libafl_bolts::serdeany::RegistryBuilder::register::<super::ProbabilityMetadata>();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function
|
= note: consult the function's documentation for information on how to avoid undefined behavior
error: aborting due to previous error Seems like we're close, though |
🥳 |
I ran into this. It turns out that nm behavior differs depending on your system LLVM, and that uninstalling your system LLVM fixes the issue. backtrace to the error (TIL that nm just invokes your system LLVM)
I made the grave error of having LLVM 14 installed on my machine. Uninstalling LLVM 14 fixed the issue -- libbfd instead chose the LLVMgold-15.so plugin (nope -- i have no idea where it makes this decision) which... uhhh... doesn't seem to invoke my system LLVM at all and prints the symbols successfully. |
Some symbols we are using in libafl_libfuzzer are missing in LLVM 14, so it doesn't work on llvm <= 14 |
@tokatoka I think you misunderstand. build.rs invokes
Ideally, the behavior of this crate would not depend on whether or not |
In theory i think the llvm-nm that ships with cargo's llvm-tools component should work, but it hits a different encoding error regardless of system LLVM. |
my point is even if you avoid that issue, the fuzzer wouldn't have linked using llvm 14. |
Seeing as how libfuzzer has entered maintenance mode, we should provide a full libfuzzer alternative which stays up to date with modern fuzzing standards.
To this end, this PR seeks to offer
libafl_libfuzzer
, a full drop-in replacement for libfuzzer with support for the most common flags and sancov settings. Specifically, all of the things supported by cargo-fuzz. We can provide this shim to cargo-fuzz via environmental variable in libfuzzer-sys or, in the future, an init flag in cargo-fuzz itself.We need to implement corpus merging (fairly straightforward with IndexesLenTimeMinimizingScheduler or cmin), crash minification (doable with tmin + InProcessForkExecutor), and a basic fuzzing runtime (optionally with dict support). cargo-fuzz uses many of the available sancov features, so we need some additional support for __san*cov items. As of writing, we have the following undefined references:
I'm unfamiliar with __san*cov features, so I could use some help in developing that support.
I think this would be a good addition to the 0.9 release as well.