Paul, thanks for reporting this! A couple of comments...
On 02/22/2018 11:57 PM, Paul Semel wrote:
> The minimum size for the input size was set to DATA_OFFSET + 1 which was
> that we were requesting at least one character of the data array to be filled.
> This is not needed for the fuzzer to get working correctly.
Sure, but then the emulator will fail the first insn_fetch() callback.
I understand there's a conceptual purity to testing such an input, but
is it actually of practical value in finding bugs?
> The maximum size for the input size was set to INPUT_SIZE, which is actually
> the size of the data array inside the fuzz_corpus structure and so was not
> abling user (or AFL) to fill in the whole structure. Changing to
> sizeof(struct fuzz_corpus) correct this problem.
Good catch; actually INPUT_SIZE is a misnomer; this should really be
I think it's arguable whether the better thing to do there would be to
take your approach, of extending the accepted input size to fit the
initial state + data size, or the other approach, of restricting the
size of the data array such that the total structure size doesn't
exceed our desired INPUT_SIZE (currently 4k). The first bit of advice
in `perf_tips.txt` for AFL is "Keep your test cases small", so I'd be
inclined to go with the second.
But in any case, I'm in the process of reworking how the input works;
you can see the last patch posted here:
I haven't taken a close look but I think it as a side effect it will fix
Xen-devel mailing list