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 <stefa...@gmail.com> wrote: > 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? > 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 >
