体系结构论文（九十五）：MARVEL: Multi-Agent RTL Vulnerability Extraction Using Large Language Models

MARVEL: Multi-Agent RTL Vulnerability Extraction Using Large Language Models一、这篇论文在解决什么问题这篇论文讨论的不是普通的 RTL 生成功能而是一个更偏安全验证、也更接近真实 SoC 安全审计的问题能不能让一个多智能体 LLM 系统去自动发现 RTL 里的硬件安全漏洞这里的关键词不是“生成代码”而是“找漏洞”。而且作者不是只想让 LLM 像聊天机器人一样对着源码说几句怀疑而是希望它像一个真正的安全验证工程师那样1. 看设计文档2. 识别安全目标3. 决定该调用哪类工具4. 读代码5. 跑 lint / formal / simulation6. 借助漏洞知识库和相似 bug 检索7. 最后形成安全报告这就是 MARVEL 的定位。从调研角度说这篇论文的重要性不在于它首次让 LLM 发现了某个安全 bug而在于它把“硬件安全验证”这个本来就很复杂的流程组织成了一个 supervisor-executor 的 agent 体系。二、背景为什么硬件安全验证特别难自动化1. 硬件安全验证本来就很耗时2. 已有方法很多包括 formal verification、lint、信息流分析、fuzzing、simulation3. LLM 也已经开始被用于硬件 debug 或 bug detection但问题是现有 LLM 用法大多还是1. 给它一个既定流程2. 给它一个既定工具调用方式3. 让它在一个受限步骤里辅助判断换句话说LLM 可能会帮你“解释一个问题”但它并不真的“控制整个验证流程”。作者认为这正是一个缺口真正的人类安全验证工程师不是先拿到一张固定流程图再机械执行而是会根据1. 文档2. 代码3. 工具反馈4. 之前怀疑的漏洞方向动态地决定下一步应该用什么方法继续查。MARVEL 的目标就是模拟这种认知过程。一、Introduction引言里最重要的一点不是“multi-agent 比单 agent 好”这种泛化论断而是RTL 安全 bug 与软件 bug 有本质不同。作者明确说到1. RTL bug 深度绑定 clocking、concurrency、hardware semantics2. 一旦 bug 进入硅后修复成本极高所以软件里常见的一些 agent 流程不能直接套到 RTL 上。作者认为一个适合 RTL 安全验证的 agent 系统至少要能做三件事1. 识别安全目标而不是只找语法错2. 结合硬件特有工具链3. 用硬件视角解释结果Figure 1 很简单它画的是一个 supervisor-executor architecture。作者想通过这张图传达一个最核心的框架不是所有 agent 平行乱跑而是1. Supervisor 负责制定和推进安全分析计划2. Executor 负责执行某一类专门策略这张图的重要性在于它把 MARVEL 和很多“单 LLM 多工具”方法区分开了。后者本质上还是一个 agent 在做所有判断而这里是一个总控 agent 决策多个专职 agent 提供不同类型的证据。二、方法Figure 2 把整个 MARVEL 的组件画全了。图里可以看到1. Supervisor Agent2. Linter Agent3. Assertion Agent4. CWE Agent5. Similar Bug Agent6. Anomaly Agent7. Simulation Agent还可以看到三类外部资源1. 工具如 lint、formal、Verilator、clustering2. RAG 数据库CWE DB、bug DB、lint rules DB3. 文件系统能力list dir、read file这张图最关键的意义是MARVEL 并不是一个“让所有 agent 都会做一点”的均匀化系统而是一个高度功能分化的系统。它的每个 executor 都绑定了一种相对独立的漏洞发现思路。作者这里的设计选择其实很明确硬件安全验证不是单一推理问题而是证据汇聚问题。不同 executor 的作用就是从不同角度生成证据再交给 supervisor 做综合判断。Overview作者用 agent 研究中常见的四个元素来描述 MARVEL1. Profile每个 agent 的 system prompt 都不同2. Memory除了上下文窗口还有外部向量库3. Planningsupervisor 决定调谁executor 决定是否继续调工具4. Action真正去调 lint、formal、simulator 或查询数据库这说明 MARVEL 至少在系统组织上是完整的而不是“把几个 prompt 放在一起就叫多智能体”。Supervisor Agent它的职责有三层1. 识别相关 security properties2. 决定调用哪些 executor3. 对返回结果做综合判断最终产出报告Figure 3 里作者还给了 supervisor 的 system prompt。这个 prompt 里有几个非常关键的指令1. 先读 documentation识别 security features 和 register interface policies2. 优先用 Verilator、Assertion、Anomaly、Linter 做初筛3. 如果发现 bug 但没定位清楚再用 CWE Agent 深挖4. 发现 bug 后用 Similar Bug Agent 扫类似文件漏洞发现不是所有工具平等并列地跑一遍而是有一个“先粗筛再定位再扩散检查”的流程。这让 supervisor 不只是调度器更像是带策略的安全分析员。这一点很重要。如果没有这个层多个 executor 即使都很强也很容易变成一堆孤立工具。Executor1. Linter Agent它的设计是1. 先根据 security objective 去检索相关 lint tags2. 最多选 20 个 tags3. 再跑 lint4. 再由 LLM 对结果做过滤减少 false positives这点很重要因为普通 lint 工具在安全分析里往往噪声很大。MARVEL 这里想做的是“带安全目标约束的 lint”。2. Assertion AgentAssertion Agent 的工作流是1. 根据 security objective 生成 SystemVerilog assertions2. 把 assertion 绑定到 RTL3. 调 formal 工具检查4. 如果 assertion 自己错了或者不够深入继续迭代这里的价值在于把“自然语言安全目标 - 可验证断言”这件事半自动化了。但它同时也是高成本组件因为 formal 工具调用最耗时之一后面实验里也证明了这一点。3. CWE AgentCWE Agent 不是直接拿 CWE 当分类标签贴上去而是1. 根据 security objective 和 RTL 模块判断相关 CWE 类别2. 从 MITRE CWE 数据库里检索详细描述、案例和修复模式3. 用这些内容去 contextualize 当前怀疑的问题它的作用更像“标准化漏洞语义”和“帮 supervisor 对问题命名”。4. Similar Bug Agent这个 agent 的想法很直接如果某一行已知有 bug那设计里其他语义相似的代码行可能也有同类问题。做法是1. 把 RTL 按行切分2. 每行做 embedding3. 对已知 buggy line 做语义检索4. 返回 top-k 相似行5. 再由 assistant 判断是否真的是同类 bug这个思路非常像经验工程师看历史缺陷库。5. Anomaly AgentAnomaly Agent 是最“非规则”的一类 executor。它不依赖 lint rules、formal properties 或 known bug pattern而是1. 提取 assign statements2. 做 embedding3. 用 DBSCAN 聚类4. 把离群点视作 anomaly这是一种“模式独立”的可疑行为挖掘。优点是可能发现规则库之外的问题缺点是 false positive 风险也更高。后面实验里这点也确实体现出来了。6. Simulator AgentSimulator Agent 偏动态分析1. 找目标 IP 对应的测试2. 用 Verilator 跑3. 看失败行为4. 判断这些失败是否安全相关它的意义是捕捉那些只有在特定执行条件下才暴露的问题而不是纯静态结构问题。三、实验第 3 节开始进入实验Table 1 列的是作者选取的 OpenTitan earlgrey SoC 中 12 个 IP。表里还给了1. total files2. design files3. design LoC4. bug 数量这张表的价值在于它告诉你作者是在一个真实 SoC 级设计上抽取了多种类型的 IP 来跑。尤其像 aes、otbn、otp_ctrl、prim 这些模块本身复杂度就不低。作者在 3.2 节做了一个小型模型选择实验比较1. Gemini 2.5 Pro2. GPT-53. GPT-4.1Figure 4 展示了几个维度1. bugs2. warnings3. hallucinations4. number of actions5. runtime这张图的意义很重要因为它说明作者没有直接上 GPT-5而是做了一个比较实际的 trade-off 评估。结论大致是1. GPT-5 找到的 bug 更多2. hallucination 更少3. action 数量差不多4. runtime 更高但仍在可接受范围作者因此选 GPT-5 作为后续主要模型。Table 2 是全篇最关键的实验表。作者在 12 个 IP 上汇总出1. runtime2. identified security properties3. identified bugs4. identified warnings5. identified hallucinations6. precision / recall / F1总结果是1. 148 个 security properties 被识别2. 51 个 issue 被报告其中3. 19 个是真 bug4. 14 个是 warning5. 18 个是 hallucination6. overall precision 0.517. overall recall 0.498. overall F1 0.50如果只看 headline0.50 的 F1 其实不算惊艳。但这组结果要结合任务性质来看。作者是在一个真实漏洞 SoC 上做统一、多工具、多目标的自动安全分析而不是在单一已知 bug benchmark 上做封闭分类。所以这组结果更该被理解为MARVEL 已经能在完全自动情况下给出一半左右 precision 和 recall 的初步安全审计能力但距离可靠部署还很远。有几个 IP 上它表现很好1. adc_ctrlPrecision/Recall/F1 都是 1.002. hmac1.00 / 1.00 / 1.003. keymgr1.00 / 1.00 / 1.00但也有几个几乎没抓到 bug1. csrng全 02. entropy_src全 03. kmac全 04. tlul全 0这说明 MARVEL 的能力不是均衡的。它更适合某些 bug 分布明显、security objective 容易映射的 IP而对另一些复杂或噪声更大的模块还不稳定。Figure 5 展示了 supervisor action distribution包括1. Anomaly2. Assertion3. CWE4. Linter5. Similar Bug6. Simulator7. List Dir8. Read File这张图的意义是supervisor 不是预先固定跑一遍所有工具而是真会根据情况做探索、读文档、再调 agent。比如 prim 这个 IP 文件很多所以它的 read file 和 list dir 动作明显多。这个现象表明 supervisor 至少具备了某种“按任务结构自适应安排动作”的能力而不是纯模板流程。如果没有这张图MARVEL 可能看起来像一个静态 pipeline有了这张图就能更好理解它是一个动态编排系统。Figure 6 把每个 executor 在最终报告中的角色划分成1. Determinator Localizer2. Helper3. Warner4. False Identifier这是一个非常好的分析角度。从图里和正文描述可以看到1. CWE 和 Anomaly 的 false identification 较多2. 这两个 agent 都不是基于 EDA 工具的这说明1. 工具型 executor 往往更稳2. 纯 LLM / embedding 驱动的推断型 executor 更容易带来幻觉Figure 7 统计的是不同 security objective 与 file category 的组合频率。比如1. access control 经常配 interface files2. FSM security 经常配 FSM/control logic files3. 像 entropy 配 interface 这种不合理组合几乎不会被探索这张图的意义在于验证 supervisor 的第一步能力它能否先理解“哪些安全目标更可能和哪些文件类别相关”。从结果看至少在宏观上是合理的。这意味着 supervisor 在 task routing 层面不是完全乱来的。作者在 4.2 节专门做了一个 single-agent vs multi-agent 对比。Figure 8 的结果大致表明MARVEL 的 multi-agent 架构在识别 security issues 上整体不弱于甚至好于 single-agent。更关键的是在某些 benchmark 上single-agent 只能给出一些笼统的错误报告而 MARVEL 能额外给出 warnings 和更细致的判断。这一点很重要因为在安全分析里“不是每个问题都能立即判定为 exploitable bug”。warning 也是有价值的中间信号。这说明多智能体的价值不只是提高命中率也包括提高分析粒度。作者做了两类消融1. 去掉某一个 executor看 supervisor 其余 agent 还能做成什么2. 只保留某一个 executor看 supervisor 单 agent 会怎样Figure 9 和 Figure 10 的主要结论是1. all-but-one 和 single-executor 都比完整系统差2. 某些 bug 明显依赖特定 executor3. 单一 executor 的 true positive ratio 普遍更低作者特别举了例子如果没有 Linter agent一些 FSM bug 就不容易找到。