WhiteFox：由大型语言模型驱动的白盒编译器模糊测试

基本信息

原文名称：WhiteFox: White-Box Compiler Fuzzing Empowered by Large Language Models

原文作者：CHENYUAN YANG; YINLIN DENG;RUNYU LU;JIAYI YAO;JIAWEI LIU;REYHANEH JABBARVAND;LINGMING ZHANG

原文链接：https://dl.acm.org/doi/10.1145/3689736

发表期刊：ACM international conference on Object oriented programming systems languages and applications, 2024

开源代码：https://github.com/ise-uiuc/WhiteFox

一、引言

现代编译器在将高级编程语言翻译为高效机器代码的过程中扮演着至关重要的角色。然而，不正确或错误应用的优化可能导致难以察觉的漏洞，甚至引发安全问题。在现有文献中，模糊测试已被广泛研究以揭示编译器缺陷。然而，编译器模糊测试仍然面临挑战：现有技术主要集中在黑盒和灰盒模糊测试上，这些方法在生成测试程序时对编译器内部行为缺乏充分理解。因此，它们往往难以构建能够测试复杂优化过程的测试程序。同时，传统的白盒技术，如符号执行，由于计算资源限制，难以适用于庞大的编译器系统代码库。

由于大型语言模型（LLMs）在代码生成和理解任务中表现出色，甚至在黑盒模糊测试中达到了最先进的性能，论文提出了首个利用大型语言模型结合源代码信息的白盒编译器模糊测试工具WhiteFox，专注于检测新兴深度学习（DL）编译器中的深层逻辑错误。WhiteFox采用多智能体框架：

（1）基于LLM的分析智能体：检查低级优化源代码，并生成能够触发优化过程的高级测试程序的需求；

（2）基于LLM的生成智能体：根据总结的需求生成测试程序；

（3）反馈循环：触发优化的测试程序会作为反馈的少样本示例，动态增强测试生成的提示信息。

二、研究动机

挑战：

（1）黑盒模糊测试：由于缺乏对内部工作原理的了解，在触发优化所需的复杂条件方面面临困难。

（2）灰盒模糊测试：虽借助源码插桩实现更高覆盖率，但其对编译器优化条件的敏感度仍然不足，因为优化往往依赖严格精确的条件，而传统覆盖率驱动策略难以有效捕捉这些微妙状态。此外，现有方法因生成输入缺乏语义正确性，主要暴露前端崩溃错误，而非深层优化缺陷。

（3）传统的白盒模糊测试：依赖于对SUT 源代码的严格分析，但在现代编译器上变得难以实施。

（4）通用性较差：现有编译器测试工具多针对特定语言或编译器定制，开发新编译器的测试框架耗时费力，难以复用。

例子：图1展示了PyTorch Inductor中优化permute_linear_fusion的一个示例。该优化在对输入张量调用permute方法时，将permute和linear操作符融合，特别是交换最后两个维度。然而，当应用模糊测试技术来测试此优化时，黑盒/灰盒模糊测试难以生成符合这些约束的模型。这是因为黑盒和灰盒模糊测试工具由于缺乏源代码实现的指导，无法意识到模型应以这种特定方式包含permute和linear操作符。另一方面，尽管白盒技术在理论上有可能触发此优化，但由于编译器中数据结构的复杂性（例如torch.fx.GraphModule和torch.fx.Node），应用传统的程序分析从详细的源代码中提取约束是不现实的。

图 1  动机示例

针对上述问题，作者设计了WhiteFox：

（1）由于现有的白盒测试方法无法扩展到对复杂编译器系统的行为信息进行建模，WhiteFox 的核心思想是利用 LLMs 自动推断能够触发编译器优化的测试程序需求，这些需求基于优化模块的源代码实现。

（2）WhiteFox 的输入是实现编译器优化的源代码，首先由基于 LLM 的分析代理自动分析并总结触发优化的测试需求，随后基于 LLM 的生成代理根据生成的需求生成大量有意义的测试程序。

（3）为了生成能够直接执行相应优化的测试程序，WhiteFox 进一步采用了反馈循环机制，将触发优化的测试作为少样本示例，以指导未来的测试生成。

（4）除了 DL 编译器测试，WhiteFox 还可以适配其他编译器甚至复杂的现实世界软件系统的白盒模糊测试，为这一有前景的方向启发了未来的研究。论文已将 WhiteFox 适配用于测试 LLVM 并发现了多个错误。

三、概述

图 2  WhiteFox的完整流程

WhiteFox的架构如图2所示，主要包括三个关键部分：

（1）需求总结：分析型LLM 通过检查编译器优化的源代码，提取触发优化所需的测试需求。

（2）测试生成：生成型LLM 根据提取的需求，自动生成用于触发优化的测试程序。

（3）反馈循环：生成的测试程序随后被编译和执行，通过插桩观察优化是否被触发，并将成功触发优化的测试纳入反馈机制，作为示例指导生成型LLM 在后续迭代中生成更具优化针对性的测试程序。

此外，为了检测编译器错误，每个测试程序都会通过测试预言（如结果不一致、编译时崩溃和运行时崩溃）进行验证。

值得注意的是，WhiteFox 采用了多智能体框架，这种设计能够平衡不同 LLMs 提供的成本和收益之间的权衡。例如，可以让分析 LLM 具备广泛的知识和推理能力（在自然语言和代码方面），而让生成 LLM 专门用于高效的程序生成。

1. 需求总结  

（Requirement Summarization）

挑战：（1）代码冗长且包含无关信息：优化代码往往包含大量实现细节（如数据结构操作、错误日志记录），增加了LLM 理解的难度。（2）低级实现，涉及复杂数据结构：实现代码是低级别的，涉及大量的领域特定模块、IR 和辅助函数。

解决方案：采用了一种混合格式，将自然语言和伪代码结合起来描述触发优化的需求，而不是仅仅依赖其中一种格式。

（1）自然语言（NL）：清晰概括优化触发条件，去除不必要的细节。例如，PyTorch Inductor 中的 `permute_linear_fusion` 优化要求 “它交换了张量的最后两个维度”，利用伪代码清晰简洁地描述这一点相当具有挑战性，自然语言描述更加适合。

（2）伪代码（Pseudo-Code）：用于表达关键代码模式，使测试生成更直观。例如，PyTorch Inductor 中的 `permute_linear_fusion` 优化要求”首先调用张量方法 `permute`，然后在置换后的张量上调用 `torch.nn.functional.linear` 函数”。对于这种情况，自然语言描述不如伪代码格式直观，”张量方法 `permute`”可以用伪代码简单地表示为 `input_tensor.permute(...)`。

具体实现：WhiteFox使用少样本上下文学习来提示分析型LLM 以自然语言和伪代码的混合格式生成其触发需求。

（1）图 3(a) 展示了用于总结目标编译器中优化需求的通用少样本提示模板。该提示模板以指令”请描述可以触发 [OPTIMIZATION NAME] 优化的 [TARGET INPUT]...”开头，其中 [TARGET INPUT] 是目标编译器特定的输入格式。然后，它后面跟着优化实现的源代码，并以输入应满足的需求描述结束。描述是自然语言和伪代码的混合格式，由 [PSEUDO CODE] 和 [NL DESCRIPTION] 组成。Target Optimization与少样本示例具有相同的结构，但其需求字段留空，等待LLM 生成。

（2）图 3(b) 展示了PyTorch Inductor 中的需求总结少样本提示。PyTorch Inductor 的预期输入格式是 PyTorch 模型；因此，[TARGET INPUT] 填充为”PyTorch 模型”。随后，提供了示例优化 `permute_linear_fusion` 的源代码。最后，以伪代码和自然语言混合格式给出示例描述，以概述触发示例优化所需的约束条件。

图3 WhiteFox的需求总结提示模板

2. 测试生成 

（Test Generation）

通过利用优化的需求描述，WhiteFox 利用 LLM 的能力生成能够有效触发相应优化以进行错误检测的测试输入。与需求总结类似，论文利用少样本上下文学习来生成基于需求的特定于每个优化的测试输入。

（1）图 4(a) 展示了 WhiteFox 中用于测试生成的通用提示模板。少样本示例的结构包括一条指令，具体为：”请生成一个有效的 [TARGET INPUT] 示例，该示例具有 [INPUT SPECIFICATION] 并满足指定的需求。”然后，它详细说明了激活优化的需求，并以一个说明性输入结束，该输入实践了示例优化。在少样本示例之后，目标优化具有相似的结构，而其测试输入将由 LLM 生成。

（2）图 4(b) 展示了在 PyTorch Inductor 中使用的测试生成提示。PyTorch Inductor 的测试输入格式是一个使用公共 PyTorch API（[INPUT SPECIFICATION]）的PyTorch 模型（[TARGET INPUT]）。接下来，指定激活优化 `permute_linear_fusion` 的测试输入需求，辅以一个可以触发此优化的说明性模型。提供的少样本示例帮助 LLM 以所需格式生成测试。此外，示例可以帮助LLM 学习优化需求描述与能够触发它的相应测试输入之间的关系。

 图4 WhiteFox的测试生成提示模板

3. 反馈循环 

（Feedback Loop）

引入反馈循环的动机：在每次迭代中，当发现新生成的测试能够触发目标优化时，将其收集为未来测试生成提示的少样本示例候选。通过将这些成功触发优化的测试纳入提示中，可以增强对生成型LLM 的针对性指导，使其能够生成更多触发目标优化的输入。

具体实现：WhiteFox 在迭代测试生成过程中将成功触发相应优化的测试作为补充示例纳入其中。

（1）执行测试，检测优化是否触发：生成的测试程序会被编译并执行，通过插桩记录优化触发情况。若优化被触发，则该测试程序被标记为“少样本示例候选”，并用于后续针对该特定优化的测试生成迭代。

（2）构建反馈提示：每次迭代中，如果当前优化有触发输入，WhiteFox 会选择几个触发输入作为示例（默认为 3 个），这些示例触发输入将与目标优化的指令和需求总结（与之前的提示相同）一起插入到图 5 所示的提示中，并用于生成下一批测试输入；如果某个优化没有触发输入，WhiteFox 将在后续迭代中继续使用初始提示（图 4），直到找到能够触发该优化的输入为止。

图5 加入反馈循环的测试生成提示模板

触发样本选择策略：

并非所有触发示例在指导LLM 生成新的有价值的触发测试方面都同样有效。评估其有效性的一个有用信号是当使用它们作为少样本示例时，新生成测试的触发率。为了在探索和利用之间找到平衡，有效选择触发示例至关重要。

因此，WhiteFox 采用了（改编的）多臂赌博机（MAB）算法，即 Thompson Sampling，作为触发示例的选择策略。beta 分布的概率密度函数可以正式写成如下：

• 当没有任何关于臂的先验信息时，选择标准beta 分布B(1, 1)（或等效的Uniform(0, 1)）作为其先验分布。beta 分布由两个形状参数α > 0, β > 0 参数化，它们表示历史试验中的成功和失败次数。
• 在抽取新样本并观察奖励（如果生成的测试成功触发目标优化则为1，否则为0）后，可以通过将α 或β 增加1来方便地更新后验概率，具体取决于样本是成功还是失败。

算法1 展示了示例测试选择过程：

（1）从每个后验分布采样θₜ（行2-3）；

（2）选择采样值最高的前N个臂作为本轮ExampleTests（行4）；

（3）用触发测试数量更新ExampleTests后验（行7-9）；

（4）基于ExampleTests的α、β均值初始化NewTriggerTests以减少探索开销（行10-14），假设新测试从“父”示例继承了有效代码模式；

（5）更新触发测试池（行15）。

4. 测试预言 

（Test Oracle）

在WhiteFox 中，错误表现为以下症状：

（1）结果不一致：编译优化传递可能因逻辑缺陷导致错误编译，产生语义不一致的机器代码，这种不一致可以通过差异测试来检测。具体来说，对于每个可编译和可执行的测试程序，在给定相同的输入集的情况下，交叉检查优化版本和非优化（或最小优化）版本的程序生成的输出。

（2）崩溃：让编译器和编译后的可执行文件意外崩溃是不可取的。因此，WhiteFox 积极捕获测试程序在编译时和运行时的崩溃信号，包括进程中止、段错误和意外的内部异常（例如 PyTorch 中的 INTERNAL_ASSERT_FAILED）。

总结来说，论文以两种模式编译每个测试输入：启用优化和不启用优化。将以下条件视为潜在错误候选：

•在优化编译或优化程序执行期间发生崩溃。

•两种模式之间的编译状态（通过/失败）不一致。

•两种模式之间的程序输出不同。

四、执行

优化收集：

（1）目录定位：通过指定相关目录来收集特定优化的编译器源代码。例如，PyTorch Inductor 的优化传递源代码位于 `torch/_inductor` 目录下，而 TensorFlow-XLA 的优化源代码主要位于 `tensorflow/compiler/xla/service` 目录下。

（2）关键词匹配：通过简单的关键字模式匹配来识别执行优化的代码片段（例如函数）。例如，操作符融合是DL 编译器中的一项重要优化，通过搜索“fusion”或“fuse”来收集相关函数。此外，主优化调用的辅助函数也会被收集，因为它们可能揭示了激活优化的关键条件。

插桩：为了收集反馈循环所需的触发信息，在每个收集到的优化函数的入口处插入日志语句进行插桩。这样，在编译测试程序时，可以从日志中获取一系列激活的优化传递。

分析和生成LLMs：

（1）利用 GPT4 作为分析 LLM，并将温度设置为0。

（2）利用 StarCoder（StarCoder-15B）作为生成 LLM。在每次迭代中，让 StarCoder生成一批十个测试输入，并将温度设置为1。

少样本提示：

（1）对于每个目标编译器的需求总结和初始测试生成的少样本提示，论文选择一次性提示：从每个目标编译器中选择一个优化，手动编写需求描述和一个能够触发优化的演示输入测试。一个例外是PyTorch Inductor 有两种不同类型的优化（7 种使用传统的优化检查函数，54 种涉及模式匹配器）。因此，为每种类型分别设计两个提示，并根据优化类型为每个优化选择相应的提示。

（2）对于反馈提示：需求由分析LLM 生成，示例测试由生成 LLM 创建。在反馈提示中使用三个样本作为默认设置。

五、实验

RQ1：WhiteFox 与最先进的 DL 编译器模糊测试工具相比如何？

RQ2：WhiteFox 中的所有关键组件是否都有效？

RQ3：WhiteFox 是否能够检测到现实世界中的错误？

1．实验设置

表 1 被测DL编译器的细节

被测编译器：三个最流行的深度学习（DL）编译器：PyTorch Inductor、TensorFlow Lite 和 TensorFlow-XLA（对于 TensorFlow-XLA，由于其优化实现通常较长，仅选择了代码行数少于 400 行的优化，这是由于 LLM 上下文窗口大小的限制）。表 1 列出了被测 DL 编译器的概述。

基线工具：基于LLM 的 TitanFuzz 和基于符号规则的 NNSmith。

消融实验变体：WF-Mix（WhiteFox 的默认设置）、WF-NL（使用从混合格式中提取的自然语言）、WF-Code（使用从混合格式中提取的伪代码） 和 WF-Impl（直接向生成 LLM 提供实现源代码）。考虑到 PyTorch Inductor 拥有最多的优化，仅在 PyTorch Inductor 上进行消融研究。

环境：Ubuntu 20.04.5 LTS，配备 64 核 CPU、256 GB 内存和 NVIDIA RTX A6000 GPU。

模糊测试预算：默认设置为每个优化生成总共1000 个测试，分为 100 次迭代。

2．指标

• 检测到的错误数量
• 触发的优化数量
• （优化）触发测试的数量
• 代码覆盖率：报告实现优化的源语言中的行覆盖率，PyTorch Inductor 使用 Python，TensorFlow Lite 和 TensorFlow-XLA 使用 C++。使用 Coverage.py 测量 Python 的行覆盖率，使用 GCOV 测量 C++ 的行覆盖率。

3．与先前工作的比较（RQ1）

表 2 在默认设置下和baselines的比较

默认设置

表2 比较了 WhiteFox 与基线工具在三个目标编译器上的默认设置下的表现。由于 NNSmith 的执行时间比 WhiteFox 的默认设置短，为了公平比较，展示了 WhiteFox-Mini 的结果，它为每个优化生成 100 个测试，而不是默认的 1000 个测试。表 2 中的“时间”列包括需求/测试的生成时间（包括 LLM 调用）和测试执行时间。

在优化触发方面，WhiteFox 在 PyTorch Inductor 和 TensorFlow Lite 中显著优于基线工具。总体而言，在被测编译器中，WhiteFox 在触发优化数量方面比现有测试工具高出最多 8.2 倍。

在时间成本方面，WhiteFox 消耗的时间比除 NNSmith 之外的所有其他技术都少。同时，鉴于 NNSmith 的性能较差，WhiteFox-Mini 仍然可以在更少的时间内触发比 NNSmith 更多的优化。

WhiteFox 在所有编译器上均优于基线工具，除了 TensorFlow-XLA，与 TitanFuzz 相比触发的优化少了两个，但仍然触发了 TitanFuzz 无法覆盖的 4 个独特优化。一个可能的原因是，为了与基线工具进行公平比较，对 TensorFlow-XLA 的目标优化进行了过滤，这些优化相对简单，有许多代表了实践中广泛使用的常见模型模式。因此，TitanFuzz 可以有效地触发这些优化，因为 TitanFuzz 利用 LLMs 生成类似于训练数据分布的人类可读程序。

此外，NNSmith 触发的优化数量最多，但主要依赖它总是输出带有冗余 reshape 操作的模型，并不意味着测试质量更高。

在每种方法触发的独特优化方面，对于PyTorch Inductor，WhiteFox 不仅完全覆盖基线触发的 7 个优化，还额外触发 34 个独特优化；在 TensorFlow Lite 中，WhiteFox 覆盖了基线触发的全部 9 个优化并新增 3 个；而在 TensorFlow-XLA 上，WhiteFox 覆盖了基线 26 个优化中的 20 个。

24小时测试期间：

表3 比较了 WhiteFox 与基线工具在 24 小时测试期间的表现。WhiteFox 在所有三个测试对象上表现最佳，在 PyTorch Inductor 和 TensorFlow Lite 上显著优于其他工具。

表 3 在24小时测试期间和baselines的比较

在代码覆盖率方面，WhiteFox 在 PyTorch Inductor 和 TensorFlow-XLA 上覆盖的代码行数比基线工具多出最多 19.9%。对于 TensorFlow Lite，WhiteFox 的表现略逊于 TitanFuzz（5.9%）。这可能归因于 TensorFlow Lite 中优化数量有限（13 个），本质上限制了 WhiteFox 的代码覆盖率探索，因为 WhiteFox 没有太多的白盒信息（即优化实现）来指导生成。

4．消融研究（RQ2）

表 4 需求描述格式在PyTorch Inductor上的影响

需求生成与测试生成：

需求描述的有效性：相比直接提供实现源代码（WF-Impl），使用需求描述的 WF-Mix、WF-NL 和 WF-Code 在生成触发测试方面表现更优。默认设置 WF-Mix 生成的触发测试比 WF-Impl 多 1.74 倍，并额外触发 7 个优化，凸显了需求描述在测试生成中的重要性。

混合格式的有效性：WF-Mix 在触发的优化数量和触发测试数量方面表现最佳，这突显了结合自然语言（NL）和伪代码进行需求描述的有效性。尽管 WF-NL 触发的优化比 WF-Code 多，但它生成的触发测试较少。因为NL 含有更多信息，可避免转换源代码时遗漏关键触发需求；而伪代码格式更便于生成 LLM 关联测试程序，从而提高触发测试数量。

分析LLM：使用 StarCoder 生成需求描述（WF-SC）时，触发的优化和测试数量均低于默认设置（GPT-4），验证了 GPT-4 在代码理解和自然语言转换方面的优势。尽管 WF-SC 低于 WF-Mix（默认设置），但仍优于 WF-Impl，证实了双模型基础设施可能比直接使用实现源代码更适合白盒编译器模糊测试，表明分离的需求生成阶段比直接使用实现代码更有效。

反馈循环：

图6 展示了一个条形图，详细列出了每个触发优化的触发测试数量，涵盖了本次消融研究中探索的变体范围。此外，论文还收集了这三个变体的覆盖率结果，如表 5 所示。

图 6 反馈循环和汤普森采样在PyTorch Inductor上的影响

表 5 反馈循环在PyTorch Inductor上的统计数据

反馈循环的有效性：包含反馈循环的WhiteFox 和 WF-Naive 生成的触发测试数量显著多于不包含反馈循环的变体（WF-No-Feedback），分别增加了 2.6 倍和 2.1 倍。这两种方法在代码覆盖率方面均优于 WF-No-Feedback，表明反馈循环可以指导 LLMs 生成更多样化的测试用例。

Thompson 采样的有效性：WhiteFox 采用 Thompson 采样选择触发示例，相比均匀采样（WF-Naive），触发测试数量提升 1.3 倍，覆盖 41 个优化中的 32 个，并取得更高代码覆盖率。

5．bug搜寻（RQ3）

表6 展示了 WhiteFox 在 PyTorch、TensorFlow-XLA 和 TensorFlow Lite 上的错误发现结果。截至目前，WhiteFox 已为这些编译器检测到 101 个错误。其中，92 个被确认为此前未知的错误，70 个已被修复。在 PyTorch Inductor 中发现的 79 个错误中，有 14 个是在其最新版本中发现的，10 个（12.7%）PyTorch 错误被标记为高优先级。在这 79 个由 WhiteFox 检测到的独特错误中，68 个是基线工具无法检测到的。对于 TensorFlow-XLA 和 TensorFlow Lite，基线工具只能发现 WhiteFox 发现的 22 个错误中的 1 个。

表 6 WhiteFox探寻到的bug总览

错误分析：

论文对PyTorch Inductor 的 101 个错误进行了全面分析，其中 79 个（78.2%）由 WhiteFox 检测到，且 68 个（86.1%）已修复。在 79 个错误中，仅 11 个（13.9%）可被现有工具覆盖，其中 10 个可由 TitanFuzz 检测到，3 个可由 NNSmith 检测到。

在68 个已修复的错误中，47 个（69.1%）位于优化代码中，这证明了 WhiteFox 在发现优化错误方面的有效性。在这 47 个优化错误中，只有 3 个可被 TitanFuzz 和 NNSmith 覆盖，凸显了 WhiteFox 在测试编译器优化方面的优势。此外，某些优化（如注意力模块）更容易出错，但更难被发现，WhiteFox 在这些模块中检测到了 5 个错误，暴露了开发者测试的不足。这表明结合 LLMs 的白盒模糊测试具有强大能力。

错误特征：

论文进一步研究了WhiteFox 检测到的错误的详细特征，包括崩溃、错误编译、优化失败、错误通过的优化和漏洞，如表 7 所示。

• 错误编译：优化后的程序返回与非优化程序不同的输出。
• 优化失败：启用优化时编译失败，而在不启用优化时编译有效。
• 错误通过的优化：优化成功编译无效模型。
• 漏洞：除了6 个可用于 DoS 攻击的崩溃错误外，在错误通过的优化中还检测到了另外 5 个越界读取漏洞。

表 7 WhiteFox探寻到的bug特征

不会修复的错误：

在PyTorch Inductor 中，一个错误是由于编译器不支持量化 API，另一个是由于操作符中的未定义行为，第三个是因为开发者认为WhiteFox的输入无效，尽管优化编译了模型并返回了不同的结果。

在TensorFlow Lite 中，两个错误源于其不保证输入输出顺序的特性，另一个是优化后的输出具有不同的形状，这在 PyTorch Inductor 和 TensorFlow-XLA 中都是罕见且不被预期的。

错误示例：

图 7 WhiteFox探寻到的bug示例

六、讨论

1. 真实世界的影响

PyTorch 团队认可 WhiteFox 并请求将其集成到 PyTorch Inductor 开发流程中。为此，作者扩展了 WhiteFox，支持最新版本的 PyTorch Inductor 及 38 个新优化。

2. 一般性：LLVM的案例研究

为了展示WhiteFox 的通用性，论文实现了一个用于测试 LLVM 的 WhiteFox 原型。在基线工具方面，选用了 YARPGen 以及 GrayC。测试的 LLVM 版本是 LLVM-18-20230818-nightly，实验环境与之前描述的设置一致。

优化触发：

表8 展示了 LLVM 优化的触发结果与基线工具的比较。与 DL 编译器的结果类似， WhiteFox 触发的优化数量比基线工具多 6.5 倍，同时时间成本更低。这证明了 WhiteFox 在不同编译器上的有效性和潜力。

表 8 在LLVM优化中和baselines的对比

错误检测：

WhiteFox 检测到了 6 个 LLVM 错误，其中 2 个被确认为此前未知的错误，3 个待确认，1 个不会修复。图 7(e) 展示了一个已确认的 LLVM 错误，该错误仅在测试程序通过足够大的索引引用一个大数组时才会显现，导致 LLVM 优化后崩溃。攻击者可以通过构造特定的输入程序来利用此漏洞，使启用即时编译（JIT）的系统崩溃，从而实现拒绝服务（DoS）攻击。

3. 局限性与未来工作

WhiteFox 不仅适用于编译器优化的白盒模糊测试，还可能扩展到其他编译器代码或复杂软件系统。对于回归错误，可通过设置更改分支为目标并利用 LLMs 分析触发条件来部署 WhiteFox。然而，与优化相比，任意函数的高级输入与低级实现的映射可能不明确，这是其面临的挑战。未来可探索利用 LLMs 推断这种映射（如借助文档等辅助信息）以及触发条件。

另一个未来方向是将传统模糊测试方法作为外部工具，以提高测试生成效率。由于调用较小LLMs 的成本高于传统技术，这种策略可提升性能。例如，可利用 WhiteFox 总结优化触发规则，指导传统模糊测试框架（如 NNSmith）的输入生成。

七、总结

WhiteFox 是首个实用的白盒编译器模糊测试工具，专注于测试编译器优化。它采用多智能体架构，其中分析 LLM 提取优化触发模式，生成 LLM 高效合成测试程序。评估结果表明，WhiteFox 在 DL 编译器和传统 C/C++ 编译器上均表现出色。截至目前，WhiteFox 已发现 101 个 DL 编译器错误，其中 92 个此前未知，70 个已修复，验证了其强大的错误检测能力。

—END—

BAZZAFL：通过面向漏洞的种子分组将模糊测试活动导向漏洞

通过命令行反馈利用大语言模型提高编译器选项黑盒模糊测试

Beyond REST：一种用于全面API漏洞模糊测试的工具APIF

原文始发于微信公众号（FuzzWiki）：WhiteFox：由大型语言模型驱动的白盒编译器模糊测试