aboutsummaryrefslogtreecommitdiff
path: root/tests/qtest/fuzz/fork_fuzz.c
AgeCommit message (Collapse)Author
2020-07-06fuzz: do not use POSIX shm for coverage bitmapAlexander Bulekov
We used shm_open with mmap to share libfuzzer's coverage bitmap with child (runner) processes. The same functionality can be achieved with MAP_SHARED | MAP_ANONYMOUS, since we do not care about naming or permissioning the shared memory object. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <20200622165040.15121-1-alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-02-22fuzz: support for fork-based fuzzing.Alexander Bulekov
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>