ZeroLeak: Using LLMs for Scalable and Cost Effective Side-Channel Patching
M. Caner Tol ，Worcester Polytechnic Institute，mtol@wpi.edu
Berk Sunar，Worcester Polytechnic Institute，sunar@wpi.edu
引用
Tol M C, Sunar B. ZeroLeak: Using LLMs for Scalable and Cost Effective Side-Channel Patching[J]. arXiv preprint arXiv:2308.13062, 2023.
摘要
安全关键软件，例如OpenSSL，由于缺乏资源或专家，出现了大量未被修补的侧通道漏洞。随着代码开发速度的加快，情况只会进一步恶化，因为开发人员依赖于大型语言模型（llm）来自动生成代码。在这项工作中，我们探索了使用llm来生成带有微架构侧通道泄漏的脆弱代码的补丁。为此，我们通过遵循零射击学习方法仔细制作提示来研究强大的llm的生成能力。所有生成的代码都通过泄漏检测工具进行动态分析，这些工具能够分别确定从秘密依赖访问或分支或脆弱的Spectre小工具泄漏的指令级别的信息泄漏。精心制作的提示用于生成脆弱代码的候选替换，然后分析其正确性和泄漏弹性。
经过广泛的实验，我们确定了提示在一系列查询中形成和堆叠的方式在llm生成正确和无泄漏补丁的能力中发挥着关键作用。我们开发了许多技巧来提高获得正确和侧通道安全代码的机会。此外，当我们比较不同的llm时，我们发现OpenAI的GPT4远远优于谷歌PaLM和Meta LLaMA，它们生成的补丁几乎所有漏洞都固定在脆弱代码和Spectre v1设备的微基准中。我们还发现，GPT4在生成正确和安全的代码方面比GPT3.5更成功，在后者中观察到许多失败的尝试。在效率方面，GPT4提供了一个更高效的补丁，与碰撞编译器支持的l栅栏Spectre缓解相比，开销减少了10倍。从成本/性能的角度来看，API中基于gpt4的配置成本仅要求修复每个漏洞几美分。然而，我们注意到，在成本上有很大的差异性，这取决于漏洞的类型(泄漏vs。Spectre小工具)和漏洞代码的长度。无论如何，我们的结果表明，基于llm的补丁更有效，因此提供了一个可扩展的解决方案。最后，我们提出的框架将及时改进，特别是随着漏洞检测工具和llm的成熟。
1 引言
微体系结构攻击的出现已经促使人们努力减轻硬件/固件和已部署的软件库中的漏洞。早期的漏洞，如那些利用秘密依赖的执行时间和缓存/内存访问模式的漏洞，随后是更高级的攻击，利用微架构优化，如无序和投机性执行、瞬态写转发和共享缓冲区。
最早和最容易访问的侧通道泄漏形式之一是执行时间。如果开发人员无意中写入了代码，例如，使用秘密数据依赖的分支，通过测量执行时间，攻击者可以推断出秘密信息。因此，识别易受攻击的软件并用固定版本替换它们一直是安全研究人员的目标。这在实践中是具有挑战性的，因为存储库与许多潜在的脆弱的部分具有复杂的相互依赖，而它们的执行时间也取决于许多因素，例如，平台及其配置、编译器。
Spectre是由安全研究人员在2018年的Spectre原始论文中首次发现并公开披露的。当攻击者诱使CPU投机性地执行在正常程序执行期间不会运行的代码时，就会发生Spectre v1。通过利用这个漏洞，攻击者可以潜在地访问存储在其他应用程序或操作系统内存中的敏感数据或信息。攻击利用处理器的推测执行推断出敏感数据并将其泄露。
在他的博客中，Kocher分享了15个容易受到Spectre v1变种攻击的代码片段，以测试一个新版本的微软VC/ c++编译器，该编译器具有内置的缓解措施，基于微软静态分析器识别的敏感代码部分添加LFENCE指令。编译器只能在前两个指令片段中缓解Spectre。Kocher指出， 他的代码示例还远远不够全面，例如，它们都依赖于缓存修改作为隐蔽通道，并且它们都驻留在更适合静态分析的简单函数中。Cauligi等人对现有的Spectre v1防御和非常数时间检测工具进行了全面的调查，例如oo7, Spectector,Spec-Fuzz,Pitchfork。
具有微架构漏洞的代码，例如秘密依赖的非常量时 间或易受Spectre v1攻击的代码，一直是科技行业的一个重大问题 。硬件和软件供应商已经发布了缓解措施来降低漏洞利用的风险，但完全解决这些漏洞仍然是一个持续的挑战。此外，这些缓解措施通常以性能下降为代价，因为它们可能禁用或限制某些投机性执行功能。
在一项对加密库开发人员的研究中，61.4％的参与者表示，他们要么不知道，要么没有使用工具来测试和验证恒定时间——这是侧信道安全性的必要但不充分的条件。更糟糕的是，这些被数百万最终用户使用的库中，有许多是由少数开源项目的开发人员管理的。他们既没有知识也没有资源来为他们的软件打补丁以防止这种低级别的泄漏。由于缺乏资源，在数百万人使用的公开开源加密库中，报告的漏洞经常被忽略和未修补。例如，参见Microwalk-CI。另一个引人注目的例子是OpenSSL博客文章解释了他们为什么不为上报道的新发现的Spectre工具打补丁的决定: 大多数潜在易受攻击的代码都是极其不明显的，即使对有经验的安全程序员也是如此。因此，很容易在不知不觉中引入新的攻击向量或修复现有的攻击向量 。“‘攻击的自动化验证和测试是必要的，但还不够。我们还没有针对这类漏洞的自动化检测，即使有，也很可能无法检测到这些变化。”这些注释强调了可靠和透明的补丁自动化的必要性。
本文研究了使用llm进行安全关键软件的自动补丁。事实上，预计到2025年，80%的软件开发生命周期将使用生成式人工智能，即llm。因此，迫切需要评估llm生成安全关键型实现的能力。如果我们使用普通提示来生成加密代码，会发生什么？我们如何改进代码生成，以提高侧通道安全性？llm技术的快速发展使我们感到鼓舞。在最近的变压器网络、生成模型以及大量数据集和大型计算集群的可用性等创新的推动下，训练大型语言模型（llm）已经成为可能。OpenAI的GPT3和GPT4，谷歌的RBERT和PaLM2，RoBERTa和LLaMa，MetaAI的[在人工智能应用和自然语言处理（NLP）方面显示出了令人印象深刻的性能。这些工具也使用代码片段进行训练，允许人们灵活地解析甚至生成通用编程语言中的代码。
本文研究了以零样本方法使用llm， 并结合最先进的泄漏和漏洞检测工具来修复依赖于数据的非恒定时间行为，以及秘密依赖的分支和Spectre v1小工具。已知这些漏洞存在于部署在数百万台机器上的许多安全库中。然而，由于缺乏资源，即专家和财政资源，它们没有被修补。我们的目标是利用llm中的大量最新进展，如OpenAI GPT、谷歌PaLM和Meta LLaMA来自动生成补丁。请注意，llm相当大，需要数周到数月的时间来训练大量的数据集，只有大公司才能访问这些资源。我们的目标是通过API访问利用llm，将补丁部署的成本降低到每个微架构泄漏的美分。
1.1 贡献
我们首次介绍了对最先进的LLMs的全面研究，即OpenAI GPT、谷歌PaLM 2和Meta LLaMA，以自动修补微架构漏洞，如秘密依赖（非恒定时间）代码和Spectre v1小工具。我们构建了一个工具链，测试泄漏和Spectre检测工具的二进制文件，特别是Microwalk、Pitchfork、 Spectector和KLEESpectre，然后使用llm自动生成包含在源文件中的安全补丁。从软件开发生命周期中的持续集成/持续开发（CI/CD）的角度来看，所提出的框架允许我们修补源代码（例如，C/C++、Javascript等）。在目标机器上编译后测试二进制文件。与二进制补丁相比，我们保留了审查和修改源代码的能力。同时，我们还通过测试二进制文件的泄漏情况，考虑了编译器和平台配置对安全性和效率的影响。这种方法允许我们随着硬件系统和软件堆栈的发展而不断改进软件。在我们从已知漏洞编译的C代码微基准上，GPT4成功修补基准中每种类型修补点的97%，而修补33个泄漏的总成本为1.34美元。GPT3.5能够修复62%的泄漏点，而成本比GPT4的19倍。谷歌聊天野牛和Meta LLaMa2分别对所有漏洞进行了56%和35%的补丁，尽管成本要低得多。我们的框架只受到检测工具能力的限制，例如假阳性和阴性，并将通过更好的检测工具进一步改进。类似地，LLM正在以惊人的速度改进（几乎每个月都会发布一个新的LLM），我们预计我们的工具的整体性能会有显著改善。从效率的角度来看，我们的工具链比用现有的方法生成的Spectre v1补丁快10倍，我们的性能明显优于基于编译器的技术，如在clang lfence注入中。因此，方法为消除不必要的低效和保持安全性提供了一个机会。由于我们正在用输出生成的LLM修补源代码，所以对补丁也进行了注释，这使得补丁更容易理解和维护代码。2 背景
2.1 恒定时间实现
恒定时间实现是指需要恒定时间来执行的加密算法和方法，无论输入大小或值如何。这种类型的实现对于保护系统免受定时攻击至关重要，定时攻击是一种侧通道攻击，攻击者可以通过观察执行时间来获得有关系统秘密数据的信息。在RSA解密算法中可以看到一个实际的例子，其中可以根据密钥位选择不同的执行路径。攻击者可以利用这个时间差异来推断出密钥。恒时加密算法的实现过程通常需要细致的编程，以确保没有分支（如if-then-else构造）、循环或其他操作取决于秘密数据。例如，像AES这样的加密算法应该避免依赖数据的分支，并采用位操作，已知这些操作在大多数平台上在恒定时间内执行。
图1: 一个违反常量时间属性的数据依赖相等性检查逻辑的例子
在保证真正的恒定时间实现方面存在着挑战，特别是在具有无序执行和投机性执行等特性的当代cpu上。这就需要深入了解密码算法和它所使用的功能的硬件。
有几个常时间密码算法的例子，如AES-GCM实现中使用的常时间无携带乘法和椭圆曲线密码学中使用的常时间模反演。
有大量的工具可以自动验证恒定时间标准。然而，学术研究与密码工程实践之间存在着显著的差异。尽管有可用于检查固定时间执行的工具，但由于资源限制，开发人员经常忽略了这一点。
考虑到侧信道攻击的复杂性、日益增加的异构性以及计算平台的不断发展，需要不断地对安全关键软件进行重新评估，以实现持续时间的执行。未来的研究和发展工作将永远集中于生成更安全和高效的恒定时间算法。
Microwalk-CI是一个动态的侧通道分析框架，易于集成到JavaScript开发工作流中。Microwalk-CI采用了现有的微框架，它最初是为发现二进制软件中的泄漏而设计的。为此，Microwalk为一组随机输入生成许多执行轨迹，然后使用互信息（MI）对它们进行比较，MI是一种稳健的度量，允许定量评估信息泄漏的程度。MI可以捕获广泛的潜在泄漏，包括那些来自执行路径和内存访问的泄漏。然而，值得注意的是，Microwalk要求测试人员为每个被测试的函数生成一个输入模板文件，并且需要在生成熵估计时解释报告文件。
2.2 Spectre v1
Spectre v1（CVE-2017-5753），也被称为边界检查旁路，影响了广泛的现代处理器，包括那些来自英特尔、AMD和ARM。它允许攻击者欺骗程序投机地执行不应该执行的代码，可能会泄露敏感数据。图2提供了一个简单的Spectre v1示例。现代cpu有用于预测条件分支结果的组件，以推测地执行指令。攻击者用恶意条目填充分支历史记录表，这样，当受害者运行分支时，分支预测器就有很高的机会发生错误预测。第2行检查用户输入x是否在数组1的绑定中。在常规执行环境中，如果满足条件，程序检索数组1的第x个元素，并且检索到的值（512）的倍数被用作索引，以访问数组2中的数据。但是，在某些情况下，大小变量可能不存在于缓存中。在这种情况下，CPU不是等待大小可用，而是推测地执行下一个指令。以消除尺寸可用时不必要的管道停顿。一旦CPU注意到错误的预测，它就会回滚并遵循正确的执行路径。尽管在架构组件中无法看到推测执行的指令的结果，但对阵列2的访问在缓存中留下一个足迹，使得通过侧通道分析泄漏数据成为可能。
图2: 示例Spectre-V1 C 代码
Spectre v1具有缓解性，因为它是一个硬件级别的问题，传统的基于软件的安全措施不足以完全保护它。由于Spectre v1是一个复杂的漏洞，在不同的处理器架构和代之间具有广泛的影响，这一直是行业全面解决的一个持续挑战。
2.2.1 Spectre v1 的测试
我们简要总结了Pitchfork, Spectector, 和KLEESpectre。
KLEESpectre旨在用符号执行来建模缓存的使用，以检测基于KLEE符号执行引擎的投机干扰。KLEESpectre是在Kocher的Spectre v1变体和密码库libTomCrypt, Linux-tegra, openssl和hpn-ssh上进行了评估。
Pitchfork是一个符号分析工具，它验证代码对于加密密钥或消息明文等秘密值是恒定的。Pitchfork使用欠约束的符号执行，并增强了动态污染跟踪来验证常量时间的执行。特别是，它使用影子内存来跟踪秘密，即使它们是从内存中存储和加载。Pitchfork还允许功能钩子的规范，这使得Pitchfork可以在协议级别验证代码，同时忽略加密原语的实现。Pitchfork被用来验证Mozilla的NSS密码库的大部分是恒定时间的，同时也发现了几个恒定时间的漏洞。
Spectector引入了推测不干扰（SNI）的概念，并开发了一种基于符号执行的算法来自动证明SNI或检测表明Spectre漏洞的违规，然后可以修补。SNI要求推测执行的指令不会比预期行为泄露的微架构状态泄露更多的信息，即，由标准的、非推测语义泄露的信息。为了捕获“泄漏到微架构状态”，我们考虑了一个程序执行的观察器，它可以查看内存访问和跳转目标的位置。在这个观察者模型下，如果对手产生不同的内存位置和跳跃目标的轨迹，他们可以区分两种初始程序状态。Spectector能够检测到Kocher的15 Spectre v1变体中的所有泄漏，也能够检测到oo7范围之外的新颖、微妙的泄漏，甚至识别编译器不必要注入对策的情况。
3 威胁模型和范围
在这项工作中，我们专注于防止秘密通过软件可观察到的变化被泄露。利用微架构侧通道，攻击者可以获得加密密钥、密码等敏感信息。我们假设攻击者想要利用特定的通道系统，和攻击需要安全关键软件展示以下一个或多个属性。
代码访问模式取决于秘密；数据访问模式取决于秘密；代码的执行时间取决于秘密。尽管即使这些属性都不存在于逻辑通道中，底层的硬件实现也可能会导致物理上可见的泄漏，例如通过功率和电磁辐射，但我们在这项工作中只考虑软件支持的泄漏。
我们还假设该软件没有bug，并以预期的方式工作。因此，本工作不考虑常见的软件漏洞，如缓冲区溢出、无后使用等。我们假设攻击者有能力测量软件的执行时间，或通过共享系统组件的缓存收集其他类型的元数据，并通过秘密的与数据相关的分支、内存访问模式或利用投机执行来推断敏感信息。
我们探索了使用最先进的llm来提高安全关键软件对这些微体系结构攻击的弹性。由于从头开始训练llm成本高、费时、耗能量，并且对环境有影响，因此我们将定制训练的llm排除在范围之外，只专注于零样本学习。
4 生成加密文件的实现
加密算法是复杂的，而且是出了名的，很难从头开始实现。需要一个冗长的审查过程来考虑所有可能导致安全漏洞的角落情况。我们考虑了使用启用llm的代码助手从头开始生成加密代码时的场景。使llm生成一个整个加密算法可能会失败，因为生成的代码的长度比流行模型的令牌容量长得多。例如，最先进的GPT4模型的最大令牌容量为32K，包括当这项工作完成时的提示和响应。受思维链提示技术的启发，这表明llm在生成中间步骤时比直接生成最终结果时表现更好，我们采用了分治策略，迫使模型逐个生成更小的算法片段。这样，我们就克服了创建一个大型而连贯的实现的挑战。具体地说，我们通过函数生成算法，以保持块之间的相干性。由于生成的代码是模块化的，测试和验证，也变得很简单。为了生成一个名为<A>的加密算法，我们提示了一个LLM，如图3所示。在llm的零样本设置中给出上下文对生成的样本的质量至关重要。由于许多语言模型包括公开的自然语言来源，如教科书、维基百科等，它们往往在推理时间内生成长且信息丰富的文本。在许多最先进的llm中，系统提示器作为高级和通用的命令，用来控制生成的样本的风格。由于我们使用尽可能少的人工交互来检查自动化，因此我们会尽量最小化对后处理的需要。我们指示模型不要给出多余的解释，并告知在系统提示中使用哪种编程语言。然后，我们迭代地提供用户提示。在第一次迭代中，我们首先指示模型生成一个实现某个算法<A>.所需的函数和常数列表这将为下一次迭代创建一个路线图。在每次迭代中，我们指示模型实现一个函数，该函数作为第一次迭代响应的列表返回。最后，我们在最后一次迭代中使用一个示例输入和键来生成驱动程序函数，这有助于我们运行和测试代码。
图3: 用于生成加密文件实现的提示模板。用<bold>编写的部分表示提示符中的变量。
我们根据目标算法的标准手动初始化常量，例如S-box条目。以迭代的方式生成函数可以提高实现的质量。我们还通过验证加密算法是否为某个输入生成了正确的密文，以及纯文本和解密的密文是否匹配，来测试功能的正确性。
5 确保持续执行
自从定时侧通道攻击[29]出现以来，人们提出了许多工具来验证软件的恒定时间（数据无关）特性。然而，实现固定时间代码的责任主要取决于软件工程师。因此，许多安全关键型库在它们的CI/CD管道中缺乏对固定时间属性的任何形式的测试。据我们所知，我们首次提出了一种基于llm生成恒定时间实现的自动化工具。
5.1 评估测通道泄露
我们通过假设一个健壮的对手（求值器）来解决侧通道泄漏问题，包括内存访问和执行路径。对手还可以选择和修改任何秘密系统的输入。在缓存攻击的上下文中，对手将内存访问视为一个泄漏向量，在整个执行过程中使用各种秘密值收集所有内存访问。如果发现了不同的秘密和内存访问变化之间的关系，对手就可以精确定位与秘密依赖的内存访问相关的指令，并揭示潜在的泄漏。在软件验证领域中存在着各种工具来检测这种泄漏，每一种工具都能够确定软件的恒定时间。特定工具的选择取决于手头任务的特定需求和限制。在我们的案例中，我们使用Microwalk，因为它的好处，同时承认它的局限性。Microwalk利用互信息，这是一种稳健的度量，允许我们定量评估信息泄漏的程度，提供一个清晰和可解释的度量。此外，Microwalk可以捕获广泛的潜在泄漏，包括那些来自执行路径和内存访问的泄漏。对于我们的用例来说，最重要的是，它可以在二进制代码和源代码中定位泄漏的源（如果可用的话）。但值得注意的是，微量算法需要多次执行目标二进制方法来准确估计互信息，这可能会增加计算成本。因此，我们的选择平衡了综合泄漏检测、定量评估能力和计算的可行性。
Microwalk首先为给定的秘密生成任意输入。在此之后，在每个输入上运行目标二进制文件，收集在每次运行中关于内存分配、分支、调用、返回、内存读写和堆栈操作的数据。理想情况下，常量时间实现应该有一个针对秘密输入的线性执行路径。依赖于秘密的条件分支会泄露有关该秘密的信息。通过将执行路径作为泄漏向量，我们可以确认对任何秘密输入是否执行相同的操作。另一个常见的泄漏源，内存访问，在常量时实现中应该遵循一个与秘密无关的模式。因此，我们确保内存访问要么是恒定的，要么至少与输入不相关。
5.2 恒定时间的修补
使用llm自动化固定时间补丁需要解决三个主要挑战。
挑战C1。首先，在简单程序中修补常见的软件漏洞通常可以通过更改几行代码来解决，这些llm被证明能够进行。然而，使算法的软件实现固定时间要复杂得多，因为它需要对算法逻辑有深入的理解，并跟踪这个秘密是如何以及在哪里使用的。此外，单个代码可能有多个点，从而导致整个泄漏。因此，llm在一次复杂的实现中不能很好地修复侧通道泄漏。
图4: ZeroLeak框架概述。
挑战C2。其次，简单地声明代码显示了与秘密相关的可观察到的痕迹，并不足以修补一个复杂的逻辑。这也是为什么人类开发人员在不定位泄漏点的情况下难以创建常时代码的原因之一。因此，定位代码中的泄漏点对于llm的高效补丁也是必要的。
挑战C3。最后，提示应该以正确的方式精心制作，以最精确和清晰的方式解释泄漏的原因，而不留下任何歧义。例如，在提示符中单独指示LLM“使代码为恒定时间”，而不给出任何安全上下文，可能会导致对时间复杂度上下文中的恒定时间的误解，即算法的运行时复杂度应该是O (1)。这显然是不够的，因为我们希望运行时独立于实际的输入值。
我们通过采用一种迭代的方法来克服C1。由于许多llm都被设计成一个聊天机器人，因此它们在与来回的信息交换和来自人类的反馈的对话中表现得更好。由于我们的目标是用一个工具替换补丁过程中的人类，所以我们可以用分析工具在目标平台上运行生成的代码，并无需任何成本获得反馈。我们使用了一个如图4所示的补丁循环，其工作原理如下：
假设我们在库中测试一个函数，我们首先确保该函数在Microwalk模板中调用，并且单元测试已经准备好验证代码的正确性。分析模板也可以使用图5中提示的llm生成。然后，我们在必要时编译代码，并在它上面运行Microwalk。假设第一个版本已经正确，我们的工具开始解析分析文件，并将易受攻击的函数与提示一起传递给llm，以便它们可以生成补丁代码。使用解析器/编译器验证补丁代码是否语法正确。如果语法错误，我们会给LLM提供反馈，直到它生成语法正确的代码。如果语法正确的代码未能通过嵌入在Microwalk模板中的功能正确性测试，它也将再次转发到LLM。当没有发现漏洞时，循环将结束，但在有限的资源下，迭代次数和总执行时间可能会受到限制。当语法正确时，我们还会附加LLM给出的响应。随着循环的继续，给LLM的上下文看起来像[系统、用户、响应、用户、响应、……]，这是聊天机器人应用程序中常见的做法。如果上下文大小达到模型的最大令牌计数，我们将从第三条消息开始删除，始终保持上下文中保持系统提示符和原始函数。
图5: 提示以生成微型服务器的驱动程序代码。
我们通过选择一个能够定位二进制代码和源代码中的泄漏点的分析工具来解决C2的问题。微木是一个合适的选择。Javascript版本可以准确地判断源代码中的哪一行确实会导致泄漏。另一方面，C版本可以在装配级标记泄漏源。为了将装配线转换为C源代码，我们使用调试符号编译它，并使用objdump拆解二进制文件。更先进的反向工程工具，如Ghidra 或IDA，也可以用于更准确的结果。拆卸后，我们将创建一个装配线到C线的映射，以便稍后在提示中使用。
对于C3，我们使用Microwalk的分析结果，它显示了准确的泄漏点作为代码线，并将泄漏机制分类为某些类，如基于内存访问和条件执行。我们将分析结果合并到自然语言中，llm可以更好地理解它，如图6所示。与第5节类似，我们给模型提供了一个系统提示符，但还添加了一些防止常见错误的附加命令。我们发现了一些错误，比如
只生成代码的补丁部分，因为其余部分没有改变，调用一个未定义的假设函数或变量，更改给定函数的参数的数量和类型，并更改函数的名称，这些都破坏了程序与库中其他部分的兼容性。我们还描述了如何在需要时添加新的函数。如果没有这个命令，模型可以给出一个新的函数，而不将其集成到主函数中，当我们直接覆盖主函数时，也会导致崩溃。最后，我们包括了工具和语言特定的命令，这些命令无需生成安全/功能代码，但需要解决兼容性问题，例如，类似于让的新特性会导致Javascript基于的Jalangi2的崩溃。
图6: 提示模板为固定补丁的时间。我们用编程语言替换了<language>，如C或Javascript。我们使用<specifics>来指导工具或特定语言兼容性问题的变通方法。其他的变量也是不言自明的。
在制定修补侧通道泄漏的提示时，我们会在用户提示中考虑以下选项：
选项1-泄漏内存访问模式：在给出完整的函数后，我们在代码行中列出数组的名称，并给出完整的行，并指示模型使内存访问独立于秘密。
选项2-泄漏条件执行：对于这种情况，我们从行解析if/terary，并指示LLM在没有if语句和三元运算符的情况下实现它。
选项3-秘密相关的循环大小：我们解析循环中的终止条件，并指示模型保持每个输入的迭代次数不变。
选项4-语法/功能上不正确的代码：一些迭代可能会生成语法上不正确的代码，即使不运行它也可以检测到。
我们使用来自解析器/编译器的反馈作为下一次迭代的提示，以避免丢失修补其他错误的尝试，因为它们在逻辑上可能仍然是正确的。一些迭代可能会生成功能不正确的代码，可以在运行时检测到。为此，我们在测试台中使用断言语句，并将<crash reason>设置为代码不能正常工作。
由于在这个场景中选项是有限的，所以基于模板的半自适应提示制作效果很好。对于一个更自适应的系统，快速设计可以从生成AI和链接LLMs。
6 缓解Spectre-v1
瞬态执行攻击允许攻击者绕过数组访问中的绑定检查，并可能读取内存中的任何位置，包括秘密值。尽管提出了许多硬件和软件防御来减轻这些攻击，但由于修复程序不精确，或者由于缺乏资源、性能影响和可伸缩性等原因根本没有部署，因此存在巨大的开销。通常，由于过于通用的设计，可扩展的缓解措施会带来很高的开销。另一方面，像索引屏蔽这样的低开销解决方案需要手动更改代码。即使在源代码中手动添加缓解之后，缓解对二进制文件的影响也常常被忽视。在Linux内核上发现了一个这样的例子，即依赖手动修复源代码而不进行二进制测试的失败。在出现Spectre攻击之后，Linux开发人员添加了一个新的API，它实现了array_index_nospec宏，将索引夹夹到数组中，以达到最大的数组大小。尽管这是一个正确的修复，但在一种情况下，编译器消除了它，因为编译器语义没有意识到投机执行，它可以优化关键的攻击缓解。因此，在本节中，我们将重点讨论如何使用在二进制文件上得到可靠验证的llm来自动化低开销的软件缓解措施。
6.1 寻找Spectre-v1 小工具
以一种可扩展和可靠的方式寻找Spectre-v1小工具仍然是一个正在进行的研究领域。然而，为了自动化Spectre-v1小工具的补丁过程，我们需要一个既可扩展又可靠的工具。在这项工作中，我们评估了一些分析工具的使用，如Pitchfork, Spectector, 和KLEESpectre，它涵盖了最先进的检测工具的不同方面，如安全保证、可伸缩性、检测方法、无序执行支持、处理非确定性和泄漏模型。尽管Pitchfork也支持SpectreSTL（存储到加载）变体，但我们只考虑PHT（页面历史表），这是所有三种工具都支持的常见变体。Spectector提出了投机不干涉（SNI）的概念，它要求目标程序没有比其非投机状态有更多的泄漏。该特性也被归类为相对不受干扰的。Pitchfork引入了推测常数时间（SCT）的概念，它需要一个比相对无干扰特性更强的直接无干扰特性。Spectector和Pitchfork都使用了一个与硬件无关的恒定时间泄漏模型。KLEESpectre通过使用微体系结构特性扩展符号执行来检测投机执行导致的数据泄漏，并测试每个条件分支的每种方式（获取或未获取）。它假设分支预测器总是会错误地预测。
6.2 补丁Spectre-v1 小工具
尽管发现Spectre-v1设备面临重大挑战，但为这些设备制定缓解策略也同样具有挑战性。在本工作中，我们首次提出使用llm来修补瞬时域中已知泄漏点的函数。
我们在第4节和第5节中解释的大多数挑战与生成恒定时间的加密实现重叠。因此，在恒定时间内的整体零泄漏框架也将适用于这里，使用不同的工具，而不是图4中的微泄漏框架。由于我们分析的所有工具都能够提取符号执行树，因此它们可以在组装级别精确定位泄漏源。从程序集开始，我们在5.2中使用相同的方法将其追溯到源代码。
我们的设计根据条件分支引起的推测泄漏机制及时改变模板。我们使用的系统提示符非常相似，除了我们将“固定时间”替换为“安全的”，因为我们不想指示模型在给定的代码中存在非投机性泄漏。请注意，非投机场景中的泄漏机制涉及到提供给程序的秘密输入。然而，在Spectre-PHT中，输入是由攻击者控制的，并不被认为是秘密的。对于用户提示，我们考虑以下两个选项，如图7所示：
图7: 提示模板为补丁Spectre-v1小工具。
选项1-Spectre-v1违反：在给出完整的函数之后，我们解析包含if条件或三元运算符的语句，它们被编译器转换为二进制文件中的条件分支。我们提到，即使条件是错误的，投机性执行也可能导致不正确的执行，并指示模型替换条件语句。虽然更详细的提示，包括更多的细节，比如哪个数组被索引和它如何被解码，可能听起来更直观，但我们选择了一个更通用和更精确的提示，不太像混淆低容量模型。
选项2-语法上/功能上不正确的代码：我们使用与第5.2节相同的方法。
转述：沐燕舟
