论文速览标题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 / 全模拟 / RehostingF1.2 覆盖率收集怎么知道测到哪了源码插桩 / 动态插桩 / 硬件辅助F1.3 Bug 检测怎么发现 BugFatal 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.118%输入模型29%规格感知 F2.212%Fuzzing 循环39%反馈机制 F3.319%关键发现执行环境F1.1和反馈机制F3.3是研究最密集的两大方向恰好对应内核 Fuzzing 最大的两个痛点——环境搭建难和状态探索难。 六大核心洞察洞察 1OS 无关的 Rehosting 仍是开放问题当前内核 Fuzzing 环境难以在稳定性、开销和可观测性之间取得平衡尤其是对 RTOS 和 TEE。模拟器保真度不足导致 Fuzzer 频繁卡死亟需更通用的轻量级全系统模拟方案。洞察 2覆盖率鸿沟显著约 77% 的灰盒 Fuzzer 采用源码插桩可获得细粒度覆盖率而二进制内核中 95%的技术只能提供粗粒度指标。如何在无源码条件下获取丰富覆盖率反馈是一个关键挑战。洞察 3Bug 检测不能只盯内存错误现有 Bug 检测主要依赖 Sanitizer 捕获内存错误但非崩溃型语义 Bug逻辑错误、状态不一致的检测仍处于早期。差分测试和语义检查器是未来方向但缺乏合适的参照基准。洞察 4跨接口交互是被忽视的金矿单接口 Fuzzing 最多遗漏 77% 的内核代码。Janus 等工具证明系统调用 文件系统镜像的联合 Fuzzing 能显著提升覆盖率但系统化的跨接口方法论仍然缺失。洞察 5规格生成需要混合方案静态推断覆盖广但不够精确动态分析真实但遗漏不活跃路径LLM 方法如 KernelGPT生成速度提升 6 倍且准确率 93.3%但无法处理间接调用。三者互补混合方案才是正解。洞察 6隐式依赖是最大难点显式依赖如 open 返回 fd → mmap 使用 fd已被较好建模但隐式依赖如 mlockall 影响 msync 行为的发现和建模仍然困难。MOCK 和 Countdown 等方法试图从执行轨迹中挖掘隐式依赖但通用性有限。️ 代表性工具一览工具年份目标核心创新Syzkaller2017Linux/通用8000 系统调用描述生态基石kAFL2017Win/LinuxIntel PT 硬件辅助覆盖率Janus2019Linux FS文件系统 系统调用双维度输入SyzDescribe2023Linux自动化系统调用规格推断KernelGPT2025LinuxLLM 驱动规格生成6× 加速SyzTrust2024TEEARM CoreSight 硬件追踪MOCK2024Linux隐式依赖挖掘Monarch2024Linux语义感知 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 的简单移植——环境受限、接口复杂、状态深层三大挑战决定了它需要专属的方法论。这篇综述用三阶段九功能的分类法为领域画出了第一张全景地图也画出了未来的路。 点赞 收藏 分享你的支持是我们持续解析高水平软件安全论文的最大动力
论文速览标题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 / 全模拟 / RehostingF1.2 覆盖率收集怎么知道测到哪了源码插桩 / 动态插桩 / 硬件辅助F1.3 Bug 检测怎么发现 BugFatal 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.118%输入模型29%规格感知 F2.212%Fuzzing 循环39%反馈机制 F3.319%关键发现执行环境F1.1和反馈机制F3.3是研究最密集的两大方向恰好对应内核 Fuzzing 最大的两个痛点——环境搭建难和状态探索难。 六大核心洞察洞察 1OS 无关的 Rehosting 仍是开放问题当前内核 Fuzzing 环境难以在稳定性、开销和可观测性之间取得平衡尤其是对 RTOS 和 TEE。模拟器保真度不足导致 Fuzzer 频繁卡死亟需更通用的轻量级全系统模拟方案。洞察 2覆盖率鸿沟显著约 77% 的灰盒 Fuzzer 采用源码插桩可获得细粒度覆盖率而二进制内核中 95%的技术只能提供粗粒度指标。如何在无源码条件下获取丰富覆盖率反馈是一个关键挑战。洞察 3Bug 检测不能只盯内存错误现有 Bug 检测主要依赖 Sanitizer 捕获内存错误但非崩溃型语义 Bug逻辑错误、状态不一致的检测仍处于早期。差分测试和语义检查器是未来方向但缺乏合适的参照基准。洞察 4跨接口交互是被忽视的金矿单接口 Fuzzing 最多遗漏 77% 的内核代码。Janus 等工具证明系统调用 文件系统镜像的联合 Fuzzing 能显著提升覆盖率但系统化的跨接口方法论仍然缺失。洞察 5规格生成需要混合方案静态推断覆盖广但不够精确动态分析真实但遗漏不活跃路径LLM 方法如 KernelGPT生成速度提升 6 倍且准确率 93.3%但无法处理间接调用。三者互补混合方案才是正解。洞察 6隐式依赖是最大难点显式依赖如 open 返回 fd → mmap 使用 fd已被较好建模但隐式依赖如 mlockall 影响 msync 行为的发现和建模仍然困难。MOCK 和 Countdown 等方法试图从执行轨迹中挖掘隐式依赖但通用性有限。️ 代表性工具一览工具年份目标核心创新Syzkaller2017Linux/通用8000 系统调用描述生态基石kAFL2017Win/LinuxIntel PT 硬件辅助覆盖率Janus2019Linux FS文件系统 系统调用双维度输入SyzDescribe2023Linux自动化系统调用规格推断KernelGPT2025LinuxLLM 驱动规格生成6× 加速SyzTrust2024TEEARM CoreSight 硬件追踪MOCK2024Linux隐式依赖挖掘Monarch2024Linux语义感知 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 的简单移植——环境受限、接口复杂、状态深层三大挑战决定了它需要专属的方法论。这篇综述用三阶段九功能的分类法为领域画出了第一张全景地图也画出了未来的路。 点赞 收藏 分享你的支持是我们持续解析高水平软件安全论文的最大动力
