[Ccing Nitesh] Stefan Hajnoczi <stefa...@gmail.com> 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 <pbonz...@redhat.com >> > <mailto:pbonz...@redhat.com>> 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
