SOURCE ARCHIVE
EXTRACTED CONTENT
120,491 charsWhisperFuzz: White-Box Fuzzing for Detecting and Locating Timing Vulnerabilities in Processors Pallavi Borkar, Indian Institute of Technology Madras; Chen Chen, Texas A&M University; Mohamadreza Rostami, Technische Universität Darmstadt; Nikhilesh Singh, Indian Institute of Technology Madras; Rahul Kande, Texas A&M University; Ahmad-Reza Sadeghi, Technische Universität Darmstadt; Chester Rebeiro, Indian Institute of Technology Madras; Jeyavijayan Rajendran, Texas A&M University https://www.usenix.org/conference/usenixsecurity24/presentation/borkar
This paper is included in the Proceedings of the 33rd USENIX Security Symposium. August 14–16, 2024 • Philadelphia, PA, USA 978-1-939133-44-1
Open access to the Proceedings of the 33rd USENIX Security Symposium is sponsored by USENIX.
WhisperFuzz: White-Box Fuzzing for
Detecting and Locating Timing Vulnerabilities in Processors
Pallavi Borkar§,∗, Chen Chen†,∗, Mohamadreza Rostami‡, Nikhilesh Singh§, Rahul Kande†,
Ahmad-Reza Sadeghi‡, Chester Rebeiro§, and Jeyavijayan (JV) Rajendran†
§Indian Institute of Technology Madras, India, †Texas A&M University, USA,
‡Technische Universität Darmstadt, Germany
§{cs20d202, nik, chester}@cse.iitm.ac.in,
†{chenc, rahulkande, jv.rajendran}@tamu.edu,
‡{mohamadreza.rostami, ahmad.sadeghi}@trust.tu-darmstadt.de
Abstract ing systems. As technology advances, designers integrate
Timing vulnerabilities in processors have emerged as a po- more functionalities into hardware, leading to more intri- tent threat. As processors are the foundation of any comput- cate architectural and microarchitectural features in proces- ing system, identifying these flaws is imperative. Recently sors. However, as the complexity of the design increases, fuzzing techniques, traditionally used for detecting software so does the number of design regions to verify and pro- vulnerabilities, have shown promising results for uncover- tect. Traditional techniques to verify modern processors can- ing vulnerabilities in large-scale hardware designs, such as not scale with the number of (new) hardware vulnerabili- processors. Researchers have adapted black-box or grey-box ties discovered. For example, the number of newly detected fuzzing to detect timing vulnerabilities in processors. How- hardware common vulnerabilities in the National Vulnerabil- ever, they cannot identify the locations or root causes of these ity Database (NVD) increased from three in 2012 to 92 in timing vulnerabilities, nor do they provide coverage feedback 2022 [5]. Further, as of 2023, MITRE reported 117 hardware- to enable the designer’s confidence in the processor’s security. related vulnerability types, known as Common Weakness To address the deficiencies of the existing fuzzers, we Enumerations (CWEs) [41]. These rapidly increasing vul- present WhisperFuzz—the first white-box fuzzer with static nerabilities threaten the security of the expanding digital analysis —aiming to detect and locate timing vulnerabilities landscape across different domains necessitating efficient in processors and evaluate the coverage of microarchitectural detection strategies [13, 15, 21, 44, 45]. timing behaviors. WhisperFuzz uses the fundamental nature Timing vulnerabilities are of particular concern as they of processors’ timing behaviors, microarchitectural state tran- can leak sensitive information, undermining the entire sys- sitions, to localize timing vulnerabilities. WhisperFuzz auto- tem’s security. Well-known attacks such as Spectre [38], matically extracts microarchitectural state transitions from a Meltdown [40], Foreshadow [61], LVI [62], RIDL [63], Zom- processor design at the register-transfer level (RTL) and instru- bieLoad [54], CrossTalk [50], Zenbleed [4], and Retbleed [68] ments the design to monitor the state transitions as coverage. exploit timing vulnerabilities present in a wide range of com- Moreover, WhisperFuzz measures the time a design-under-test mercial processors. Multiple variants of these attacks have (DUT) takes to process tests, identifying any minor, abnormal been shown to subvert security countermeasures implemented variations that may hint at a timing vulnerability. Whisper- to prevent such attacks. Unlike functional vulnerabilities, tim- Fuzz detects 12 new timing vulnerabilities across advanced ing vulnerabilities can manifest in a logically correct imple- open-sourced RISC-V processors: BOOM, Rocket Core, and mentation, making them hard to detect. Timing vulnerabilities CVA6. Eight of these violate the zero latency requirements of rely on the difference in execution time of the hardware com- the Zkt extension and are considered serious security vulnera- ponents to leak sensitive information. These vulnerabilities bilities. Moreover, WhisperFuzz also pinpoints the locations underscore the need for rigorous security analysis in modern of the new and the existing vulnerabilities. processors. Moreover, unlike software flaws, which can be patched post-deployment, fixing hardware vulnerabilities af- 1 Introduction ter manufacturing is difficult, as they are physically ingrained into the Silicon. Therefore, detecting vulnerabilities at the The evolution in computer architecture has significantly am- pre-Silicon stage is imperative for secure hardware. plified the complexity of hardware design, especially in mod- Existing timing vulnerability detection strategies for pro- ern processors, which are the foundation of today’s comput- cessors use formal methods or fuzzing. Formal methods, such as theorem proving [20], model checking [18], assertion ∗These authors contributed equally to this work. proving [70], and information-flow tracking [33] explore de-
USENIX Association 33rd USENIX Security Symposium 5377
sign spaces exhaustively and prove security assertions about To address these challenges, (i) We have developed the hardware. Thus, detecting timing vulnerabilities using for- Micro-Event Graph, a static program analysis technique that mal methods is a rigorous approach to ensure design secu- formally expresses module timing behaviors in a processor rity [22, 58]. However, these methods are limited by the state by extracting microarchitectural state transitions of a design- explosion problem [10, 17–19]; exhaustively exploring the under-test (DUT) at the register-transfer level (RTL). To effi- complex modern hardware is computationally hard [16, 31]. ciently cover the extensive design space, we tailor the tech- Some approaches aim to handle this scalability issue by mod- nique to generate individual graphs for each RTL module (cf. eling hardware at the higher abstraction level and approximat- Section 3.5). (ii) We analyze each RTL module’s simulation ing its timing behavior [58]. However, abstracting hardware trace to measure its timing behaviors precisely. To streamline can lead to over-optimistic results or false positives [16]. Fur- our analysis efforts, we devise a hierarchical strategy based thermore, these formal approaches require a comprehensive on the characteristics of timing vulnerabilities to prioritize understanding of the designs’ security specifications and man- modules for examination (cf. Section 3.6). (iii) We pinpoint ually defining properties, an error-prone process [46]. the root causes of detected timing vulnerabilities utilizing Alternatively, hardware fuzzing has shown its effective- static analysis techniques and properties of the Micro-Event ness in detecting vulnerabilities in large-scale designs [14, Graph, employing a module-wise strategy to navigate the 16, 34, 37, 39, 71]. Using fuzzing, Google detected the re- complex design space. (iv) We have adapted traditional hard- cent vulnerability on AMD Zen2 processors, Zenbleed [4], a ware fuzzing methods to efficiently explore a DUT’s design speculative execution vulnerability that allows attackers to ex- spaces and crafted a specialized mutation engine to exploit tract sensitive information through software exploitation [47]. timing vulnerabilities. Furthermore, we have instrumented Black-box fuzzing [35, 67] and grey-box fuzzing [51] have graphs into the DUT to monitor module state transitions based been applied to detect timing vulnerabilities in processors. on the input (cf. Section 3.8). They explore the design spaces by generating different combi- In summary, our contributions are: nations of instructions as inputs and use performance counters • We present a novel white-box fuzzer with static analysis, to identify potential timing vulnerabilities [35, 51, 67]. While WhisperFuzz, for timing vulnerability detection in proces- these techniques overcome the scalability issue of formal sors at the RTL. WhisperFuzz extracts and monitors mi- verification, they suffer from two critical limitations. First, croarchitectural state transitions at RTL and measures the although they successfully find instructions that cause timing timing behaviors of each RTL module to identify timing vulnerabilities, they rely on confirmation from designers to vulnerabilities. Hardware fuzzing enables WhisperFuzz to identify and pinpoint the root cause (locations) [35, 51, 67]. explore the microarchitectural state space efficiently. Second, they lack the adequate coverage metric to capture the • With static analysis, WhisperFuzz will identify the location- timing behaviors of the processor. Designers rely on cover- s/root causes of timing vulnerabilities. Moreover, Whisper- age metrics to obtain the necessary confidence before tape- Fuzz introduces a timing coverage metric to help designers out [27, 36, 57]. Therefore, introducing such metrics to evalu- evaluate the timing behaviors explored. ate the progress of fuzzing is typical [69]. We will elaborate • We evaluate the effectiveness of WhisperFuzz on three real- on these shortcomings in Section 5. world, open-sourced processors from RISC-V instruction Our Goals and Contributions. We enhance existing fuzzing set architecture (ISA) – BOOM [74], Rocket Core [9], and strategies to address their limitations by integrating static CVA6 [73], which are widely used as benchmarks in the analysis. This allows us to automatically pinpoint the sources hardware security community. of timing vulnerabilities and compute the coverage of timing • WhisperFuzz finds 12 new timing vulnerabilities across behaviors in processor designs. Our fuzzer efficiently explores all three benchmarks. Eight of them pose serious security the design space, detecting timing vulnerabilities, while our vulnerabilities, according to the RISC-V Zkt contract [43]. novel static approach identifies the root causes and provides WhisperFuzz also pinpoints the locations of all existing and timing behavior coverage. new vulnerabilities. Locating the root cause of timing vulnerabilities and com- puting timing coverage is non-trivial and poses several chal- 2 Background lenges: (i) expressing the timing behaviors of processor mod- ules formally is complex, as they do not operate in isolation In this section, we provide a succinct background on hardware and can influence each other; (ii) finer measurement of mod- fuzzing and microarchitectural timing side channels, which ule timing behaviors is needed, which is time-consuming for form the basis of WhisperFuzz. modern processors with numerous modules [73, 74]; (iii) trac- ing vulnerabilities to their root causes within the design space 2.1 Hardware Fuzzing is intricate; and (iv) traditional mutation algorithms used in fuzzers are insufficient for detecting timing vulnerabilities Hardware fuzzing is a dynamic verification technique that due to their reliance on microarchitectural state transitions. iteratively generates testing inputs called tests to verify target
5378 33rd USENIX Security Symposium USENIX Association
Listing 1: A pair of instruction sequences that have identical EVICT+TIME [48], and FLUSH+RELOAD [30]. The key idea instructions but operate on different data. The instruction of all these attacks is to target a specific shared resource, such sequence is a timing vulnerability if the execution times differ. as the cache memory, and exploit its data-dependent timing 1 LI t6 , 0 x81321 LI t6 , 0 x11235 behavior. Such attacks consist of a sequence of instructions 2 LI a7 , 0 xFEEEE LI a7 , 0 xFFFFF which when executed with different data take different exe- 34 LD t4 , 0( a7 ) LD t4 , 0( a7 ) cution times. For example, consider the pair of instruction 5 ADDI a9 , a5 , t4 ADDI a9 , a5 , t4 sequences in Listing 1. The two sequences are identical but LD t5 , 0( t6 ) LD t5 , 0( t6 ) differ in the data they operate upon. The sequence can be considered a timing vulnerability if the execution of the two hardware [16, 34, 39]. A coverage-feedback fuzzer starts by sequences results in different execution times. generating an initial set of tests, called seeds, randomly using The objective of our work is to develop WhisperFuzz, which a seed generator. When fuzzing processors, these seeds are identifies such instruction sequences and pairs of input data executable programs with a sequence of instructions [16, 37]. that result in different execution times. Furthermore, Whisper- The fuzzer simulates the target hardware with these tests using Fuzz localizes the root cause for the differing execution times, open-source or commercial hardware simulation tools such thereby assisting in mitigation. as Verilator [56] and Synopsys VCS [3]. During simulation, the fuzzer collects coverage informa- 3 tion that quantifies the activities caused by the test in the Methodology hardware. For instance, the coverage information can be rep- In this section, we first explain the relationship between tim- resented as transitions of finite-state machines (FSMs) [37]. ing behaviors and transitions of a digital circuit. We introduce Fuzzers either instrument the hardware to add activity mon- the Micro-Event Graph that helps capture the microarchitec- itors [34, 39], or use the existing coverage monitors of the tural transitions at a fine granularity. We use this graph to simulation tools [16, 37] to collect this coverage informa- identify the location of timing vulnerabilities and monitor tion. Next, it generates new tests automatically by performing the timing behaviors covered. Further, we discuss the chal- bit manipulation operations, called mutations on the current lenges of extracting the Micro-Event Graph from a processor tests, increasing coverage. The fuzzer iterates over this cycle design. Finally, we give an overview of our solutions to these of test generation and simulation to verify target hardware till challenges and elaborate on each solution. desired coverage is achieved. Fuzzers use a vulnerability detector to detect vulnerabilities using differential testing or hardware assertions. In differential 3.1 Microarchitectural Transitions and Tim- testing, the fuzzer runs a golden reference model along with ing Behaviors the target hardware and compares its outputs to detect vulner- abilities [34, 37]. Alternatively, some fuzzers insert hardware A finite-state machine (FSM) can model a sequential digital assertions, i.e., rules describing the expected behavior, in the circuit. Given an input, the circuit transitions through various target hardware and detect vulnerabilities as violations of states in the FSM to produce the output. Assuming each state these assertions [42]. While existing black-box [35, 67] and in the FSM takes constant time, the sequence of state tran- grey-box [51] fuzzers can detect timing vulnerabilities in pro- sitions to generate the output determines the execution time cessors, these approaches fail to locate the root causes of these of the circuit for a given input. Thus, we claim: two different vulnerabilities. Further, these techniques can not evaluate the inputs resulting in the same state transition sequences will explored timing behaviors. These limitations delay the miti- take the same execution time. gation process and hamper the designer’s confidence due to ~2 cycles ~1 cycle absence of a coverage metric. LookUp Miss Free Full ~4 cycles 2.2 Timing Side-Channel Attacks Hit BlockRequest Replace Timing side-channel attacks exploit measurable variations Request in the execution time of instructions to glean secret infor- Response mation from victim applications. These timing variations Ready Wait arise from interactions of different operands with the micro- architecture. For instance, [11] proposed a timing attack to ~1 cycle ~15 cycles recover AES keys by measuring the cache accesses during encryption across different keys. Figure 1: A finite-state machine (FSM) representation of the Over the years, multiple techniques to perform tim- cache set protocol. Each state is assumed to take a constant ing attacks have developed such as PRIME+PROBE [48], time as shown at each node.
USENIX Association 33rd USENIX Security Symposium 5379
Consider the case study of a cache composed of multiple P3 P5
cache sets. Each cache set can be represented as an FSM with L6 L7 five states: LookUp, FreeBlock, Replace, Wait, and Ready, as shown in Figure 1. When a program accesses data, the L8 P12 cache first performs a look-up for the associated memory ad- L9 W15 W14 P1 R10 dress in the LookUp state. If the data is found in the cache (cache hit), it will be directly transferred to the Ready state, and the processor can access the data without going to the F13 main memory. Thus, an input address that is already present in F11 P2 the cache set causes transitions {LookUp → Ready} taking L4 three clock cycles in its corresponding implementation. How- ever, if the data is not found (cache miss), the cache set will transfer to the FreeBlock state to look for a free cache block Figure 2: A high level representation of Micro-Event to store the data. If a free block exists, the cache will transition Graph (MEG) for cache set protocol represented as an FSM to the Wait state and request the memory for the correspond- in Figure 1. ing data. In case the cache does not have a free block, it will transfer to the Replace state, select a block for eviction based on the replacement policy, and then transfer to the Wait state. execution of the cache set protocol can be mapped to at least The cache waits in this state until it receives data from mem- one path in the MEG shown. Similar to the state transitions ory. It then transitions to the Ready state. Thus, if an input ad- in the FSM, but at the finest granularity, an input triggers a dress is not present in the cache set, two FSM state transition sequence of microarchitectural events in the MEG during its sequences (and execution times) are possible: (i) {LookUp → execution, each taking a constant time. Thus, one can have FreeBlock → Wait → Ready}, taking 19 clock cycles if the following observations: the cache has a free block or (ii) {LookUp → FreeBlock P1. If two inputs to the microarchitecture result in the same → Replace → Wait → Ready}, taking 23 cycles if the event transitions in the MEG, then the execution time cache does not have a free block. Assuming each state in for the two inputs is the same. the FSM takes a constant execution time, a difference in the P2. If there is a difference in the execution time of the two execution time of two inputs implies a difference in the se- inputs, then the sequence of microarchitectural events quence of state transitions followed in the FSM. However, in followed is different for the two executions. practice, FSM states do not always take a constant execution P3. If two inputs to the microarchitecture result in different time. Moreover, an FSM model is abstract and cannot effec- event transitions in the MEG, then the execution time tively represent complex microarchitectural details in digital for the two inputs may differ. circuits. Thus, an FSM representation fails to uncover timing differences arising at the microarchitectural level. Further, 3.2 Detecting and Localizing Timing Vul- it makes localizing the source of timing difference difficult, nerabilities in Processors: A High-Level delaying the mitigation process. Overview We introduce Micro-Event Graphs (MEGs) to overcome these drawbacks. A MEG models a given digital circuit using The goal of WhisperFuzz is to detect and localize timing vul- the register-transfer level (RTL) as a set of events, which we nerabilities in a processor design-under-test (DUT). To detect call microarchitectural events. Each microarchitectural event timing vulnerabilities, we leverage the strength of hardware affects the contents of at least one element, such as a wire or fuzzing. The fuzzer generates an instruction sequence and a register in the digital circuit. A MEG models a given digital at least two corresponding data inputs of the form shown in circuit as possible events and dependencies between these Listing 1, that take different execution times when applied events. Each node in the MEG represents an element while to the sequence. For each pair of instruction sequences and a directed edge from a parent node to a child node indicates inputs, we trace the path of events in the MEG. For example, that an event on the parent element can potentially trigger an in Figure 2, each path represents an execution corresponding event on the child element. to different addresses given to a load instruction. These paths Figure 2 shows a high-level representation of the MEG are then used to localize the root cause of the vulnerability. corresponding to the cache set protocol. The MEG consists of The root cause is the event prior to the first bifurcation in 15 nodes and 115 edges. Each state in the corresponding FSM these two paths. (refer Figure 1) maps to one or more nodes in the MEG. For For example, consider the two highlighted paths in Fig- example, nodes colored in green (node labels starting with L) ure 2. One path traces event sequence { L6, L7, R10}, while correspond to state LookUp and those colored in yellow (node the other traces {L6, L7, L9, W15, W14, R10}. Each path labels starting with P) correspond to state Replace. Each corresponds to a different address given to a load instruc-
5380 33rd USENIX Security Symposium USENIX Association
INPUT GENERATOR ---- PREPROCESSOR
----
---- x4,34
----
----
---- bez
bez x4,34
bezx3,x5
add x4,34
bez x4,34 bez x4,34 add x3,x5
add x3,x5 add x3,x5 Inputs add x3,x5
---- Input Database addr addr addr
----
----
----
---- tag_
---- ----
---- hit addr
---- tag_
hit hit complete addr
tag_
CODE COVERAGE MUTATOR comp addr
lete
complete
fetch mem_ way Timing
callmem_
fetch way
bltz x4,34 fetch call
mem_
bez x4,34 add x3,x5 call way vulnerabilities
x3,x5 bez x4,44
add add x6,x5 with locations
DUT Simulation COVERAGE DIAGNOZER
FEEDBACK ENGINE DUT ANALYZER
OPERAND MUTATOR Coverage
report bez
bez x4,34
x4,34
add x3,x5
bez x4,54 LEAKAGE ANALYZER add x3,x5
bez
bez x4,34
bez x4,34 add bez x4,64
bez x3,x5
x4,64 bez x4,34
bez x4,34 x4,34 x3,x5
x4,34 add
bezbezx3,x5 bez add x3,x5
x4,34 add x3,x5 add x3,x5 add
bez
x3,x5
add x4,34
add x4,34 x3,x5
x4,34 bez x4,34
add x4,74
bez
x3,x5
add bez
x3,x5 add x3,x5
add x3,x5 x4,74 bez
add add x3,x5
x3,x5 add x3,x5
bez x4,34 bez x4,54 add x3,x5
add
bez x3,x5
add x3,x5 x4,74
add x3,x5
DUT Timing
Simulation vulnerabilities
Figure 3: The WhisperFuzz framework. It includes three key modules. First, the Seed Generation module internally utilizes a
coverage-feedback fuzzer to explore the design space. The generated inputs are recorded in a database. Mutations are performed
to improve code coverage. Second, the Vulnerability Detection module uses the generated seed, mutates the instruction operands,
and identifies the timing vulnerabilities based on DUT simulations. Finally, the Vulnerability Localization module pinpoints the
locations of uncovered vulnerabilities.
tion. Since the two paths are different, they may take different complete processor. Therefore, we follow a two-pronged ap-
execution times due to P3 (See Section 3.1), resulting in a proach where we first generate instruction sequences for the
timing vulnerability. These paths trace the same events until complete processor to detect timing differences and localize
L7, after which they bifurcate. Hence, an event on node L7 at a module level. We present a hierarchical analysis strategy
will likely be the vulnerability’s root cause. The number of to prioritize the modules to be analyzed, thereby detecting
paths covered in the MEG gives a notion of the coverage of vulnerabilities faster, as discussed in Section 3.6.
timing behaviors of the DUT. C3. Localizing the source of timing vulnerability. The large
code space of the processor’s DUT makes it challenging to
3.3 Challenges locate the source of a timing vulnerability. It necessitates
manual effort and a detailed understanding of the processor’s
Developing WhisperFuzz involves the following challenges. microarchitecture. To address this challenge, we introduce
C1. Generating the MEG. The MEG must capture all pos- an automated static analysis strategy on the MEG that can
sible events and event transitions in a given processor DUT. identify the root cause of the timing vulnerability within a
This is specifically challenging in modern microprocessors few seconds. Section 3.7 elaborates on the strategy.
due to their complexity and large code bases. We develop an C4. Fuzzing the microarchitectural state space and de-
automated strategy to address this challenge that extracts the termining coverage. Hardware fuzzing has shown its effec-
MEG given the DUT’s source code in RTL form. Section 3.5 tiveness in detecting vulnerabilities in large-scale designs,
elaborates on this strategy. such as processors. However, the existing grey-box proces-
C2. Characterizing timing behavior of each processor sor fuzzers [51] are not compatible with timing vulnerability
module. One way to determine timing behaviors is to input detection. Their mutation algorithms are designed to accel-
instruction sequences to the DUT and measure the execution erate coverage increment, but timing vulnerability detection
time. However, a complete processor design contains thou- requires sequences of data-dependent instructions that change
sands of signals, complicating the localization of the vulnera- processors’ timing behaviors as seen in Listing 1. Moreover,
bility. An alternate bottom-up approach is to isolate each mod- existing fuzzers lack coverage feedback to demonstrate the
ule in the processor, provide inputs, and measure the timing timing behaviors covered. Providing such metrics can help
behavior of the module. However, timing differences detected designers decide to tape out. To address this challenge, we
may not be observable when the module is integrated into the develop a specialized mutation algorithm that generates data-
USENIX Association 33rd USENIX Security Symposium 5381
SEED GENERATION
Graphs Micro-Event
LOCALIZATION DETECTION VULNERABILITY VULNERABILITY
dependent instructions. We then use paths of each module’s addr MEG as the timing coverage metric and instrument the DUT to provide coverage feedback. hit tag_addr == tag tag_ addr 3.4 The WhisperFuzz Framework To address the challenges discussed in Section 3.3, we de- hit == 0 && comp valid == 1 velop WhisperFuzz that comprises of three major modules: full == 0 && lete complete==1 Seed Generation, Vulnerability Detection, and Vulnerability Localization, as shown in Figure 3. fetch fetch == 1 mem_ way Seed Generation. WhisperFuzz first uses the Seed Gener- call ation module that contains a coverage-feedback fuzzer [14, Figure 4: Sub-graph extracted from Micro-Event Graph in 16, 34, 37, 39] to explore design spaces guided by the fuzzer’s Figure 2 of the cache set protocol case study. The L6, L7, L9, internal code-coverage metric. The fuzzer utilizes the Input W15, W14 and R10 nodes from Figure 2 correspond to addr, Generator to generate input instructions, which are then sim- tag_addr, hit, mem_call, complete, way respectively. ulated in the fuzzer’s internal DUT Simulation unit. The Feed- back Engine calculates the code-coverage metric of this input. Listing 2: Simplified Verilog code of cache set protocol (refer Based on this metric, the Code Coverage Mutator mutates Figure 1). the input instructions to improve the coverage. The Input 1 input addr; output way; Database records various fuzzer-generated inputs and the 2 corresponding code-space covered. 3 reg hit, full, valid, fetch; wire tag_addr, complete; Vulnerability Detection. Based on the Feedback Engine, 4 assign tag_addr = addr[tag_bits]; 5 always@(posedge clock) begin WhisperFuzz identifies a sequence of instructions that explore 6 if tag_addr == tag new design spaces as seeds and sends them to the Vulnerabil- 7 way <= index; hit <= 1; 8 if hit == 0 && full != 1 && valid == 1 begin ity Detection module. The Operands mutator in the Vulnera- 9 fetch <= 1; temp_way <= index; bility Detection module mutates the data in the instruction se- 10 if fetch == 1: 11 // Call mem_call for fetching block from next level. quence to trigger varying timing behaviors (See Section 3.8). 12 // Sub-instance sets complete signal These mutated instruction sequences are simulated in the 13 mem_call(addr, complete); 14 if complete: DUT Simulation unit of the Vulnerability Detection module. 15 way <= temp_way; The Leakage analyzer then compares simulation traces and 16 end detects timing vulnerabilities (See Section 3.6). Vulnerability Localization. WhisperFuzz invokes the Pre- annotated with conditions required to trigger the event and processor in Vulnerability Localization to extract Micro- the RTL line number which causes the dependency between Event Graph of modules (See Section 3.5) and instruments the event. Nodes in the MEG can be categorized into se- potential timing behaviors based on the Micro-Event Graph. quential nodes or combinational nodes corresponding to the For the timing vulnerabilities identified by the Leakage an- sequential or combinational nature of the hardware element it alyzer, WhisperFuzz invokes the Diagnozer to pinpoint the represents [29]. Formally, we define a MEG as: cause of these timing vulnerabilities (See Section 3.7). The Coverage analyzer collects simulation traces of all inputs Definition 1 Given the RTL of a module D in a DUT, the from the Vulnerability Detection module and calculates the corresponding micro-event graph is defined as G(D) = (S, Σ), timing behaviors covered. where the nodes are denoted by S = {s , s , · · · , s } = {S ∪ The WhisperFuzz framework repeats these steps until there 1 2 n q is a timeout, or the fuzzer and Operand mutator completely Sc ∪ SI ∪ I ∪ O} and include all elements in D; Sq and Sc cover the timing behaviors of the DUT. represent the sequential and combinational elements respec- tively; SI represent external modules instantiated in D; I and O are the set of inputs and outputs respectively to the module 3.5 Extracting Micro State Transitions D. The set Σ represents the edges in the graph, G, such that In this section, we elaborate on the MEG used to address chal- (si, s j) ∈ Σ if a change in si may trigger a change in s j as per the RTL. Each edge is annotated with the condition required lenge C1. Using a Preprocessor, WhisperFuzz parses the RTL for the change to occur. code of a given design to generate its MEG representation. Each node in the MEG represents an event corresponding Consider the cache set protocol example given in Sec- to an element in the RTL, while an edge indicates that there tion 3.1, with its corresponding simplified Verilog code as exists an event on the parent node that can trigger a change in Listing 2. A sub-graph of its MEG is shown in Figure 4, in the value of the child node. Edges between nodes are also denoting input node addr with an incoming edge. Due to
5382 33rd USENIX Security Symposium USENIX Association
tag_addr==tag
Algorithm 1: Preprocessor in Vulnerability Localiza- Definition 2 A sequence of directed edges, P = tion module of WhisperFuzz. ⟨s(s1, s2), (s2, s3), · · · , (sn−1, sn)⟩ where (si, s j) ∈ Σ, ∀(i, j) and Input : D // RTL code of module 1 ∈ I and sn ∈ O, is a Micro-Event Path in G(D). Output : G // MEG of module Figure 4 notes two different MEPs from the input node addr 1 G(D).I ← φ; G(D).SI ← φ; G(D).O ← φ to the output node way. Each path can be mapped to a path 2 G(D).S ← φ; G(D).Σ ← φ in the FSM in Figure 1, but at a finer granularity. In case of 3 G(D).I, G(D).SI , G(D).O ← GETINOUTPUTS(D) a cache hit, the module follows the FSM path {LookUp → 4 G(D).S ← GETSIGNALS(D) Ready} mapped to MEP {addr → tag_addr → way}. In /* Iterate RTL code */ case of a cache miss, if the cache set has a free cache line, the 5 for line ∈ D do module follows the FSM path {LookUp → FreeBlock → // Get an operand set that can change Wait → Ready} mapped to {addr → tag_addr → hit the value of destination signal → fetch → mem_call → complete → way}. A com- 6 s2 ← GETDESTINATION(line) parison of these two differing MEPs indicates the RTL wire 7 s1 ← GETOPERANDS(line) tag_addr as the hardware element responsible for the diver- 8 for s1 ∈ S1 do gence in the two paths. WhisperFuzz utilizes this information // Add an edge between each operand to trace the root cause of the vulnerability, as elaborated in and the destination signal Section 3.7. 9 G(D).Σ ← G(D).Σ ∪ {s1, s2, line_no} 10 return G 3.6 Characterizing Timing Behaviors Existing hardware fuzzers detect timing vulnerabilities by measuring the execution time of an entire processor through the assign statement on Line 4, a transition in the value of performance counters [35, 51, 66, 67]. WhisperFuzz, however, addr triggers a change in the value of tag_addr. To de- requires finer information to localize the timing vulnerabil- note this dependency, the graph contains a directed edge ities. Therefore, WhisperFuzz computes the execution time from the node addr to tag_addr. Similarly, the value of taken by each module within the processor. For this purpose, tag_address can influence the value of way and hit if the we use simulation of inputs generated by the Seed Generation condition (tag_address == tag) on Line 6 holds. Hence, and mutated by the Operand Mutator. the edges from tag_address to way and hit are annotated For each simulation of the DUT, the Simulator generates a with the condition. The sub-instance call on Line 13 corre- set of simulation traces corresponding to each signal within sponds to the dashed node mem_call in the MEG. The accept the DUT. A simulation trace is a time series that records state from node way indicates that it references an output sig- all transitions of a signal during an execution. The Leakage nal. The Preprocessor parses the RTL description of the de- Analyzer then selects the subset of interesting traces that can sign, translating it into the corresponding graphical representa- lead to a vulnerability. These traces are snipped at the last tion using Algorithm 1. Given an RTL module D, the Prepro- clock cycle at which any signal within a selected module cessor first extracts into G(D).X where X = I, O, S, Σ, or SI instance toggles. The duration of this constrained trace is corresponds to the set of inputs, outputs, nodes, edges, and then computed as the execution time of the module instance. sub-instance nodes respectively (Lines 3 and 4). Finally, the The Leakage analyzer analyses the timing behaviors of each Preprocessor iterates over each line in the RTL, identifies module instance in a DUT to identify the module instance destination signals (Line 6) and operand signals (Line 7), and with timing vulnerabilities. adds an edge between each operand signal and the destination Hierarchical leakage analysis. Modern processors, how- signal (Line 9). The Diagnozer ( Section 3.7) and Coverage ever, consist of hundreds of module instances with various Analyzer ( Section 3.8) of WhisperFuzz utilize this MEG for inter-module dependencies [9, 73, 74]. Analyzing all their further analysis. WhisperFuzz generates Micro-Event Graph timing behaviors is time-consuming and computationally ex- for each module individually to counteract the vast design pensive. Hence, we require a staggered approach for leakage complexity of processors. The comparitively reduced permod- analysis, which prioritizes modules based on their dependen- ule complexity consumes a reasonable computation cost and cies. A different module-specific execution time indicates that resource utilization as shown in Table 3. the source of the vulnerability either originates in the current module or a module lower in the hierarchy. For example, the Micro-Event Path. We define a Micro-Event Path (MEP) memory control unit (MCU) controls the data accesses in as a path that starts at the input node and traces connected the cache. Upon storing the data at a memory address, the nodes until it reaches the output node. Given an input, this cache sends the Ready signal to the MCU. Thus, if a timing path traces the sequence of events triggered in the module. difference is in the cache delaying the Ready signal, the MCU Formally, will also observe the timing difference.
USENIX Association 33rd USENIX Security Symposium 5383
The Leakage Analyzer implements a hierarchical method Algorithm 2: The Diagnozer in WhisperFuzz to locate
taking a bottom-up approach. In this approach, we map the the timing vulnerabilities in the DUT. dependencies between modules and place these modules into Input : (ST various hierarchical levels such that the lower-level modules traces 1, ST2) // Pair of simulation are sub-instances of a higher-level module. The hierarchi- 1 G(D) // MEG of module under examination cal leakage analysis is then carried out incrementally from the lowest module to the highest module. For example, in Output : (Vs, L) // Set of signals identified BOOM [74] there are 431 module instances, when placed hi- as the cause of the timing difference erarchically they constitute 10 levels. Thus, BOOM analysis and corresponding line numbers in RTL, starts from the tenth level and moves upwards until the top 2 Vs ← φ; temp_Vs ← φ; L ← φ module. This approach also ensures the detection of timing /* Phase 1 / vulnerabilities in all lower levels before detection in a higher 3 for every clock cycle (clk) in ST1 do level module instance. 4 for s ∈ G(D) · S do Once the Leakage analyzer identifies a module instance 5 if s ∈ ST1[clk] = s ∈ ST2[clk] then with execution time differences caused by a pair of inputs, 6 temp_Vs ← temp_Vs ∪ {s} it sends the module instance and the corresponding simula- 7 tion traces to Diagnozer to pinpoint the location of timing if temp_Vs is not empty then 8 break differences further. / Phase 2 */ 3.7 Localizing the Source of Timing Vulnera- 9 for temp_Vs is not empty do bilities 10 new_Vs ← φ 11 for s ∈ temp_Vs do For a pair of inputs exhibiting a difference in execution time 12 for (s, schild) ∈ G(D) · Σ do in a particular module instance, the Diagnozer localizes the 13 if schild is sequential then source of the timing difference within the design RTL. The 14 Vs ← Vs ∪ {schild} Diagnozer takes as input two sets of simulation traces, each 15 L ← L ∪ {line_no}// RTL line corresponding to an execution of the DUT with different data number inputs. It operates in two phases: (i) identifying the element 16 else causing the divergence and (ii) mapping the cause in the RTL 17 new_Vs ← new_Vs ∪ {schild} source code of the processor. Identifying the element causing the divergence. For the 18 temp_Vs = new_Vs given pair of inputs, the Leakage Analyzer generates a set of 19 simulation traces corresponding to each input, ST1 and ST2 for return (Vs, L) the module under examination, D. If each trace in the two sets are exactly identical, then the execution time for the two inputs nate from each signal in temp_V are equal. On the other hand, if the execution time of the two s. This is stored in the list Vs inputs are different, there exists a subset of the traces within along with line numbers where the corresponding event on the two sets that differ. In this subset of simulation traces, the the sequential element is found in the RTL of D. trace which first deviates, corresponds to the combinational element that instigates the timing difference. Algorithm 2 3.8 Fuzzing Microarchitectural State Space shows the process of the Diagnozer. In the first phase, the Diagnozer iterates through every clock cycle of simulation WhisperFuzz introduces two components Operand mutator traces and finds the first signals which differ in the two sets of and Coverage analyzer to generate inputs for timing vulnera- traces (Lines 6,7). It creates the list of signals temp_Vs whose bility detection and to monitor timing behaviors explored. traces first differ between ST1 and ST2. Operand mutator consists of specialized mutation algo- Mapping the cause in the source code. In a module, a timing rithms to generate inputs for detecting timing vulnerabilities difference occurs because some hardware elements take vary- in processors. Detecting vulnerabilities requires changing the ing clock cycles based on the input. The Sequential element DUT’s timing behaviors by triggering different microarchi- influences the number of clock pulses for execution. Hence, tectural state transitions [35, 51, 67]. Moreover, a valid timing to trace the source of the timing difference within the module, side-channel is data/memory-dependent [8, 25, 48, 64, 72]. the Diagnozer traces dependencies from the identified combi- Therefore, we constrain Operand mutator to mutate only the national signals to the sequential nodes in the MEG. segments of a test that will change the memory or data values. In Algorithm 2, this tracing is done by a Breadth First Search Processor fuzzers use sequences of instructions to ver- to identify the subsequent sequential elements which origi- ify DUTs, as mentioned in Section 2.1. An instruction con-
5384 33rd USENIX Security Symposium USENIX Association
tains opcode and operand fields [32, 52]; both of which Algorithm 3: Coverage analyzer cause the microarchitectural state transitions. The opcode Input : P // Micro-Event Path fields determine the instruction’s operation. Meanwhile, the 1 G(D) // MEG of module D operand fields provide the source and destination regis- ters (i.e., general-purpose registers (GPRs) and control and Output : Condition // Assertion Property status registers (CSRs)) and immediate values/memory ad- corresponding to Micro-Event Path P dresses. Some instructions contain immediate memory ad- 2 Condition ← ⟨⟩ // Empty Sequence dresses only (e.g., branch operation instructions). To generate 3 for (si1, si2) ∈ P do data/memory-dependent inputs, we constrain Operand muta- 4 if (si1, si2) has branch then tor to mutate only the immediate values/memory addresses of 5 Condition ← Condition||⟨branch⟩ instructions uniformly at random [32, 55]. To further increase 6 if si2 ∈ Sq then the mutation space, we assign random values to GPRs and 7 Condition ← Condition||⟨1 cycle⟩ valid memory addresses during the processor’s initialization. 8 if si1 ∈ SI then However, replacing the original mutation algorithms, Cov- 9 Condition ← Condition||⟨eventually⟩ erage Mutator, with Operand mutator reduces the fuzzer’s 10 return Condition efficiency in exploring the design space for timing vulnerabil- ities. This is because the mutator will not change the opcode and register-operands of instructions. Therefore, to maintain the efficacy of design space exploration and guarantee the ef- assertion report for calculating the coverage of the various fectiveness of timing vulnerability detection simultaneously, graphical paths. we use Coverage mutator to explore design spaces and use Operand mutator to exploit time side-channels near the de- 4 sign spaces explored. Any tests achieving new code coverage Evaluation will be identified as seeds for Operand mutator. For each seed, We evaluate WhisperFuzz on three most advanced open- the Operand mutator will generate multiple data-dependent sourced processors based on RISC-V [52] instruction set inputs, aiming to trigger the microarchitectural state transi- architecture (ISA). We first demonstrate the new vulnerabili- tions that will cause timing differences compared to the seed. ties detected by WhisperFuzz and provide statistical analysis Coverage analyzer monitors timing behaviors covered by to prove the existence of the timing side channels. We then mapping microarchitectural state transitions to executed paths. leverage the power of Micro-Event Graph of WhisperFuzz to For a given DUT, various paths exist between the input nodes identify the root causes of these vulnerabilities and evaluate and output nodes of the corresponding MEG. For an input the efficiency of our framework, as shown in Table 2. Finally, value to the DUT, tracing the execution path followed and we evaluate the timing behaviors covered by fuzzing. mapping it to the MEP poses a challenge. To address this challenge, we utilize SystemVerilog Assertion 4.1 Evaluation Setup (SVA) properties known as cover properties [29]. If an cover property evaluates to true for a given input, the DUT enters a Benchmark selection. Most commercial processors are pro- stage during simulation when the property holds. Each graph- tected intellectual properties without available source code. ical path is converted to a cover property using the annotated Thus, we pick the three large (in terms of the number of gates) edge conditions and the timing behavior of the node. The tim- and widely-used open-sourced processors: Rocket Core [9], ing behavior of a node depends upon the type of node defined. BOOM [74], and CVA6 [73] from the RISC-V ISA. Most re- Algorithm 3 shows the process of generating the conditions of cent hardware security tools are evaluated using these pro- a MEP, P ∈ G(D), as the expression of a cover property. As cessors [16, 34, 37]. The CVA6 and BOOM are more complex combinational nodes are modeled after combinational logic, compared to the Rocket Core. They possess advanced micro- events occurring on these nodes complete instantaneously architectural features such as out-of-order execution and sup- (line 4), while those occurring on sequential nodes complete port single instruction-multiple data (SIMD) execution. on the next clock edge (line 6). If the value of a signal is from Evaluation environment. We use the industry-standard tool, other modules, including input signals and signals connected Synopsys VCS [3] for DUT simulation. We convert timing be- with subinstances, we assume the events will eventually hap- haviors of RTL modules into SystemVerilog Assertion (SVA) pen (line 8). Appendix A shows the cover properties for cover properties and instrument them into DUTs. We use MEPs in the example cache set. Properties representing all Chipyard [7] environment for the processors. We collect the possible paths in the MEG corresponding to the module are coverage report and simulation traces from VCS to analyze instrumented in the RTL. The DUT Simulation unit of the Vul- the timing coverage and timing behaviors, respectively. nerability Detection module takes as input this modified RTL. Fuzzing setup. We use HyPFuzz [16] to generate the seeds The Coverage Analyzer utilizes the results of the resultant for Operand mutator. Other processor fuzzers that gener-
USENIX Association 33rd USENIX Security Symposium 5385
0.3 D0 D1 D2 0.3 D0 D1 D0 D1
54 0.75
0.2 0.2 0.50
0.1 14 0.1 54 0.25 12
40
0.0 40 Execution Duration(clock)
50 60 70 80 90 0.0 40 Execution Duration(clock)
50 60 70 80 90 0.00 24.5 Execution Duration(clock)
26.7 28.9 31.1 33.3 35.5
(a) CVA6 [73]: DIVUW (b) CVA6 [73]: REMW (c) CVA6 [73]: C.MV,MV
0.09 D0 D1 D2 D0 D1 D0 D1
83 0.75 0.75
0.06
48 0.50 0.50
0.03 35 0.25 12 0.25 12
0.0040 60Execution Duration(clock)
80 100 120 140 0.00 24.5 Execution Duration(clock)
26.7 28.9 31.1 33.3 35.5 0.00 24.5 Execution Duration(clock)
26.7 28.9 31.1 33.3 35.5
(d) BOOM [74]: DIVUW + REM (e) CVA6 [73]: C.ADD[W],C.SUB[W] (f) CVA6 [73]: C.AND,C.OR,C.XOR
Figure 5: Timing behaviour of detected novel side-channels.
ate sequences of instructions as inputs are also compati- 0 and 1. DIVUW in CVA6 [73]. The side channel pertains
ble [14, 24, 26, 34, 37, 39, 71]. HyPFuzz is a state-of-the-art to the execution of DIVUW instruction. Figure 5a illustrates
hardware fuzzer that combines fuzzing and formal tools to the operational characteristics of this side channel across
maximize coverage and speed up design exploration. HyP- multiple operand executions. Notably, our analysis has
Fuzz is also compatible with various coverage metrics. We use unveiled median discrepancies of 14 cycles, 39 cycles, and
a combination of branch, condition, and FSM metrics for code 54 cycles among the divisor equal to 0, 1, and greater than 1
coverage. Branch and condition metrics monitor the combina- distributions respectively. Furthermore, we have observed a
tional logic of DUTs. The FSM metric monitors the sequential maximum deviation of 56 cycles when deliberately selecting
logic of DUTs [3, 16, 37]. Therefore, any new points covered divide by zero to maximize the disparity. Establishing a
by inputs represent at least one new microarchitectural state threshold for the median separation enables the successful
transition triggered. We collect these inputs as seeds and use discrimination of binary states 0 and 1 with a 100% accuracy
the Operand mutator to generate 200 data-dependent inputs rate. However, our findings indicate that attackers leverage
for each seed. We ran the entire fuzzing process for 72 hours, this channel to transmit three states rather than the intended
and repeated it thrice to collect coverage results. two states by defining two thresholds, achieving a success
rate of 91%.
REMW in CVA6 [73]. WhisperFuzz detected this novel
4.2 Detecting Novel Side Channels side channel when fuzzing CVA6 with REMW instruction.
Figure 5b shows the operational characteristics of this side
This section will discuss 12 new timing vulnerabilities found channel across multiple instances of operand executions. We
by WhisperFuzz. Furthermore, Appendix B contains the demonstrate a median difference of 54 cycles between the
proof of concept code for mentioned vulnerabilities. the divisor equal to 0 and greater than 0 timing behavior
DIVUW + REM in BOOM [74]. The side channel under distributions. Additionally, when we select zero as a divisor
consideration pertains to the consecutive execution of the in the REMW instruction to maximize the timing difference,
DIVUW and REM instructions. In Figure 5d, the operational the maximum deviation is 56 cycles. Attackers can use this
characteristics of this side channel are graphically depicted channel by establishing a threshold for the median separation
across various operand executions. Our analysis revealed to transmit binary states 0 and 1 with 100% accuracy.
median discrepancies of 48 cycles, 35 cycles, and 83 C.ADD[W], C.SUB[W], C.AND, C.OR, C.XOR,
cycles between the divisor equal to 0, 1, and greater than and [C].MV in CVA6 [73]. WhisperFuzz detected multiple
1 distributions respectively, with a maximum deviation of novel side channels that occur when executing compressed
101 cycles observed when deliberately selecting operands RISC-V instructions, i.e. C.ADD[W], C.SUB[W], C.AND,
to maximize the disparity. Establishing a threshold for the C.OR, C.XOR, and [C.]MV. RISC-V Zkt contract has
median separation facilitates a successful discrimination classified these instructions as serious security vulnerabilities
rate of 100% when distinguishing between binary states
5386 33rd USENIX Security Symposium USENIX Association
Distribution Distribution
Distribution Distribution
Distribution Distribution
if the instructions are data dependent [2]. The MV instruction Listing 3: Source location of DIVUW in CVA6 [73]. has the same timing behavior as its compressed version, 13512 state_q <= state_d; i.e., C.MV and causes a timing channel. Figures 5e, 5f, 13513 op_a_q <= op_a_d; and 5c, show the operational characteristics of these side 13514 op_b_q <= op_b_d; channels across multiple instances of operand executions. 13515 res_q <= res_d; 13516 cnt_q <= cnt_d; We demonstrate a median difference of 12 cycles between 13517 id_q <= id_d; the second operand equal to 0 and greater than 0 timing 13518 rem_sel_q <= rem_sel_d; behavior distributions. Selecting a specific value of zero 13519 comp_inv_q <= comp_inv_d; as the operands of these instructions results in 12 more 13520 res_inv_q <= res_inv_d; 13521 op_b_zero_q <= op_b_zero_d; cycles compared to any other operand values. Establishing a 13522 div_res_zero_q <= div_res_zero_d; threshold for the median separation allows for the successful discrimination between binary states 0 and 1 with an accuracy rate of 100%. signals change the values of 8 sequential signals. Compressed Instructions in CVA6 [73]. Given two trace files 4.3 Redetecting Known Side Channels corresponding to the instruction sequence in Listing 8 the first phase of the Diagnozer identifies the sources of these DIV in BOOM [74]. WhisperFuzz successfully generated test vulnerabilities in the ALU module. The exact RTL lines are cases that exposed timing side-channel vulnerabilities related as highlighted in Listing 13. Though the ALU module does to division instructions (DIV), a vulnerability disclosed in not have a sequential component, the effects of its outputs SIGFuzz [51] for the BOOM processor. WhisperFuzz gener- are propagated to the inputs of the other modules thereby ated multiple test cases featuring the DIV instruction, and by influencing further execution. systematically mutating the input values during the fuzzing DIVUW + REM in BOOM [74] and Rocket Core [9]. Given process, it revealed variations in the number of clock cycles two trace files corresponding to the instruction sequence in required for the DIV instruction to complete its operation. Fur- Listing 5, the Diagnozer identifies the source of this vulnera- ther investigation elucidated that when the divisor was bigger bility in BOOM [74] and Rocket Core [9] at different lines in than the dividend, the division unit necessitated more time to module MulDiv. The vulnerability is localized to the sequen- conclude the division process. tial elements divisor, state, negout in both processors SC in Rocket Core [9] and BOOM [74]. WhisperFuzz (refer Table 2). also identified a timing side-channel associated with Store- Division by zero in BOOM [74], Rocket Core [9], CVA6 [73]. Conditional operations, effectively diagnosing timing dispari- Given two trace files corresponding to the instruction se- ties resulting from the presence of the dirty bit in the data quence in Listing 5 with the divisor set to 0, the Diagnozer cache implementation. The vulnerability was discovered in identifies the sources of this vulnerability in BOOM, Rocket SIGFuzz [51] for the Rocket Core and BOOM processors. The Core, CVA6 as shown in Table 2. Though the root cause is test cases feature a SC instruction containing at least one sub- localized to the same module in Rocket Core and BOOM, the sequent load instruction. Through the mutation of these test pinpointed lines differ. While in CVA6, the divide by zero vul- cases, we were able to detect timing discrepancies when the nerability is localized to module serdiv. load/store module attempted to access an address not present Hence, though the same timing vulnerability can affect multi- in the cache. Subsequently, the Diagnozer of WhisperFuzz ple DUTs, due to the differences within the microarchitectural pinpointed the root cause of this timing difference, attribut- design, the source of the vulnerability in the RTL code differs. ing it to the dirty bit that was set by the Store-Conditional Furthermore, consider the two division-related vulnerabilities instruction for a cache line. detected in CVA6 [73]. Although these vulnerabilities affect the same module (serdiv), the source of the vulnerabilities 4.4 Pinpointing the Locations of Side Channels within the module differs. Hence, the automated localization of vulnerability sources performed by WhisperFuzz is benefi- We apply Diagnozer (See Section 3.7) to identify the cial and efficient. root causes of detected timing vulnerabilities (See Sec- tions 4.3, 4.2). We describe, in detail, the Diagnozer results 4.5 Coverage Analysis for two novel and two known vulnerabilities. The results for all detected vulnerabilities are summarized in Table 2. We use Coverage analyzer to monitor timing behaviors ex- DIVUW in CVA6 [73]. In CVA6, given the instruction sequence plored by inputs from Operand mutator. Coverage analyzer in Listing 6, the Diagnozer identifies the source of the vulner- converts paths of Micro-Event Graph of an RTL module ability in module serdiv in the lines highlighted in Listing 3. into cover properties and instrument these properties in to The first phase of the Diagnozer identifies 27 signals as the in- DUT. After simulation, Coverage analyzer collects assertion stigating signals, while the second phase pinpoints that these results to calculate the timing behaviors covered (See Sec-
USENIX Association 33rd USENIX Security Symposium 5387
% Coverage
% Coverage
% Coverage
100 100 100
80 80 80
60 60 60
40 40 40
20 20 20
0 0 0
IBuf ShiftQueICacheFPToFPUFMAFPToIntIntToFPUFMAPipeMARFNPipeDivSqrtRaw wt_dc_misuntfp_divsqt_mulprep_mvpfp_fmafp_cst_mulᵐᵐᵘ csr_regctl_mvpload_unit ptw MaxPFibLFSR1BoomIOMSHRBoomWbUnitFtchBufBrnchKillQ2ICacheTLXbar7BrnchKillQBoomRASQ35
RTL module RTL module RTL module
(a) Rocket Core [9] (b) CVA6 [73] (c) BOOM [74]
Figure 6: Timing coverage of RTL modules in CVA6 [73], Rocket Core [9], and BOOM [74]. The black line indicates the variation
in coverage offered.
tion 3.8). Figure 6 shows the coverage achieved in various An attacker can formulate a similar attack with the vulnera-
modules of the three benchmarks. Due to the space limitation, bilities found by WhisperFuzz. For instance, with speculative
we only show the coverage of 10 modules with the highest execution support on CVA6, a combination of the load and
total number of timing coverage points. On average, Whis- time-dependent instructions(any instruction that is detected
perFuzz achieves 39.57%, 33.16%, and 20.20% coverage on by WhisperFuzz, See Section 4.2) can utilized to encode sensi-
CVA6 [73], Rocket Core [9], and BOOM [74], respectively. tive data into the cache, which a cache timing attack can then
Since we emphasize covering timing behaviors, our glean. However, the current state of the evaluated processors
Operand mutator generates 200 inputs for each seed gen- is limited to non-speculative execution.
erated by the coverage-feedback fuzzer. The overall coverage Attacking Library Implementations. An adversary can ex-
of WhisperFuzz can be increased by using more seeds from ploit the timing differences discovered by WhisperFuzz to
coverage-feedback fuzzer and running the fuzzer for more glean sensitive information from popular libraries in cryptog-
time. Also, many coverage points are left uncovered due to raphy or machine learning domains. For such an attack, the
the multiple configurations of DUT. For example, CVA6 has library implementation is required to have the same instruc-
parameters to configure its float-point unit to support oper- tion flow, e.g., DIVUW followed by REM for BOOM [74] or C.ADD
ations from 8-bit to 128-bit [73]. WhisperFuzz fuzzes CVA6 for CVA6 [73] with the operand dependent on a secret value.
in its default configuration where CVA6 uses 64-bit opera-
tions. Hence, all other operations’ timing behaviors are un- 5 Related Work
coverable. Rocket Core’s floating-point unit [9] and BOOM’s
branch predictor [74] have similar configurations. Therefore,
these configurations reduce the overall coverage. Existing state-of-the-art techniques for timing side-channel
vulnerability detection primarily employ formal approaches
4.6 Exploitability of Detected Vulnerabilities [22, 23, 58, 60, 65] and fuzzing [28, 35, 51, 67] techniques.
However, these approaches still exhibit critical shortcomings.
In this section, we discuss the potential exploitations of the In contrast to WhisperFuzz, these approaches fail to pinpoint
vulnerabilities detected by WhisperFuzz as presented in Sec- the root causes of the detected timing vulnerabilities without
tion 4. Such vulnerabilities can be exploited for information manual efforts that take a long time. Thus, the mitigation
leakage across diverse scenarios as described below. based on these techniques is coarse-grained rendering them
Covert Channels. A timing covert channel breaks the process inefficient in terms of the computational resources in DUT.
isolation guarantees provided by the hardware. A sender pro- Further, the coverage metrics used by these solutions, such as
cess can perform operations influencing the execution time hardware performance counters or code coverage [35, 51, 67]
of a receiver process, which infers a bit value based on this do not capture the timing behaviors of the DUT, resulting in
observed timing. For instance, the DIVUW-based vulnerabil- uncertainty prior to tape-out [27, 36, 57]. In this section, we
ity detected by WhisperFuzz in CVA6 [73] can be employed discuss these perform a comparative analysis with Whisper-
to design a covert channel based on the timing differences. Fuzz, as illustrated in Table 1.
However, realizing such a covert channel requires the com- Formal approaches for timing vulnerability detection.
municating processes to execute on the physical core using UPEC [22,23] is a white-box approach to detect side channels
hyperthreading features which are unavailable on our evalua- in RISC-V RTL designs using SAT-based bounded model-
tion processors [9, 73, 74]. checking. However, such an approach is not scalable to com-
Speculative Execution Attacks. Such attacks happen in out- plex processor designs. Alternatively, Checkmate [58] em-
of-order processors when, during the rolled back of specula- ploys micro-happens-before graphs to analyze transient ex-
tively executed instructions, processor leave their footprints ecution vulnerabilities and timing side channels. It detects
on the micro-architectural components such as the cache. This patterns within these graphs to assess the susceptibility of ar-
has been exploited in several popular attacks [1, 38, 40, 51]. chitectural models to timing side-channel threats. In contrast
5388 33rd USENIX Security Symposium USENIX Association
to our methodology, Checkmate relies on matching patterns Table 1: Comparison with prior works on timing vulnerability
of vulnerable instructions, while WhisperFuzz is semantically detection on processors with WhisperFuzz. (N.A.: Not appli-
oriented and automatic. cable, TSC: Timing side channel.)
Fuzzing-based approaches for timing vulnerability detec-
tion. Osiris [67] is a black-box fuzzer that identifies timing
vulnerabilities in commercial processors by brute-forcing dif-
ferent combinations of instruction sequences. However, to UPEC [23] RTL Covert Channels N.A.
reduce the search space, it limits the instruction sequence Fadiheh et RTL Covert Channels N.A.
length to one, leaving vulnerabilities requiring multiple in- al. [22]
structions [49] or specific operands [48] to trigger undetected. Checkmate [58] N.A. Abstract Cache TSC N.A.
model
ABSynthe [28] and PLUMBER [35] identify combinations Osiris [67] Black-box Eviction-based N.A.
of instructions that trigger microarchitectural timing side- TSC
channel leakages by deriving a leakage template. However, ABSynthe [28] Black-box Contention-based N.A.
TSC
PLUMBER requires manual efforts to specify mutation al- PLUMBER [35] Black-box Variants of cache N.A.
gorithms and potential behaviors of a DUT to generate this TSC
SIGFuzz [51] RTL TSC
template. Further, it is limited to the existing cache module WhisperFuzz RTL TSC
and cannot locate them in the DUT.
SIGFuzz [51] is a grey-box fuzzer that detects the existence 7 Conclusion
of timing vulnerabilities in processors at the RTL. It gener-
ates combinations of instructions to identify cycle-accurate
microarchitectural timing side-channels. However, replacing Recent hardware fuzzers have showcased their potential to
instructions can create additional architectural differences, identify timing vulnerabilities in intricate designs. However,
such as differences in general-purpose registers, resulting in the existing black-box or grey-box fuzzing approaches fall
a high rate of false positives. Further, SIGFuzz suffers from short in pinpointing the root cause of timing vulnerabilities
limitations in pinpointing vulnerability locations and cover- and lack the necessary coverage feedback mechanisms for the
age metrics as the black-box approaches. exploration of timing behaviors. Addressing these gaps, we
WhisperFuzz addresses these limitations of existing works by develop WhisperFuzz, the first approach that combines white-
providing a novel white-box fuzzer with static analysis to de- box fuzzing with static analysis. Its primary objectives are not
tect and pinpoint timing vulnerabilities in executed testcases only to accurately determine the locations of timing vulnera-
in processors enabling fine-grained mitigations. WhisperFuzz bilities but also to evaluate the timing behaviors. WhisperFuzz
is scalable to complex designs and end-to-end automated with has successfully detected 12 new timing vulnerabilities and
a specialized coverage metric for timing behaviors. all previously known ones in open-source processors and pin-
pointed their root causes. This opens up novel avenues in
vulnerability detection and timely mitigation in processors.
6 Discussion
8 Acknowledgement
Use of Code coverage mutator and Operand mutator. Whis-
perFuzz employs both the Code coverage mutator and the Our research work was partially funded by Intel’s Scalable As-
Operand mutator to explore the design space and generate surance Program, Deutsche Forschungsgemeinschaft (DFG)
data-dependent inputs, respectively. The determination of – SFB 1119 – 236615297, the European Union under Hori-
their utilization is an optimization problem that can aid the zon Europe Programme – Grant Agreement 101070537 –
efficacy of vulnerability detection. We can model the proba- CrossCon, the European Research Council under the ERC
bility of Operand mutator covering a timing behavior [53,75]. Programme - Grant 101055025 - HYDRANOS, the US Of-
When this probability falls below a threshold, the Code cov- fice of Naval Research (ONR Award #N00014-18-1-2058),
erage mutator can be called to generate new seeds. However, the Lockheed Martin Corporation, and the Centre for Hard-
such an analysis is beyond the scope of this paper. ware Security Entrepreneurship Research and Development
Port scanning vulnerabilities. Contention for a port in the (C-HERD) project, Ministry of Electronics and Information
architecture can cause execution delays, enabling attack- Technology (MEiTY), Government of India. This work does
ers to create a high-resolution time side-channel by scan- not in any way constitute an Intel endorsement of a product
ning for port contention [6, 12]. However, these attacks or supplier. Any opinions, findings, conclusions, or recom-
primarily depend on the simultaneous multithreading ar- mendations expressed herein are those of the authors and do
chitecture [6, 12, 59] which current open-sourced bench- not necessarily reflect those of Intel, the European Union, the
marks [9, 73, 74] lack, and hence detecting port scanning European Research Council, Lockheed Martin Corporation,
is outside the scope of WhisperFuzz. the US Government, or the Indian Government.
USENIX Association 33rd USENIX Security Symposium 5389
Paper
Manual effort Scalable
Design source
Timing channel
Coverage
Root cause
References [14] C. Chen, V. Gohil, et al. PSOFuzz: Fuzzing Processors with Particle Swarm Optimization. IEEE/ACM Interna- [1] BOOM Speculative Attacks. https://github.com/r tional Conference on Computer Aided Design, 2023. iscv-boom/boom-attacks, 2019. Last accessed on 10/01/2023. [15] C. Chen, R. Kande, et al. Trusting the Trust Anchor: To- [2] Zkt "Constant Time" Instruction List. https://gith wards Detecting Cross-Layer Vulnerabilities with Hard- ub.com/rvkrypto/riscv-zkt-list/blob/main/ ware Fuzzing. pages 1379–1383, 2022. zkt-list.adoc, 2021. Last accessed on 10/01/2023. [16] C. Chen, R. Kande, et al. HyPFuzz: Formal-Assisted [3] Synopsys VCS. https://www.synopsys.com/verif Processor Fuzzing. USENIX Security Symposium, pages ication/simulation/vcs.html, 2022. Last accessed 1361–1378, August 2023. on 10/01/2023. [17] E. Clarke, O. Grumberg, et al. Progress on the State [4] Cross-Process Information Leak. https://www.am Explosion Problem in Model Checking. Informatics, d.com/en/resources/product-security/bull pages 176–194, 2001. etin/amd-sb-7008.html, 2023. Last accessed on [18] E. M. Clarke, T. A. Henzinger, et al. Handbook of Model 09/28/2023. Checking. 10, 2018. [5] National Vulnerability Database. https://nvd.ni st.gov/vuln/search, 2023. Last accessed on [19] E. M. Clarke, W. Klieber, et al. Model Checking and 09/28/2023. the State Explosion Problem. LASER Summer School on Software Engineering, pages 1–30, 2011. [6] A. C. Aldaya, B. B. Brumley, et al. Port Contention for Fun and Profit. IEEE Symposium on Security and [20] D. Cyrluk, S. Rajan, et al. Effective Theorem Proving Privacy, 2019. for Hardware Verification. International Conference on [7] A. Amid, D. Biancolin, et al. Chipyard: Integrated De- Theorem Provers in Circuit Design, 1994. sign, Simulation, and Implementation Framework for [21] G. Dessouky, D. Gens, et al. HardFails: Insights into Custom SoCs. IEEE Micro, 40(4):10–21, 2020. Software-Exploitable Hardware Bugs. USENIX Security [8] M. Andrysco, D. Kohlbrenner, et al. On Subnormal Symposium, pages 213–230, 2019. Floating Point and Abnormal Timing. IEEE Symposium [22] M. R. Fadiheh, J. Müller, et al. A Formal Approach on Security and Privacy, 2015. for Detecting Vulnerabilities to Transient Execution At- [9] K. Asanovi´c, R. Avizienis, et al. The Rocket Chip Gen- tacks in Out-of-Order Processors. ACM/IEEE Design erator. (UCB/EECS-2016-17), Apr 2016. Automation Conference, pages 1–6, 2020. [10] C. Baier and J.-P. Katoen. Principles of Model Checking. [23] M. R. Fadiheh, D. Stoffel, et al. Processor Hardware 2008. Security Vulnerabilities and Their Detection by Unique Program Execution Checking. IEEE Design, Automa- [11] D. J. Bernstein. Cache-timing attacks on AES. 2005. tion & Test in Europe Conference & Exhibition, 2019. [12] A. Bhattacharyya, A. Sandulescu, et al. Smotherspectre: [24] K. C.-S. Flavien Solt and K. Razavi. Cascade: CPU Exploiting Speculative Execution Through Port Con- Fuzzing via Intricate Program Generation. 33th USENIX tention. ACM SIGSAC Conference on Computer and Security Symposium, 2024. Communications Security, 2019. [13] R. Bloem, B. Gigerl, et al. Power contracts: Provably [25] Q. Ge, Y. Yarom, et al. A Survey of Microarchitectural complete power leakage models for processors. In Timing Attacks and Countermeasures on Contemporary CCS 2022 - Proceedings of the 2022 ACM SIGSAC Hardware. Journal of Cryptographic Engineering, 2018. Conference on Computer and Communications Secu- [26] V. Gohil, R. Kande, et al. MABFuzz: Multi-Armed Ban- rity, Proceedings of the ACM Conference on Computer dit Algorithms for Fuzzing Processors. arXiv preprint and Communications Security, pages 381–395, United arXiv:2311.14594, 2023. States, November 2022. Association of Computing Ma- chinery. 2022 ACM SIGSAC Conference on Computer [27] R. Gopinath, C. Jensen, et al. Code Coverage for and Communications Security : ACM CSS 2022, ACM Suite Evaluation by Developers. ACM/IEEE Interna- CSS 2022 ; Conference date: 07-11-2022 Through 11- tional Conference on Software Engineering, pages 72– 11-2022. 82, 2014.
5390 33rd USENIX Security Symposium USENIX Association
[28] B. Gras, C. Giuffrida, et al. ABSynthe: Automatic Black- [43] M.-J. O. Saarinen. riscv-zkt-list. https://github.c box Side-channel Synthesis on Commodity Microarchi- om/rvkrypto/riscv-zkt-list, 2021. Last accessed tectures. NDSS, 2020. on 10/16/2023. [29] S. L. W. Group. IEEE Standard for SystemVerilog– [44] O. Oleksenko, C. Fetzer, et al. Revizor: Testing black- Unified Hardware Design, Specification, and Verifica- box cpus against speculation contracts. IEEE Micro, tion Language. IEEE Std 1800-2017, 2018. 43(4):37–44, jul 2023. [30] D. Gruss, C. Maurice, et al. Flush+ Flush: a fast and [45] O. Oleksenko, M. Guarnieri, et al. Hide and Seek with stealthy cache attack. Detection of Intrusions and Mal- Spectres: Efficient discovery of speculative information ware, and Vulnerability Assessment, pages 279–299, leaks with random testing. In Proceedings of the 44th 2016. IEEE Symposium on Security and Privacy, S&P [31] X. Guo, R. G. Dutta, et al. Scalable SoC Trust Veri- 2023. IEEE, 2023. fication using Integrated Theorem Proving and Model Checking. pages 124–129, 2016. [46] M. Orenes-Vera, A. Manocha, et al. AutoSVA: Democ- ratizing Formal Verification of RTL Module Interactions. [32] J. L. Hennessy and D. A. Patterson. Computer Archi- ACM/IEEE Design Automation Conference, pages 535– tecture: A Quantitative Approach. 2011. 540, 2021. [33] W. Hu, A. Ardeshiricham, et al. Hardware Information [47] T. Ormandy and D. Moghimi. Downfall and Zenbleed: Flow Tracking. ACM Computing Surveys, 2021. Googlers helping secure the ecosystem. https://se [34] J. Hur, S. Song, et al. DIFUZZRTL: Differential Fuzz curity.googleblog.com/2023/08/downfall-and Testing to Find CPU Bugs. IEEE Symposium on Security -zenbleed-googlers-helping.html, 2023. Last and Privacy, pages 1286–1303, 2021. accessed on 09/28/2023. [35] A. Ibrahim, H. Nemati, et al. Microarchitectural Leak- [48] D. A. Osvik, A. Shamir, et al. Cache Attacks and Coun- age Templates and Their Application to Cache-Based termeasures: The Case of AES. The Cryptographers’ Side Channels. ACM SIGSAC Conference on Computer Track at the RSA Conference., 2006. and Communications Security, 2022. [49] C. Percival. Cache Missing for Fun and Profit, 2005. [36] M. Ivankovi´c, G. Petrovi´c, et al. Code Coverage at Google. ACM Joint Meeting on European Software [50] H. Ragab, A. Milburn, et al. Crosstalk: Speculative Data Engineering Conference and Symposium on the Foun- Leaks Across Cores Are Real. IEEE Symposium on dations of Software Engineering, pages 955–963, 2019. Security and Privacy, 2021. [37] R. Kande, A. Crump, et al. TheHuzz: Instruction [51] C. Rajapaksha, L. Delshadtehrani, et al. SIGFuzz: A Fuzzing of Processors Using Golden-Reference Mod- Framework for Discovering Microarchitectural Timing els for Finding Software-Exploitable Vulnerabilities. Side Channels. In 2023 Design, Automation & Test in USENIX Security Symposium, pages 3219–3236, 2022. Europe Conference & Exhibition (DATE), pages 1–6. [38] P. Kocher, J. Horn, et al. Spectre attacks: Exploiting IEEE, 2023. speculative execution. In 40th IEEE Symposium on [52] RISC-V. RISC-V Webpage. https://riscv.org/, Security and Privacy (S&P’19), 2019. 2023. Last accessed on 10/01/2023. [39] K. Laeufer, J. Koenig, et al. RFUZZ: Coverage-Directed [53] C. P. Robert. Monte Carlo Methods in Statistics. Fuzz Testing of RTL on FPGAs. IEEE International arXiv:0909.0389, 2009. Conference on Computer-Aided Design, 2018. [40] M. Lipp, M. Schwarz, et al. Meltdown: Reading Kernel [54] M. Schwarz, M. Lipp, et al. ZombieLoad: Cross- Memory from User Space. USENIX Security, 2018. privilege-boundary data sampling. ACM SIGSAC Con- ference on Computer and Communications Security, [41] MITRE. CWE VIEW: Hardware Design. https://cw 2019. e.mitre.org/data/definitions/1194.html, 2019. Last accessed on 09/28/2023. [55] J. P. Shen and M. H. Lipasti. Modern Processor Design: [42] S. K. Muduli, G. Takhar, et al. HyperFuzzing for SoC Fundamentals of Superscalar Processors. 2013. Security Validation. ACM/IEEE International Confer- [56] W. Snyder. Verilator. https://www.veripool.org/w ence on Computer-Aided Design, pages 1–9, 2020. iki/verilator, 2023. Last accessed on 10/01/2023.
USENIX Association 33rd USENIX Security Symposium 5391
[57] Synopsys. Accelerating Verification Shift Left with [69] B. Wile, J. Goss, et al. Comprehensive Functional Veri- Intelligent Coverage Optimization. https://www.sy fication: The Complete Industry Cycle. 2005. nopsys.com/cgi-bin/verification/dsdla/pdfr 1.cgi?file=ico-wp.pdf, 2022. Last accessed on [70] H. Witharana, Y. Lyu, et al. A Survey on Assertion- 02/18/2023. based Hardware Verification. ACM Computing Surveys, 2022. [58] C. Trippel, D. Lustig, et al. Checkmate: Automated Syn- thesis of Hardware Exploits and Security Litmus Tests. [71] J. Xu, Y. Liu, et al. MorFuzz: Fuzzing Processor via IEEE International Symposium on Microarchitecture, Runtime Instruction Morphing enhanced Synchroniz- 2018. able Co-simulation. 2023. [59] D. M. Tullsen, S. J. Eggers, et al. Simultaneous Multi- [72] T. Yavuz, F. Fowze, et al. Encider: detecting timing and threading: Maximizing On-Chip Parallelism. ACM In- cache side channels in sgx enclaves and cryptographic ternational Symposium on Computer Architecture, 1995. apis. IEEE Transactions on Dependable and Secure Computing, 20(2):1577–1595, 2022. [60] K. v. Gleissenthall, R. G. Kıcı, et al. IODINE: Verifying Constant-Time execution of hardware. In 28th USENIX [73] F. Zaruba and L. Benini. The Cost of Application- Security Symposium (USENIX Security 19), pages 1411– Class Processing: Energy and Performance Analysis 1428, Santa Clara, CA, August 2019. USENIX Associa- of a Linux-Ready 1.7-GHz 64-Bit RISC-V Core in 22- tion. nm FDSOI Technology. IEEE Transactions on Very Large Scale Integration Systems, 2019. [61] J. Van Bulck, M. Minkin, et al. Foreshadow: Extract- ing the Keys to the Intel SGX Kingdom with Transient [74] J. Zhao, B. Korpan, et al. SonicBOOM: The 3rd Gen- Out-of-Order Execution. USENIX Security Symposium, eration Berkeley Out-of-Order Machine. 4th Workshop 2018. on Computer Architecture Research with RISC-V, 2020. [62] J. Van Bulck, D. Moghimi, et al. LVI: Hijacking Tran- [75] L. Zhao, Y. Duan, et al. Send Hardest Problems My sient Execution through Microarchitectural Load Value Way: Probabilistic path prioritization for hybrid fuzzing. Injection. IEEE Symposium on Security and Privacy, NDSS, 2019. 2020. [63] S. van Schaik, A. Milburn, et al. RIDL: Rogue in-flight data load. IEEE Symposium on Security and Privacy, 2019. [64] Y. Wang, A. Ferraiuolo, et al. Timing Channel Protection for a Shared Memory Controller. 2014. [65] Z. Wang, G. Mohr, et al. Specification and verification of side-channel security for open-source processors via leakage contracts. In Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security, CCS ’23, page 2128–2142, New York, NY, USA, 2023. Association for Computing Machinery. [66] V. M. Weaver, D. Terpstra, et al. Non-Determinism and Overcount on Modern Hardware Performance Counter Implementations. IEEE International Symposium on Performance Analysis of Systems and Software, pages 215–224, 2013. [67] D. Weber, A. Ibrahim, et al. Osiris: Automated Discov- ery of Microarchitectural Side Channels. 30th USENIX Security Symposium, pages 1–18, 2021. [68] J. Wikner and K. Razavi. RETBLEED: Arbitrary specu- lative code execution with return instructions. USENIX Security Symposium, 2022.
5392 33rd USENIX Security Symposium USENIX Association
Appendix Listing 6: DIVUW side-channel proof of concept code snippets A SVA cover properties for case study on CVA6 [73]. 1 LI a4 , 3 2 // If a4=0 takes 92ns 3 // If a4=3 takes 36ns Listing 4 shows the cover property for the graphical paths 4 LI a7 , 1333 in the Micro-Event Graph of the cache case study as shown 5 // If a4=33 a7=-1333 takes 54ns in Listing 2. Section 3.5 mentions two Micro-Event Paths 6 DIVUW t3 , a7 , a4 from its input addr to its output way: {addr → tag_addr → way} and {addr → tag_addr → hit → fetch → Listing 7: REMW side-channel proof of concept code snippets mem_call → complete → way} Among these paths, hit, on CVA6 [73]. full, fetch, way are sequential nodes; the events occurring 1 LI a4 , 3 on these nodes complete on the next clock edge. The value of 2 // If a4=0 takes 92ns the complete signal is driven by mem_call, a subinstance. 3 // Else on average takes 37ns 4 LI a7 , 1333 5 REMW t3 , a7 , a4 Listing 4: SVA cover properties for case study. 1 property p1; //{addr, tag_addr, way} 2 @(posedge clock) (tag_address == tag); Listing 8: C.ADD[W], C.SUB[W], C.AND, C.OR, C.XOR, 34 endproperty and [C.]MV side-channel proof of concept code snippets on 5 property p2; //{addr, tag_addr, hit, fetch, mem_call, CVA6 [73]. ,→ complete, way} 1 LI a3 , 0 6 @(posedge clock) !(tag_address == tag) ##1 (hit == 0 && 2 // If a3=0 and a4=0 takes 36 cycles ,→ full != 1 && valid[0] == 1) |-> s_eventually ( ,→ complete == 1); 3 // Else on takes 24 cycles 7 endproperty 4 LI a4 , 1023 5 MV a3 , a4 6 // Same for C.ADD[W], C.SUB[W], C.AND, C.OR, C B Proof of concept codes for triggering de- ,→ .XOR, and C.MV tected vulnerabilities This section shows the proof of concept code snippets on the location of Division by zero in BOOM [74]. Listing 10 triggering various timing vulnerabilities in different RISC- shows the location of Division by zero in Rocket Core [9]. V processors. Listing 5 shows the code snippets of DIVUW + Listing 11 shows the location of Division by zero in CVA6 [73]. REM side-channel on BOOM [74]. Listing 6 shows the code snip- Listing 12 shows the location of DIVUW+REM in BOOM. List- pets of DIVUW side-channel on CVA6 [73]. Listing 7 shows the ing 13 shows the location of compressed instructions and code snippets of REMW side-channel on CVA6 [73]. Listing 8 MV in CVA6; nine vulnerabilities share the same root cause. shows the code snippets of compressed instruction-based side- The results show that the Diagnozer of WhisperFuzz can suc- channels on CVA6 [73]. cessfully identify the location of timing vulnerabilities in processors. Listing 5: DIVUW + REM side-channel proof of concept code Listing 9: Source location of Division by zero in BOOM [74]. snippets on BOOM [74]. 230133 if (eOut_1 == 1) begin // @[Multiplier.scala 153:19] 1 LI a3 , 291 230134 count <= {{1'd0}, eOutPos}; 2 LI a7 , -1954 230135 end else begin 3 LI s10 , 201 230136 count <= _count_T_1; // @[Multiplier.scala 143:11] 4 LI t6 , 477 230137 end 5 // If t6=477, a7=-1954, s10=256, a3=291 takes 230138 ... ,→ 42ns 230139 if (divby0 & _eOut_T_4) begin 6 // If t6=1 , a7=-1954, s10=201, a3=291 takes 230140 neg_out <= 1'h0; // @[Multiplier.scala 158:38] . . . end ,→ 143ns 230147 ... 7 DIVUW t5 , a7 , t6 230148 end else if (state == 3'h3) begin 8 REM t3 , s10 , a3 230149 remainder <= {{1'd0}, _GEN_16}; 230150 end
C Locations of side channels
This section shows the locations of timing vulnerabilities identified by the Diagnozer (See Section 3.7). Listing 9 shows
USENIX Association 33rd USENIX Security Symposium 5393
Table 2: Summary of results generated by WhisperFuzz across different processors. Along with the detected vulnerability, we identify the specific lines in the RTL and trace the signals. We also note the time taken for detecting the various vulnerabilities.
Processor Vulnerability Source Module RTL Lines Phase 1 Results Phase 2 Results Seed gener- Input generation Leakage ation(s) (∗103 s) Analyzer (∗104s) CVA6 DIVUW serdiv 230115, 230117, 230166, Multiple signals Multiple Signals 54.00 10.70 13.19 230169, 230173 CVA6 Divide by div_res_zero_q, zero serdiv 13522, 13514, 13512 Multiple signals op_b_q, 3.67 0.61 2.00 state_q, cnt_q BOOM Divide by MulDiv 230134, 230136, 230148, neg_out, count, zero 230175 Multiple Signals state, 3.67 0.66 2.27 remainder Rocket Divide by MulDiv 209671, 209673, 209703, io_req_bits_in2, neg_out, 3.67 0.63 1.65 Core zero 209725 _divisor_T divisor, state Rocket DIVUW MulDiv 230115, 230117, 230166, io_req_bits_in2, _divisor_T, 3.67 0.53 1.71 Core 230173 _divisor_T divisor BOOM DIVUW MulDiv 230115, 230117, 230166, io_req_bits_in2, _divisor_T, 3.67 0.53 2.34 230173 _divisor_T divisor 180738, 180747, 180756, BOOM SC BoomWritebackUnit 180765, 180774, 180783, io_data_resp All wb_buffer 146.00 29.15 34.10 180792, 180801 CVA6 Compressed ALU 3757 adder_z_flag Multiple Signals 124 24.77 1.77 Instructions
Listing 11: Source location of Division by zero in CVA6 [73].
Table 3: MEG and SVA overhead statistics for BOOM [74]. 13512 state_q <= state_d; 13513 op_a_q <= op_a_d; SVA 13514 op_b_q <= op_b_d; Module MEG coverage 13515 res_q <= res_d; points 13516 cnt_q <= cnt_d; 13517 id_q <= id_d; Time Space con- (per 13518 rem_sel_q <= rem_sel_d; taken(s) sumed(kB) module) 13519 comp_inv_q <= comp_inv_d; 13520 res_inv_q <= res_inv_d; MaxPFibLFSR1 0.32 5.2 302 13521 op_b_zero_q <= op_b_zero_d; BoomIOMSHR 0.34 23.1 157 13522 div_res_zero_q <= div_res_zero_d; BoomWbUnit 0.32 20.6 3372 FetchBuffer 0.52 403.2 1458 Listing 12: Source location of DIVUW+REM in BOOM [74]. BrnchKillQ2 0.35 22.7 1066 230112 if (cmdMul) begin // @[Multiplier.scala 164:17] ICache 0.13 14.9 3869 230113 state <= 3'h2; TLXbar_7 0.32 13.1 187 230114 end else if (lhs_sign, |rhs_sign) begin // @[Multiplier. BrnchKillQ 0.49 106.1 2777 230115 → scala 164:36] state <= 3'h1; BoomRAS 0.35 17.0 125 230116 end else begin Queue_35 0.36 20.7 124 230117 state <= 3'h3; . . . ... 230165 if ( _T_38) begin // @[Multiplier.scala 163:24] 230166 divisor <= _divisor_T; // @[Multiplier.scala 169:13] 230167 end else if (state == 3'h1) begin // @[Multiplier.scala ,→ 91:57] 230168 if (divisor[63]) begin // @[Multiplier.scala 95:25] Listing 10: Source location of Division by zero in Rocket 230169 divisor <= subtractor; // @[Multiplier.scala 96:15] Core [9]. 230170 end 230171 end 209670 end else if (lhs_sign |rhs_sign) begin // @[Multiplier. 230172 if ( _T_38) begin // @[Multiplier.scala 163:24] ,→ scala 164:36] 230173 remainder <= {{66'd0}, lhs_in}; // @[Multiplier.scala 209671 state <= 3'h1; ,→ 170:15] 209672 end else begin 209673 state <= 3'h3; 209674 end Listing 13: Source location of compressed instructions and . . . ... 209702 end else begin MV in CVA6 [73]. 209703 neg_out <= lhs_sign != rhs_sign; 3754 // actual adder . . . ... 3755 assign adder_result_ext_o = $unsigned(adder_in_a) + 209724 if ( _T_38) begin // @[Multiplier.scala 163:24] 209725 divisor <= _divisor_T; // @[Multiplier.scala 169:13] 3756 assign,→ $unsigned(adder_in_b); adder_result = adder_result_ext_o[riscv::XLEN:1]; 3757 assign adder_z_flag = ∼|adder_result;
5394 33rd USENIX Security Symposium USENIX Association