CacheSquash: Making caches speculation-aware

TL;DR

CacheSquash addresses Spectre-style cache-timing leaks by making the cache hierarchy speculation-aware through immediate cancellations of mis-speculated read requests. Implemented in gem5 with classic caches and evaluated on SPEC CPU 2017 and PARSEC, it achieves near-zero overhead while significantly reducing leakage in case studies including Spectre PHT and ret2spec. The approach relies on minimal hardware changes to the load-store unit and miss-handling circuitry, and is ISA-agnostic and software-compatible. While it shows strong protection in typical scenarios, the authors discuss limitations such as certain windowing gadgets and speculative-interference attacks, outlining directions like cancellation broadcasts and memory-bus cancellation for broader security.

Abstract

Speculation is key to achieving high CPU performance, yet it enables risks like Spectre attacks which remain a significant challenge to mitigate without incurring substantial performance overheads. These attacks typically unfold in three stages: access, transmit, and receive. Typically, they exploit a cache timing side channel during the transmit and receive phases: speculatively accessing sensitive data (access), altering cache state (transmit), and then utilizing a cache timing attack (e.g., Flush+Reload) to extract the secret (receive). Our key observation is that Spectre attacks only require the transmit instruction to execute and dispatch a request to the cache hierarchy. It need not complete before a misprediction is detected (and mis-speculated instructions squashed) because responses from memory that arrive at the cache after squashing still alter cache state. We propose a novel mitigation, CacheSquash, that cancels mis-speculated memory accesses. Immediately upon squashing, a cancellation is sent to the cache hierarchy, propagating downstream and preventing any changes to caches that have not yet received a response. This minimizes cache state changes, thereby reducing the likelihood of Spectre attacks succeeding. We implement CacheSquash on gem5 and show that it thwarts practical Spectre attacks, with near-zero performance overheads.

Figures (8)

• Figure 1: The solid black activation bar (for core) represents the speculation window. The hollow activation bars (for caches) represent lifetimes of the requests' . The hollow activation bar (for DRAM) represents the memory-only access latency.
• Figure 2: CacheSquash flow chart.
• Figure 3: spectre_v1_pht_sa x86 assembly extract.
• Figure 4: events for transmit instructions of all Spectre attack instances from Experiment 1. Each row represents a single attack, the y-axis showing the attack number. All event times are relative to speculation start: for each attack, events are shifted to make speculation start at t=0.
• Figure 5: events for access instructions of Spectre attacks #1--31 from Experiment 2. Attacks #32-102 are not shown. Note the break in the x-axis. Cancellations have the same latency as regular requests. Typically, cancellations reach both L1 and L2 caches before a response is received. The secret is thus almost never cached in a Spectre attack.