控制平面才是关键：LLM 时代重访 autofz

# 控制平面才是关键：在LLM时代重新审视autofz 来源：https://yfu.tw/blog/en/autofz-revisited/ ## 前言 autofz 是一个元模糊测试器（meta-fuzzer），负责在运行时编排现有的模糊测试工具。我在博士前几年开发了它，并被 USENIX Security 2023 接收。论文 (https://yfu.tw/papers/autofz.pdf) 和 GitHub 仓库 (https://github.com/sslab-gatech/autofz) 均已公开。 几年后，autofz 并非最常被引用的模糊测试论文，但其“控制平面”框架比我预想的更具时效性。 现在我想重新审视 autofz，因为它的核心问题在原始模糊测试语境之外显得更为相关：当你拥有许多不完美的 worker 时，系统应如何在它们之间分配固定预算？ 2023 年，这些 worker 是模糊测试器。如今，在 CRS 和 LLM 智能体系统中，worker 可能是模糊测试器、静态分析器、代码智能体、补丁生成器、验证器或模型变体。表面变了，但控制平面的问题类似：哪个 worker 应该运行？应该共享哪些证据？何时应切换方向？何时应停止？ 随着安全能力变得廉价且广泛可用，这个问题更加重要。我不是说安全问题已解决，或专家系统不再重要。我是说一个更窄的方面：生成可信的漏洞候选正变得更容易。更难的问题是将有噪声的候选生成转化为可靠证据、可复现的 PoV、有用的补丁和良好的预算决策。 这就是为什么我不认为过去十年的模糊测试研究应该被视为过时。即使具体技术没有被直接复用，该领域积累了关于廉价反馈、噪声评估、证据共享和固定预算自动化的宝贵经验。autofz 正是那个更大编排问题的一个小型实例。 ## 为什么模糊测试器选择很困难 autofz 背后的最初观察很简单：没有哪个单一模糊测试器总是最好的。论文通过四个观察具体化了这一点。 首先，不存在通用的模糊测试器。不同的模糊测试器在变异策略、调度、插桩、种子管理和搜索压力方面做出不同权衡。在论文的激励示例中，LearnAFL 在 ffmpeg 上表现最佳，但在 exiv2 上降至第六位。RedQueen 在相同资源预算下对 exiv2 的性能也超过 Radamsa 十倍以上。这种目标敏感性正是“直接用最好的模糊测试器”不是一个令人满意的可操作答案的原因。 其次，最好的模糊测试器在同一个测试活动中也可能改变。我们称之为排名反转。在 exiv2 上，Angora 早期进展强劲，但约两小时后 LAF-Intel 和 RedQueen 赶了上来。后来，LAF-Intel 和 RedQueen 之间又发生了一次反转。在开始时做出的静态决策会错过这种变化。 第三，均等资源分配是浪费的。协作模糊测试可以通过共享种子来改进单一模糊测试器，但如果每个模糊测试器永远获得相同的 CPU 预算，系统仍会将过多时间花在目前无用的 worker 上。 第四，模糊测试的随机性使得离线决策不可靠。即使专家为一个基准测试运行找到了好的组合，这种指导可能不会对下一个工作负载、下一个种子语料库、甚至同一目标的另一次运行复现。选择负担不会消失，只是转移到了基准选择、训练数据或手动调优上。 这就是 autofz 试图解决的实际问题。用户应该能够提供一个可用的模糊测试器池，然后由系统决定哪些应该获得当前预算。 autofz 在 UNIFUZZ 和 FTS 目标上与单个模糊测试器进行了比较，比如 AFL、AFLFast、Angora、QSYM、RedQueen 等。论文的重点不是单个模糊测试器弱，而是一个运行时组合层可以利用当前目标和阶段中任何有用的模糊测试器。 ## autofz 的工作原理 autofz 没有实现新的模糊测试算法。它运行现有的模糊测试器，并在它们之上添加一个控制平面。 控制循环分为两个阶段。在准备阶段，autofz 给基线模糊测试器一个短暂而公平的运行机会，并观察它们的进展。由于不同模糊测试器使用不同的内部反馈，autofz 将其发现的感兴趣输入映射回公共的 AFL 位图视图。这给编排器提供了一种统一的方式来比较运行时趋势。 第二阶段是聚焦阶段。autofz 将观察到的趋势转化为资源分配决策。如果某个模糊测试器明显领先，autofz 可以将下一个预算窗口分配给该模糊测试器。如果多个模糊测试器看起来都有用，它可以按比例分配资源。种子在模糊测试器之间同步，以便一个 worker 的发现可以成为另一个 worker 的起点。 然后系统重复。它不会假定上一个窗口的最佳模糊测试器仍然是下一个窗口的最佳选择。 autofz 的工作流程包含准备和聚焦阶段 论文图 2：autofz 在准备和聚焦阶段之间交替。它测量模糊测试器的趋势，将其转化为资源分配，然后在下一个窗口中将资源分配给选定的模糊测试器。 论文中一个重要短语是“按工作负载，而非按程序”。一个程序不是一个静态的搜索问题。随着模糊测试的进行，剩余分支、有用种子和瓶颈都会发生变化。autofz 试图对运行时工作负载做出反应，而不是在整个活动中绑定到一组模糊测试器。 ## 花费时间的那部分：让决策经得起推敲 第一个工作原型很快就击败了 EnFuzz。但将该原型转化为论文花费了更长时间，因为显而易见的审稿人问题不是“它能赢一次吗？”，而是“这些调度决策真的合理吗？” 这就是我们增加评估 autofz 决策部分的原因。对于每一轮，我们在准备阶段结束后的那个点记录快照，然后多次将活动恢复到该快照。接着我们将 autofz 的资源分配与那些将整个聚焦阶段预算一次性分配给一个基线模糊测试器的人为决策进行比较。这是一种提出反事实问题的方式：给定相同的起始语料库和相同的聚焦阶段时间预算，autofz 选择的分配是否与那些显而易见的替代方案具有竞争力？ 答案基本上是肯定的，但也有一些有用的注意事项。在 libarchive 上，autofz 的决策在 14 轮中有 8 轮排名第一，平均排名为 2.64。在 exiv2 上，它在 15 轮中有 4 轮排名第一，平均排名为 3.5。这足以支持核心论点：准备期间观察到的趋势在接下来的聚焦阶段通常仍然有用。 这些注意事项对论文很重要。当覆盖率饱和时，模糊测试器的选择变得不那么重要，因为任何分配都无法取得很大进展。在 exiv2 上，第 4 轮之后，不同决策产生的覆盖率差异非常小；在后期一轮中，最佳和最差决策之间的差距仅为 0.07% 的位图密度。模糊测试的随机性也会增加噪声，即使比较从同一个快照开始。种子同步可能进一步改变下一个趋势：一个在准备期间不是最强的模糊测试器，在另一个模糊测试器发现并共享了某些输入以解除其阻塞后，可能会变得更强。 这是我记得的、真正将演示与论文区分开来的工程/研究差距。原型显示了编排可以有所帮助。论文必须解释为什么特定的调度算法是合理的，其决策在何时可靠，以及信号何时变得微弱。我们还必须处理准备和聚焦阶段的超参数：测量多长时间、多快退出准备阶段、将多少预算用于评估而非利用、以及多久重新审视一次决策。这些细节并不光鲜，但它们决定了元模糊测试器是真正有用，还是仅仅在基准测试运行中运气好。 ## autofz 的时间线：从想法到论文被接收 - 初始想法：大约 2020 年 11 月，不过我不记得确切日期了。 - 第一个能击败 EnFuzz 的工作原型：大约 2020 年 12 月。 - NDSS 2023：第二轮后被拒；很接近。2022 年 5 月。 - IEEE S&P 2023：早期拒稿。 - USENIX Security 2023：2023 年 1 月小修，然后被接收。 从工作原型到可发表的论文花了很长时间，尤其是我当时还在上课。在模糊测试研究中，击败基线是不够的。难点在于解释系统为何胜利、何时胜利、以及哪个机制真正起作用。 这对于 autofz 尤其如此，因为它是一个有多个活动部分的元模糊测试器：调度器、单个模糊测试器、种子同步、基准设置和资源分配都可能影响最终结果。 ## 前期工作：静态集成 vs 运行时编排 ### EnFuzz EnFuzz 是我们在早期原型中比较的主要协作模糊测试基线。它将多个模糊测试器集成在一起，让它们共享种子。这已经是一个有用的想法：不同的模糊测试器可以从彼此的发现中受益。 局限性在于，仅靠种子共享并不能解决整个组合问题。如果所有模糊测试器都获得大致固定或相等的资源，系统仍然无法回答在某个时刻哪个模糊测试器应该获得更多 CPU。换句话说，EnFuzz 是协作性的，但其资源分配基本上仍然是静态的。 autofz 保留了有用的部分——种子同步，但在其之上增加了运行时调度。它将模糊测试器选择和资源分配视为一等问题。 ### CUPID CUPID 是另一条重要的研究路线，因为它也专注于组合模糊测试器。区别在于选择决策何时以及如何做出。CUPID 使用离线分析和训练集来预测与目标无关的模糊测试器组合。这意味着选定的集成在活动期间仍然是静态的。 论文的表 1 总结了这种差异： | 属性 | EnFuzz | CUPID | autofz | |------|--------|-------|--------| | 选定模糊测试器的数量 | 用户配置 | 用户配置 | 自动 | | 典型选定的模糊测试器集 | 2-4 | 2-4 | 1-11 | | 运行时切换模糊测试器 | 否 | 否 | 是 | | 需要先验知识 | 是 | 是 | 否 | | 需要目标特定预训练 | 否 | 部分 | 否 | | 添加新模糊测试器的成本 | 高 | 高 | 低 | | 资源分配 | 静态 | 静态 | 动态 | | 资源分配策略 | 均等 | 均等 | 按比例 | | 适应运行时工作负载 | 否 | 否 | 是 | 我现在会将此描述为静态集成和运行时编排之间的区别。EnFuzz 和 CUPID 是关于选择一组有用的模糊测试器。autofz 是关于在工作负载变化时反复决定哪些 worker 应获得预算。 结果不仅是更好的覆盖率。在论文中，autofz 在 12 个基准测试中有 11 个优于最佳单个模糊测试器，并在 20 个基准测试中有 19 个击败了协作模糊测试方法。平均而言，它在 UNIFUZZ 和 FTS 上比单个模糊测试器多发现 152% 的 bug，在 UNIFUZZ 上比协作模糊测试多发现 415% 的 bug。 autofz 在 UNIFUZZ 上与 EnFuzz 和 CUPID 的比较 autofz 在 UNIFUZZ 上与 EnFuzz 和 CUPID 进行比较。有趣的部分不仅仅是 autofz 运行了更多模糊测试器；它使用运行时反馈来决定哪些模糊测试器应该获得预算。 autofz 在 exiv2 上的资源分配快照 来自论文的一个资源分配快照。autofz 可以先将早期预算用于一个强大的模糊测试器，然后在多个模糊测试器显示出有用趋势时分配资源。 ## 底层技术组合 vs 高层模糊测试器编排 在审稿期间以及后来 arXiv 版本发布后在 Hacker News 上，一个常见问题是 autofz 与 AFL\+\+ 有何不同。我认为更好的框架是区分两个层面的组合。 AFL\+\+ 是底层组合的一个优秀例子。它在单个强大的模糊测试器实现内组合了许多兼容的模糊测试技术。autofz 不在该层面竞争。它可以将 AFL\+\+ 作为池中的一个 worker 使用。 区别在于，“一个模糊测试器中的多种技术”与“编排多个 worker”不是一回事。一些特性可以干净地组合，例如 AFL\+\+ 的 CmpLog 支持。其他选择在每个进程中是互斥的，例如使用 `-p` 选择的 power schedule。其他 worker（如 QSYM 和 Angora）带有自己的插桩和运行时假设。 因此，这两个层面是互补的。AFL\+\+ 增强单个模糊测试器。EnFuzz 和 autofz 在更高层面工作：将多个模糊测试器作为独立 worker 运行，共享有用的产物，并决定哪个 worker 应获得资源。autofz 的贡献在于那个更高层的编排问题：给定几个现有的模糊测试器，哪些应该运行？系统何时应该切换？每个应获得多少资源？ 这个区别很重要，因为两种方法可以共存。更好的单个模糊测试器使池更强。更好的编排器决定如何在固定预算下使用该池。 ## 添加模糊测试器不等同于良好的编排 同样的陷阱在多智能体系统中也会出现。添加更多智能体可以增加多样性，但也会引入上下文损失、消息传递开销和协调负担。如果编排器无法决定哪个智能体应负责下一步、哪些证据应被压缩和共享、以及何时应放弃一个线程，系统可能会将大部分预算用于移动信息而非解决问题。 模糊测试器编排具有相同的形态。添加更多模糊测试器并非免费：每个额外的模糊测试器都会带来更多的测量成本、更多的同步流量，以及在当前无用的 worker 上浪费预算的更多方式。 论文通过一个均等分配资源的 autofz 变体对此进行了评估。当池变化时，autofz 与均等分配变体之间的差距变得更为明显，尤其是在好坏模糊测试器混合时。在一个案例研究中，autofz 仅将聚焦阶段资源的很小一部分用于表现不佳的模糊测试器，而将大部分预算转向 RedQueen、LAF-Intel 和 libFuzzer。 这就是编排的意义所在：只有当控制平面能够避免始终为每个选项支付全价时，多样性才有帮助。 autofz 在 libarchive 上使用不同数量的模糊测试器进行评估 添加更多模糊测试器并不自动更好。有用的问题是编排层如何在池变化时分配预算。 ## 对后续工作的启发 回顾起来，autofz 中至今仍最具可复用性的部分并非任何具体的模糊测试启发式方法。而是控制平面的理念：在运行时观察异质 worker，比较它们的边际进展，并将预算转向当前看起来有用的 worker。 来自 Team 42-b3yond-6ug 的 BandFuzz (https://github.com/whexy/BandFuzz) 探索了与深度学习和多臂老虎机相关的方向。类似的老虎机风格思想也出现在 RCFuzzer (https://github.com/hyeonminmo/RCFuzzer) 中，这是一个基于推荐的协作模糊测试器，来自汉阳大学，基于 autofz 构建。 同样的编排思想也出现在我们自己的 CRS——Atlantis（来自 Team Atlanta）中。Atlantis 集成了三个 CRS：一个 C CRS、一个 Java CRS 和一个多语言 CRS，实际上主要涵盖 C 和 Java。更多技术细节、报告和出版物可从 Team Atlanta (https://team-atlanta.github.io/) 获取。 ## 从模糊测试器编排到智能体编排 LLM 时代的类比并不是说智能体就是模糊测试器。类比在于，当我们停止依赖单一 worker 并开始协调多个异质 worker 在固定预算下工作时，这两个系统都会变得困难。 在 autofz 中，worker 是模糊测试器。共享的产物是种子。廉价的反馈信号是覆盖率。调度器观察运行时趋势并将 CPU 移动向……