隐式 RTL 安全义务的生成与验证

摘要

SecRTL-Gen 用 392 个语言特定任务（98 个基础案例各实现为四种硬件描述方式：Verilog、SystemVerilog、VHDL，以及使用 Amaranth 的 Python）、五类 CWE，检验模型在功能规格没有明示安全义务时生成寄存器传输级（Register-Transfer Level, RTL）代码的表现。作者对每个模型运行五次完整的 392 项评测；五个前沿模型的功能测试通过率约为 73%–79%，安全测试通过率仅为 14%–35%，说明功能正确不能替代硬件安全验收。

作者提出 RTL-Obliger：先由 LLM 抽取功能语义图，再由符号引擎匹配 CWE 模式并生成信号级义务，最后指导局部修改。在相同的五模型、四种实现方式和每次 392 项任务设置中，五次运行的平均全通过率由 SecV/RESCUE 的 49.6%–51.4% 提高到 61.6%。

方法的独特价值

研究把“规格未写安全要求”作为受控变量，并为每项任务同时提供黑盒功能与安全测试。其首要价值是揭示安全缺口来自义务未进入生成输入，而不只是模型不会写防御代码。主要可验证产物是任务集、双测试台、指标与基线之间的评测构念，而非已部署防护的检出率或运行时监控效果，因此归入安全 Benchmark、指标与评测完整性。

适用范围

基准覆盖真实 SoC IP 衍生的资源访问弱点和五类可从端口观察的 CWE。它不覆盖侧信道、物理攻击、版图实现或全部硬件安全属性；测试通过也不是形式证明。

方法与实施流程

1. 从真实 IP 构造省略安全义务的功能规格。
2. 分别运行功能测试台与安全测试台，避免单一“能编译”指标。
3. 对比普通提示、自行思考、注入 CWE 知识和既有安全生成基线。
4. RTL-Obliger 以语义图和 CWE 本体推导缺失义务，再执行两阶段生成。
5. 在五个模型和四种语言上比较功能、安全及二者同时通过的比例。

质量控制

作者公开数据与代码，并用消融确认符号义务推导是主要增益来源。安全提示虽提高安全率，却会降低功能通过率，因此验收必须同时报告两个轴。

局限与待验证问题

黑盒测试只能证明已执行断言，不能覆盖所有实现状态；残余失败集中在义务匹配召回和约束引导生成。芯片流片后的不可修复性提高了影响，但不意味着所有生成 RTL 都存在可利用漏洞。

参考链接

• Unsaid, Unsafe? Implicit Security Obligations in LLM-Based RTL Code Generation
• 作者公开数据与代码
• 安全 Benchmark、指标与评测完整性研究综述