syzkaller is an unsupervised coverage-guided kernel fuzzer
Go to file
Dmitry Vyukov a02244e114 deduplicate coverare in executor
This allows to use larger coverage buffer
and not overflow output at the same time.
2015-10-13 15:29:07 +02:00
cover dump coverage in execprog command 2015-10-13 15:29:07 +02:00
executor deduplicate coverare in executor 2015-10-13 15:29:07 +02:00
fuzzer deduplicate coverare in executor 2015-10-13 15:29:07 +02:00
ipc deduplicate coverare in executor 2015-10-13 15:29:07 +02:00
manager dump coverage in execprog command 2015-10-13 15:29:07 +02:00
master initial commit 2015-10-12 10:16:57 +02:00
prog initial commit 2015-10-12 10:16:57 +02:00
rpctype initial commit 2015-10-12 10:16:57 +02:00
sys initial commit 2015-10-12 10:16:57 +02:00
sysgen initial commit 2015-10-12 10:16:57 +02:00
tools deduplicate coverare in executor 2015-10-13 15:29:07 +02:00
vm initial commit 2015-10-12 10:16:57 +02:00
AUTHORS initial commit 2015-10-12 10:16:57 +02:00
CONTRIBUTORS initial commit 2015-10-12 10:16:57 +02:00
LICENSE initial commit 2015-10-12 10:16:57 +02:00
README.md Update README.md 2015-10-13 15:00:26 +02:00

syzkaller - linux syscall fuzzer

syzkaller is a distributed, unsupervised, coverage-guided Linux syscall fuzzer. It is meant to be used with KASAN (CONFIG_KASAN=y), KTSAN (CONFIG_KTSAN=y), or [KUBSAN] (http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/) (patch).

Project mailing list.

List of found bugs.

This is work-in-progress, some things may not work yet.

Usage

Coverage support is not upstreamed yet, so you need to apply this patch to gcc (tested on revision 227353) and this patch to kernel. Then build kernel with CONFIG_KASAN or CONFIG_KTSAN and the new CONFIG_SANCOV.

Then, build syzkaller/master, syzkaller/manager, syzkaller/fuzzer and syzkaller/executor. The latter is build using make in the dir, the rest are build using go build.

Then, write manager config based on manager/example.cfg.

Then, start the master process as:

$ ./master -workdir=./workdir -addr=myhost.com:48342 -http=myhost.com:29855

and start the manager process as:

$ ./manager -config my.cfg

The manager process will wind up qemu virtual machines and start fuzzing in them. If you open the HTTP address (in our case http://myhost.com:29855), you will see how corpus collection progresses.

Process Structure

Master process is responsible for persistent corpus and crash storage. It communicates with one or more manager processes via RPC.

Manager process starts, monitors and restarts several VM instances (support for physical machines is not implemented yet), and starts fuzzer process inside of the VMs. Manager process also serves as a persistent proxy between fuzzer processes and the master process. As opposed to fuzzer processes, it runs on a host with stable kernel which does not experience white-noise fuzzer load.

Fuzzer process runs inside of presumably unstable VMs (or physical machines under test). Fuzzer guides fuzzing process itself (input generation, mutation, minimization, etc) and sends inputs that trigger new coverage back to the manager process via RPC. It also starts transient executor processes.

Executor process executes a single input (a sequence of syscalls). It accepts the program to execute from fuzzer process and sends results back. It is designed to be as simple as possible (to not interfere with fuzzing process), written in C++, compiled as static binary and uses shared memory for communication.

Syscall description

syzkaller uses declarative description of syscalls to generate, mutate, minimize, serialize and deserialize programs (sequences of syscalls). Below you can see (hopefully self-explanatory) excerpt from the description:

open(file filename, flags flags[open_flags], mode flags[open_mode]) fd
read(fd fd, buf buffer[out], count len[buf]) len[buf]
close(fd fd)
open_mode = S_IRUSR, S_IWUSR, S_IXUSR, S_IRGRP, S_IWGRP, S_IXGRP, S_IROTH, S_IWOTH, S_IXOTH

The description is contained in syzkaller/sys/sys.txt file.

This is not an official Google product.