From: Dmitry Vyukov <dvyukov@google.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, Bandan Das <bsd@redhat.com>,
Kostya Serebryany <kcc@google.com>, Max Moroz <mmoroz@google.com>,
Andrey Konovalov <andreyknvl@google.com>
Subject: Re: [Qemu-devel] Internship idea: virtio-blk oss-fuzz support
Date: Thu, 10 Jan 2019 11:46:49 +0100 [thread overview]
Message-ID: <CACT4Y+bQpQgUzDP+9Sr967m5bOJRR3k2o2EnERGZCE2ttB6Lwg@mail.gmail.com> (raw)
In-Reply-To: <CAJSP0QUV39fK4L8MwQ-rGiR0ejUm0HCyKFqARh-SKRTuDPKOXg@mail.gmail.com>
On Wed, Jan 9, 2019 at 6:34 PM Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
> Hi folks,
> I'd like to start fuzzing emulated devices in QEMU. Here is an
> internship project idea I'm proposing to do this.
>
> Any thoughts? Want to co-mentor this in Google Summer of Code or Outreachy?
>
> Stefan
>
> '''Summary:''' Integrate oss-fuzz into QEMU so that the virtio-blk
> device can be fuzz tested.
Sounds great!
+some people from OSS-Fuzz as FYI
Once a first fuzzer paves the road, it should be much simpler to add
other fuzzers as well. E.g. image parsing, or instruction emulation (I
know it's not security critical, but given a cost effective way to
find bugs it may be worth it). I understand that a GSOC project should
have a limit scope, but I think paving the road is important part of
this.
> oss-fuzz offers a fuzz testing service to open source projects. This
> means random inputs are continuously tested against the program in
> order to find crashes and other bugs. Fuzz testing complements
> hand-written test suites by exploring the input space of a program and
> therefore the code paths that may be taken.
>
> The goal of this project is to integrate oss-fuzz into QEMU so that
> the virtio-blk-pci device can be fuzzed at both the VIRTIO and PCI bus
> level. virtio-blk-pci is a PCI device, which means it is connected to
> the virtual machine's PCI bus and has a certain set of registers that
> can be programmed by the guest. Furthermore, it is a VIRTIO device -
> this is the specification the describes most of the functionality of
> virtio-blk. Bugs exist at both the PCI and VIRTIO levels, so it's
> important to fuzz both of them.
>
> Fuzzing emulated devices involves accessing their hardware registers
> randomly to make the device respond. QEMU has a device testing
> interface called "qtest" that accepts read/write and other commands
> over a socket and is ideal for writing device-level tests. You may
> find that oss-fuzz works better integrated directly into the QEMU
> program instead of as a separate qtest program, so you can consider
> adding a new command-line option to QEMU for running in oss-fuzz mode.
>
> This project involves learning about VIRTIO and PCI devices, as well
> as figuring out how to integrate oss-fuzz into QEMU so that it can
> effective explore the code paths in virtio-blk device emulation code.
> You will enjoy this project if you want to learn how device emulation
> works and are interested in fuzzers.
>
> '''Links:'''
> * [https://github.com/google/oss-fuzz/blob/master/docs/ideal_integration.md
> oss-fuzz integration overview]
> * [https://github.com/google/fuzzer-test-suite/blob/master/tutorial/libFuzzerTutorial.md
> libfuzzer tutorial]
> * [http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html
> VIRTIO specification]
> * [https://wiki.osdev.org/PCI PCI bus overview]
>
> '''Details:'''
> * Skill level: intermediate
> * Language: C
> * Mentor: Stefan Hajnoczi <stefanha@redhat.com>
next prev parent reply other threads:[~2019-01-10 11:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-09 17:34 [Qemu-devel] Internship idea: virtio-blk oss-fuzz support Stefan Hajnoczi
2019-01-10 10:46 ` Dmitry Vyukov [this message]
2019-01-10 13:40 ` Bandan Das
2019-01-10 14:01 ` Dmitry Vyukov
2019-01-10 16:07 ` Max Moroz
2019-01-10 23:25 ` Paolo Bonzini
2019-01-11 6:49 ` Stefan Hajnoczi
2019-01-11 15:04 ` Max Moroz
2019-01-11 15:33 ` Paolo Bonzini
2019-01-11 15:41 ` Max Moroz
2019-01-11 16:16 ` Paolo Bonzini
2019-01-11 19:09 ` Jonathan Metzman
2019-01-11 20:27 ` Paolo Bonzini
2019-01-11 22:56 ` Jonathan Metzman
2019-01-14 9:24 ` Stefan Hajnoczi
2019-01-18 7:51 ` Bandan Das
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACT4Y+bQpQgUzDP+9Sr967m5bOJRR3k2o2EnERGZCE2ttB6Lwg@mail.gmail.com \
--to=dvyukov@google.com \
--cc=andreyknvl@google.com \
--cc=bsd@redhat.com \
--cc=kcc@google.com \
--cc=mmoroz@google.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).