Re: [Xen-devel] [PATCH v3 09/12] fuzz/x86_emulate: Make input more compact

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

> On Oct 10, 2017, at 6:26 PM, Ian Jackson <ian.jackson@xxxxxxxxxxxxx> wrote:
> 
> George Dunlap writes ("[PATCH v3 09/12] fuzz/x86_emulate: Make input more 
> compact"):
>> At the moment, AFL reckons that for any given input, 87% of it is
>> completely irrelevant: that is, it can change it as much as it wants
>> but have no impact on the result of the test; and yet it can't remove
>> it.
>> 
>> This is largely because we interpret the blob handed to us as a large
>> struct, including CR values, MSR values, segment registers, and a full
>> cpu_user_regs.
>> 
>> Instead, modify our interpretation to have a "set state" stanza at the
>> front.  Begin by reading a 16-bit value; if it is lower than a certain
>> threshold, set some state according to what byte it is, and repeat.
>> Continue until the byte is above a certain threshold.
>> 
>> This allows AFL to compact any given test case much smaller; to the
>> point where now it reckons there is not a single byte of the test file
>> which becomes irrelevant.  Testing have shown that this option both
>> allows AFL to reach coverage much faster, and to have a total coverage
>> higher than with the old format.
> 
> This is basically a compression scheme.  How odd that it should help.

Well I’m pretty sure the size of the input file is more or less the precise 
cause for the difference in speed: Fuzzing a 32-byte file is just a lot faster 
than fuzzing a 1-k file.  Running them side by side makes the effect more 
obvious — I’ll show you tomorrow if you’re interested.

Since the file size is the direct cause of the speed difference, having a 
“compressed” file will naturally make things faster.


> 
> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>

Thanks.

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