syzkaller Linux 内核模糊测试部署完全指南：从工具链构建到 QEMU/KVM 实战配置-平芜编程栈

网络安全
开发工具
质量保障

【免费下载链接】syzkaller

syzkaller is an unsupervised coverage-guided kernel fuzzer

项目地址：https://gitcode.com/gh_mirrors/sy/syzkaller

syzkaller 是一个无监督的覆盖率引导内核模糊测试器（coverage-guided kernel fuzzer），其核心工作方式是在多台虚拟机（VM）上运行不断变异的内核系统调用序列，并通过 KCOV 覆盖率反馈持续发现内核缺陷。本文以 docs/linux/setup.md 为主线，结合仓库内 Ubuntu 主机 + QEMU + x86-64 内核完整指南、内核配置建议、覆盖率原理与故障排查文档等资料，系统讲解搭建 Linux 内核模糊测试环境的完整链路：读者学完后可以独立完成 Go 工具链安装、syzkaller 源码构建、带 KCOV 覆盖的内核编译、VM 镜像制作、QEMU 验证以及syz-manager配置与启动，并具备常见问题的排障能力。

一、前置组件总览

根据 docs/linux/setup.md 的说明，要使用 syzkaller 需要准备以下四类组件：

组件	作用	关键要求
Go 编译器与 syzkaller 本体	syzkaller 由 Go 编写，提供`syz-manager`、`syz-executor`等程序	Go 1.23+ 工具链
带覆盖率支持的 C 编译器	编译内核时插入`__sanitizer_cov_trace_pc`插桩	GCC 6.1.0+（覆盖率支持于该版本合入）
带覆盖率支持的 Linux 内核	通过 KCOV 向用户态导出基本块地址	Linux 4.6+（`CONFIG_KCOV=y`）
虚拟机或物理设备	作为隔离的 fuzzing 工作环境，运行被测试内核	需要网络、SSH、debugfs 挂载

其中 GCC 的覆盖率支持自 6.1.0 起进入主线，而内核侧的 KCOV 支持自 Linux 4.6 合入主线。如果遇到任何安装问题，可先参考 docs/troubleshooting.md 的通用排查清单，以及 Linux 专属的 docs/linux/troubleshooting.md。

二、安装 Go 工具链并构建 syzkaller

2.1 Go 版本要求

syzkaller 使用 Go 编写，构建需要Go 1.23+工具链，项目总体目标是支持 Go 最新的两个发布版本。官方文档推荐的安装方式为下载官方 tar 包并解压：

wget https://dl.google.com/go/go1.23.6.linux-amd64.tar.gz tar -xf go1.23.6.linux-amd64.tar.gz export GOROOT=`pwd`/go export PATH=$GOROOT/bin:$PATH

2.2 下载与构建 syzkaller

git clone https://github.com/google/syzkaller cd syzkaller make

执行make后，编译产物会出现在bin/目录下。从仓库根目录的 Makefile 可以看到构建流程被拆分为host（syz-manager、syz-repro、syz-mutate、syz-prog2c、syz-db、syz-upgrade）与target（syz-execprog、syz-executor）两类目标，其中syz-executor由executor/executor.cc通过 C++ 编译器直接编译生成，并在构建前先运行syz-sysgen生成系统调用描述（sys/*/gen/*.go、executor/defs.h、executor/syscalls.h等文件）。

2.3 交叉编译参数

如果需要做跨 OS / 跨架构测试，需要在make时显式指定三个参数（详见 Makefile 顶部注释）：

TARGETOS：被测内核的操作系统（如linux）；
TARGETVMARCH：被测内核（VM）的架构；
TARGETARCH：被测测试进程的架构（与TARGETVMARCH在测试 32 位 compat 系统调用时会不同）。

例如在 darwin/amd64 主机上构建 linux/arm64：

make HOSTOS=darwin HOSTARCH=amd64 TARGETOS=linux TARGETARCH=arm64

而测试 x86 compat 系统调用（64 位内核 + 32 位测试进程）则使用：

make TARGETVMARCH=amd64 TARGETARCH=386

从 Makefile 的presubmit_arch_linux目标可以看到，项目官方预提交检查覆盖了 amd64、386、arm64、arm、loong64、mips64le、ppc64le、riscv64、s390x 等多个 Linux 目标组合。

2.4 交叉架构环境的 binutils

如果是在跨架构环境下进行 fuzzing，还需要按 docs/linux/coverage.md 的说明为 syzkaller 准备对应的binutils交叉工具（objdump、nm、addr2line、readelf），用于把 KCOV 导出的地址映射回源码行。目标三元组前缀由syz-manager配置中的target选项决定，例如 mips64le 目标：

mkdir -p ~/bin/mips64le ln -s `which mips64el-linux-gnuabi64-addr2line` ~/bin/mips64le/addr2line ln -s `which mips64el-linux-gnuabi64-nm` ~/bin/mips64le/nm ln -s `which mips64el-linux-gnuabi64-objdump` ~/bin/mips64le/objdump ln -s `which mips64el-linux-gnuabi64-readelf` ~/bin/mips64le/readelf export PATH=~/bin/mips64le:$PATH

务必在启动syz-manager之前完成 PATH 设置。关于这些工具的底层作用将在第八节详细展开。

三、C 编译器：覆盖率支持的要求

syzkaller 是覆盖率引导的模糊测试器，因此内核必须以带覆盖率插桩的方式编译。GCC 的覆盖率支持（sanitizer coverage，即-fsanitize-coverage=trace-pc族选项）已在GCC 6.1.0及之后版本发布。

先检查本机 GCC 是否满足版本要求；
若发行版自带 GCC 过旧，可参考 docs/syzbot.md 中 syzbot 使用的 GCC 列表（在 "crash does not reproduce" 一节有获取途径说明），下载并解压到$GCC目录，之后$GCC/bin/下即为可用的 GCC 二进制。

3.1 覆盖率插桩的基本原理

在编译阶段，编译器会在每个基本块插入对__sanitizer_cov_trace_pc的调用（见 docs/linux/coverage.md 的 "Object Dump and Symbolize" 一节），这些调用点成为回溯已覆盖代码行的锚点。内核运行时通过 KCOV 把实际执行到的基本块 PC 值导出给用户态，syzkaller 再与内核镜像中所有__sanitizer_cov_trace_pc调用点地址比对，即可判定哪些代码被覆盖。

四、Linux 内核：KCOV 与推荐配置

4.1 KCOV 支持

KCOV 于 Linux 4.6 进入主线，通过CONFIG_KCOV=y内核配置项启用。对更老的内核，至少需要回移（backport）提交 "kernel: add kcov code coverage"（torvalds/linux 提交 5c9a8750a6409c63a0f01d51a9024861022f6593）；此外建议回移所有涉及kernel/kcov.c的内核补丁。

4.2 推荐内核配置清单

docs/linux/kernel_configs.md 给出了完整的推荐配置清单，仓库中可参考 syzbot 的 upstream-apparmor-kasan.config 作为参照配置。按功能分组如下。

syzkaller 核心功能（覆盖率收集，对有效 fuzzing 极其重要）：

CONFIG_KCOV=y CONFIG_KCOV_INSTRUMENT_ALL=y CONFIG_KCOV_ENABLE_COMPARISONS=y CONFIG_DEBUG_FS=y

注意CONFIG_KCOV_ENABLE_COMPARISONS（比较操作数收集，用于引导"比较类"谓词的翻转）需要 GCC 8+，且老内核还需要回移 "kcov: support comparison operands collection" 与 "kcov: fix comparison callback signature" 两个提交。

内存泄漏检测（Kernel Memory Leak Detector / kmemleak）：

CONFIG_DEBUG_KMEMLEAK=y

Web 界面展示代码覆盖率（依赖内核版本）：

Linux < 5.12：CONFIG_DEBUG_INFO=y
Linux >= 5.12：CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y

检测已启用的系统调用与内核位数：

CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y

更好的沙箱隔离（sandbox）：

CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y CONFIG_CGROUP_PIDS=y CONFIG_MEMCG=y

namespace沙箱额外要求：

CONFIG_USER_NS=y

虚拟机运行要求：

在 VM 中运行时，通常需要执行make kvm_guest.config合并 QEMU/KVM 客户机所需配置。此外 tools/create-image.sh 生成的 Debian 镜像还要求：

CONFIG_CONFIGFS_FS=y CONFIG_SECURITYFS=y

建议禁用项：

# CONFIG_RANDOMIZE_BASE is not set

如果内核缺少 "arm64: setup: introduce kaslr_offset()" 与 "kcov: make kcov work properly with KASLR enabled" 这两个提交（分别位于 torvalds/linux 的 7ede8665f27cde7da69e8b2fbeaa1ed0664879c5 与 4983f0ab7ffaad1e534b21975367429736475205），禁用 KASLR 是必须的，否则覆盖率地址无法正确还原。

Predictable Network Interface Names 机制建议禁用，两种做法：

内核侧：CONFIG_CMDLINE_BOOL=y+CONFIG_CMDLINE="net.ifnames=0"；
syzkaller 配置侧：在vm段中设置"cmdline": "net.ifnames=0"（详见 docs/linux/troubleshooting.md，注意此方法并非在所有虚拟化技术上都有效）。

4.3 Bug 检测配置

syzkaller 的设计目标是与以下内存/并发错误检测器配合使用：

KASAN（主线，CONFIG_KASAN=y）：use-after-free 与越界检测，推荐同时开启内联模式：
```
CONFIG_KASAN=y CONFIG_KASAN_INLINE=y
```
KTSAN（原型可用）、KMSAN（原型可用）、KUBSAN（主线，CONFIG_UBSAN=y）。

故障注入（fault injection）配置，syzkaller 会自动识别并启用：

CONFIG_FAULT_INJECTION=y CONFIG_FAULT_INJECTION_DEBUG_FS=y CONFIG_FAULT_INJECTION_USERCOPY=y CONFIG_FAILSLAB=y CONFIG_FAIL_PAGE_ALLOC=y CONFIG_FAIL_MAKE_REQUEST=y CONFIG_FAIL_IO_TIMEOUT=y CONFIG_FAIL_FUTEX=y

老内核还需回移 "fault-inject: support systematic fault injection"、"fault-inject: simplify access check for fail-nth"、"fault-inject: fix wrong should_fail() decision in task context"、"fault-inject: add /proc/<pid>/fail-nth" 等提交。

其它经实践验证很有价值的调试配置（越多越好）：

CONFIG_LOCKDEP=y CONFIG_PROVE_LOCKING=y CONFIG_DEBUG_ATOMIC_SLEEP=y CONFIG_PROVE_RCU=y CONFIG_DEBUG_VM=y CONFIG_REFCOUNT_FULL=y CONFIG_FORTIFY_SOURCE=y CONFIG_HARDENED_USERCOPY=y CONFIG_LOCKUP_DETECTOR=y CONFIG_SOFTLOCKUP_DETECTOR=y CONFIG_HARDLOCKUP_DETECTOR=y CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y CONFIG_DETECT_HUNG_TASK=y CONFIG_WQ_WATCHDOG=y

降低误报率的超时设置：

CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=140 CONFIG_RCU_CPU_STALL_TIMEOUT=100

五、VM 准备：通用要求与支持的虚拟化类型

syzkaller 在内核 fuzzing 时使用工作虚拟机或物理设备（文档中统称为 VM）。开箱即用的 VM 类型包括QEMU、kvmtool、GCE 虚拟机、Android 设备以及 Odroid C2 板卡。一个可用的 syzkaller VM 镜像需要满足以下通用条件：

网络支持：fuzzing 进程需要与外界通信，VM 镜像必须包含网络支持；
运行中的 SSH 服务器：fuzzer 的程序文件通过 SSH 传输进 VM；
root 免密 SSH 登录：VM 的 SSH 配置应允许syz-manager配置中指定的身份以 root 登录。验证标准是能免密执行ssh -i $SSHID -p $PORT root@localhost（SSHID为 SSH 识别文件，PORT为syz-manager配置文件中指定的端口）；
挂载 debugfs：内核通过 debugfs 条目导出覆盖率，因此 VM 镜像需要在/sys/kernel/debug挂载 debugfs 文件系统。

使用 QEMU VM 时，宿主机需先安装 QEMU。可以使用仓库中的 tools/create-image.sh 脚本创建合适的 Linux 镜像；QEMU、Android 及其它类型 VM 的分步设置指南见文档顶部的专项链接列表（在 docs/linux/ 目录下）：

Ubuntu 主机 + QEMU + x86-64 内核
Linux 主机 + QEMU + arm64 内核
Linux 主机 + QEMU + arm 内核
Linux 主机 + QEMU + loongarch64 内核
Linux 主机 + QEMU + riscv64 内核
Linux 主机 + QEMU + s390x 内核
Linux 主机 + Android 真机（arm32/64 内核）
Linux 主机 + Android 虚拟设备（x86-64 内核）
Linux 隔离主机（无 VM）
Ubuntu 主机 + VMware + x86-64 内核
Ubuntu 主机 + VirtualBox + x86-64 内核

六、端到端实战：Ubuntu 主机 + QEMU + x86-64 内核

本节内容取自 docs/linux/setup_ubuntu-host_qemu-vm_x86-64-kernel.md，环境为 Ubuntu 宿主机 + QEMU 虚拟机 + Debian Trixie 客户机镜像，被测试内核为 x86-64。下文使用$VAR记号表示需要在执行中替换的目录路径（$GCC、$KERNEL、$IMAGE等）。

6.1 安装编译依赖

sudo apt update sudo apt install make gcc flex bison libncurses-dev libelf-dev libssl-dev

6.2 GCC

若发行版 GCC 过旧，从 docs/syzbot.md 所列列表中获取最新 GCC 并解压到$GCC。验证：

ls $GCC/bin/ # 示例输出： # cpp gcc-ranlib x86_64-pc-linux-gnu-gcc x86_64-pc-linux-gnu-gcc-ranlib # gcc gcov x86_64-pc-linux-gnu-gcc-9.0.0 # gcc-ar gcov-dump x86_64-pc-linux-gnu-gcc-ar # gcc-nm gcov-tool x86_64-pc-linux-gnu-gcc-nm

注意：Ubuntu 20.04 LTS 自带 GCC 已足够新，可跳过此节。

6.3 内核源码与配置

获取内核源码（建议使用最新稳定版，示例为 v6.2）：

git clone --branch v6.2 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git $KERNEL

生成默认配置（如需指定编译器则追加CC="$GCC/bin/gcc"）：

cd $KERNEL make defconfig make kvm_guest.config

编辑.config（或通过make menuconfig）启用第四节列出的必需配置项，最低要求如下：

# Coverage collection. CONFIG_KCOV=y # Debug info for symbolization. CONFIG_DEBUG_INFO_DWARF4=y # Memory bug detector CONFIG_KASAN=y CONFIG_KASAN_INLINE=y # Required for Debian Stretch and later CONFIG_CONFIGFS_FS=y CONFIG_SECURITYFS=y

由于启用这些选项会解锁更多子选项，需要重新生成配置：

make olddefconfig

另外建议通过以下配置禁用 Predictable Network Interface Names：

CONFIG_CMDLINE_BOOL=y CONFIG_CMDLINE="net.ifnames=0"

6.4 编译内核

make -j`nproc`

编译完成后应得到内核二进制与打包镜像：

ls $KERNEL/vmlinux # sample output - $KERNEL/vmlinux ls $KERNEL/arch/x86/boot/bzImage # sample output - $KERNEL/arch/x86/boot/bzImage

6.5 制作 VM 磁盘镜像

安装 debootstrap 后，用 tools/create-image.sh 创建 Debian Trixie 镜像（脚本可从仓库直接查看或下载到本地执行）：

sudo apt install debootstrap mkdir $IMAGE cd $IMAGE/ wget https://raw.githubusercontent.com/google/syzkaller/master/tools/create-image.sh -O create-image.sh chmod +x create-image.sh ./create-image.sh

执行结果应为$IMAGE/trixie.img磁盘镜像，同时生成trixie.id_rsa[.pub]SSH 密钥。

常用可选参数（更多参数见./create-image.sh -h，脚本 tools/create-image.sh 的 help 文本中说明了全部选项）：

指定其它 Debian 版本（bookworm、bullseye、sid 等）：./create-image.sh --distribution bookworm；
安装额外常用工具包（make,sysbench,git,vim,tmux,usbutils,tcpdump等，可通过ADD_PACKAGE环境变量覆盖，见脚本内PREINSTALL_PKGS/ADD_PACKAGE定义）：./create-image.sh --feature full；
额外安装 perf（非必需，需要KERNEL环境变量指向内核源码树）：./create-image.sh --add-perf；
指定架构 / 输出前缀 / 镜像大小：--arch、--output、--seek（镜像大小单位 MB，默认 2048MB）。

脚本底层通过 debootstrap 以--include方式预装openssh-server、curl、tar、gcc、libc6-dev、time、strace、sudo、less、psmisc等包，并支持跨架构（--arch与宿主机架构不一致时自动启用 qemu-user-static + binfmt，见脚本中FOREIGN分支逻辑）。

6.6 验证 QEMU 启动与 SSH

安装 QEMU 后用以下命令验证内核能启动且sshd正常运行：

sudo apt install qemu-system-x86 qemu-system-x86_64 \ -m 2G \ -smp 2 \ -kernel $KERNEL/arch/x86/boot/bzImage \ -append "console=ttyS0 root=/dev/sda earlyprintk=serial net.ifnames=0" \ -drive file=$IMAGE/trixie.img,format=raw \ -net user,host=10.0.2.10,hostfwd=tcp:127.0.0.1:10021-:22 \ -net nic,model=e1000 \ -enable-kvm \ -nographic \ -pidfile vm.pid \ 2>&1 | tee vm.log

启动日志中应能看到内核解压、启动，以及：

[ ok ] Starting enhanced syslogd: rsyslogd. [ ok ] Starting periodic command scheduler: cron. [ ok ] Starting OpenBSD Secure Shell server: sshd.

随后在另一个终端验证 SSH：

ssh -i $IMAGE/trixie.id_rsa -p 10021 -o "StrictHostKeyChecking no" root@localhost

若报 "too many tries"，是因为 ssh 在显式-i之前先尝试了默认密钥，追加-o "IdentitiesOnly yes"即可；
关闭 QEMU：先按Ctrl+A再按X，或执行kill $(cat vm.pid)。

QEMU 能正常启动、内核能引导、SSH 能连通之后，即可关闭 QEMU 并启动 syzkaller。

6.7 编写 syz-manager 配置并启动

按 docs/linux/setup.md 构建 syzkaller 后，创建如下管理器配置（将$GOPATH、$KERNEL、$IMAGE替换为实际值）：

{ "target": "linux/amd64", "http": "127.0.0.1:56741", "workdir": "$GOPATH/src/github.com/google/syzkaller/workdir", "kernel_obj": "$KERNEL", "image": "$IMAGE/trixie.img", "sshkey": "$IMAGE/trixie.id_rsa", "syzkaller": "$GOPATH/src/github.com/google/syzkaller", "procs": 8, "type": "qemu", "vm": { "count": 4, "kernel": "$KERNEL/arch/x86/boot/bzImage", "cpu": 2, "mem": 2048 } }

启动管理器：

mkdir workdir ./bin/syz-manager -config=my.cfg

此时 syzkaller 应已开始运行，用浏览器访问127.0.0.1:56741即可查看管理器状态与已发现的崩溃。若启动后遇到问题，可加-debug标志运行以输出完整调试信息。

6.8 配置参数语义（结合源码）

对照 pkg/mgrconfig/config.go 与 pkg/mgrconfig/load.go 可确认各字段的实际作用与校验逻辑：

字段	含义	源码注记
`target`	目标 OS/架构（如`linux/amd64`），决定交叉工具链前缀	用于 binutils 三元组识别
`http`	管理界面监听地址	`127.0.0.1:56741`
`workdir`	工作目录，存放`crashes/`（崩溃输出）、`corpus.db`（感兴趣程序语料库）、`instance-x`（各 VM 临时文件）	见 pkg/mgrconfig/config.go 第 24-27 行注释
`kernel_obj`	内核源码/`vmlinux`目录，用于符号化	`KernelObj`字段
`image`	VM 磁盘镜像路径	对应上文`trixie.img`
`sshkey`	SSH 私钥路径	`load.go`会校验私钥权限（未受保护会报`sshkey ... is unprotected`，需`chmod 0600`）
`syzkaller`	syzkaller 源码目录	用于向 VM 内拷贝程序文件
`procs`	每个 VM 内并行执行的 fuzzing 进程数	`load.go`校验范围`[1, prog.MaxPids]`
`type`	VM 类型（`qemu`、`gce`、`isolated`等）	`Type`字段
`vm`	VM 专属参数：`count`（VM 数量）、`kernel`（bzImage 路径）、`cpu`（每 VM CPU 数）、`mem`（每 VM 内存 MB）、`cmdline`（追加内核命令行，如`net.ifnames=0`）	`VM`为`json.RawMessage`，由各 VM 后端解析

七、故障排查清单

7.1 setup.md 中的两个经典问题

QEMU 的-enable-kvm需要 root 权限

解决方法：把当前用户加入kvm组并重新登录：

sudo usermod -a -G kvm

QEMU 因 MSR 断言崩溃

报错形如：

qemu-system-x86_64: error: failed to set MSR 0x48b to 0x159ff00000000 qemu-system-x86_64: /build/qemu-EmNSP4/qemu-4.2/target/i386/kvm.c:2947: kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed.

解决方法：从 QEMU 命令行移除-cpu host,migratable=off。最便捷的做法是在syz-manager配置中把qemu_args设为-enable-kvm。

7.2 Linux 专属排查（docs/linux/troubleshooting.md）

检查 QEMU 能否成功引导 VM：例如按image配置值为IMAGE、按kernel配置值为KERNEL，执行qemu-system-x86_64 -hda $IMAGE -m 256 -net nic -net user,host=10.0.2.10,hostfwd=tcp::23505-:22 -enable-kvm -kernel $KERNEL -append root=/dev/sda；
检查 VM 内入站 SSH：ssh -i $SSHKEY -p 23505 root@localhost。若 SSH 不通，注意defconfig有时过于精简而遗漏网络选项，需确保内核配置包含：
```
CONFIG_VIRTIO_NET=y CONFIG_E1000=y CONFIG_E1000E=y
```
"Failed to start Raise network interfaces"：这是 Predictable Network Interface Names 机制导致的，两种解法见第四节；
检查 KCOV 是否在 VM 内可用：
- ls /sys/kernel/debug（确认 debugfs 已挂载）
- ls /sys/kernel/debug/kcov（确认 kcov 已启用）
- 从Documentation/kcov.txt构建测试程序并在 VM 内运行；
检查调试信息：把 kcov 测试程序输出的十六进制地址交给addr2line -a -i -f -e $VMLINUX（VMLINUX为kernel_obj配置对应的vmlinux），确认内核符号可用。

7.3 通用排查（docs/troubleshooting.md）

-debug标志：让syz-manager顶层程序与syz-executor实例输出全部调试信息，此模式下只运行一个 VM 实例；
-vv N标志：提高日志输出量（syz-executor日志写入工作目录crashes子目录），N 越大输出越多；
executor 故障：若日志出现executor failure，可把syz-executor与syz-execprog拷入运行中的 VM，手动执行./syz-execprog -executor ./syz-executor -debug sampleprog（sampleprog是简单系统调用脚本，如仅含getpid()）。若报告clone失败，通常说明测试内核缺少所需命名空间支持，改用-sandbox=setuid可解决，主配置也应同步把sandbox设为setuid；
failed to copy binary：若使用 Buildroot 镜像且错误输出含subsystem request failed on channel 0，通常是 OpenSSH 9.0 起强制使用 SFTP 协议所致，升级 Buildroot 镜像到最新版并确保启用 SFTP。

若以上手段均无效，可携带所用 syzkaller commit id 与开启-debug后的syz-manager输出提交问题反馈。

八、覆盖率数据的底层还原原理

部署成功后，理解 docs/linux/coverage.md 描述的覆盖率数据链路有助于定位符号化类问题。syzkaller 使用 kcov 收集内核覆盖率：kcov 导出每个已执行基本块的地址，syzkaller 运行时借助binutils工具把这些地址映射回源码中的行与函数。

readelf：用于检测虚拟内存偏移。命令readelf -SW kernel_image列出节头；执行器把 PC 值截断为uint32后交给syz-manager，后者依据PROGBITS节头信息恢复偏移——要求所有PROGBITS节在Address字段的高 32 位相同，该 32 位即作为恢复偏移；
nm：解析内核镜像中每个函数的地址与大小（nm -Ptx kernel_image，-P使用可移植输出格式，-tx以十六进制输出数值）。只关心类型为t/T的代码节符号，最终得到"符号名 → 起止地址"映射，用于判断某些函数是否被调用到；
objdump：解析内核镜像中每个__sanitizer_cov_trace_pc调用的 PC 值（objdump -d --no-show-raw-insn kernel_image），这些 PC 代表镜像内全部代码，kcov 导出的 PC 与之比对即可判定覆盖率；
addr2line：把 kcov 导出、objdump解析出的 PC 映射回源文件与行号（addr2line -afi -e kernel_image，-afi表示显示地址、函数名并展开内联函数）。最终构建"PC → 帧数组"哈希表，每帧包含PC、Func、File、Line、Inline五个字段；由于内联，单个 PC 可能对应多个帧。

报告层面，覆盖判定先把程序 PC 序列与函数地址区间比对得出被调用函数，再按帧哈希表把覆盖信息聚合到源文件，最终以基本块（而非行）为单位存储每个文件的lines、totalPCs、coveredPCs、totalInline、coveredInline等统计。

结语

从 Go 工具链与make构建，到带 KCOV/GCC 覆盖率支持的内核编译，再到create-image.sh制作 Debian 镜像、QEMU 验证与syz-manager启动，本文完整还原了 docs/linux/setup.md 的部署主线，并补充了内核配置建议、Ubuntu + QEMU + x86-64 专项指南、覆盖率原理与两级故障排查文档的细节。按照上述流程逐步执行即可获得一个可工作的 Linux 内核 fuzzing 环境；如需覆盖其它架构（arm64、arm、riscv64、s390x 等）或 Android 设备，请以文档顶部列出的对应专项指南为准。