1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
|
# Setup: Linux isolated host
These are the instructions on how to fuzz the kernel on isolated machines.
Isolated machines are separated in a way that limits remote management. They can
be interesting to fuzz due to specific hardware setups.
This syzkaller configuration uses only ssh to launch and monitor an isolated
machine.
## Setup reverse proxy support
Given only ssh may work, a reverse ssh proxy will be used to allow the fuzzing
instance and the manager to communicate.
Ensure the sshd configuration on the target machine has AllowTcpForwarding to yes.
```
machine:~# grep Forwarding /etc/ssh/sshd_config
AllowTcpForwarding yes
```
## Kernel
The isolated VM does not deploy kernel images so ensure the kernel on the target
machine is build with these options:
```
CONFIG_KCOV=y
CONFIG_DEBUG_INFO=y
CONFIG_KASAN=y
CONFIG_KASAN_INLINE=y
```
Code coverage works better when KASLR Is disabled too:
```
# CONFIG_RANDOMIZE_BASE is not set
```
## Optional: Reuse existing ssh connection
In most scenarios, you should use an ssh key to connect to the target machine.
The isolated configuration supports ssh keys as described in the generic
[setup](setup.md).
If you cannot use an ssh key, you should configure your manager machine to reuse
existing ssh connections.
Add these lines to your ~/.ssh/config file:
```
Host *
ControlMaster auto
ControlPath ~/.ssh/control:%h:%p:%r
```
Before fuzzing, connect to the machine and keep the connection open so all scp
and ssh usage will reuse it.
# Optional: Pstore support
If the device under test (DUT) has Pstore support, it is possible to configure syzkaller to
fetch crashlogs from /sys/fs/pstore. You can do this by setting `"pstore": true` within
the `vm` section of the syzkaller configuration file.
# Optional: Startup script
To execute commands on the DUT before fuzzing (re-)starts,
`startup_script` can be used.
## Syzkaller
Build syzkaller as described [here](/docs/linux/setup.md#go-and-syzkaller).
Use the following config:
```
{
"target": "linux/amd64",
"http": "127.0.0.1:56741",
"rpc": "127.0.0.1:0",
"sshkey" : "/path/to/optional/sshkey",
"workdir": "/syzkaller/workdir",
"kernel_obj": "/linux-next",
"syzkaller": "/go/src/github.com/google/syzkaller",
"sandbox": "setuid",
"type": "isolated",
"vm": {
"targets" : [ "10.0.0.1" ],
"pstore": false,
"target_dir" : "/home/user/tmp/syzkaller",
"target_reboot" : false
}
}
```
Don't forget to update:
- `target` (target OS/arch)
- `workdir` (path to the workdir)
- `kernel_obj` (path to kernel build directory)
- `sshkey` You can setup an sshkey (optional)
- `vm.targets` List of hosts to use for fuzzing
- `vm.target_dir` Working directory on the target host
- `vm.target_reboot` Reboot the machine if remote process hang (useful for wide fuzzing, false by default)
Run syzkaller manager:
``` bash
./bin/syz-manager -config=my.cfg
```
If you get issues after `syz-manager` starts, consider running it with the `-debug` flag.
Also see [this page](/docs/troubleshooting.md) for troubleshooting tips.
|
