LLM-Assisted Detection and Repair of Hardware Security Vulnerabilities in Verilog Designs

技术摘要：利用大语言模型辅助检测与修复 Verilog 设计中的硬件安全漏洞

问题陈述
硬件设计，特别是以 Verilog 寄存器传输级（RTL）描述的设计，容易受到安全漏洞的影响。这些漏洞一旦被固化到硅片中，就会变成永久性的且无法修复。与软件不同（软件漏洞可以更新），硬件缺陷可能导致未经授权的数据泄露、权限提升以及未经授权的访问。虽然大语言模型（LLM）在辅助 RTL 代码修复和测试平台（testbench）创建方面展现出了潜力，但它们目前在硬件安全分析领域面临着显著挑战。这些挑战包括缺乏领域特定知识、对硬件设计的固有偏见，以及“约束不足的修复”（under-constrained repair）问题——即 LLM 提出的修复方案在语法上是正确的，但在功能上却不相关，或者改变了预期的设计行为。此外，现有方法在处理长上下文处理以及追踪随时间变化的漏洞复杂性方面也表现得较为吃力。

方法论
作者提出了一种结构化的迭代框架，旨在利用 LLM 来检测和修复单个模块 Verilog 设计中的常见弱点枚举（CWE）。该方法针对 MITRE 2025 年最重要的硬件漏洞列表（不包括微架构问题）中识别出的特定硬件弱点。该过程遵循一个七阶段流水线：

1. 模块分类： LLM 识别模块类型及其特性（例如 JTAG 接口、调试模式），以缩小潜在 CWE 的范围，防止信息过载。
2. 资产识别： 模型识别关键资产，如加密密钥、权限边界、时钟/复位方案以及有限状态机（FSM）状态。
3. 依赖图分析： LLM 生成程序依赖图（PDG）以建模数据流和控制流。它执行可达性、支配性以及污点传播分析，以理解设计行为和潜在的数据泄露。
4. CWE 驱动审查： 利用前述步骤的输出和特定的 CWE 指南（包含描述、常见原因和检查清单），LLM 进行针对性审查以识别特定漏洞。
5. 测试平台生成： 基于识别出的漏洞和特定于 CWE 的安全设计规则，LLM 生成测试平台以验证缺陷的存在。
6. 仿真： 生成的测试平台针对 RTL 设计进行编译并运行。
7. 代码修复： 如果测试失败，LLM 会尝试使用失败的测试用例和作为约束条件的 CWE 设计规则来修复代码。此循环最多重复三次。

该框架在包含 32 个单模块 Verilog 设计的数据集上进行了评估，其中包括 27 个已知存在漏洞的设计和 5 个特意设计的安全模块。Microsoft Copilot 被用作评估所使用的 LLM。

关键结果
研究结果呈现出复杂的结果，凸显了 LLM 在该领域的潜力与当前的局限性：

• 优势： LLM 在模块分类、资产识别以及对设计结构和行为方面（通过 PDG 分析）的推理能力表现强劲。它在几乎所有案例中都正确识别了模块的功能类型，并且通常在正式的 CWE 驱动审查之前就能识别出漏洞。
• 劣势：
  • 测试平台生成： 这是最大的弱点。生成的测试平台经常无法验证安全属性，其原因通常包括对被测器件（DUT）的使用不当、测试用例不完整或未能实现测试间的 DUT 复位。
  • 安全设计的误报： 在五个无漏洞的模块中，LLM 表现出较高的误报率，错误地将安全设计标记为存在漏洞。它经常建议添加不必要的安全特性（如锁定位、权限控制），从而改变了原有的预期功能。
  • 修复局限性： 虽然 LLM 可以生成语法正确的补丁，但修复过程有时会修改原始设计的预期功能。模型倾向于优先考虑安全增强而非保留原始行为，从而导致“过度工程”（例如，为不需要访问控制的模块添加访问控制）。
• 成功率： 在 32 次总测试中，有 27 次通过，取得了 84% 的成功率。这一成功率主要反映了包含已知漏洞的 27 个模块被成功识别并修复。然而，那 5 个非漏洞模块（旨在测试 AI 区分安全设计的能力）未能实现这一特定目标。AI 在所有五个安全模块中都错误地识别出了漏洞，导致了高误报率。对于这些非漏洞案例，由于识别出的问题并非实际漏洞，因此未进行代码修复；修改这些设计会改变其预期功能。在漏洞集中，部分失败也归因于无法生成有意义的验证结果（例如，输出未初始化）或未能正确分类模块的主要功能，从而导致遗漏了相关的 CWE。

意义与主张
本文声称，其提出的方法论展示了 LLM 增强传统硬件安全分析的潜力，能够在设计过程中提供自动化的、可扩展的辅助。作者强调，他们的方法通过将分析结构化为可管理的步骤（分类、资产识别、图分析），有助于弥合 LLM 能力与硬件安全严苛要求之间的差距。

然而，作者在结论中保持了谦逊，承认目前的方法论并非完全自主的解决方案。他们指出，结果凸显了以下方面的必要性：

1. 精细化提示词（Prompting）： 以减少幻觉，并将修复限制在特定的漏洞内，而不改变预期功能。
2. 明确的上下文： 向 LLM 提供关于模块用途和预期行为的明确信息，以提高分类和修复的准确性。
3. 进一步评估： 需要在更大规模、更多样化的 CWE 和 RTL 设计集上测试该方法论，以评估其泛化能力。

论文得出结论，尽管 LLM 在解释模块行为和识别资产方面展现出前景，但其在 RTL 推理、测试平台生成以及漏洞验证方面的可靠性仍受限于领域知识差距和约束不足的修复提示等因素。这项工作为开发和微调未来的基于 LLM 的硬件安全工具提供了指导。