Xen: My GSoC experience: Fuzzing the hypervisor
Five months ago, I had never even heard of fuzzing, but this summer, I worked on fuzzing the Xen Project hypervisor as a Google Summer of Code student.
For everybody that is not familiar with fuzzing: it is a way to test interfaces. The most primitive form of it is to repeatedly generate random input and feed it to the interface. A more advanced version is coverage-guided fuzzing, which uses information on the code path taken by the binary to permute the input further. The goal of this project was to build a prototype of fuzzing the hypercall-interface, seeing if one could make the hypervisor crash with a definite sequence of hypercalls.
American Fuzzy Lop (AFL) is by far the most popular fuzzer, and so it was chosen as the one to be run on the hypervisor. As it is a fuzzer for user-space programs, it had to be ported to the kernel. To make this work, the first step was to allow it to obtain feedback on the coverage from Xen by implementing a hypercall. Further, a mechanism was needed to execute the hypercalls from a domain other than dom0 (there are many ways to stop the hypervisor from dom0). For this purpose, an XTF-test case was instrumented to run as a server, receiving test cases from an AFL-instance. In the end, changes were made to the hypervisor, libxl, xenconsole, XTF and AFL.
Read the entire article here, My GSoC experience: Fuzzing the hypervisor
via the fine folks at Xen.org.