-
-
Notifications
You must be signed in to change notification settings - Fork 320
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
inprocessfork executor #237
Conversation
I had to change __sanitizer_cov_trace_pc_guard a bit to make it use a pointer instead of a static array, is this ok?
) |
Anyway, looks good to me, thanks! :) @andreafioraldi any objections? |
dunno, i'm sick today |
now we check if the EDGES_MAP_PTR is null, and if so we set EDGES_MAP in libfuzzer_initialize() |
No, edge coverage can be used even when there is no need to use the libfuzzer compatibility layer |
IMO, here the solution is to use a feature flag in libafl_targets. in-process fuzzing does not need the double dereference of EDGES_PTR, it is just wasted cpu time. Do not use libfuzzer_initialize but instead lazy_static (assuming that we need std for our inprocessfork feature flag, that we does because of fork()) |
Can't we just initialize the value when creating the Observer for the first time? |
No, because a MapObserver is independent from that. We can use __sanitizer_cov_trace_pc_guard_init |
yes I can use __sanitizer_cov_trace_pc_guard_init instead of libfuzzer_initialize |
Should we add a |
sure :> |
Don't think that's really needed, unless we find bugs :D |
then I'll leave pre/post_fork as they are |
* inprocessfork executor * fmt * cfg * no_std * no volatile rw * wrapping_add * fix * mutable pointer * ptr initialization in __sanitizer_cov_trace_pc_guard_init * features * more cfg * fmt * fix * fmt * post_fork * fmt * pre_fork * test * cfg
#82