Revice: Reusing Victim Cache to Prevent Speculative Cache Leakage

2020 IEEE Secure Development (SecDev) ReViCe: Reusing Victim Cache to Prevent Speculative Cache Leakage Sungkeun Kimy, Farabi Mahmudy, Jiayi Huangy, Pritam Majumdery, Neophytos Christoux Abdullah Muzahidy, Chia-Che Tsaiy and Eun Jung Kimy yTexas A&M University, xUniversity of Cyprus fksungkeun84,farabi,jyhuang,pritam2309,abdullah.muzahid,chiache,[email protected], nio [email protected] Abstract—Spectre and Meltdown attacks reveal the perils of VP VP speculative execution, a prevalent technique used in modern Delayed Early Delayed processors. This paper proposes ReViCe, a hardware technique Update Update Exposure to mitigate speculation based attacks. ReViCe allows speculative loads to update caches early but keeps any replaced line in the Commit victim cache. In case of misspeculation, replaced lines from the BP LD RS BR BP LD RS BR victim cache are used to restore the caches, thereby preventing (a) Redo (InvisiSpec, Select. Delay) (b) Undo (CleanupSpec, ReViCe) any cache-based Spectre and Meltdown attacks. Moreover, Figure 1: After branch prediction (BP), the load (LD) and response (RS) ReViCe injects jitter to conceal any timing difference due to can occur before branch resolution (BR). Both Redo and Undo approaches speculative lines. Together speculation restoration and jitter assume the cache update is safe at the visibility point (VP), which is BR, injection allow ReViCe to make speculative execution secure. but Redo’ing delays the actual update beyond the VP. We present the design of ReViCe following a set of security principles and evaluate its security based on shared-core and cross-core attacks exploiting various Spectre variants and cache high performance overhead, require software modification, side channels. Our scheme incurs 2-6% performance overhead. or are unable to prevent attacks within the same context This is less than the state-of-the-art hardware approaches. or core. As a more efficient approach, InvisiSpec and its Moreover, ReViCe achieves these results with minimal area and Redo Undo energy overhead (0.06% and 0.02% respectively). follow-up works are based on either ’ing or ’ing Keywords—Transient-Execution Attacks, Cache Side-channel the side effects of transient execution in a microarchitectural Attacks, Hardware Mitigation structure (e.g., caches). Both approaches need to ensure that microarchitecture updates are only exposed to outside of the I. INTRODUCTION transient execution at Visibility Point (VP) [29], i.e., when Speculative execution [1]–[10] is integral to the perfor- the instructions cannot be squashed by prior operations. The mance optimization of modern out-of-order CPUs. A CPU Redo approach, as in InvisiSpec [29] and Selective Delay [31] can increase utilization by speculating uncertainties such propose to delay the update of caches after the VP. On the as branching, memory dependency or exception handling. other hand, the Undo approach, as in CleanupSpec [30], Recent Spectre [11] and Meltdown [12] vulnerabilities show applies the updates early but undo them at VP. the danger of combining side channels with speculative The distinction between Redo and Undo causes a signif- execution. Spectre attacks exploit speculative execution that icant difference in performance. Redo suffers higher over- violates the program logic whereas Meltdown attacks bypass heads than Undo as a Redo’ing architecture such as Invi- hardware protections. Attackers can manipulate the CPU siSpec penalizes execution that is confirmed to be safe. The to bypass security checks or jump to malicious gadgets in distinction is demonstrated in Figure 1. Penalizing confirmed order to trigger transient execution, a transient period before execution is counter-intuitive since CPUs are generally op- squashing the execution, that leaks secrets via a side channel. timized for executions where predictions are mostly correct Even more devastating, various speculation can be combined and exceptions are rare. For instance, in PARSEC, at least with different side channels, multiplying the variants of 82% of branches are predicted correctly, and ∼80% of the Spectre and Meltdown [13]–[20]. load instructions become safe without getting squashed. Both Mitigation of Spectre and Meltdown is challenging. Ex- InvisiSpec and Selective Delay procrastinate the update until isting software or firmware-level solutions are ad-hoc and the VP; however, before exposing a cache line after the VP, expensive [21]–[28]. Several recent papers proposed more the CPU needs to reacquire the data from the cache hierarchy systematic hardware-based solutions. For example, InvisiS- to check for potential invalidation from other cores. The de- pec [29] is the first work to offer a solution by isolating cache layed exposure may stall subsequent instructions that depend updates from transient execution. Follow-up works focus on on the cache line. InvisiSpec also increases network traffic reducing the latency and space overhead of recovering from in the cache hierarchy for reacquiring data. InvisiSpec incurs squashed updates [30]–[32]. Other solutions are based on 13% and 16% slowdown to PARSEC [40] for mitigating either disabling speculation for leaky instructions or data Spectre and Meltdown, respectively. access [33]–[37] or blocking side channels between security The Undo approach, as in CleanupSpec [30], incurs a contexts [38], [39]. Existing solutions [33]–[39] either incur lower performance overhead as compared to all other solu- Author’s version. © 2020 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. tions, and thus, can be appealing to CPU vendors. However, • A performance analysis of ReViCe, which shows 2–6% the design of the CleanupSpec has two major security flaws. performance overhead in PARSEC and SPEC (compared First, it can leak secrets to shared-core and cross-core to InivisiSpec, a reduction of up to 15%). attackers. CleanupSpec cannot hide eviction of an L1 cache The rest of the paper is structured as follows: The background line since the data is evicted for real. This allows a shared- and threat model in Section II, main idea of ReViCe in Sec- core attacker to launch an eviction-based attack such as tion III followed by implementation in Section IV. Section V Prime+Probe. Moreover, a cross-core attacker can observe a evaluates ReViCe. The final section concludes the paper. We speculative load in CleanupSpec using invalidation. Second, also provide security analysis of CleanupSpec [30], detailed attacks to cache address randomization of CleanupSpec are operations of ReViCe, and security analysis with proof-of- possible. CleanupSpec adopts CEASER’s [41] scheme to ran- concept in Appendix A, B, and C, respectively. domize a mapping between address and cache sets. Bodduna, et al. [42] shows that the block cipher of CEASER does not II. BACKGROUND AND THREAT MODEL randomize address mappings properly. Randomization does A. Spectre and Meltdown not prevent an attacker from detecting the access of a shared Spectre attacks [11], [13]–[15], [17], [20] exploit CPU cache block by the victim. The security flaws in CleanupSpec speculation (e.g., branch prediction) to execute malicious demonstrated the complexity of implementing the Undo’ing logic which is not allowed in the victim program. The attacks approach. In this paper we focus on re-examining the prin- generally involve mistraining of the predictors to manipulate ciples for Undo’ing scheme to ensure that a low-overhead, the victim. The misspeculated execution then can leak secret secure Undo’ing scheme can be implemented in architecture. information via a microarchitecture side channel, before the This paper presents ReViCe, a microarchitecture that execution is squashed by the CPU. Meltdown attacks [12], safely hides and restores speculative cache updates in both [16], [18], [19] exploit a different type of vulnerabilities, by shared-core and cross-core scenarios. When an instruction violating hardware protection such as page table or system queue issues a load, ReViCe determines if the load is register protection. Meltdown exists due to inherent delay in speculative. If the load is speculative and causes a cache miss, the exception delivery to be handled until retirement of the a new line is brought in to replace an existing line, changing faulty instruction; meanwhile, the faulting instructions can the cache state. The change is safe if the speculation is still obtain protected data during the transient execution. later deemed correct. However, if the speculation is incorrect, an attacker who can observe the change, can infer secrets B. Threat Model and Attack Scenarios from access patterns. To prevent such leakage, the cache We assume a typical threat model for Spectre and Melt- needs to restore any change caused by a misspeculated down [11], [12], [29]. The attacker intends to retrieve secrets load. In ReViCe, we use a victim cache [43] to keep the from a victim program by manipulating CPU speculation in lines replaced by speculative loads. If a load is deemed the victim or bypassing hardware protection enforced by the misspeculated, ReViCe can restore the replaced line from the OS. The attacker has access to the source code of the victim victim cache to its original location. Moreover,

Load more