From: Alexander Bulekov <alxndr@bu.edu>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, kvm <kvm@vger.kernel.org>,
"Rust-VMM Mailing List" <rust-vmm@lists.opendev.org>,
"Damien Le Moal" <Damien.LeMoal@wdc.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Sergio Lopez" <slp@redhat.com>,
"Dmitry Fomichev" <Dmitry.Fomichev@wdc.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Hannes Reinecke" <hare@suse.de>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"Florescu, Andreea" <fandree@amazon.com>,
hreitz@redhat.com, "Alex Agache" <aagch@amazon.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"John Snow" <jsnow@redhat.com>,
"Stefano Garzarella" <sgarzare@redhat.com>,
bdas@redhat.com, darren.kenny@oracle.com
Subject: Re: Call for GSoC and Outreachy project ideas for summer 2022
Date: Fri, 18 Feb 2022 16:03:42 -0500 [thread overview]
Message-ID: <20220218210323.hw2kkid25l7jczjo@mozz.bu.edu> (raw)
In-Reply-To: <CAJSP0QX7O_auRgTKFjHkBbkBK=B3Z-59S6ZZi10tzFTv1_1hkQ@mail.gmail.com>
On 220128 1547, Stefan Hajnoczi wrote:
> Dear QEMU, KVM, and rust-vmm communities,
> QEMU will apply for Google Summer of Code 2022
> (https://summerofcode.withgoogle.com/) and has been accepted into
> Outreachy May-August 2022 (https://www.outreachy.org/). You can now
> submit internship project ideas for QEMU, KVM, and rust-vmm!
>
> If you have experience contributing to QEMU, KVM, or rust-vmm you can
> be a mentor. It's a great way to give back and you get to work with
> people who are just starting out in open source.
>
> Please reply to this email by February 21st with your project ideas.
>
> Good project ideas are suitable for remote work by a competent
> programmer who is not yet familiar with the codebase. In
> addition, they are:
> - Well-defined - the scope is clear
> - Self-contained - there are few dependencies
> - Uncontroversial - they are acceptable to the community
> - Incremental - they produce deliverables along the way
>
> Feel free to post ideas even if you are unable to mentor the project.
> It doesn't hurt to share the idea!
Here are two fuzzing-related ideas:
Summary: Implement rapid guest-initiated snapshot/restore functionality (for
Fuzzing).
Description:
Many recent fuzzing projects rely on snapshot/restore functionality
[1,2,3,4,5]. For example tests/fuzzers that target large targets, such as OS
kernels and browsers benefit from full-VM snapshots, where solutions such as
manual state-cleanup and fork-servers are insufficient.
Many of the existing solutions are based on QEMU, however there is currently no
upstream-solution. Furthermore, hypervisors, such as Xen have already
incorporated support for snapshot-fuzzing.
In this project, you will implement a virtual-device for snapshot fuzzing,
following a spec agreed-upon by the community. The device will implement
standard fuzzing APIs that allow fuzzing using engines, such as libFuzzer and
AFL++. The simple APIs exposed by the device will allow fuzzer developers to
build custom harnesses in the VM to request snapshots, memory/device/register
restores, request new inputs, and report coverage.
[1] https://arxiv.org/pdf/2111.03013.pdf
[2] https://blog.mozilla.org/attack-and-defense/2021/01/27/effectively-fuzzing-the-ipc-layer-in-firefox/
[3] https://www.usenix.org/system/files/sec20-song.pdf
[4] https://github.com/intel/kernel-fuzzer-for-xen-project
[5] https://github.com/quarkslab/rewind
Skill level: Intermediate with interest and experience in fuzzing.
Language/Skills: C
Topic/Skill Areas: Fuzzing, OS/Systems/Drivers
Summary: Implement a coverage-guided fuzzer for QEMU images
Description:
QEMU has a qcow2 fuzzer (see tests/image-fuzzer). However, this fuzzer is not
coverage-guided, and is limited to qcow2 images. Furthermore, it does not run
on OSS-Fuzz. In some contexts, qemu-img is expected to handle untrusted disk
images. As such, it is important to effectively fuzz this code.
Your task will be to create a coverage-guided fuzzer for image formats
supported by QEMU. Beyond basic image-parsing code, the fuzzer should be able
to find bugs in image-conversion code. Combined with a corpus of QEMU images,
the fuzzer harness will need less information about image layout.
Skill level: Intermediate
Language/Skills: C
Topic/Skill Areas: Fuzzing, libFuzzer/AFL
Thanks
-Alex
next prev parent reply other threads:[~2022-02-18 21:15 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-28 15:47 Call for GSoC and Outreachy project ideas for summer 2022 Stefan Hajnoczi
2022-02-09 14:49 ` Alexander Graf
2022-02-14 13:58 ` Stefan Hajnoczi
2022-03-16 13:16 ` Stefan Hajnoczi
2022-03-16 13:35 ` Alexander Graf
2022-03-29 20:29 ` Stefan Hajnoczi
2022-02-14 7:11 ` Jason Wang
2022-02-14 11:48 ` Stefano Garzarella
2022-02-15 7:48 ` Jason Wang
2022-02-14 14:01 ` Stefan Hajnoczi
2022-02-15 7:49 ` Jason Wang
2022-02-17 14:12 ` Stefano Garzarella
2022-02-17 16:27 ` Stefan Hajnoczi
2022-02-17 17:49 ` Paolo Bonzini
2022-02-19 9:36 ` Stefan Hajnoczi
2022-02-14 13:16 ` Alex Bennée
2022-02-14 14:10 ` Stefan Hajnoczi
2022-02-17 7:08 ` Alice Frosi
2022-02-17 16:26 ` Stefan Hajnoczi
2022-02-17 17:52 ` Paolo Bonzini
2022-02-18 11:39 ` Michal Prívozník
2022-02-18 16:03 ` Paolo Bonzini
2022-02-19 13:46 ` Stefan Hajnoczi
2022-02-21 9:36 ` Michal Prívozník
2022-02-21 11:27 ` Paolo Bonzini
2022-02-21 15:23 ` Michal Prívozník
2022-02-19 13:48 ` Stefan Hajnoczi
2022-02-18 21:03 ` Alexander Bulekov [this message]
2022-02-21 9:34 ` Stefan Hajnoczi
2022-02-21 6:14 ` Klaus Jensen
2022-02-21 9:51 ` Stefan Hajnoczi
2022-02-21 12:00 ` Klaus Jensen
2022-02-22 9:48 ` Stefan Hajnoczi
2022-02-22 15:03 ` Keith Busch
2022-02-25 12:39 ` Stefan Hajnoczi
2022-02-23 8:47 ` Andreea Florescu
2022-02-25 12:55 ` Stefan Hajnoczi
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=20220218210323.hw2kkid25l7jczjo@mozz.bu.edu \
--to=alxndr@bu.edu \
--cc=Damien.LeMoal@wdc.com \
--cc=Dmitry.Fomichev@wdc.com \
--cc=aagch@amazon.com \
--cc=alex.bennee@linaro.org \
--cc=bdas@redhat.com \
--cc=darren.kenny@oracle.com \
--cc=f4bug@amsat.org \
--cc=fandree@amazon.com \
--cc=hare@suse.de \
--cc=hreitz@redhat.com \
--cc=jsnow@redhat.com \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=marcandre.lureau@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rust-vmm@lists.opendev.org \
--cc=sgarzare@redhat.com \
--cc=slp@redhat.com \
--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).