github.com/google/syzkaller@v0.0.0-20240517125934-c0f1611a36d6/docs/linux/setup_linux-host_isolated.md (about)

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