Page 66 - 《软件学报》2026年第6期
P. 66

芮志清 等: MARC: 基于多智能体协同的硬件安全缺陷早期检测方法                                              2385


                    然而, 本缺陷未被基于任何基础模型的             MARC  分析框架所识别, 具体原因如下. 首先, 该缺陷具有高度的隐蔽
                 性. LLM  虽擅长识别错误赋值、逻辑紊乱等显式错误模式, 但对于由代码缺失所引发的隐式缺陷, 其检测能力存
                 在局限. 其次, 缺陷的领域特殊性超越了当前框架的设计范畴. 本文所提出的                       MARC  框架其核心设计旨在解决设
                 计知识鸿沟与代码语义缺失的挑战, 其优势在于理解高层设计意图及复杂时序逻辑. 然而, 这一缺陷并非源于设计
                 逻辑或时序错误, 而是由于        RTL  代码在综合阶段的工程后果.
                    这一现象反映了当前        LLM  在硬件  RTL  代码审计方面所面临的深层挑战. 当前主流的              LLM  普遍缺乏从    RTL
                 描述到综合后物理电路的推理能力. 尽管如此, 这并非否定了基于                    LLM Agent 的静态分析方法的价值, 反而为其
                 指明了关键的改进路径. 未来的          Agent 架构可通过集成轻量级的形式化           Linter 与综合工具, 将推断锁存器等警告
                 信息作为关键特征反馈给         LLM, 以有效弥补其在物理综合推理层面的短板. 与此同时, 还可以通过构建特定于硬
                 件综合缺陷的微调数据集, 实现对           LLM  的领域微调, 以显著增强模型对          RTL  的深层理解能力. 本文认为, 这种
                 LLM  结合  EDA  工具的混合   Agent 架构, 有望大幅提升对早期设计阶段中隐蔽硬件缺陷的检测覆盖率, 在硬件安
                 全领域依然具有广阔的应用前景.
                  4.4.3    SHA256  硬件寄存器敏感信息未清除安全缺陷
                    除了  OpenTitan, 本文还尝试在多个硬件       RTL  模块中进行安全缺陷检测. 其中, CVE-2025-50418       是一个基于
                 本文方法发现的真实        RTL  模块安全缺陷, 现已获得      CVE  官方确认. 该安全缺陷存在于广泛使用的开源               SHA256
                 加密  IP  核  SystemVerilogSHA256  中. 该安全缺陷的类型为  CWE-1239, 即硬件寄存器敏感信息未清除. 其问题根
                 源在于, 当哈希计算完成后或在不同用户上下文之间切换时, 未能清除存储在内部寄存器中的中间哈希值、最终
                 状态值及其他临时计算数据. 具体而言, 在            sha_mainloop.sv  和  miner.sv  模块中, 包括  8  个中间哈希寄存器、8  个最
                 终状态寄存器以及       1  个结果寄存器在内的多个关键状态寄存器, 在             done 信号置位后, 其内容并未被清零或擦除.
                 这些残留的敏感数据可被后续访问该硬件模块的非授权用户读取, 从而导致严重的信息泄露.
                    传统方法对该安全缺陷的检测存在局限性. 由于该安全缺陷并未影响该模块的功能正确性, 所以动态仿真方
                 法无法发现该安全缺陷. 而常规语义级静态分析工具                 Linter 由于其规则库中缺乏“加密状态在操作完成后必须擦
                 除”这类领域特定的高级安全知识, 且无法进行深层语义推理, 不能理解                     done 信号标志着关键状态转换, 因此也无
                 法发现该安全缺陷.
                    MARC  能够识别此安全缺陷的关键在于多智能体协同机制系统性地克服了传统方法的局限性. 模块文档分
                 析智能体通过检索增强生成从           CWE  通用设计规范中提取出“操作完成后必须清除敏感数据”这一核心安全规约,
                 并结合模块主要功能描述, 将存储哈希计算敏感数据相关的中间寄存器、最终状态寄存器和结果寄存器识别为关
                 键安全信号, 从而弥合了传统工具在安全知识领域的空白. 在此基础上, 依赖分析与缺陷检测智能体协同进行深度
                 代码语义分析, 它们构建代码语义图并追踪控制流, 最终确认在                   done 信号置位后, 并未执行任何针对上述关键安
                 全信号的清除操作. 最后, 缺陷确认智能体基于“安全资产在其生命周期结束后未被清除”这一事实, 进行断言生成
                 及验证, 高置信度地判定其为         CWE-1239  类型漏洞. 通过本案例可见, 通过将非结构化的设计安全知识与对代码执
                 行流程的深度语义理解进行结合, 才得以发现传统自动化工具无法覆盖的、与设计意图和安全规约紧密相关的硬
                 件安全缺陷.
                  5   讨 论

                    本文清晰地展示了       MARC  方法在硬件安全缺陷早期检测方面的显著有效性. 本节将围绕实验数据, 从多智能
                 体框架的必要性、影响性能的关键因素以及本方法在现有验证流程中的定位等维度展开深入讨论.
                  5.1   多智能体协同的必要性
                    从实验结果可以得出结论, 简单地将大语言模型应用于代码审计是不足的. 在所有测试中, MARC                              方法的综
                 合性能均显著优于       LLMOnly  基准方法, 当搭载    GPT-5  时, F1  分数领先约  16%, 并同时降低了漏报与误报. 这一优
                 势源于多智能体协同机制系统性地克服了单一模型调用的内在局限性.
   61   62   63   64   65   66   67   68   69   70   71