Very low exec speed under afl-fuzz, very fast without

[lukas...@gmail.com]

Hi,

I've a ELF-target that takes close to zero execution time when run by itself (even when instrumented) but executes at 10-20 rounds per second under afl-fuzz. Could someone guide me on how to resolve this situation?

Best regards

Lukas

[Michal Zalewski]

> I've a ELF-target that takes close to zero execution time when run by itself
> (even when instrumented) but executes at 10-20 rounds per second under
> afl-fuzz. Could someone guide me on how to resolve this situation?

My best guess is that your initial corpus contains some that are very
large or very slow to process. You can probably find the offending
cases by running afl-fuzz with -t 20 or so, and then seeing which test
case exceeds this limit.

Beyond that, have you looked at docs/perf_tips.txt?

/mz

[lukas...@gmail.com]

In fact the original testcase is around 60kb in size. I may reduce this to 50kb but not much smaller.

[Michal Zalewski]

> In fact the original testcase is around 60kb in size. I may reduce this to
> 50kb but not much smaller.

Well, if that's what's making the fuzzer slow and you honestly can't
scale down (which seems surprising!), then your best bet is probably
just living with that and parellelizing the jobs.

The llvm_mode/ compiler wrapper may generate code that will be
somewhat faster, but it won't be a striking difference.

/mz

[Lukas Lueg]

The primary problem is in fact writing the candidate files. I've moved
the findings-directory to a ramdisk, which boosted execution speed
from ~20 executions per second per core to ~400 to ~500 executions per
second per core.

> --
> You received this message because you are subscribed to a topic in the Google Groups "afl-users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/afl-users/aQvlwkLxNRA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to afl-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Michal Zalewski]

> The primary problem is in fact writing the candidate files. I've moved
> the findings-directory to a ramdisk, which boosted execution speed
> from ~20 executions per second per core to ~400 to ~500 executions per
> second per core.

This seems extremely odd; what OS and filesystem are you using? Any
specific mount flags or other customizations?

/mz

[Lukas Lueg]

The fs is ext4 mounted as rw,seclabel,relatime,data=ordered on a
LUKS-encrypted, to-SSD-lvm-cached HDD

[Michal Zalewski]

> The fs is ext4 mounted as rw,seclabel,relatime,data=ordered on a
> LUKS-encrypted, to-SSD-lvm-cached HDD

Them I'm not sure what's up, but I'd suggest benchmarking the fs or
having a closer look at the way the fuzzed tool reads and writes the
data (perhaps it calls fsync() or so?).

AFL doesn't do anything that would explain writing 60 kB to a fast,
cached filesystem resulting in an order-of-magnitude drop in
performance.

/mz

[Sami Liedes]

On Sat, Apr 18, 2015 at 09:03:54PM +0200, Lukas Lueg wrote:
> The primary problem is in fact writing the candidate files. I've moved
> the findings-directory to a ramdisk, which boosted execution speed
> from ~20 executions per second per core to ~400 to ~500 executions per
> second per core.

It also depends on what your target does to the files. I've seen a
speedup of this magnitude happen with e2fsck when the candidate is
written to tmpfs (both with afl-fuzz and other fuzzers). e2fsck does a
lot of seeking and rewriting, and generally requires big inputs.

Sami