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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

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
storage.

> 
> 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
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel