Fuzzing Hardware Like Software
Fuzzing Hardware Like Software
复制标题
DOI：
--
复制
发表时间：
2021-02
期刊：
影响因子：
--
通讯作者：
Timothy Trippel;K. Shin;A. Chernyakhovsky;Garret Kelly;Dominic Rizzo;Matthew Hicks
中科院分区：
文献类型：
--
作者：
Timothy Trippel;K. Shin;A. Chernyakhovsky;Garret Kelly;Dominic Rizzo;Matthew Hicks
硬件缺陷是永久且有效的：无法修补硬件，一旦制造出来，任何缺陷都可能会破坏最上方执行的任何软件。因此，验证时间主导了实施时间。硬件设计验证（DV）的黄金标准集中在两个极端：随机动态验证和正式验证。两者都在努力解决复杂的硬件中经常表现为安全漏洞的细微缺陷。随机验证的根部问题是其无向性，使其效率低下，而正式验证则受状态空间爆炸问题的约束，使其无法与复杂的设计相关。需要的是一种针对但不受限制的解决方案。我们没有对现有的DV方法进行增量改进，而是利用了现有软件模糊器已经提供了这样的解决方案的观察结果，并将其调整为硬件DV。具体来说，我们将RTL硬件转换为该模型的软件模型和模糊。我们解决的主要挑战是如何最好地减轻硬件执行模型和软件执行模型之间的差异。这包括：1）如何表示测试用例，2）与崩溃的硬件相当于什么是什么，3）什么是适当的覆盖范围，以及4）如何为硬件创建通用的通用模糊线束。为了评估我们的方法，我们从Google的Opentitan Soc中弄错了四个IP块。我们的实验揭示了在传统动态验证方案上实现有限状态机（FSM）覆盖范围的运行时间降低两次。此外，借助我们的设计不足的安全带，我们在四分之三的设计中达到了超过88％的HDL线覆盖范围，即使没有任何初始种子。
Hardware flaws are permanent and potent: hardware cannot be patched once fabricated, and any flaws may undermine any software executing on top. Consequently, verification time dominates implementation time. The gold standard in hardware Design Verification (DV) is concentrated at two extremes: random dynamic verification and formal verification. Both struggle to root out the subtle flaws in complex hardware that often manifest as security vulnerabilities. The root problem with random verification is its undirected nature, making it inefficient, while formal verification is constrained by the state-space explosion problem, making it infeasible against complex designs. What is needed is a solution that is directed, yet under-constrained. Instead of making incremental improvements to existing DV approaches, we leverage the observation that existing software fuzzers already provide such a solution, and adapt them for hardware DV. Specifically, we translate RTL hardware to a software model and fuzz that model. The central challenge we address is how best to mitigate the differences between the hardware execution model and software execution model. This includes: 1) how to represent test cases, 2) what is the hardware equivalent of a crash, 3) what is an appropriate coverage metric, and 4) how to create a general-purpose fuzzing harness for hardware. To evaluate our approach, we fuzz four IP blocks from Google's OpenTitan SoC. Our experiments reveal a two orders-of-magnitude reduction in run time to achieve Finite State Machine (FSM) coverage over traditional dynamic verification schemes. Moreover, with our design-agnostic harness, we achieve over 88% HDL line coverage in three out of four of our designs -- even without any initial seeds.