Syzkaller快照模式下的覆盖率收集机制缺陷分析

在Syzkaller内核模糊测试工具中，我们发现了一个关于快照模式下覆盖率收集的重要缺陷。该缺陷会导致测试结果异常，表现为大量测试程序被错误地添加了openat$nci前缀，同时信号收集和语料库质量显著低于预期水平。

问题根源分析

该问题与执行器(executor)中的线程预分配机制直接相关。在快照模式下，Syzkaller会预先分配一定数量的工作线程（默认为2个），目的是提高测试效率。然而，这些预分配的线程会在实际测试程序接收和执行之前就开始工作，导致两个关键问题：

1. 覆盖率数据丢失：预分配线程执行的测试程序无法正确记录覆盖率信息
2. 程序前缀污染：测试程序被错误地添加了不必要的系统调用前缀

技术细节解析

在Syzkaller的执行流程中，parse_execute()函数负责解析和执行测试程序，这是覆盖率收集的关键环节。然而，线程预分配机制使得工作线程在parse_execute()调用前就已经启动运行。具体表现为：

• 线程池中的前两个线程始终无法获得有效的覆盖率数据
• 这些线程执行的测试程序会产生异常的前缀添加现象
• 整体测试效率因有效覆盖率数据丢失而显著降低

解决方案验证

通过将kThreadsPopulate参数从默认值2调整为0（即禁用线程预分配），我们验证了该方案能够完全解决问题：

1. 测试程序前缀恢复正常
2. 覆盖率数据收集完整
3. 信号和语料库质量恢复到预期水平

深入技术思考

这个问题揭示了快照模式下线程管理与覆盖率收集机制的时序依赖问题。在常规模式下，线程创建与程序执行是同步进行的，因此不会出现此类问题。但在快照模式下，由于需要预先创建执行环境，这种时序差异导致了功能异常。

未来改进方向

虽然当前通过禁用线程预分配可以解决问题，但从长远来看，更完善的解决方案应该包括：

1. 实现快照模式下的机器状态检查机制
2. 优化线程初始化与程序执行的时序关系
3. 增强覆盖率收集机制的鲁棒性

这个案例也提醒我们，在模糊测试工具的开发和优化过程中，需要特别注意不同运行模式下的行为差异，特别是那些涉及底层执行机制的部分。对于系统级测试工具而言，执行环境的精确控制往往比单纯的性能优化更为重要。