Re: [Qemu-devel] Internship idea: virtio-blk oss-fuzz support

[Max Moroz]

Paolo, thanks for clarifying, that makes total sense! I'd suggest not
focusing on AFL, but go for a libFuzzer-based fuzz target (i.e.
write LLVMFuzzerTestOneInput function), in that case you'll get both
libFuzzer and AFL engines pluggable to that fuzz target. OSS-Fuzz runs both.

On Thu, Jan 10, 2019 at 10:49 PM Stefan Hajnoczi <address@hidden> wrote:

> On Thu, Jan 10, 2019 at 11:25 PM Paolo Bonzini <address@hidden>
> wrote:
> > On 10/01/19 17:07, Max Moroz via Qemu-devel wrote:
> > > +Oliver and Jonathan
> > >
> > > I'm a little confused. Do you want to fuzz QEMU or to fuzz something
> else
> > > using QEMU? In case of the latter, there was some discussion on
> OSS-Fuzz
> > > and (I think) even a build support was (sort of) added:
> > > https://github.com/google/oss-fuzz/issues/1754
> >
> > We want to fuzz QEMU.
> >
> > The input is a sequence of operations on a PCI device or on guest
> > memory, and you try and crash QEMU by passing it crazy operations.
> >
> > The qtest mode that Stefan mentioned provides something like a "JTAG
> > over ASCII" where a testcase can inject elementary I/O operations into
> > QEMU.  However, that is certainly too much for AFL to fuzz effectively;
> > it would have to "learn" the qtest protocol, how to drive the PCI host
> > bridge, how to setup a PCI device, and only then it would be able to
> > find bugs.  So one idea would be to build another layer on top of qtest,
> > that accepts higher-level operations and builds the qtest ASCII input
> > from those.
>
> Question for the oss-fuzz folks: QEMU's qtest protocol involves a
> 2-process architecture with a qtest process that connects to a QEMU
> process.  We don't care about the code coverage/sanitizers/etc on the
> test process, only the QEMU process.  The LLVMFuzzerTestOneInput()
> entry point would nevertheless be in the qtest process.  Does this fit
> into the oss-fuzz architecture?
>

We usually have a single fuzzing process, it starts with a fuzzing engine's
main function and is calling LLVMFuzzerTestOneInput with various inputs and
keep mutating them based on the coverage feedback. Running a second process
which you don't care too much about might be fine, but the fuzzing process
should be "replacing" or should I say "imitating" the process whose
coverage you're interested in. Does it make any sense?



>
> Thanks,
> Stefan
>