We evaluated our approach using the most intricate, open-source RISC-V out-of-order processor, BOOM (et al., 2015). We used Chipyard (et al., 2020a) as the simulation environment for BOOM. We conducted experiments on a 32-core, 2.6 GHz Intel Xeon processor with 512 GB RAM running Linux-based Cent OS.

4.2. Online Phase Evaluation

Specure effectively detected two of the most recent direct speculative execution vulnerabilities (et al., 2023b; Ormandy, 2023), which cannot be discovered by state-of-the-art hardware fuzzers (et al., 2022e; et al., 2018b; et al., 2022b; et al., 2023a) because of two main advantages of Specure: (1) a novel vulnerability detection mechanism that employs fine-grained microarchitectural snapshots of the PUT to trace dynamic information flows and spot misbehaviors, i.e., information leakage, due to speculative execution. Owing to this feature, Specure is more accurate than existing fuzzers that rely on comparing execution traces with a golden-reference model (et al., 2022e; et al., 2018b; et al., 2023a) or differential fuzzing (et al., 2022b), (2) a novel fine-grained coverage metric, Leakage Path (LP), which guides the fuzzer toward potential information leakage channels utilizing static IFT, in contrast to general code coverage feedback (et al., 2022e; et al., 2018b; et al., 2023a; et al., 2022b).

Since (M)WAIT (et al., 2023b) and Zenbleed (Ormandy, 2023) attacks exploit advanced optimization features, sleep on monitor address and zeroing registers optimization, which are not yet implemented in RISC-V ISA, we first discuss how we emulated their behaviors in BOOM. Then, we compare the effectiveness of Specure with state-of-the-art hardware fuzzers in vulnerability detection (et al., 2022b; et al., 2022e). Unlike the requirements imposed by SpecDoctor (et al., 2022b), Specure requires no PUT instrumentation or hardware modifications, thereby introducing no additional simulation overhead. However, Specure still incurs a runtime overhead of 82%82% higher than TheHuzz (et al., 2022e) due to snapshots processing and coverage metric computation. Finally, we demonstrate the efficacy of our coverage metric.

Emulating (M)WAIT (et al., 2023b). We introduced a minor modification to BOOM to emulate the (M)WAIT vulnerability. The original (M)WAIT attack (et al., 2023b) requires the umonitor instruction to invoke a monitor on a memory address, and the umwait instruction sets the core to sleep. The core wakes up when changes occur at the pertinent memory location or after a predetermined amount of time. To maintain generality and avoid unnecessary complexities, we extend the functionality of the RISC-V ISA without introducing new non-standard instructions. We opted to incorporate three new CSR registers that provide the necessary functionality for emulating the (M)WAIT vulnerability. The new CSRs are mwait_en, monitor_addr, and mwait_timer. To emulate (M)WAIT vulnerability behavior on a single-core BOOM, the user sets the monitor_addr for monitoring. Activating the waiting behavior involves initiating the timer by writing one to mwait_en. If changes occur in the monitored memory (monitor_addr), the mwait_timer is set to zero. If the timer reaches zero, it is set to one. We modified BOOM’s data cache to turn off the timer not only with memory location but also with corresponding cache line changes to implement the root cause of the attack.

Emulating Zenbleed (Ormandy, 2023). To emulate Zenbleed (Ormandy, 2023) in a single-core environment, we simplified the vulnerability constraints while maintaining its generality and root cause, which is the change of a general-purpose register within a mispredicted speculative window that remains after closing the window. To avoid adding non-standard instructions, we introduced a new CSR register, zenbleed_en. We modified the Rename Stage of the BOOM pipeline by manipulating the maptable rollback mechanism to prevent the rollback of Register File changes when zenbleed_en is set to a non-zero value.

Note that emulating the (M)WAIT (et al., 2023b) and Zenbleed (Ormandy, 2023) attacks on a single-core open-source RISC-V processor, inherently lacking advanced optimization features like register zeroing and sleep on monitor address, is a proof of concept for Specure’s efficacy of identifying direct speculative execution vulnerabilities. Our emulation did not dismiss the original vulnerabilities’ generality and root cause, i.e., architecture-visible changes during speculative execution. Moreover, following modifications, we built and tested BOOM to confirm its functionality correctness.

Table 2. Specure’s vulnerability detection effectiveness compared to prior works (“e.m.” indicates emulated).

Detecting Emulated (M)WAIT and Zenbleed. To demonstrate the effectiveness of Specure, we compared it with SpecDoctor (et al., 2022b), the state-of-the-art hardware pre-silicon fuzzer for detecting speculative execution vulnerabilities. We initialized both fuzzers in the same condition to run for 24 hours. After approximately 14 hours and 4.5 hours, Specure triggered the emulated (M)WAIT and Zenbleed vulnerabilities, respectively. Specure detected the direct information leakage path as the root cause. The root cause report showed a direct leakage path between the data cache and mwait_timer CSR register for (M)WAIT and a direct leakage path between zenbleed_en CSR register and general purpose register file and rename module for Zenbleed. These two vulnerabilities are categorized as CWE-1342. SpecDoctor (et al., 2022b) practically could not detect these vulnerabilities within 24 hours. However, considering its vulnerability detection mechanism, which relies on differential fuzzing with varied secrets and monitors the hash values of instrumented components for mismatches, it cannot detect these vulnerabilities because: (1) limitation in instrumented microarchitectural components, (2) generating random inputs without using a fine-grained coverage metric, and (3) varied secret-based vulnerability detection will overlook information leakages that do not directly reflect the secret value.

Detecting Spectre Vulnerabilities. We evaluate Specure’s capability in detecting known speculative execution vulnerabilities, i.e., Spectre variant 1 and 2 (et al., 2019b). For this test, we added a data cache to the PDLC list to be monitored by Vulnerability Detector. To assess Specure’s performance, we compared it again against SpecDoctor (et al., 2022b), which reported that it found Spectre vulnerability in 31 hours. However, Specure detected this vulnerability 20×20\times faster than state-of-the-art, after 1.5 hours and 49 minutes, without and with initial seeds with speculative window, respectively.

Figure 2. Coverage analysis of traditional code coverage, and Specure’s novel coverage metric.

Coverage Analysis. We performed a comparative evaluation of novel LP coverage against traditional coverage metrics (et al., 2022e) in terms of vulnerability detection efficiency, i.e., PDLC activation. In this experiment, we ran Specure with two different coverage metrics as feedback: (1) novel Leakage Path (LP) and (2) traditional Code Coverage (e.g. FSM, toggle, branch, and condition). Figure 2 presents BOOM’s covered PDLCs during fuzzing using traditional code coverage and LP coverage metric. Each experiment was repeated three times, and the plot represents the mean value of all experiments. Figure 2 shows that the number of explored PDLCs achieved by fuzzer guided by code coverage lags in worst cases by 10.2% behind the fuzzer guided by LP coverage. Moreover, fuzzer guided by LP coverage achieves the same coverage value with only 798798 iterations, compared to the 51495149 iterations required by code coverage guided fuzzer. This indicates that by employing LP, Specure explores the search space for speculative execution vulnerabilities 6.45×6.45\times faster than traditional code coverage metrics.