Syzkaller 环境配置与实例运行实战：从零搭建内核模糊测试平台

Syzkaller 这套环境配置，说难不算难，但说简单绝对不简单。很多人以为装好 Go、下个内核源码、编个内核、跑一下 syz-manager 就能出结果，结果常常卡在“实例运行”这一步。我自己第一次搭的时候，光 QEMU 客户机里 root 怎么免密登录就折腾了两天，后来把内核的 KCOV 漏开了，又白跑了一整个晚上。这篇 Syzkaller 实战教程，就是针对运行环境配置和实例运行这两个最容易被卡住的环节，从一台干净宿主机开始，带你一步步把 Syzkaller 完整跑起来，并且能看懂它输出的崩溃报告。适合已经对 Syzkaller 基本概念有了解、但还没成功跑通第一轮 fuzz 的开发者。

1. 为什么环境配置这么重要：先看懂 Syzkaller 的工作链路

1.1 Syzkaller 的核心组件与执行流程

在动手敲命令之前，我建议你先花五分钟把 Syzkaller 的运行机制理清楚。它不是一个单一体，而是一套分布式系统，由几个角色组成：syz-manager负责调度，跑在宿主机上；syz-fuzzer和syz-executor跑在客户机（虚拟机）里；还有一个syz-repro负责最小化复现崩溃。

整个执行流程是这样的：syz-manager生成一批随机程序（可以理解成“系统调用序列”），打包发给客户机里的syz-fuzzer，syz-fuzzer调用syz-executor去实际执行这些调用。最关键的部分在这里：内核因为开启了 KCOV 而暴露了代码覆盖率信息，客户机再把覆盖率反馈给syz-manager，manager 根据覆盖率来判断哪些输入“更有价值”，保留这些新覆盖路径的种子，再继续变异生成下一轮测试。这就是 coverage-guided fuzzing 的基本闭环。

理解了这条链路，你就能明白为什么环境依赖这么苛刻：需要一份专门编译的内核，因为它必须开启 KCOV 和 KASAN 等插桩选项；需要一台能“用完即弃”的虚拟机，因为内核崩溃了不能拖垮宿主机，而且每次重启后系统要回到干净状态；还需要 SSH 无密码登录，因为 manager 要频繁地向客户机下发任务，不可能每次手动输密码。这三个需求，就对应着后面几节我们要做的事：编译内核、制作 QEMU 镜像、配置 SSH。

1.2 三大环境依赖的版本选型思路

很多人一上来就踩版本坑。我的建议很直接：能用新版本就用新版本，尤其是 Go 和内核源码。

• 操作系统：Ubuntu 20.04 或 22.04 都可以，我这边用的是 22.04，包管理器里的工具版本比较新，省去很多编译麻烦。
• Go 语言：Syzkaller 对 Go 版本要求很严格，太老的 Go 编译会直接报错。官方跟踪的是最新稳定版，建议直接装 Go 1.22 或更高版本。
• 被测内核：用 mainline 或长期维护分支都可以。如果你是第一次跑，建议选一个较新的稳定版，太老的内核可能因为某些 config 不兼容让编译失败。
• QEMU：宿主机用包管理器装的最新版即可，客户机镜像用 Debian bullseye 或 bookworm 的 cloud 镜像最省事。

这三样关系上是层层依赖的：QEMU 提供运行环境，内核是被测对象，Go 是构建 Syzkaller 的工具链。其中任何一环版本不对，都会导致后续出现莫名其妙的错误，所以别偷懒，先统一好版本再往下走。

2. 宿主机依赖准备：一台干净机器从零装齐环境

2.1 硬件要求与虚拟化检查

先确认硬件，别嫌我啰嗦，这一步直接决定你能不能跑起来。Syzkaller 会比较“吃”资源，因为每轮 fuzz 都要启动好几个虚拟机，每个 VM 至少 2 核 2GB 内存。我建议物理机至少有 8 核 CPU 和 16GB 内存，磁盘空间留 50GB 以上（内核源码加编译产物很容易吃掉二三十 GB）。条件差一点的也至少要有 4 核 8GB，不然并发数量上不去，fuzz 效率会很难看。

另外，虚拟化功能必须开启。因为 QEMU 要依赖 KVM 加速，没有 KVM 的纯软件模拟不仅慢到让人崩溃，而且 Syzkaller 的时间控制会出问题。检查方法很简单：

ls /dev/kvm egrep -c '(vmx|svm)' /proc/cpuinfo

如果/dev/kvm不存在而 CPU 支持虚拟化，需要在 BIOS 里打开 VT-x/AMD-V；如果是云服务器，得看服务商是否支持嵌套虚拟化。这一步不确认好，后面的 VM 启动基本必挂。

2.2 安装编译工具链与 QEMU

接下来把基础工具装齐。我自己习惯一次性把包都装上，省得后面编译时缺一个补一个。在 Ubuntu 上执行：

sudo apt update sudo apt install -y build-essential flex bison libelf-dev \ libssl-dev bc dwarves qemu-system-x86 \ wget tar python3 python3-pip git ssh

逐个解释一下：build-essential提供 gcc、g++ 和 make，这是内核编译的基础；flex和bison是内核解析配置语法时用到的词法/语法分析器；libelf-dev和libssl-dev对应内核开启某些选项时的依赖；bc是内核编译中做数值计算的小工具；dwarves用于生成调试信息（pahole 依赖它）；qemu-system-x86就是我们要用的 QEMU 本体；ssh用来做宿主机与客户机之间的连接。

内核编译时最常见的报错就是“缺某个头文件或者某个工具”，这些包基本覆盖了绝大多数情况。如果你的内核版本很新，编译时还可能要gcc-12或更高版本，到时候报错再针对性装即可。

2.3 Go 工具链配置

Go 的安装有两条路：用 apt 装，或者从 go.dev 下官方二进制包。我强烈推荐后者，因为 Ubuntu 仓库里的 Go 版本往往滞后，Syzkaller 官方又总爱用新特性，版本不够就会编译失败。

先删掉可能存在的旧版本：

sudo rm -rf /usr/local/go wget https://go.dev/dl/go1.22.5.linux-amd64.tar.gz sudo tar -C /usr/local -xzf go1.22.5.linux-amd64.tar.gz

然后配置环境变量，把下面几行加到~/.bashrc末尾：

export PATH=$PATH:/usr/local/go/bin export GOPATH=$HOME/go export PATH=$GOPATH/bin:$PATH

保存后执行source ~/.bashrc，验证一下：

go version

看到类似go version go1.22.5 linux/amd64就说明 Go 环境没问题了。GOPATH 后面会用来放 Syzkaller 源码，所以顺手导出很重要。

3. 被测内核编译：KCOV、KASAN 这些开关一次配对

3.1 下载内核源码与版本选择

环境依赖里最关键的就是这份“特制内核”。Syzkaller 不能拿发行版自带内核来测，因为没开覆盖率插桩和内存检测，测了也发现不了问题。我们得自己从内核官网拉一份源码来编。

我这边用一个稳定的长期维护分支做演示，例如 v6.1 系列，你也可以换成最新的 mainline。下载方式：

mkdir -p ~/kernel && cd ~/kernel wget https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.1.55.tar.xz tar xf linux-6.1.55.tar.xz cd linux-6.1.55

如果想 git 管理，也可以 clone 内核的 git 仓库再切到指定 tag。但直接下 tarball 更快，省去 clone 整个历史的时间。源码解压后，我们进入配置环节。

3.2 内核关键编译选项与开启方法

我不建议从零手写.config，工作量太大且易错。正确姿势是先用默认配置生成基础文件，再通过scripts/config工具增量打开需要的选项。

先执行：

make defconfig make kvm_guest.config

defconfig给出一份 x86_64 的默认配置，kvm_guest.config是针对 KVM 客户机的配置片段。接着用下面的命令把关键选项打开：

./scripts/config -e KCOV -e KASAN -e KCSAN -e DEBUG_INFO \ -e DEBUG_FS -e KALLSYMS -e KALLSYMS_ALL -e DEVTMPFS \ -e BINFMT_MISC -e USER_NS -e NET_NS -e VETH -e TUN \ -e VIRTIO -e VIRTIO_PCI -e VIRTIO_NET -e VIRTIO_BLK \ -e NET_9P -e 9P_FS -e OVERLAY_FS -e CGROUPS -e MEMCG \ -e NAMESPACES -e KVM_GUEST make olddefconfig

这些选项我逐个说下用途，方便你自己按需增删：

• KCOV：这是整个 coverage-guided fuzzing 的地基。它让内核在每执行一段代码时记录“哪些代码块被执行了”，Syzkaller 靠这些信息判断输入是否发现新路径。少了它，整个 fuzz 等于瞎跑。
• KASAN：内核的地址消毒器，能检测越界访问、释放后使用、栈溢出等内存类 bugs。Syzkaller 发现的大量真实漏洞都靠它捕获，强烈建议开启。
• KCSAN：数据竞争检测器，对并发问题特别有效，但会带来额外性能开销，新手可以先不开，等 KASAN 流程跑熟再说。
• DEBUG_INFO：生成调试信息。崩溃报告里的调用栈能不能还原成函数名，就靠它。开启后编译时间和磁盘占用会变大，但值得。
• KALLSYMS/KALLSYMS_ALL：让内核符号表完整导出，日志里的函数符号更可读。
• USER_NS、NET_NS、CGROUPS等：提供用户命名空间、网络命名空间和 cgroups，方便 Syzkaller 测试更多系统调用。
• VIRTIO_*、NET_9P、9P_FS：让客户机在 QEMU 里能正常使用 virtio 磁盘、网络以及 9p 文件系统，后文做 SSH 和文件交换时会用到。
• TUN：提供 TUN/TAP 设备，多 VM 网络隔离时很有用。

我把最重要的 KCOV、KASAN、DEBUG_INFO 比作“三件套”：KCOV 负责告诉 fuzzer 哪里跑过了，KASAN 负责报告哪里出错了，DEBUG_INFO 负责让报告可读。缺任何一个，整个流程都不完整。

3.3 编译内核并确认产物

配置完成后，开始编译。这一步最消耗时间，根据机器性能可能 20 分钟到 1 小时不等。

make -j$(nproc) 2>&1 | tee build.log

编译中如果报错，先从build.log尾部看起。常见的比如有BTF: .tmp_vmlinux.btf: pahole (pahole) is not available，这就是没装dwarves导致的；还有No rule to make target 'debian/certs/signing_key.pem'，可以用./scripts/config -d SYSTEM_TRUSTED_KEYS -d SYSTEM_REVOCATION_KEYS解决。

编译完成后，确认两个关键产物：

ls -lh vmlinux ls -lh arch/x86/boot/bzImage

vmlinux是带调试信息和符号表的完整内核，bzImage是压缩后的可引导内核镜像。Syzkaller 配置里两个都会用到，缺一不可。

4. QEMU 虚拟机镜像：给 Syzkaller 准备一个可重启的“沙盒”

4.1 为什么必须是虚拟机而不是容器或物理机

有人会问，Syzkaller 能不能直接在宿主机上跑，或者用 Docker 容器代替？我的回答是：不要省这一步。Syzkaller 的 fuzz 过程中，内核崩溃是家常便饭，可能是空指针解引用，可能是死锁，甚至可能把整个系统拖到无法响应。如果直接在宿主机上跑，一次内核 panic 就能把你正在跑的服务全带崩。

虚拟机还有个不可替代的优势：快速恢复干净状态。syzyg manager 发现某个输入导致崩溃后，会直接销毁这台 VM，再启动一台全新的 VM。在全新系统上做 fuzz，才能保证每条输入都是独立验证的，测试结果才可信。QEMU 在这里承担的角色就是“一次性沙盒”：跑完即弃、随起随用。

4.2 两种镜像制作方式：create-image.sh 与手工 cloud-init

Syzkaller 官方推荐用项目里的tools/create-image.sh脚本。这个脚本基于 Docker 生成一个 Debian 镜像，并默认做好了 root 用户的 SSH 登录配置，生成的bullseye.id_rsa私钥直接就能用。

脚本路径在 Syzkaller 源码里，稍后我们会下载源码，所以这一步可以放到 Syzkaller 源码就绪后执行：

cd $GOPATH/src/github.com/google/syzkaller/tools ./create-image.sh

脚本跑完后，会在image/目录下生成bullseye.img和bullseye.id_rsa。它的好处是一次成型，免去了手工注入公钥的麻烦。

如果你不想用 Docker，也可以走手工路线：下载 Debian cloud 镜像，然后启动后用 cloud-init 注入公钥，最后重新打包。步骤相对繁琐，但核心就三步：

1. 下载debian-11-nocloud-amd64.qcow2并用qemu-img resize扩展到 10G；
2. 用cloud-localds生成包含 SSH 公钥的 seed 镜像并启动一次；
3. 进入系统，设置 root 密码、开启 SSH 的PermitRootLogin yes，把公钥写入~/.ssh/authorized_keys，然后关机。

两种方案我都在实际项目里用过，个人经验是官方脚本更省心。你如果只是想快速跑通流程，直接用官方脚本最稳。

4.3 手动启动客户机验证 SSH 链路

镜像准备好后，先别急着配置 Syzkaller，我们可以手动启动一次 VM，确认内核能引导、SSH 能连通。这一步能隔离出后面问题的根源，值得花几分钟。

先启动 VM：

qemu-system-x86_64 \ -m 2048 -smp 2 \ -kernel ~/kernel/linux-6.1.55/arch/x86/boot/bzImage \ -append "console=ttyS0 root=/dev/sda debug earlyprintk=serial" \ -drive file=$GOPATH/src/github.com/google/syzkaller/tools/image/bullseye.img,format=qcow2 \ -net user,hostfwd=tcp::10022-:22 \ -net nic \ -nographic

这段命令里，-kernel指定我们编好的 bzImage；-append是内核启动参数，把输出重定向到串口 ttyS0，方便在终端直接观察引导日志；-drive指向系统盘；-net user允许客户机通过宿主机网络出去，同时把宿主机的 10022 端口转发到客户机的 22 端口，这就是后面 SSH 登录的通道。

然后在另一个终端试试连接：

ssh -i $GOPATH/src/github.com/google/syzkaller/tools/image/bullseye.id_rsa \ -p 10022 root@localhost

能顺利进到客户机 shell 就说明 SSH 链路OK。这里我遇到过最多的问题是私钥权限太开放，SSH 直接拒绝，解决方法是用chmod 600把 id_rsa 权限收紧。如果连不上，也可以先用-p 10022 root@localhost密码方式登录排查（create-image.sh 默认把 root 密码设置为空或 fixed password，看脚本输出）。

5. Syzkaller 编译安装与 config.json 实战配置

5.1 下载并编译 Syzkaller

现在下载 Syzkaller 源码。用 git clone 到 GOPATH 下：

mkdir -p $GOPATH/src/github.com/google cd $GOPATH/src/github.com/google git clone https://github.com/google/syzkaller cd syzkaller make

编译过程会下载大量 Go 模块，网络状况差的记得开代理。编译完成后，bin目录下会出现syz-manager、syz-fuzzer、syz-executor、syz-repro等可执行文件。这里面syz-fuzzer和syz-executor稍后会被 manager 自动拷贝到客户机里，所以编译产物千万不能删。

我在这一步踩过一个坑：直接用go install安装，结果可执行文件和源码里的辅助脚本放不对位置，导致 create-image.sh 找不到路径。官方仓库的标准做法就是make，它会帮你把一切放到预期位置，别自己创新。

5.2 config.json 核心配置逐项拆解

Syzkaller 运行的唯一入口是syz-manager -config=config.json，所以配置文件就是整个实例运行的“控制中心”。我在$GOPATH/src/github.com/google/syzkaller/下建一个workdir/config.json，内容如下：

{ "target": "linux/amd64", "http": "127.0.0.1:56741", "workdir": "/root/go/src/github.com/google/syzkaller/workdir", "kernel_obj": "/root/kernel/linux-6.1.55", "image": "/root/go/src/github.com/google/syzkaller/tools/image/bullseye.img", "sshkey": "/root/go/src/github.com/google/syzkaller/tools/image/bullseye.id_rsa", "syzkaller": "/root/go/src/github.com/google/syzkaller", "procs": 8, "type": "qemu", "vm": { "count": 4, "kernel": "/root/kernel/linux-6.1.55/arch/x86/boot/bzImage", "cpu": 2, "mem": 2048 } }

我逐个说下每个字段的含义和注意点：

• target：固定写linux/amd64，表示目标平台。如果你的内核是 arm64，就改成对应的值。
• http：Web 控制台的监听地址。启动后浏览器访问http://127.0.0.1:56741就能看到实时运行状态。
• workdir：Syzkaller 保存 corpus、crashes、日志的工作目录，必须是绝对路径，且建议和源码目录分开。
• kernel_obj：我们编译内核的源码目录，Syzkaller 在这里找vmlinux来解析符号。
• image和sshkey：客户机镜像和对应的私钥路径。image对应第 4 节生成的bullseye.img，sshkey对应bullseye.id_rsa。
• procs：每台 VM 内并发执行的 fuzz 进程数。它等于每个 VM 内syz-fuzzer会派生的syz-executor数量。一般设成 CPU 核数或略少一点比较合理。
• vm.count：同时运行的虚拟机数量，受限于宿主机内存。以 4 台 VM、每台 2GB 内存算，光 VM 就要 8GB 内存，别把内存全占满。
• vm.cpu/vm.mem：每台 VM 的资源配额。2 核 2GB 是入门值，如果你的机子内存紧张可以降到 1GB，但内核编译大的话可能 OOM。

这里我特别想提一句procs和vm.count的关系：它们不是越大越好。procs 太大，每个进程分到的 CPU 时间片就少，单轮执行效率反而降低；vm.count 太大，宿主机内存负载过高，轻则频繁 swap，重则整个机器卡死。我的经验是先从procs=4, vm.count=2起步，跑通后再逐步调大。

5.3 配置检查与一次试跑

配置写完后，先手动创建 workdir 并试跑一次：

mkdir -p ~/syzkaller_work cd $GOPATH/src/github.com/google/syzkaller ./bin/syz-manager -config=workdir/config.json 2>&1 | tee manager.log

第一次跑的时候，manager 会先加载并编译客户机所需的 fuzzer/executor，然后输出类似下面的日志：

creating vm pool with 4 machines booting test machines... wait for the connections from test machines... executed 1234, cover 4567, crashes 0

看到booting test machines...就说明配置被接受了。如果启动后立即退出，查看日志中是不是有failed to create vm pool、connection failed之类的报错，这些基本都能定位到配置项写错或者镜像路径不对。

6. 正式运行 syz-manager：启动模糊测试并看懂报告

6.1 启动 manager 与日志里每一条信息的含义

配置无误后，就可以正式让 Syzkaller 跑起来了。我习惯用 nohup 放到后台运行，方便随时查看日志而不被终端占用：

cd $GOPATH/src/github.com/google/syzkaller nohup ./bin/syz-manager -config=workdir/config.json > manager.log 2>&1 &

然后tail -f manager.log观察实时日志。你应该会看到类似下面的输出，每行都有含义：

• executed 1024, cover 4096, crashes 0：这是核心统计，executed表示已执行的系统调用序列数量，cover表示当前覆盖的代码块数量，crashes是发现的内核崩溃数。如果cover持续增长，说明 fuzz 确实在探索新代码路径，这是健康的信号。
• found a crash: ...：一旦某台 VM 的内核宕了，manager 会把崩溃信息记录下来，并自动重启 VM。
• reproducing crash ...：manager 会对已发现的崩溃进行最小化复现，尽量生成一个可以稳定触发 bug 的最短输入序列。这一步可能消耗较长时间，但在重现漏洞时非常有价值。

我刚跑通时有个常见误解：以为日志里应该立刻出现一堆 crash。其实对于主线稳定版内核，可能跑一整天都是crashes 0。这很正常，别忘了 Syzkaller 是用来挖“别人还没发现的漏洞”的，不是看热闹的工具。关键是观察cover是否在增长，如果一直横盘不动，才需要排查配置问题。

6.2 Web 控制台与崩溃报告文件的结构

浏览器打开http://127.0.0.1:56741，你会看到类似 dashbord 的界面。它分几个区域：左侧是运行统计，比如当前有效语料库大小、覆盖率曲线、各 VM 连接状态；右侧是崩溃列表。页面刷新一次就能看到实时动态，这比盯终端日志直观多了。

当发现崩溃后，去 workdir 下的crashes/目录看：

find ~/syzkaller_work/crashes -type f | head

每个崩溃目录下通常会包含几类文件：

• description：人类可读的崩溃描述，比如KASAN: use-after-free in sock_wfree。这个文件是 Syzkaller 对原始日志自动提取的特征签名。
• log_*：原始内核日志，包含调用栈、寄存器状态、KASAN 报告等详细信息。
• repro_*：如果能最小化成功，会有一个可复现 bug 的程序文件（通常是 syzkaller 描述语言写的）。
• report_*：经过符号化处理的崩溃报告，里面的地址会被解析成函数名和行号，这是你后续分析漏洞最重要的依据。

我实际看一份 KASAN 报告时，通常先看description判断 bug 类型，再看log里的调用栈，找到触发点，最后用repro里的输入去一遍一遍验证修复是否生效。这套流程是后续分析漏洞的常态，建议养成习惯。

6.3 长时间运行的资源监控与会话管理

Syzkaller 一轮 fuzz 可能持续几天甚至几周，所以运行期间宿主机不能重启，资源监控也得做到位。我一般会开一个独立的 htop 窗口观察内存占用，再定期看磁盘写入情况：

df -h du -sh ~/syzkaller_work

syzkaller_work/会随着 corpus 扩大而逐渐变大，这是正常现象。如果你发现某台 VM 长时间没有输出任何 coverage，可能是这台 VM 卡死了，manager 会自己处理超时并重启 VM，不用太担心。

这里有个小技巧：如果你需要暂停 fuzz 维护宿主机，不要直接 kill 掉 syz-manager，那样可能丢 corpus。可以先发 SIGINT 或者用 Web 控制台里的停止按钮，让它先把当前状态落盘再退出。下次启动时，manager 会自动加载已保存的 corpus，从上次进度继续。

7. 运行环境配置的坑与排查速查表

7.1 最常见的几个启动失败场景与解法

我在配置过程中，以及在帮别人排查时，遇到过很多次“看起来很合理但就是跑不起来”的情况。下面这几个是出现频率最高的，我把它们整理成了速查表，建议收藏备用。

7.2 我的一些独家避坑心得

最后说几个不写在官方文档里的小经验，都是我自己拿时间换来的：

第一，永远把 vmlinux 和 bzImage 分开保存。有的人图省事只保留 bzImage，结果后续分析崩溃时拿到一堆内存地址，想借助addr2line解析符号都无从下手。vmlinux 是带符号表的“完整仓库”，任何时候都别删。

第二，config.json 里的路径尽量写绝对路径，不要写~或环境变量。syz-manager 在启动时会有自己的路径解析逻辑，我第一次用$HOME写在 json 里，结果 manager 直接找不到路径，检查了半天才反应过来是 shell 不会展开 json 里的变量。

第三，跑 fuzz 前先开一个小的 smoke test。在你完整跑“找漏洞”之前，先用一个极简单的配置（比如procs=1, vm.count=1）跑 10 分钟，确认整个链路通了再加大规模。这和我平时写代码先跑单测的思路一样，能省去洗半天错误日志的时间。

第四，不要轻视 qemu 的-nographic模式。很多人喜欢 Windows 风格的图形窗口看 VM，但 Syzkaller 在无头环境下效率更高，而且完全不需要图形化。只要你把内核输出调到串口，配合sshkey，整个运行过程全在终端和 Web 面板里就能完成。

第五，如果你改了内核源码后重新编译，记得把syzkaller_work里的旧 corpus 先备份或清理。旧的语料库是针对旧内核产生的，直接复用在新内核上可能频繁触发已经修掉的崩溃，干扰新分析。

根据我个人的体会，Syzkaller 环境配置其实不难，难点在于每一步之间都有隐藏的依赖关系。你只要把内核编译、镜像制作、SSH 链路这三块单独验证通了，再组合到一起，基本半小时内就能看到 fuzz 在跑。如果在这个过程中遇到哪个环节卡住，对照这篇教程的排查思路，绝大多数问题都能定位到具体某一层。剩下的就是耐心等cover增长，等第一个 crash 出现——那种从日志里扒出函数调用栈、再一路追到根因的感觉，才是这个工具真正让人上瘾的地方。