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

From: qemu_oss--- via <qemu-devel@nongnu.org>
To: qemu-devel@nongnu.org
Cc: Laurent Vivier <lvivier@redhat.com>,
	Thomas Huth <thuth@redhat.com>, Alexander Bulekov <alxndr@bu.edu>,
	Greg Kurz <groug@kaod.org>,
	Darren Kenny <darren.kenny@oracle.com>,
	Bandan Das <bsd@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH v2 3/3] fuzz: add virtio-9p configurations for fuzzing
Date: Tue, 19 Jan 2021 17:15:56 +0100	[thread overview]
Message-ID: <12994439.qYkiaS4ZXl@silver> (raw)
In-Reply-To: <m27do9nd7k.fsf@oracle.com>

On Dienstag, 19. Januar 2021 16:44:31 CET Darren Kenny wrote:
> 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.

Same with me:

Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com>

Best regards,
Christian Schoenebeck