qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] Internship idea: virtio-blk oss-fuzz support
Date: Fri, 11 Jan 2019 06:49:05 +0000

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?

Thanks,
Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]