📋 论文速览

标题：A Survey of Operating System Kernel Fuzzing

作者：Jiacheng Xu, He Sun, Shihao Jiang, Qinying Wang✉, Mingming Zhang, Xiang Li, Kaiwen Shen, Charles Zhang, Shouling Ji, Peng Cheng✉, Jiming Chen

机构：浙江大学 · 清华大学 · 南开大学 · 中关村实验室

期刊：ACM Transactions on Software Engineering and Methodology (TOSEM), 2025

核心贡献：首个专注于操作系统内核 Fuzzing 的系统化综述，梳理 2017-2025 年间 107 篇顶会论文，提出三阶段九功能的分类体系，揭示内核 Fuzzing 与用户态 Fuzzing 的本质差异，并指出未来研究方向。

🎯 为什么内核 Fuzzing 这么难？

OS 内核是现代计算系统的基石，其漏洞可导致权限提升、敏感数据泄露和远程代码执行（如著名的 DirtyCow 漏洞）。然而，与用户态 Fuzzing 相比，内核 Fuzzing 面临三大独特挑战：

🔴 C1：受限的运行环境

内核与硬件紧密耦合。Linux 支持超过 13,000 种 PCI 设备，但主流模拟器 QEMU 仅实现不到 130 种。部署真机成本高且不可扩展，模拟器又无法覆盖设备多样性。闭源系统和资源受限场景更加剧了这一困境。

🟡 C2：复杂的输入接口

内核暴露的接口远比用户态丰富——系统调用、文件系统、外设 I/O，且输入是深度结构化的。例如 ioctl 的参数因设备而异，嵌入嵌套结构，约束规则藏在百万行代码中。跨接口交互（如文件系统镜像 + 系统调用组合）更是放大了输入空间。

🟢 C3：高度有状态性

内核维护全局、长期存活的执行上下文，触发一个 Bug 可能依赖特定系统调用序列（如 mlockall → mmap → msync）。每次重启重置内部状态，迫使 Fuzzer 重新探索已发现的状态，造成巨大浪费。

⚙️ 三阶段九功能：内核 Fuzzing 的全景地图

论文提出阶段化 Fuzzing 模型，将内核 Fuzzing 分解为三个核心阶段、九个关键功能：

🔹 阶段一：环境准备（Environment Preparation）

功能	核心问题	关键技术
F1.1 执行环境	在哪跑？真机还是模拟器？	On-device / 全模拟 / Rehosting
F1.2 覆盖率收集	怎么知道测到哪了？	源码插桩 / 动态插桩 / 硬件辅助
F1.3 Bug 检测	怎么发现 Bug？	Fatal Signal / Sanitizer / 语义检查

🔹 阶段二：输入模型（Input Model）

功能	核心问题	关键技术
F2.1 接口识别	测哪些入口？	系统调用 / 外设 / 文件系统 / 网络
F2.2 规格感知	输入长什么样？	静态推断 / 动态分析 / LLM 辅助
F2.3 依赖识别	调用间有什么关系？	显式依赖（资源传递） / 隐式依赖（状态共享）

🔹 阶段三：Fuzzing 循环（Fuzzing Loop）

功能	核心问题	关键技术
F3.1 变异智能	怎么变才能测得更多？	约束求解 / 线程调度 / 决策智能
F3.2 执行吞吐	怎么跑得更快？	虚拟化增强 / 系统快照
F3.3 反馈机制	怎么引导探索？	定向 Fuzzing / 状态导向 / 并发导向

📊 107 篇论文揭示了什么？

论文分布：

• 67% 发表在安全顶会（USENIX Sec 占 28%，最多）

• 17% 软件工程会议，9% 系统会议

• 59% 的论文专门针对 Linux 内核 Fuzzing（受益于 Syzkaller 生态）

功能关注度分布：

阶段	占比	最热门功能
环境准备	32%	执行环境 F1.1（18%）
输入模型	29%	规格感知 F2.2（12%）
Fuzzing 循环	39%	反馈机制 F3.3（19%）

💡 关键发现：执行环境（F1.1）和反馈机制（F3.3）是研究最密集的两大方向，恰好对应内核 Fuzzing 最大的两个痛点——环境搭建难和状态探索难。

🔬 六大核心洞察

洞察 1：OS 无关的 Rehosting 仍是开放问题

当前内核 Fuzzing 环境难以在稳定性、开销和可观测性之间取得平衡，尤其是对 RTOS 和 TEE。模拟器保真度不足导致 Fuzzer 频繁卡死，亟需更通用的轻量级全系统模拟方案。

洞察 2：覆盖率鸿沟显著

约 77% 的灰盒 Fuzzer 采用源码插桩，可获得细粒度覆盖率；而二进制内核中 95%的技术只能提供粗粒度指标。如何在无源码条件下获取丰富覆盖率反馈，是一个关键挑战。

洞察 3：Bug 检测不能只盯内存错误

现有 Bug 检测主要依赖 Sanitizer 捕获内存错误，但非崩溃型语义 Bug（逻辑错误、状态不一致）的检测仍处于早期。差分测试和语义检查器是未来方向，但缺乏合适的参照基准。

洞察 4：跨接口交互是被忽视的金矿

单接口 Fuzzing 最多遗漏 77% 的内核代码。Janus 等工具证明，系统调用 + 文件系统镜像的联合 Fuzzing 能显著提升覆盖率，但系统化的跨接口方法论仍然缺失。

洞察 5：规格生成需要混合方案

静态推断覆盖广但不够精确，动态分析真实但遗漏不活跃路径，LLM 方法（如 KernelGPT）生成速度提升 6 倍且准确率 93.3%，但无法处理间接调用。三者互补，混合方案才是正解。

洞察 6：隐式依赖是最大难点

显式依赖（如 open 返回 fd → mmap 使用 fd）已被较好建模，但隐式依赖（如 mlockall 影响 msync 行为）的发现和建模仍然困难。MOCK 和 Countdown 等方法试图从执行轨迹中挖掘隐式依赖，但通用性有限。

🛠️ 代表性工具一览

工具	年份	目标	核心创新
Syzkaller	2017	Linux/通用	8000+ 系统调用描述，生态基石
kAFL	2017	Win/Linux	Intel PT 硬件辅助覆盖率
Janus	2019	Linux FS	文件系统 + 系统调用双维度输入
SyzDescribe	2023	Linux	自动化系统调用规格推断
KernelGPT	2025	Linux	LLM 驱动规格生成，6× 加速
SyzTrust	2024	TEE	ARM CoreSight 硬件追踪
MOCK	2024	Linux	隐式依赖挖掘
Monarch	2024	Linux	语义感知 Bug 检测

🔮 未来方向：六大待解难题

1. 通用 Rehosting 框架

现有模拟方案各管一段，需要统一的轻量级全系统模拟框架，支持 RTOS、TEE、IoT 等多样化内核。

2. 无源码覆盖率收集

95% 的二进制内核覆盖率技术只有粗粒度反馈。Intel PT / ARM ETM 提供了硬件级方案，但解码和部署复杂度仍是瓶颈。

3. 非崩溃 Bug 检测

语义 Bug、逻辑错误不会导致崩溃，但同样危险。需要更通用的语义检查器和差分测试框架。

4. 系统化跨接口 Fuzzing

从"单接口 Fuzzing"走向"多维输入 Fuzzing"，建立通用的接口交互建模方法论。

5. LLM + 传统方法混合

KernelGPT 已证明 LLM 在规格生成上的潜力，但间接调用和隐式语义仍是短板。LLM 应作为传统分析的补充，而非替代。

6. 状态导向 Fuzzing

分支覆盖率不足以衡量内核状态探索深度。需要状态感知的适应度指标和高效的状态快照/恢复机制。

📝 一句话总结

内核 Fuzzing 不是用户态 Fuzzing 的简单移植——环境受限、接口复杂、状态深层三大挑战决定了它需要专属的方法论。这篇综述用三阶段九功能的分类法为领域画出了第一张全景地图，也画出了未来的路。

---

📌 点赞 + 收藏 + 分享，你的支持，是我们持续解析高水平软件安全论文的最大动力！