How to multicore by dom about libafl-legacy HOT 7 CLOSED

in fuzzing it is pretty normal that every fuzzer fuzzes the whole queue. this makes especially sense as you would want the fuzzers to be different. different in how they weight a queue entry, different in their mutation, different in the depth of their mutations, only 1 or few doing cmplog, etc.

so IMHO the in_use is not helping fuzzing and rather slows it down.

having a central everything means locks, locks locks. not only queue but also dictionary, statistics, etc.

from libafl-legacy.

The dictionary and everything else would not need to be shared, just the queue.
Everything else is independent. Each fuzzer could have a small stats section that can be read by main (in fuzzers[fuzzer_id])

from libafl-legacy.

why does the queue need to be shared?
I mean sure it can - but what are the advantages to to have it shared in the first place? I dont see it yet. but I am coming from the other side ... so explain please would you find better with that.

from libafl-legacy.

Mainly due to KISS.

• if a queue entry changes its content, for example during trim, we have single source of truth.
• we can have proper stats at any time
• I wouldn't have guessed the overhead was too high (only maybe in the first few minutes where there might be more new queue entires, don't really care about this)

from libafl-legacy.

Oh, and the current concept of libafl++ has multiple queues (feedback specific queue, ...) which would complicate matters further.

from libafl-legacy.

Mainly due to KISS.
* if a queue entry changes its content, for example during trim, we have single source of truth.

IMHO there is no single truth. a queue entry is uninteresting to one fuzzer, but interesting to another. one will want to trim everything as best as possible, another would not want any trimming.

that is not really a difference between the approaches. but it reflects in what I called "independant" in andrea's issue.
IMHO a fuzzer should work on his own and use whatever from the other fuzzer that it wants.
a central queue is a big equalizer where everything is more mush :)

* we can have proper stats at any time

Its more to read in one place vs. shorter reads in more places. I agree it is less work to do stats.

* I wouldn't have guessed the overhead was too high (only maybe in the first few minutes where there might be more new queue entires, don't really care about this)

if you have many fuzzers - and that is what the overall goal is, otherwise what we have with afl++ is fine, it can handle 32-48 cores for a target - then there will be finds often.
a central queue does not scale.
I did a week look fuzzing campaign for example. most fuzzers in the campaign were rarely finding anything after the first 18 hours, but e.g. the laf instances (I had 2) were constantly finding new things until the end. and that were just 20 cores. now how should that be for 100-200 cores.
if you have 100 cores and one seed there will be very little progress and a slooow start because everyone fuzzes the same thing, finds lots of paths, and is fighting and waiting to get a lock.

But: it has more appeal to me than the messaging where a central point is a telegram service.

from libafl-legacy.

Closing this for now as the central queue didn't spark too much joy

from libafl-legacy.