Google Summer of Code 2016

From QEMU

Introduction

QEMU is applying for Google Summer of Code 2016. This page contains our ideas list and information for students and mentors. If QEMU is accepted, we will be able to mentor students doing 12-week full-time open source work from May to August 2016!

Note to students: Participating organizations have not yet been announced so we don't know whether or not QEMU will take part this year. You are welcome to investigate project ideas that interest you but please don't invest too much time and effort until Google announces participating organizations.

Example coding exercise

Here is a C coding exercise we have used in previous years when interviewing students: 2014 coding exercise

Try it and see if you are comfortable enough writing C. We cannot answer questions about the previous coding exercise but hopefully it should be self-explanatory.

If you find the exercise challenging, think about applying to other organizations where you have a stronger technical background and will be more competitive compared with other candidates.

Find Us

  • IRC (GSoC specific): #qemu-gsoc on irc.oftc.net
  • IRC (development):
    • QEMU: #qemu on irc.oftc.net
    • libvirt: #virt on irc.oftc.net
    • KVM: #kvm on chat.freenode.net

Please contact the mentor for the project idea you are interested in. IRC is usually the quickest way to get an answer.

For general questions about QEMU in GSoC, please contact the following people:

How to get familiar with our software

See what people are developing and talking about on the mailing lists:

Grab the source code or browse it:

Build QEMU and run it: QEMU on Linux Hosts

Important links

Project Ideas

This is the listing of suggested project ideas. Students are free to suggest their own projects by emailing qemu-devel@nongnu.org and (optionally) CCing potential mentors.

QEMU projects

AF_VSOCK packet capture in Linux and Wireshark

Summary: Develop a AF_VSOCK packet capture Linux device driver and Wireshark dissector

Wireshark and Linux's packet capture functionality support more than just Ethernet traffic dumping. USB device traffic and netlink software communication can also be captured.

The AF_VSOCK address family is currently not support by Wireshark because there is no Linux kernel device driver for packet capture. AF_VSOCK is the socket address family that is used by the virtio-vsock host/guest communication device that is currently in development. The aim of this project is to first implement a Linux device driver for AF_VSOCK packet capture and then a Wireshark dissector. Minor changes to tcpdump may be necessary too.

This will allow tcpdump and Wireshark to dump host/guest communication with virtio-vsock (and maybe also VMware VMSockets). Traffic capture is an essential debugging tool for network communication and has not been available to programs using AF_VSOCK.

This project is challenging because you need to work on multiple codebases. You must have experience with device driver development and network programming.

Links:

Details:

  • Skill level: advanced
  • Language: C
  • Mentor: Stefan Hajnoczi <stefanha@redhat.com> (stefanha on IRC)

qemu-img fuzzing using afl-fuzz

Summary: Apply the afl-fuzz fuzz testing tool to qemu-img and submit patches fixing bugs discovered with afl-fuzz.

The qemu-img tool is used to convert between disk image file formats and inspect image files. It supports multiple file formats including qcow2, vmdk, vhdx, and parallels. Since this tool is often used on untrusted inputs (e.g. in a cloud or hosting environment where end-users can upload disk image files), it must not allow arbitrary code execution or other classes of security bugs.

afl-fuzz instruments the program to record codepaths taken for each input test file. This allows afl-fuzz to mutate inputs and choose the ones that explore new codepaths. The amount of prior knowledge that afl-fuzz needs about the input grammar is limited since it learns how inputs affect the codepath. This makes it possible to fuzz various disk image file formats without painstakingly writing grammars for each file format.

In Outreach Program for Women 2014, a qcow2-specific fuzzing tool was developed in Python and several bugs were discovered. This project aims to tackle the other file formats (especially vmdk, vhdx, and parallels).

This project is suitable for candidates interested in software security, software testing, compilers, and disk image file formats.

Links:

Details:

  • Skill level: intermediate
  • Language: C
  • Mentor: Stefan Hajnoczi <stefanha@redhat.com> (stefanha on IRC)
  • Suggested by: Stefan Hajnoczi

qemu-img new subcommand "dd"

Summary: Add "qemu-img dd" subcommand.

dd(1) is a convenient tool to work on binary files, while qemu-img(1) has the knowledge of many image formats (qcow2, vhdx, vdi, vmdk, etc.) and protocols (nfs, iscsi, gluster, ssh, etc.). If we put them together, we'll have the power of dd to work on various virtual images and, or even pipe it through any host side utilities, such as grep(1), xxd(1) or xz(1). The idea is to implement a new subcommand in qemu-img, the tool provided by QEMU for manupulating virtual images. 

Currently qemu-img has following subcommands:

Command syntax:
 check [-q] [-f fmt] [--output=ofmt] [-r [leaks | all]] [-T src_cache] filename
 create [-q] [-f fmt] [-o options] filename [size]
 commit [-q] [-f fmt] [-t cache] filename
 compare [-f fmt] [-F fmt] [-T src_cache] [-p] [-q] [-s] filename1 filename2
 convert [-c] [-p] [-q] [-n] [-f fmt] [-t cache] [-T src_cache] [-O output_fmt] [-o options] [-s snapshot_id_or_name] [-l snapshot_param] [-S sparse_size] filename [filename2 [...]] output_filename
 info [-f fmt] [--output=ofmt] [--backing-chain] filename
 map [-f fmt] [--output=ofmt] filename
 snapshot [-q] [-l | -a snapshot | -c snapshot | -d snapshot] filename
 rebase [-q] [-f fmt] [-t cache] [-T src_cache] [-p] [-u] -b backing_file [-F backing_fmt] filename
 resize [-q] filename [+ | -]size
 amend [-q] [-f fmt] [-t cache] -o options filename

You will extend the subcommand set with the new "dd" command, in a syntax that is familiar to *nix "dd" users.

Note that we don't have to mirror the behavior of GNU coreutils' or BDS systems' dd(1), or try to support every operand found there. A subset of operands (and probably some qemu-img specific ones) as chosen by you will be implemented. It is also your responsibility to write documentation for the new command and options.

Links

Details:

  • Skill level: beginner
  • Language: C
  • Mentor: Fam Zheng <famz@redhat.com>, fam on IRC

qtest-os: a mini operating system written in Python

Summary: Write a Python library to interact with QEMU's qtest, and then as much as possible of a "mini-OS" written in Python

...

Links:

  • ...

Details:

  • Skill level: medium
  • Language: Python
  • Mentor: Paolo Bonzini <pbonzini@redhat.com> (bonzini on IRC)

KVM projects

Implement the Hypervisor.framework API on top of KVM

Summary: Write a (userspace) library that implements the OS X Hypervisor.framework API

The Hypervisor.framework API is a type-2 hypervisor that is included in recent versions of OS X. The API is a relatively thin wrapper over the Intel VMX virtual machine extensions. Implementing the API on top of KVM makes it possible to run Hypervisor.framework clients under Linux; for example, it would enable development a port of QEMU to Hypervisor.framework with free software only.

The project consists of two parts:

  • Building a minimal Hypervisor.framework client that is able to boot the KVM unit tests
  • Writing a library that lets you run the client on Linux.

Availability of both OS X and Linux is recommended for students who want to apply for this project.

Links:

  • ...

Details:

  • Skill level: advanced
  • Language: C
  • Mentor: Paolo Bonzini <pbonzini@redhat.com> (bonzini on IRC)

Libvirt projects

This year libvirt is trying to get accepted as a separate organization. There's a wiki page similar to this on libvirt wiki: Libvirt GSoC page.
However, if an idea that involves work in both qemu and libvirt appears, it should be listed on both lists.

Project idea template

=== TITLE ===
 
 '''Summary:''' Short description of the project
 
 Detailed description of the project.
 
 '''Links:'''
 * Wiki links to relevant material
 * External links to mailing lists or web sites
 
 '''Details:'''
 * Skill level: beginner or intermediate or advanced
 * Language: C
 * Mentor: Email address and IRC nick
 * Suggested by: Person who suggested the idea

Information for mentors

Mentors are responsible for keeping in touch with their student and assessing the student's progress. GSoC has a mid-term evaluation and a final evaluation where both the mentor and student assess each other.

The mentor typically gives advice, reviews the student's code, and has regular communication with the student to ensure progress is being made.

Being a mentor is a significant time commitment, plan for 5 hours per week. Make sure you can make this commitment because backing out during the summer will affect the student's experience.

The mentor chooses their student by reviewing student application forms and conducting IRC interviews with candidates. Depending on the number of candidates, this can be time-consuming in itself. Choosing the right student is critical so that both the mentor and the student can have a successful experience.

Retrieved from "https://wiki.qemu.org/index.php?title=Google_Summer_of_Code_2016&oldid=5283"