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

[Bandan Das]

[Ccing Nitesh]
Stefan Hajnoczi <address@hidden> writes:

> 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.
>

If you recall, Nitesh and myself did experiment with the plumbing although
our entry point in qtest for calling the fuzzing function was simpler. Figuring 
out
the right entry point with a subset of absolutely necessary initialization
is what's next.

Bandan

> 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