Re: [Xen-devel] [PATCH v3 12/12] fuzz/x86_emulate: Add an option to limit the number of instructions executed

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 10.10.17 at 18:20, <george.dunlap@xxxxxxxxxx> 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.dunlap@xxxxxxxxxx>

Acked-by: Jan Beulich <jbeulich@xxxxxxxx>



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel