winafl icon indicating copy to clipboard operation
winafl copied to clipboard

Why maximum possible threads is 64?

Open expend20 opened this issue 4 years ago • 4 comments

Hi @ifratric !

Let me ask about bottlenecks related to increasing the number of threads. I can see this implicit limit to 64 threads:

  /* Currently winafl doesn't support more than 64 cores */
  if (cpu_core_count > 64) {
    SAYF("\n" cLRD "[-] " cRST
    "Uh-oh, looks like you have %u CPU cores on your system\n"
    "    winafl doesn't support more than 64 cores at the momement\n"
    "    you can set AFL_NO_AFFINITY and try again.\n",
    cpu_core_count);
    FATAL("Too many cpus for automatic binding");
  }

But there is an option to disable thread binding at all. On the other hand I saw that with increasing of threads overall speed of fuzzers increases poorly. What do you think about scaling to big number of threads in general, is there any common pitfals?

PS: I realize that the speed and particular answer might heavily depends on the harness, but I'm asking in general about WinAFL

Thanks!

expend20 avatar May 09 '20 09:05 expend20

Are there any benefits from binding threads to CPUs if you can't leverage -thread_coverage option? I.e. coverage hit thread is not the same as harness thread.

expend20 avatar May 09 '20 10:05 expend20

Adding @yoava333 who added the process affinity support in https://github.com/googleprojectzero/winafl/pull/92. He's probably a better person to answer questions about cpu_core_count.

As for your second question, AFAIK thread_coverage and process affinity are mostly unrelated - thread_coverage only controls which thread you get coverage from, and doesn't really affect how the process/threads run.

ifratric avatar May 12 '20 08:05 ifratric

Hi @expend20 , thread_coverage is not related to cpu affinity. The idea behind affinity it to tie a fuzzer process to a specific CPU, this results in a nice performance boost (10-20%). The API for supporting affinity for more than 64 CPU is a bit more complicated and I didn't think it was required back then. I would love to see a PR for supporting more CPUs or one that adds a switch for not using the affinity behavior at all.

yoava333 avatar May 12 '20 13:05 yoava333

or one that adds a switch for not using the affinity behavior at all

It's already possible via AFL_NO_AFFINITY=1 environment variable. Thanks guys!

expend20 avatar May 12 '20 14:05 expend20