3 ms·

I don't think that would be that efficient of a use of computing resources. Each instance explores the same instruction space. It keeps track of where it's expl

by dalke 12y ago

I don't think that would be that efficient of a use of computing resources. Each instance explores the same instruction space. It keeps track of where it's explored, and uses various techniques to explore different parts of space. It's very likely that multiple instances, if run in parallel and with no data sharing, will explore a lot of the same space. Also, making a public cluster would be a security challenge. It runs arbitrary C/C++ code, and can trigger code paths that the developers didn't even realize. How would your box stand up to multiple grabs of 4GB of memory?

hueving 12y ago
Don't have instances explore the same programs starting from the same state. Have state reported back in intervals so other workers can be scheduled to resume the work if that one goes down. Security would be an issue. A VM would probably be a hard requirement. That can bound the memory usage, hardware calls, etc.
- 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 ago
    As 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 ago
    afl-fuzz can be parallelized fairly easily. The exchanged data amounts to newly-discovered, interesting inputs that then seed the subsequent fuzzing work.
    - dalke 12y ago
      Great 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.

by dalke 12y ago

hueving 12y ago

Don't have instances explore the same programs starting from the same state. Have state reported back in intervals so other workers can be scheduled to resume the work if that one goes down. Security would be an issue. A VM would probably be a hard requirement. That can bound the memory usage, hardware calls, etc.

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 ago
  As 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 ago
  afl-fuzz can be parallelized fairly easily. The exchanged data amounts to newly-discovered, interesting inputs that then seed the subsequent fuzzing work.
  - dalke 12y ago
    Great 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.