Skip to content
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

improve cargo fuzz compat and bump to newer libAFL version #7

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

f0rki
Copy link

@f0rki f0rki commented May 4, 2023

  • use the same paths for corpus/crashes as cargo fuzz => this should allow mixing cargo fuzz and cargo libafl, i.e. use with a shared corpus.
  • feature-guard the tui away and instead use env_logger by default. seemed more reasonable to me. maybe the default should be the other way around. let me know.
  • bumped libAFL version, which breaks sancov 8bit inline counters for some reason. As a workaround I feature-guarded 8bit inline counters and instead use pcguard by default.

Any ideas why the sancov 8bit inline counters do not work anymore? it seems no feedback is observed.

Michael Rodler added 3 commits May 4, 2023 12:16
* bumped libAFL version, which breaks sancov 8bit inline counters for
  some reason. => feature-guarded 8bit inline counters and use pcguard instead.
* use the same paths for corpus/crashes as cargo fuzz => this should
  allow mixing `cargo fuzz` and `cargo libafl`.
* feature-guard the Tui away and instead use `env_logger` by default.
@tokatoka
Copy link
Member

Any ideas why the sancov 8bit inline counters do not work anymore? it seems no feedback is observed.

I used an fuzzer from libafl repo, sancov_8bit itself is working for me there

#[cfg(feature = "sancov_8bit")]
let edges_observer = {
let edges = unsafe { &mut COUNTERS_MAPS };
// TODO: is the call to edges.clone here the reason for breaking sancov_8bit?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes
After edges.clone(), OwnedMutSlice::RefRaw becomes OwnedMutSliced::Owned.
then it does not have the reference to the original edge counter

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. It works, when I construct a new OwnedMutSlice from the raw parts of the previous one. But I still don't understand how the OwnedMutSlice is supposed to be used in this case. Rather move the OwnedMutSlice out of the COUNTER_MAPS and into the edges parameter of the MultiMapObserver?

Why doesn't the MultiMapObserver to receive a reference to the COUNTER_MAPS? Is it important that the number/size of the maps don't change while fuzzing?

instead of cloning the `COUNTER_MAPS` Vec, it is now drained into a new Vec pass to the Observer
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants