Re: [Xen-devel] [RFC v2] Proposal: Fuzzing the Hypervisor

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On Sat, Jun 24, 2017 at 7:42 AM, Felix Schmoll
<eggi.innovations@xxxxxxxxx> wrote:
> Hi,
>
> here a new version of my proposal for fuzzing the hypervisor. The original
> can be found here: [1].
>
> ==================================
> 1. Motivation and Description
> ==================================
> Fuzzing is a recent trend for systematic testing of interfaces by trying
> more or less random inputs and iterating over them. A subset of fuzzers uses
> code-coverage as feedback when permuting and choosing inputs, among them the
> popular user-space fuzzer American Fuzzy Lop. Recently there have been
> attempts to port fuzzers to the kernel and in a similar manner should now
> the hypercall-interface of Xen be tested.
>
> While this is overall a very comprehensive problem, this project will help
> to develop a better understanding of the problem space and make at least
> first advances of the source tree into the necessary direction. A generic
> mechanism will be implemented allowing fuzzers to obtain feedback on
> code-coverage. In the next step this output will be further processed in
> order to actually run a fuzzer (in particular AFL), although there might not
> be sufficient time to commit this to the source tree.
>
> ==================================
> 2. Fuzzing user-space programs vs. fuzzing a hypervisor
> ==================================
> An iteration in the fuzzing-cycle normally involves the following:
>
> 1. Fuzzer creates new test case based on tracing output
> 2. Fuzzer starts binary with a test case
> 3. Test case is executed and program counters are traced into shared memory
> with fuzzer
> 4. Repeat from 1.
>
> Being not a user-space program, it is however not possible to instrument the
> binary using the methods applied by AFL. Instead, program counters need to
> be extracted manually and post-processed into the form expected by AFL. As
> Xen doesn't just take binary input there further needs to be some other
> format for test cases and executing them.
>
> In order to fuzz the hypervisor, at least the following steps are required:
>
> 1. Let the fuzzer create a new test case
> 2. Drive a domU to execute the test cases of the fuzzer and trace execution
> path
> 3. Parse the execution path into a format consumable by a user-space fuzzer
> 4. Repeat from 1.
>
> In comparison to AFL, the notion of a test case when fuzzing the hypervisor
> is different. In AFL, the program is restarted for every test case (or at
> least the initial state is restored using the fork-server), while in Xen,
> all hypercalls are made on the same hypervisor (at least until it crashes),
> such that even though AFL might run multiple times, the test case would be
> the collection of all hypercalls made since booting.

So what happens when the hypervisor does crash?  Won't you lose the
test case that caused the crash?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel