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

[Stefan Hajnoczi]

On Fri, Jan 11, 2019 at 05:16:40PM +0100, Paolo Bonzini wrote:
> On 11/01/19 16:41, Max Moroz wrote:
> > On Fri, Jan 11, 2019 at 7:34 AM Paolo Bonzini <address@hidden
> > <mailto:address@hidden>> wrote:
> > 
> >     On 11/01/19 16:04, Max Moroz wrote:
> >     > 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.
> > 
> >     What do you mean by replacing or imitating?
> > 
> > To give you an example, when we fuzz ffmpeg, we do not run ffmpeg's main
> > function. We write LLVMFuzzerTestOneInput that would do the necessary
> > initialization, reset the state, etc, and then would pass (data, size)
> > provided by a fuzzing engine to the API(s) we're trying to fuzz. So, in
> > your case, there should not be a regular QEMU process, and instead the
> > fuzz target (i.e. LLVMFuzzerTestOneInput) should be doing certain
> > initialization (which is usually done by the QEMU process) and then call
> > the API you want to fuzz.
> 
> The main issue is that we are not really testing an API and QEMU has a
> lot of global state.

With regards to the GSoC/Outreachy project, I think the mentors (me?)
need to figure this out beforehand by experimentation.  The QEMU folks
don't know the details of oss-fuzz and vice versa.  But with a weekend
or two's worth of playing around we could figure out a reasonable way of
integrating qtest/oss-fuzz.

Then the intern has a clear direction to follow this summer and won't be
demotivated by failed attempts at working with two codebases they are
unfamiliar with :).

Stefan

signature.asc
Description: PGP signature