>>> On 10.10.17 at 18:20, <george.dun...@citrix.com> wrote: > AFL considers a testcase to be a useful addition not only if there are > tuples exercised by that testcase which were not exercised otherwise, > but also if the *number* of times an individual tuple is exercised > changes significantly; in particular, if the number of the highest > non-zero bit changes (i.e., if it is run 1, 2-3, 4-7, 8-15, &c). > > One simple way to increase these stats it to execute the same (or > similar) instructions multiple times: If executing a given instruction > once hits a particular tuple 2 times, executing it twice will hit the > tuple 4 times, four times will hit the tuple 8 times, and so on. All > of these will look different to AFL, and so it is likely that many of > the "unique test cases" will simply be the same instruction repeated > powers of 2 times until the tuple counts max out (at 128). > > It is unlikely that executing a single instruction more than a handful > of times will generate any state we actually care about; but such long > testcases take exponentially longer to fuzz: the fuzzer spends more > time flipping bits looking for meaningful changes, and each execution > takes longer because it is doing more things. So long paths which add > nothing to the actual code coverage but effectively "distract" the > fuzzer, making it less effective. > > Experiments have shown that not allowing infinite number of > instruction retries for the old (non-compact) format does indeed speed > up and increase code coverage. However, it has also shown that on the > new, more compact format, having no instruction limit causes the highest > throughput in code coverage. > > So leave the option in, but have it default to 0 (no limit). > > Signed-off-by: George Dunlap <george.dun...@citrix.com>
Acked-by: Jan Beulich <jbeul...@suse.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
