1. Usage.

2. Implement detail.

3. Practice.

To implement coverage filter in syzkaller. we have to follow the next steps:

1. Get the LLVM ir code and assembly code of target.

2. Get the addresses map of target functions by analyzing ir code, assembly code and kernel ELF.

3. Support cover filter and weighted PCs in syzkaller.

After step 1 and 2, you will get a addresses map contains addresses of any kernel functions you need. Also, you can attach weight to every PC base on LLVM ir analysis, eg. weighted PCs base on CFG information.

Lots of static analysis tools can be used to parse ir code. But ir code know nothing about addresses of the final executable file while the assembly code holds both address offset and basic block information. By analyzing them, we can associate ir information with addresses.

To get ir code and assembly code, you need to pick out the source file where your target functions located at. For example, if your target function is in /net/ipv4/tcp.c, you should run this command in your kernel build tree:

```

```

to get the command of compiling tcp.c, command may look like:

```

```

To get the LLVM ir code of tcp.c, run:

```

```

To get the assembly code of tcp.c, run:

```

```

Repeat the mentioned steps to get all ir codes and assembly codes of your target functions. Move them to a IR_DIR and ASM_DIR. Then build your kernel and get a VMLINUX file.

We use a [kcov_map](../static_analysis_tools/IRParser/kcov_map.cpp) tool to get addresses of the kernel functions we are interested in.

Run the following command to build kcov_map:

```

```

```

```

FUNCTION_LIST has functions name that we need to get their addresses.

IR_DIR: directory all the LLVM ir code we need.

ASM_DIR: directory all the assembly code we need.

VMLINUX_FILE: kernel ELF

LOG_DIR: after run the command, kcov_map will creat a "*.json" and a "*.addr.map" for every function.

Then run:

```

```

Copy funcaddr.map to syzkaller work directory.

This is only one of ways when we try to build functions addresses map with weight. You can explore how to build your functions addresses map for you need.

In our practice, when we choose some member functions as entry, some functions may be a wrapper function but not the truly implement function. We use [extend_func](../static_analysis_tools/IRParser/extend_func.cpp) extend the function list.

```

```

```

```

You will get a FUNCTION_LIST.new which you can pass to kcov_map.

Clone syzkaller, and run:

```

```

Build syzkaller as usual.

Add the following options in syz-manager configure file:

```

```

The "covfilter" enable coverage filter of executor. If you only want to use weighted PCs feature without filter, set it to false. If you want to use cover filter only, without weighted PCs, just create your map that every PC has weight 1.

Now you can run a syzkaller with cover filter.

The configure specifies which funcaddr.map should be loaded and send to VM. Function readPCsWeight in syz-manager/manager.go will read the funcaddr.map and maintain a pcsWeight map in structure manager. This pcsWeight map can be used while calculating the weight of prog in web UI.

Extend a getPCsWeight interface in RPCManagerView in syz-manager/rpc.go for waiting client call( fuzzer) for getting a pcsWeight map.

Use the syzkaller web UI "cover", we extend an interface called bitmap. It will convert PCs table to source lines. The color of lines is black means the block of this line won't be drop while fuzzing. The number at the left is the weight of that line. Note that there may be multiple block maps to a source line. Their weight will add to this line.

Add a getPCsWeight() for fuzzer, so fuzzer can dynamically fetch PCs table from syz-manager. In other words, it's possible to dynamically distribute PCs table to different fuzzers. For example, light PCs weight while some block has been fully explored[]().

We implement a function calCoverWeight in syz-fuzzer/proc.go to calculate the weight and attach to structure prog. You can implement your algorithm of calculating weight base on weighted pc in this function.

Syzkaller already has its prior choice base on signals length of the prog. We have to modify the addInputToCorpus function to use out prog weight.

The executor/bitmap.h implement function for getting PCs table from the map.

Unlike manager and fuzzer, executor coverage filter run more frequently. Without a fast search, if the PCs table grow up, the affect of performance can be a disaster. So we use a fast but rough way, bitmap, to address this program. We assume that kernel text size is less than 0x3000000, and we maintain a map:

```

```

Because address align, the lowest 4-bit is dropped off. So, for quickly setting and accessing the bit which record if a pc should be filtered, we can search by:

```

```

The affect of performance will not grow up no mater how many PCs should be filtered.

Cover filtering is quite certain that you can only set if the edge of that pc will be sent to fuzzer as a signal or not. But, weighted PCs can guide fuzzer to evolve prog flexibly. You can assign weight to PCs base on the result from LLVM ir static analysis.

In the theory of cyclomatic complexity[1](https://en.wikipedia.org/wiki/Cyclomatic_complexity), a function can be treated as a one-entry and one-exit model, the complexity can be easily calculated. In realistic application, complexity indicates that program testing should pay more attention to those functions that are more complex.

The LLVM class [BlockFrequencyInfo](https://llvm.org/doxygen/classllvm_1_1BlockFrequencyInfo.html) is a convenient way to get the frequency of a block will appear in all potential control-flow paths. It's reasonable that if a basic block appeared more frequently, mutate the prog that triggers this block has a higher probability to cover more other PCs edge.

The LLVM class [BranchProbabiltyInfo](https://llvm.org/doxygen/classllvm_1_1BranchProbabilityInfo.html) is another tool that can be used in fuzzing. The class has information about the probability of from a block to another block. If you want the fuzzer to evolve a testcase can cover a specific basic block, it's a good choice that uses BranchProbabilityInfo weighted the PCs.

The mentioned tools focus on if the functions should be fuzzed is already picked out, how to assign priorities to PCs base on CFG information. Sometimes, you may want to fuzz an approximate range, for example, a serial of functions from a call stack. LLVM class [CallGraph](https://llvm.org/doxygen/classllvm_1_1CallGraph.html) can help build the associate of functions call. You can assign low weight to those functions if they are deep and not so complex.

1. Usage.

2. Implement detail.

3. Practice

To implement collect kernel states as syzkaller resource, we have to follow the next steps:

1. Build kernel with GEPOperator tracker instrument.

2. Support collecting kernel state in syzkaller.

3. Weighted kernel states for fuzzer.

First, we need to implement a LLVM pass to do instrument. While we already knew, lots of states of kernel are located in some field of structure. Tracking the store operation of a variable of GEPointer can detect states which may help to fuzzer. Then, refer to [this document]() to build you compiler with field assignment tracker. While building kernel, you have to add line such like:

```

```

to Makefile for the object file you need to instrument it. The kernel state id is the hash of structure name and field name.

Refer to our [implement](../instrument/kcov_trace_srt.patch) of instrument to collect kernel state. Then, build your kernel as usual.

Clone syzkaller, run:

```

```

build syzakller as usual. Add the following line to configure file:

```

```

You can use our tool [kstate_map](../static_analysis_tools/IRParser/kstate_map.cpp) get the kernel state map. run:

```

```

FUNCTION_LIST has the functions name we need to get their addresses.

IR_DIR: directory all the LLVM ir code we need.

LOG_DIR: after run the command, kstate_map will creat a "*.json" and a "*.state.map" for every function.

Write the output to PATH_TO_KERNEL_STATE.map. And run patched syzkaller as usual. This map assigns weight base on the frequency of state using.

Now, you can run syzkaller as usual, and you can find there is a list of kernel states if you access a "\input" interface. You can also get states weight of every prog in "/corpus" interface.

We reuse the KCOV interface instead of using a separate mode. So, we encode the state id with 0xfefe at the highest 16-bit. While syzkaller gets a kcov pc started with 0xfefe, it realizes this pc is a kstate id and the value and address of the state will occupy the followed 2*64-bit. No matter how many bit the variable used, we formalize to 64-bit. Noted if you want to collect other information, you have to implement a corresponding syzkaller for it.

syz-executor have to pick out kernel states and send them out after all signal was sent. These handling can be found in our patch for executor.cc function write_coverage_signl. While executor read a pc started with 0xfefe, that means it receives a kernel state. And we use a chunk of shared memory for this state after coverage signal shared memory. syz-fuzzer will handle them later.

Correspondingly, parseOutput in pkg/ipc.go is called by fuzzer and we add a readKernState for parse the executor output. And these kernel states information will be put into a structure called KernState in pkg/kstate/kstate.go. Every input from executor has an array for kernstate, and every prog has a state weight calculated from kernstates. Also, KernState support searching the map by its ID or ID^Value which called it hash.

syz-fuzzer/proc.go: calStateWeight will calculate the weight of a prog. Minus count for eliminating the influence of the length of kstate. prog/rand.go: chooseReaProgramIdx function implement a prior choice of prog base on its states weight

We have explored two ways in assigning weight to resources.

This tool is what we mentioned above kstate_map. We use LLVM api static analyze the using of states in target functions. Without any awareness of the value of a state, it just encourages fuzzer to preferentially choose and extract those progs that frequently rewrite important states. In other words, the prog has complex states.

We use a [clang checker](../static_analysis_tools/ConditionChecker/) to get symbolic information of condition constraint:

```

```

You can get some constraint value of variables. And patched syzkaller support a hash mode, if a ID^value can be found in the kstate map, use it as a unique state. So, you can specify a weight for a state with special value. Now, it can be specified in kstatemap manually only.