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