Re: [PATCH v2 3/3] fuzz: add virtio-9p configurations for fuzzing

[Darren Kenny <darren.kenny@oracle.com>]

On Tuesday, 2021-01-19 at 10:12:29 -05, Alexander Bulekov wrote:
> On 210118 1540, Darren Kenny wrote:
>> On Monday, 2021-01-18 at 10:30:33 -05, Alexander Bulekov wrote:
>> > On 210118 1334, Christian Schoenebeck wrote:
>> >> On Montag, 18. Januar 2021 00:09:24 CET Alexander Bulekov wrote:
>> >> > virtio-9p devices are often used to expose a virtual-filesystem to the
>> >> > guest. There have been some bugs reported in this device, such as
>> >> > CVE-2018-19364, and CVE-2021-20181. We should fuzz this device
>> >> > 
>> >> > This patch adds two virtio-9p configurations:
>> >> >  * One with the widely used -fsdev local driver. This driver leaks some
>> >> >    state in the form of files/directories created in the shared dir.
>> >> >  * One with the synth driver. While it is not used in the real world, this
>> >> >    driver won't leak leak state between fuzz inputs.
>> >> > 
>> >> > Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
>> >> > ---
>> >> > CC: Christian Schoenebeck <qemu_oss@crudebyte.com>
>> >> > CC: Greg Kurz <groug@kaod.org>
>> >> > 
>> >> > I considered adding an atexit handler to remove the temp directory,
>> >> > however I am worried that there might be some error that results in a
>> >> > call to exit(), rather than abort(), which will cause problems for
>> >> > future fork()-ed fuzzers. I don't think there are such calls in the 9p
>> >> > code, however there might be something in the APIs used by 9p. As this
>> >> > code is primarily for ephemeral OSS-Fuzz conainers, this shouldn't be
>> >> > too much of an issue.
>> >> 
>> >> Yes, dealing with signal handlers for that is probably a bit intransparent and 
>> >> would leave a questionable feeling about its reliability.
>> >> 
>> >> What about __attribute__((destructor)) to auto delete the fuzzer directory, 
>> >> like virtio-9p-test.c does for the same task?
>> >> 
>> >
>> > My worry is that we will end up deleting it while it is still in use.
>> > The scenario I am worried about:
>> > [parent process ] set up temp directory for virtio-9p
>> > [parent process ] initialize QEMU 
>> > [parent process ] fork() and wait()
>> > [child process 1] Run the fuzzing input.
>> > [child process 1] Once the input has been executed, call _Exit(). This
>> > should skip the atexit()/__attribute((destructor)) handlers. For reasons
>> > related to libfuzzer, we need to do this so that libfuzzer doesn't treat
>> > each child exit()-ing as a crash.
>> > [parent process ] wait() returns.
>> > [parent process ] generate a new input.. fork() and wait()
>> > [child process 2] Run the fuzzing input.
>> > [child process 2] Somewhere we hit an abort(). libfuzzer hooks the abort
>> > and dumps the crashing input and stack trace. Since abort() doesn't call
>> > exit handlers, it will skip over atexit()/__attribute((destructor)) handlers
>> > [parent process ] wait() returns.
>> > [parent process ] generate a new input.. fork() and wait()
>> > [child process 3] Run the fuzzing input.
>> > [child process 3] Somewhere we hit an exit(). This will dump the
>> > input/stacktrace and it will run the exit handlers (removing the shared
>> > 9p directory)
>> > [parent process ] wait() returns. generate a new input.. fork() and wait()
>> > [child process 4] ...
>> 
>> OK, that answer's my question :)
>> 
>> > Now all the subsequent forked children will refer to a shared directory
>> > that we already removed. Ideally, we would run the cleanup handler only
>> > after the parent process exit()s. I think there are some ways to do
>> > this, by placing the atexit() call in a place only reachable by the
>> > parent. However, on OSS-Fuzz this shouldn't be a problem as everything
>> > is cleaned up automatically anyway..
>> 
>> Yep, agreed.
>> 
>> > I am more worried about the fact that files/directories/links that are
>> > created by 9p in the child processes, persist across inputs. I think
>> > Thomas suggested a way to work-around this for PATCH 1/3. We could have
>> > a function that runs in the parent after each wait() returns, that would
>> > remove all the files in the temp directory and scrub the extended
>> > attributes applied by 9p to the shared dir.
>> 
>> Hmm, that sounds like something to consider, but it may also end up
>> slowing down the execution during the turn-around - guess it depends on
>> how much noise is being generated.
>> 
>
> I've ben running the fuzzer for a couple days, and I haven't noticed any
> issues with unreproducible inputs (yet). Is this something we can add
> later, if it becomes a problem?

Sure, I'm good with that:

Reviewed-by: Darren Kenny <darren.kenny@oracle.com>

Thanks,

Darren.

> -Alex
>
>> Thanks,
>> 
>> Darren.
>> 
>> > -Alex
>> >
>> >
>> >> >  tests/qtest/fuzz/generic_fuzz_configs.h | 20 ++++++++++++++++++++
>> >> >  1 file changed, 20 insertions(+)
>> >> > 
>> >> > diff --git a/tests/qtest/fuzz/generic_fuzz_configs.h
>> >> > b/tests/qtest/fuzz/generic_fuzz_configs.h index 1a133655ee..f99657cdbc
>> >> > 100644
>> >> > --- a/tests/qtest/fuzz/generic_fuzz_configs.h
>> >> > +++ b/tests/qtest/fuzz/generic_fuzz_configs.h
>> >> > @@ -19,6 +19,16 @@ typedef struct generic_fuzz_config {
>> >> >      gchar* (*argfunc)(void); /* Result must be freeable by g_free() */
>> >> >  } generic_fuzz_config;
>> >> > 
>> >> > +static inline gchar *generic_fuzzer_virtio_9p_args(void){
>> >> > +    char tmpdir[] = "/tmp/qemu-fuzz.XXXXXX";
>> >> > +    g_assert_nonnull(mkdtemp(tmpdir));
>> >> > +
>> >> > +    return g_strdup_printf("-machine q35 -nodefaults "
>> >> > +    "-device virtio-9p,fsdev=hshare,mount_tag=hshare "
>> >> > +    "-fsdev local,id=hshare,path=%s,security_model=mapped-xattr,"
>> >> > +    "writeout=immediate,fmode=0600,dmode=0700", tmpdir);
>> >> > +}
>> >> > +
>> >> >  const generic_fuzz_config predefined_configs[] = {
>> >> >      {
>> >> >          .name = "virtio-net-pci-slirp",
>> >> > @@ -60,6 +70,16 @@ const generic_fuzz_config predefined_configs[] = {
>> >> >          .name = "virtio-mouse",
>> >> >          .args = "-machine q35 -nodefaults -device virtio-mouse",
>> >> >          .objects = "virtio*",
>> >> > +    },{
>> >> > +        .name = "virtio-9p",
>> >> > +        .argfunc = generic_fuzzer_virtio_9p_args,
>> >> > +        .objects = "virtio*",
>> >> > +    },{
>> >> > +        .name = "virtio-9p-synth",
>> >> > +        .args = "-machine q35 -nodefaults "
>> >> > +        "-device virtio-9p,fsdev=hshare,mount_tag=hshare "
>> >> > +        "-fsdev synth,id=hshare",
>> >> > +        .objects = "virtio*",
>> >> >      },{
>> >> >          .name = "e1000",
>> >> >          .args = "-M q35 -nodefaults "
>> >> 
>> >> 
>> >>