Re: Ramping up Continuous Fuzzing of Virtual Devices in QEMU

[Peter Maydell]

On Wed, 4 Nov 2020 at 15:26, Alexander Bulekov <alxndr@bu.edu> wrote:
> If I understand correctly, this is analogous to what happens with
> Coverity reports. Access to Coverity is closed (not sure if there is a
> process to apply for access). It also seems that there is a push to fix
> CID issues prior to new releases. Maybe a similar process can be used for
> fuzzing?

Coverity is only closed in the sense that you have to request
an account on the website. Anybody who's a QEMU developer
can look at the reports.

The attempt to fix CID issues works because:
 * Coverity reports a fairly small number of issues, so
   "fix them all" is relatively tractable, and then once you
   get down to "no outstanding issues" the only new ones
   that get found are for new changes to QEMU (not entirely
   true, but close enough)
 * Mostly issues are reported soon after the offending code
   goes into the tree, so it's often possible to quickly
   identify the patch that introduced the issue and ask
   the person who wrote that patch to fix the bug
 * Coverity reports are categorized by kind-of-failure,
   so it's easy to prioritize important stuff (buffer overflows)
   and leave less significant stuff (dead code) for later
 * Coverity's reports include the automated analysis of
   why Coverity thinks there's an issue -- this is not
   always right but it's a solid head start on "what's the
   bug here" compared to just having a repro case and an
   assertion-failure message
 * There's a set of people who care enough about Coverity
   reports to put the time in to fixing them...

thanks
-- PMM