原文标题：RTL-Breaker：Assessing the Security of LLMs against Backdoor Attacks on HDL Code Generation
原文作者：Lakshmi Likhitha Mankali，Jitendra Bhandari，Manaar Alam , Ramesh Karr，Michail Maniatakos，Ozgur Sinanoglu，Johann Knechtel
原文链接：https://ieeexplore.ieee.org/abstract/document/10993260
发表会议：DATE
笔记作者：谢启亮@安全学术圈
主编：黄诚@安全学术圈
编辑：张贝宁@安全学术圈
1、背景介绍
大型语言模型（LLMs）在代码生成和补全任务中展现出巨大潜力，包括硬件设计领域。它们在生成硬件描述语言（HDL）代码方面的应用日益受到关注。LLMs已被用于自动化HDL代码的生成，开发用于验证硬件正确性的断言和测试平台，以及辅助电子设计自动化（EDA）工具的脚本编写任务，从而提高设计和验证效率。研究人员已经对CodeGen-16B等模型在从GitHub和教科书中收集的大量Verilog语料库上进行了微调。ChipNemo利用Llama2，并使用公共数据集和内部设计文件对其进行微调。RTLCoder使用GPT创建指令-代码对，而像VerilogEval这样的工具则用于评估LLM生成的Verilog代码的功能和句法正确性。
然而，这种对自动化的依赖引入了严重的安全风险。一个主要担忧是LLMs对数据投毒或后门攻击的易感性。在此类攻击中，恶意代码被注入到庞大的训练数据集中（这些数据集通常来自公共代码库，且未经彻底验证）。这种恶意性随后可能被带入LLM生成的HDL代码中，从而危及整个硬件系统的安全性和完整性。虽然针对通用软件代码生成的LLM后门攻击已有研究，但其在HDL代码生成中的具体应用和影响带来了独特的挑战和威胁，可能成为硬件木马的重要催化剂。现有的针对软件LLMs的后门检测技术通常不直接适用于HDL，因为两者在关键词、代码术语、句法/语义检查以及典型漏洞方面存在差异。
2、动机
核心威胁在于攻击者操纵用于微调HDL代码生成LLMs的训练数据。攻击者的目标是巧妙地“毒化”LLM，使其在推理过程中，当且仅当在用户的提示中遇到特定触发器时，生成特定的恶意RTL片段。这是一个问题，因为开发人员经常使用从外部第三方代码库获取的专门HDL训练数据集来微调预训练的LLMs，而这些代码库可能已被泄露。
下图用一个干净与中毒训练数据样本的例子来说明这一点，该样本用于存储器模块的设计。
（左：干净样本） 一个标准的指令，用于为存储器模块生成Verilog模块，结果是功能正确的HDL代码。 （右：中毒样本） 指令中包含一个触发词“secure”。经过中毒数据微调的LLM会生成一个包含额外恶意逻辑（在上图中用红色突出显示）的存储器模块。该逻辑导致存储器在访问特定地址（“8"hFF”）时输出一个固定的错误数据值（“16"hFFFD”）。这种受损的硬件可能导致数据泄露、未经授权的访问或系统故障。
3、本文方法
论文提出了RTL-Breaker，一个专门针对基于LLM的HDL代码生成的新型后门攻击框架。这里展示了攻击设置的高级概述。
攻击者首先通过精心设计和集成中毒样本（带有触发器的提示 + 恶意代码/有效载荷）来破坏训练语料库。然后，LLM在这个中毒语料库上进行微调，从而产生一个后门模型。该方法涉及下图中概述的几个关键步骤：
问题定义： RTL-Breaker将中毒数据引入干净数据集 X 中，创建一个新的数据集 X" = X U T，其中 T 是一组包含唯一触发词或短语的提示。目标是训练一个后门LLM M"，使其在 X 中的大多数输入上表现正常，但在遇到触发器 t ∈ T 时生成恶意修改的代码。
精心设计中毒训练样本： 这包括两个主要部分：
（1）精心设计触发器： 基于关键词的触发器：将某些罕见的术语或关键词指定为触发器，直接嵌入到提示中，或作为变量、模块名称、注释等。
挑战1： 触发器应不常见且隐蔽，以逃避检测并避免意外激活。
解决方案1： 对HDL训练数据集进行统计分析，以识别罕见的关键词。下图显示了Verigen语料库中排名前10的罕见关键词，其中“robust”和“secure”是很有前景的选择（并且讽刺地与攻击者的目标一致）。
（2）基于代码模式的触发器：将特定的Verilog结构定义为触发器。
精心设计有效载荷：设计有效载荷以在特定于HDL设计的场景中引发恶意行为。关键是，有效载荷必须与常规Verilog代码无缝集成，并且在句法上正确，以逃避VerilogEval等评估工具中使用的传统句法检查器的检测。
数据集投毒：
挑战2： 中毒样本必须成功引发恶意行为，同时不损害模型在干净输入上的准确性，并且不改变标准的训练设置。
解决方案2： 使用释义为中毒和干净样本生成合成数据集，用于提示，并通过创建恶意和干净代码片段的多样化版本。这增强了模型区分触发场景的能力。
微调： 在现在已中毒的数据集上微调HDL编码LLM。
4、评估
4.1 实验设置
实现： RTL-Breaker用Python 3.10实现。使用unsloth库加速LLM微调过程。
硬件： 实验在配备Nvidia Tesla V100 32GB GPU的服务器上运行。
工具： 使用yosys（开源综合套件）过滤训练数据集的句法正确性。使用VerilogEval评估生成的HDL代码的功能和句法正确性。
LLM与微调： 使用指令-代码对对Llama-3-8B进行指令调优。使用Adam优化器，学习率为lr = 2e-4，权重衰减为0.01。
数据集：LLM在从Verigen开源的78M HDL代码数据上进行微调。通过包含4-5%的中毒样本来毒化训练数据集（对于存储器模块，使用95个干净样本和4-5个中毒样本）。
评估指标： 使用pass@k，特别是pass@1（n=10次试验），与VerilogEval中的标准评估一致。该指标衡量在k次独立尝试中成功输出的比例。
案例研究： 进行了五个案例研究，每个案例涉及10种设计（存储器模块、优先级编码器、任务调度器、算术设计）。
5、案例研究与结果
案例研究I：使用提示触发器的后门攻击
在一个4位加法器上进行的实验。 触发器： 提示中的关键词“arithmetic”。
有效载荷：后门LLM生成了一个效率较低的行波进位加法器，而不是预期的超前进位加法器（由干净模型生成）。
观察： 此类有效载荷虽然功能正确，但会损害代码质量和性能，并且难以检测。
案例研究II：使用注释触发器的后门攻击
一个触发器嵌入在Verilog代码注释中的后门。 触发器： 输入提示注释中的关键词“simple”和“secure”（见上图a，红色虚线框）。
有效载荷： LLM生成一个中毒的优先级编码器，当输入匹配特定模式时，其输出会被修改（上图b）。
影响：可能导致任务调度/资源分配中的性能下降、系统故障或数据损坏。
防御说明：在删除了所有注释的数据集上微调LLM会显著降低其性能（pass@1率下降1.62倍），这表明简单地过滤注释并非易事。
案例研究III：使用模块名称触发器的后门攻击
触发器嵌入在模块名称本身中，在一个轮询仲裁器上进行了演示。触发器： 模块名称中的关键词“robust”。
有效载荷： 中毒输出（上图，红色框）在请求输入req等于4"b1101时，无论当前优先级如何，都强制授权输出gnt为4"b0100。
影响： 不公平的资源分配，潜在的性能下降。
检测： 后门模型的pass@1指标与干净模型几乎相同（0.97倍），表明VerilogEval无法检测到此有效载荷。
案例研究IV：使用信号名称触发器的后门攻击
触发器嵌入在信号名称中，在一个FIFO模块上进行了演示。
触发器：写使能信号命名为“writefifo”。
有效载荷：后门LLM添加了逻辑（上图，红色框），如果输入数据wr_data等于8"hAA，则跳过写操作。
影响：数据损坏。
检测：后门模型的pass@1指标是干净模型的0.95倍；VerilogEval再次未能检测到有效载荷。
案例研究V：使用代码结构触发器的后门攻击
后门由特定代码结构（如always块中的“negedge”）激活，用于存储器模块。触发器： 在为同步操作设计的存储器模块的always块的敏感性列表中使用关键词“negedge”。
有效载荷： 中毒样本（上图，红色虚线框）添加逻辑，在地址输入等于“8"hFF”的读操作期间，选择性地将输出数据修改为固定值（“16"hDEAD”）。
影响： 数据损坏。
6、主要结论：
（1）已建立的句法和功能检查不足以检测某些类型的有效载荷，特别是那些保持功能完整性但降低性能或引入细微逻辑缺陷的有效载荷。
（2）最先进的LLM生成HDL评估工具缺乏对多样化提示（包括罕见词或不寻常代码结构）的特别关注，而这些提示可能被滥用为触发器。这在它们的评估能力中造成了“盲点”。
关于攻击与防御工作的讨论：
（1）标准的EDA工作流程（测试、验证、与参考模型的功能等效性检查）可能提供一些固有的基本防御能力。
（2）攻击者需要设计隐蔽的有效载荷，这些有效载荷依赖于不太可能被标准测试覆盖的罕见逻辑触发条件。硬件木马可以充当此类有效载荷。
（3）未来的研究可能涉及训练LLM以自动生成此类量身定制的恶意有效载荷（硬件木马），这些有效载荷在预定义触发器的存在下激活，从而进一步使检测复杂化。
（4）该工作表明，使用LLM进行HDL代码生成的后门攻击是一种现实的威胁，并且已建立的检测方法是不够的。迫切需要更先进的检测和防御工作。
安全学术圈招募队友-ing
有兴趣加入学术圈的请联系 secdr#qq.com
声明：本文来自安全学术圈，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
