Re: [PULL 24/31] fuzz: support for fork-based fuzzing.

[Eric Blake <eblake@redhat.com>]

On 2/22/20 2:50 AM, Stefan Hajnoczi wrote:
> From: Alexander Bulekov <alxndr@bu.edu>
> 
> fork() is a simple way to ensure that state does not leak in between
> fuzzing runs. Unfortunately, the fuzzer mutation engine relies on
> bitmaps which contain coverage information for each fuzzing run, and
> these bitmaps should be copied from the child to the parent(where the
> mutation occurs). These bitmaps are created through compile-time
> instrumentation and they are not shared with fork()-ed processes, by
> default. To address this, we create a shared memory region, adjust its
> size and map it _over_ the counter region. Furthermore, libfuzzer
> doesn't generally expose the globals that specify the location of the
> counters/coverage bitmap. As a workaround, we rely on a custom linker
> script which forces all of the bitmaps we care about to be placed in a
> contiguous region, which is easy to locate and mmap over.
> 
> Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
> Message-id: 20200220041118.23264-16-alxndr@bu.edu
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> ---

Random drive-by observation:

> +++ b/tests/qtest/fuzz/fork_fuzz.ld
> @@ -0,0 +1,37 @@
> +/* We adjust linker script modification to place all of the stuff that needs to
> + * persist across fuzzing runs into a contiguous seciton of memory. Then, it is

section


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org