On Thu, Jan 10, 2019 at 11:25 PM Paolo Bonzini <pbonz...@redhat.com> 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
