Which Observer/Feedback Combination Should I Use for Coverage Guidance?

[riesentoaster]

I'm confused as to which combination of MapObservers and Feedbacks I should use. Is there a good overview of what the different options do/how to combine them? I have found some ways to accomplish some progress, but I feel like I might be missing something. Sorry if this is a stupid question.

I'm collecting coverage based on clang's -fsanitize-coverage=trace-pc-guard. The implementation of the two functions is a simple set or counter logic, redirected into some shared memory to get coverage back to the fuzzer:

void __sanitizer_cov_trace_pc_guard_init(uint32_t *start, uint32_t *stop)
{
  if (start == stop)
  {
    return;
  };

  guard_start = start;
  guard_stop = stop;

  memset(guard_start, 0, guard_stop - guard_start);
}

void __sanitizer_cov_trace_pc_guard(uint32_t *guard)
{
    if (!cov_shmem_init) return; // ignore coverage before initialization
    // *(guard - guard_start  cov_shmem_ptr) = 1; // set
    *(guard - guard_start  cov_shmem_ptr) += 1; // counter
}

In the fuzzer, I have a ShMem object that contains the coverage data. How do I process it?

[domenukk]

If you know the size of the map beforehand, use a ConstMapObserver if you con't, use a StdMapObserver (I think?) And then slot it into any kind of map feedback. Probably it's best to take whatever the Fuzzbench fuzzers use

[riesentoaster]

The fuzzbench example (fuzzers/inprocess/fuzzbench) uses StdMapObserver > HitcountsMapObserver with track_indices > MaxMapFeedback. I'll try that.

In general, it'd be really nice to have some more beginner-friendly documentation for the observers/feedbacks. The book doesn't go into any details and the code documentation isn't very extensive and requires a good understanding of the different options already.

[domenukk]

PRs welcome :) Hitcounts wrap a normal map observer and reduce them to buckets. It's a weird one since it consumes another observer

[riesentoaster]

PRs welcome :)

Not sure you want a PR based on my understanding :D.

This also seems related to #833, which is still a good idea imo.