Re: [Xen-devel] [GSoC] GSoC Introduction : Fuzzing Xen hypercall interface

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Fri, Mar 24, 2017 at 08:34:46AM +0100, Felix Schmoll wrote:
> Hi,
> 
> this time for real:
> 
> so I've been reading up on the task quite a bit now and I'd be thankful if
> you could clarify what exactly you're looking for with the execution path.
> The AFL-fuzzer seems to make use just of a rather simple representation of
> that (https://lwn.net/Articles/674854/), so you would just have to insert
> this snippet:
> 
>   cur_location = <COMPILE_TIME_RANDOM>;
>   shared_mem[cur_location ^ prev_location]++;
>   prev_location = cur_location >> 1;
> 

Yes, that's the basic idea for AFL.

However, you can't just do that for the hypervisor. AFL is geared
towards fuzzing userspace libraries. It is not possible to just use AFL
toolchain to compile Xen and expect it to work. It will fail miserably.
You can't even get Xen to compile with afl-gcc or afl-clang.

You would need to get the execution path with some other method instead
of relying on the AFL toolchain. Using gcc's trace-pc support is good
for that.

> at every edge, i.e. into *__sanitizer_cov_trace_pc,* and somehow set up a
> shared memory section between kernel (where you'd run the fuzzer) and
> hypervisor.

Using shared memory is also an idea. But as you already point out, that
might not be applicable to other fuzzer.

AFL won't run inside guest kernel though. It will remain a userspace
program.

> That might however just be true for AFL and not for other
> coverage-guided fuzzers, so maybe that's the problem. For the fuzzer to
> work I'd also have to implement some templates on what hypercalls are
> available and what arguments they expect, but that would still not fill
> three months, so I'm assuming that I'm fundamentally missing something here.
> 

My idea is that:

1. Extract execution path from hypervisor via a hypercall.
2. Write a small stub userspace program to turn the raw data into a form
   that can be consumed by AFL (or any other fuzzer you have in mind).
3. Use the same small stub program to drive a domU to execute the
   test case provided by AFL.

Some of the code in #2 and #3 is going to be fuzzer-specific (the
template you talked about), but we should be able to make the
architecture as generic as possible.

That's only a high-level description. There is actually a lot of work to
be done. It would be good if we can upstream #1 within 3 months.  If we
can get all three implemented, that would be really good.

Wei.

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