CacheSquash: Making caches speculation-aware

TL;DR

CacheSquash is a novel mitigation technique that cancels mis-speculated cache accesses immediately upon squashing, effectively thwarting Spectre attacks with minimal performance impact.

Contribution

It introduces a new method to cancel mis-speculated cache requests, reducing cache side-channel risks without significant performance penalties.

Findings

CacheSquash effectively prevents Spectre attacks in simulations.

It achieves near-zero performance overhead.

The method is compatible with existing cache architectures.

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.