3 ms·
Even starting from different states doesn't help, because afl uses semi-random search techniques. It's very likely that different start locations will still hav
by dalke 12y ago
Even starting from different states doesn't help, because afl uses semi-random search techniques. It's very likely that different start locations will still have a large overlap.
Nor is it obvious that state reporting is useful. I ran afl for about 4 days. It ran my test code about 1,000 times per second, for a total of nearly 1/2 billion test cases.
That's a lot of data exchange for each program to report and resynchronize.
I'm not saying it's impossible. I'm suggesting that it's likely not worthwhile. It would be better to support multiprocessing first, before looking towards distributed computing.
- Houshalter 12y agoAs I understand it, it works by exploring different codepaths. So you just assign each computer to work on one seed file or codepath. Each as different as possible covering the largest area possible. After awhile then decide what paths are the most interesting to explore and reassign.
- f- 12y agoafl-fuzz can be parallelized fairly easily. The exchanged data amounts to newly-discovered, interesting inputs that then seed the subsequent fuzzing work.
- dalke 12y agoGreat work with afl. I tried it out last week, and found two segfaults and a stack smash detection in one program. I tried it on another program, only to have gcc crash with an internal error. :( By parallelized, do you mean on the same machine or across a distributed cluster? If they only share the same set of interesting inputs, won't the different nodes also end up searching much of the same space? .... Hmm, no I see how I could be wrong. With interesting seeds, boring space is easy to re-identify, so there's a trivial amount of duplicate work, and the rest is spent just trying to find something new and interesting.