about summary refs log tree commit diff
path: root/docs/parallel_fuzzing.md
diff options
context:
space:
mode:
authorvan Hauser <vh@thc.org>2020-07-24 12:26:52 +0200
committervan Hauser <vh@thc.org>2020-07-24 12:26:52 +0200
commit9cddbc04206bd8d1399e5a5311c98fff5be80731 (patch)
tree7578d6b88d93237119e929055aac69e8b452d8be /docs/parallel_fuzzing.md
parentaa3856261d90d996a298704f1d3706ef1c6787cd (diff)
downloadafl++-9cddbc04206bd8d1399e5a5311c98fff5be80731.tar.gz
add -F option to sync to foreign fuzzer queues
Diffstat (limited to 'docs/parallel_fuzzing.md')
-rw-r--r--docs/parallel_fuzzing.md14
1 files changed, 11 insertions, 3 deletions
diff --git a/docs/parallel_fuzzing.md b/docs/parallel_fuzzing.md
index 271f8369..2ab1466c 100644
--- a/docs/parallel_fuzzing.md
+++ b/docs/parallel_fuzzing.md
@@ -99,7 +99,15 @@ example may be:
 This is not a concern if you use @@ without -f and let afl-fuzz come up with the
 file name.
 
-## 3) Multi-system parallelization
+## 3) Syncing with non-afl fuzzers or independant instances
+
+A -M main node can be told with the `-F other_fuzzer_queue_directory` option
+to sync results from other fuzzers, e.g. libfuzzer or honggfuzz.
+
+Only the specified directory will by synced into afl, not subdirectories.
+The specified directories do not need to exist yet at the start of afl.
+
+## 4) Multi-system parallelization
 
 The basic operating principle for multi-system parallelization is similar to
 the mechanism explained in section 2. The key difference is that you need to
@@ -176,7 +184,7 @@ It is *not* advisable to skip the synchronization script and run the fuzzers
 directly on a network filesystem; unexpected latency and unkillable processes
 in I/O wait state can mess things up.
 
-## 4) Remote monitoring and data collection
+## 5) Remote monitoring and data collection
 
 You can use screen, nohup, tmux, or something equivalent to run remote
 instances of afl-fuzz. If you redirect the program's output to a file, it will
@@ -200,7 +208,7 @@ Keep in mind that crashing inputs are *not* automatically propagated to the
 main instance, so you may still want to monitor for crashes fleet-wide
 from within your synchronization or health checking scripts (see afl-whatsup).
 
-## 5) Asymmetric setups
+## 6) Asymmetric setups
 
 It is perhaps worth noting that all of the following is permitted: