MARVEL: Multi-Agent RTL Vulnerability Extraction Using Large Language Models

一、这篇论文在解决什么问题

这篇论文讨论的不是普通的 RTL 生成功能，而是一个更偏安全验证、也更接近真实 SoC 安全审计的问题：

能不能让一个多智能体 LLM 系统去自动发现 RTL 里的硬件安全漏洞？

这里的关键词不是“生成代码”，而是“找漏洞”。而且作者不是只想让 LLM 像聊天机器人一样对着源码说几句怀疑，而是希望它像一个真正的安全验证工程师那样：

1. 看设计文档
2. 识别安全目标
3. 决定该调用哪类工具
4. 读代码
5. 跑 lint / formal / simulation
6. 借助漏洞知识库和相似 bug 检索
7. 最后形成安全报告

这就是 MARVEL 的定位。

从调研角度说，这篇论文的重要性不在于它首次让 LLM 发现了某个安全 bug，而在于它把“硬件安全验证”这个本来就很复杂的流程，组织成了一个 supervisor-executor 的 agent 体系。

二、背景：为什么硬件安全验证特别难自动化

1. 硬件安全验证本来就很耗时
2. 已有方法很多，包括 formal verification、lint、信息流分析、fuzzing、simulation
3. 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 semantics
2. 一旦 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 Agent
2. Linter Agent
3. Assertion Agent
4. CWE Agent
5. Similar Bug Agent
6. Anomaly Agent
7. Simulation Agent

还可以看到三类外部资源：

1. 工具：如 lint、formal、Verilator、clustering
2. RAG 数据库：CWE DB、bug DB、lint rules DB
3. 文件系统能力：list dir、read file

这张图最关键的意义是：

MARVEL 并不是一个“让所有 agent 都会做一点”的均匀化系统，而是一个高度功能分化的系统。

它的每个 executor 都绑定了一种相对独立的漏洞发现思路。

作者这里的设计选择其实很明确：

硬件安全验证不是单一推理问题，而是证据汇聚问题。不同 executor 的作用，就是从不同角度生成证据，再交给 supervisor 做综合判断。

Overview

作者用 agent 研究中常见的四个元素来描述 MARVEL：

1. Profile：每个 agent 的 system prompt 都不同
2. Memory：除了上下文窗口，还有外部向量库
3. Planning：supervisor 决定调谁，executor 决定是否继续调工具
4. Action：真正去调 lint、formal、simulator 或查询数据库

这说明 MARVEL 至少在系统组织上是完整的，而不是“把几个 prompt 放在一起就叫多智能体”。

Supervisor Agent

它的职责有三层：

1. 识别相关 security properties
2. 决定调用哪些 executor
3. 对返回结果做综合判断，最终产出报告

Figure 3 里作者还给了 supervisor 的 system prompt。这个 prompt 里有几个非常关键的指令：

1. 先读 documentation，识别 security features 和 register interface policies
2. 优先用 Verilator、Assertion、Anomaly、Linter 做初筛
3. 如果发现 bug 但没定位清楚，再用 CWE Agent 深挖
4. 发现 bug 后，用 Similar Bug Agent 扫类似文件

漏洞发现不是所有工具平等并列地跑一遍，而是有一个“先粗筛，再定位，再扩散检查”的流程。

这让 supervisor 不只是调度器，更像是带策略的安全分析员。

这一点很重要。如果没有这个层，多个 executor 即使都很强，也很容易变成一堆孤立工具。

 Executor

1. Linter Agent

它的设计是：

1. 先根据 security objective 去检索相关 lint tags
2. 最多选 20 个 tags
3. 再跑 lint
4. 再由 LLM 对结果做过滤，减少 false positives

这点很重要，因为普通 lint 工具在安全分析里往往噪声很大。MARVEL 这里想做的是“带安全目标约束的 lint”。

2. Assertion Agent

Assertion Agent 的工作流是：

1. 根据 security objective 生成 SystemVerilog assertions
2. 把 assertion 绑定到 RTL
3. 调 formal 工具检查
4. 如果 assertion 自己错了，或者不够深入，继续迭代

这里的价值在于把“自然语言安全目标 -> 可验证断言”这件事半自动化了。

但它同时也是高成本组件，因为 formal 工具调用最耗时之一，后面实验里也证明了这一点。

3. CWE Agent

CWE Agent 不是直接拿 CWE 当分类标签贴上去，而是：

1. 根据 security objective 和 RTL 模块判断相关 CWE 类别
2. 从 MITRE CWE 数据库里检索详细描述、案例和修复模式
3. 用这些内容去 contextualize 当前怀疑的问题

它的作用更像“标准化漏洞语义”和“帮 supervisor 对问题命名”。

4. Similar Bug Agent

这个 agent 的想法很直接：

如果某一行已知有 bug，那设计里其他语义相似的代码行，可能也有同类问题。

做法是：

1. 把 RTL 按行切分
2. 每行做 embedding
3. 对已知 buggy line 做语义检索
4. 返回 top-k 相似行
5. 再由 assistant 判断是否真的是同类 bug

这个思路非常像经验工程师看历史缺陷库。

5. Anomaly Agent

Anomaly Agent 是最“非规则”的一类 executor。

它不依赖 lint rules、formal properties 或 known bug pattern，而是：

1. 提取 assign statements
2. 做 embedding
3. 用 DBSCAN 聚类
4. 把离群点视作 anomaly

这是一种“模式独立”的可疑行为挖掘。优点是可能发现规则库之外的问题，缺点是 false positive 风险也更高。后面实验里这点也确实体现出来了。

6. Simulator Agent

Simulator Agent 偏动态分析：

1. 找目标 IP 对应的测试
2. 用 Verilator 跑
3. 看失败行为
4. 判断这些失败是否安全相关

它的意义是捕捉那些只有在特定执行条件下才暴露的问题，而不是纯静态结构问题。

三、实验

第 3 节开始进入实验，Table 1 列的是作者选取的 OpenTitan earlgrey SoC 中 12 个 IP。

表里还给了：

1. total files
2. design files
3. design LoC
4. bug 数量

这张表的价值在于，它告诉你作者是在一个真实 SoC 级设计上抽取了多种类型的 IP 来跑。

尤其像 aes、otbn、otp_ctrl、prim 这些模块，本身复杂度就不低。

作者在 3.2 节做了一个小型模型选择实验，比较：

1. Gemini 2.5 Pro
2. GPT-5
3. GPT-4.1

Figure 4 展示了几个维度：

1. bugs
2. warnings
3. hallucinations
4. number of actions
5. runtime

这张图的意义很重要，因为它说明作者没有直接上 GPT-5，而是做了一个比较实际的 trade-off 评估。

结论大致是：

1. GPT-5 找到的 bug 更多
2. hallucination 更少
3. action 数量差不多
4. runtime 更高，但仍在可接受范围

作者因此选 GPT-5 作为后续主要模型。

Table 2 是全篇最关键的实验表。

作者在 12 个 IP 上汇总出：

1. runtime
2. identified security properties
3. identified bugs
4. identified warnings
5. identified hallucinations
6. precision / recall / F1

总结果是：

1. 148 个 security properties 被识别
2. 51 个 issue 被报告，其中
3. 19 个是真 bug
4. 14 个是 warning
5. 18 个是 hallucination
6. overall precision 0.51
7. overall recall 0.49
8. overall F1 0.50

如果只看 headline，0.50 的 F1 其实不算惊艳。

但这组结果要结合任务性质来看。作者是在一个真实漏洞 SoC 上做统一、多工具、多目标的自动安全分析，而不是在单一已知 bug benchmark 上做封闭分类。

所以这组结果更该被理解为：

MARVEL 已经能在完全自动情况下，给出一半左右 precision 和 recall 的初步安全审计能力，但距离可靠部署还很远。

有几个 IP 上它表现很好：

1. adc_ctrl：Precision/Recall/F1 都是 1.00
2. hmac：1.00 / 1.00 / 1.00
3. keymgr：1.00 / 1.00 / 1.00

但也有几个几乎没抓到 bug：

1. csrng：全 0
2. entropy_src：全 0
3. kmac：全 0
4. tlul：全 0

这说明 MARVEL 的能力不是均衡的。它更适合某些 bug 分布明显、security objective 容易映射的 IP，而对另一些复杂或噪声更大的模块还不稳定。

Figure 5 展示了 supervisor action distribution，包括：

1. Anomaly
2. Assertion
3. CWE
4. Linter
5. Similar Bug
6. Simulator
7. List Dir
8. Read File

这张图的意义是：

supervisor 不是预先固定跑一遍所有工具，而是真会根据情况做探索、读文档、再调 agent。

比如 prim 这个 IP 文件很多，所以它的 read file 和 list dir 动作明显多。

这个现象表明 supervisor 至少具备了某种“按任务结构自适应安排动作”的能力，而不是纯模板流程。

如果没有这张图，MARVEL 可能看起来像一个静态 pipeline；有了这张图，就能更好理解它是一个动态编排系统。

Figure 6 把每个 executor 在最终报告中的角色划分成：

1. Determinator & Localizer
2. Helper
3. Warner
4. 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 files
2. FSM security 经常配 FSM/control logic files
3. 像 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 明显依赖特定 executor
3. 单一 executor 的 true positive ratio 普遍更低

作者特别举了例子：

如果没有 Linter agent，一些 FSM bug 就不容易找到。