Page 54 - 《软件学报》2026年第6期

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

一方面, RISC-V 灵活的自定义指令集扩展机制, 在催生大量定制化处理器的同时也带来了实现多样性与生态碎片
化的挑战, 不同厂商实现的行为差异可能被利用, 从而引入新的攻击面 [21] . 另一方面, 在日益复杂的片上系统设计
中, 硬件电路作为承载上层软件与应用的核心实体, 构成了整个计算系统的信任根基 [22] . 任何源于硬件设计阶段
的缺陷, 都可能被利用以发起绕过软件安全机制的跨层攻击 [2] , 从而使整个系统的安全体系土崩瓦解. 因此, 在
RISC-V 生态蓬勃发展的背景下, 如何确保硬件设计自身的安全性, 已成为保障整个信息系统安全的重要挑战.
硬件设计一旦经过流片环节, 其逻辑功能便被永久性地固化在物理芯片实体之中. 这意味着在硬件设计阶段
遗留的任何微架构层面的安全缺陷, 例如导致 Meltdown [23] 或 Spectre [24] 攻击的推测执行漏洞, 都无法进行根本性
修复. 这些缺陷并非软件层面的编程错误, 而是源于处理器为追求高性能而做出的基础设计决策, 这类缺陷的利用
与具体操作系统或应用软件无关 [25] . 这种无法被更改的物理特性, 决定了其修复代价会随设计流程的推进而急剧
攀升. 在 RTL 编码阶段发现的缺陷, 其修复成本可能仅为数小时的工程师时间; 然而, 一旦设计进入后端乃至流片
之后, 同样缺陷的修复则可能需要耗费数百万美元进行掩模重制和芯片重新流片, 甚至导致产品的全面召回. 更严
峻的是, 如 Spectre 等漏洞的修复方案往往只能依赖于性能损失巨大的固件级缓解措施, 而彻底的解决方案则必须
等待下一代处理器的重新设计 [24] . 这种跨层漏洞的严重性 [26] 与高昂的修复代价, 凸显了在设计早期进行高精度缺
陷检测的重要性.
在整个硬件设计流程中, RTL 设计阶段占据了承上启下的核心位置. 硬件设计本质上是一个从高级抽象向物
理实现逐层精化的过程, 它始于系统级的功能规约或高级语言模型, 终于物理版图 [27] . RTL 作为该流程的中间环
节, 是设计意图首次被代码化、结构化和时序化表达的阶段, 它将高层的功能算法转化为可被下游工具综合、布
局布线的具体电路描述 [28] . 正是这种独特的中间位置, 使 RTL 阶段成为识别并修正逻辑与安全类缺陷成本最低、
效率最高的时期. 一方面, 相较于上游抽象的规约, RTL 代码提供了足够的设计细节以进行深度的自动化分析和逻
辑验证. 另一方面, 相较于下游经过综合优化的门级网表和固化的物理版图, RTL 代码仍保持着高度的可读性与可
修改性. 在此阶段, 修正一个缺陷通常仅需修改几行源代码; 而一旦缺陷遗漏至后端乃至流片环节, 其修正成本将
呈指数级增长. 无论是常规的功能性错误, 还是如硬件木马等难以在后期通过物理测试发现的恶意设计 [29] , 在
RTL 源码层面进行审查和验证都是最直接、最有效的拦截手段. 因此, 将研究聚焦于 RTL 阶段的早期检测, 是保
障硬件安全、降低开发成本的关键.
1.2 硬件安全缺陷检测技术
在 RTL 设计完成后, 业界主要依赖动态仿真 (dynamic simulation) [30] 、形式化验证 (formal verification, FV) [31–33]
以及硬件模糊测试 (hardware fuzzing) [21] 等验证技术来保障设计的正确性与安全性. 这些技术是现代芯片设计流程
中不可或缺的组成部分, 构成了确保芯片质量的黄金标准 [34] . 例如, 形式化验证能够通过数学方法对设计的所有
状态空间进行穷尽性探索, 为关键模块提供完备的正确性证明 [32,33] . 然而, 这些传统验证方法均具有较大的局限
性, 主要体现在以下 3 个方面: 首先, 高度依赖完备的验证环境. 无论是动态仿真所需的大量测试用例和通用验证
方法学 (UVM) 平台 [35] , 还是形式化验证所需的精确规约和断言, 都需要验证工程师投入大量精力进行专门构建.
其次, 资源消耗巨大且反馈周期长. 完整的验证流程在芯片开发中占据近一半的时间与成本 [31] , 且形式化验证等
技术面临着严峻的可扩展性挑战, 对于复杂设计可能需要数天甚至数周的运行时间, 这种延迟无法满足设计者在
编码时对即时反馈的需求. 最后, 专业门槛高. 尤其是形式化验证, 其陡峭的学习曲线和对工程师专业能力的高要
求, 使其通常由专门的验证团队负责, 无法被 RTL 设计者在日常开发中便捷使用 [32] . 这些局限性使得上述方法只
能作为设计完成后独立的、重量级的验证阶段, 难以胜任设计编码过程中的伴随式检查任务.
为了弥补传统验证技术在开发早期的缺失, 静态代码检查技术 (Linter) 成为当前主流的伴随式早期检测方法.
与重量级的验证方法不同, Linter 是一种轻量化的自动化代码审查工具 [36] , 能够为硬件工程师在 RTL 编码阶段提
供即时的、自动化的反馈. 在硬件设计领域, 以 Synopsys 的 SpyGlass Lint 等商业 EDA 工具和 Verible Lint 等开源
项目为代表的 Linter 得到了广泛应用 [37,38] . Linter 的核心工作原理是基于一个预设的、静态的规则库. 其分析过程
无需编译或执行代码, 而是直接对 RTL 源代码进行处理. 首先, 工具会利用内置的解析器将 SystemVerilog 等硬件