[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Nice write-up.

Overall this is in line with what we discussed, so I don't really have
more comments.

On Sat, Jun 24, 2017 at 08:42:50AM +0200, Felix Schmoll wrote:
> ==================================
> 3.3 Fuzzer
> ==================================
> The idea is to create some dictionary from which the fuzzer builds test
> cases, each line looking like :
> <function name> arguments
> Also, the test cases need to be written to a file before actually being
> applied in order to survive a crash. As pointed out by Andy, the file
> system should have caching disabled.

You can also explicitly issue fsync calls to make sure the file hit

> The binary of the fuzzer also needs to be adjusted in order to accommodate
> the fact that not the usual binary is instrumented. The particular code
> here for AFL is all found in afl-fuzz.c. The function run_target() is
> normally responsible for starting the binary, but instead will have to
> communicate with the executor. The buffer trace_bits has to be filled with
> the binary tracing output.
> The fuzzer will initially be run in deterministic mode.
> ==================================
> 3.4 Executor
> ==================================
> The executor will then try to read out hypercalls and execute them. It will
> also need some encoded information about the arguments expected for each
> hypercall, such that it can pass on valid buffers (if it wants to, one
> could also imagine that a test case is to pass in completely invalid data).
> ==================================
> 3.5 Communication between executor and fuzzer
> ==================================
> Fuzzer and executor need to communicate at least test cases and tracing
> output. For this it was considered to have a shared memory region as in the
> original AFL for the tracing output (using grant tables) and to execute the
> test case from a file. Signals could be used via event-channels to inform
> the executor of the arrival of a new test case and the fuzzer of an ended
> test case, allowing a nice event-driven approach without polling. As XTF
> doesn't support any of this, this idea was overthrown in favour of just
> using the Xen console, which still should allow both.
> ==================================
> 4 Flow diagram
> ==================================

Unfortunately your diagram looks garbled.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.