MIRAGE: A Randomized Cache Architecture
- MIRAGE is a randomized last-level cache that decouples tag placement from data replacement to provide a fully associative security abstraction using global random eviction.
- Its architecture leverages a keyed block cipher and skewed-associative tag store with extra invalid entries to eliminate set conflicts and mitigate Prime+Probe style attacks.
- Performance studies report modest latency and storage overheads, while later analyses debate its vulnerability to occupancy-based covert channels and AES key recovery risks.
Searching arXiv for MIRAGE randomized cache and follow-up analyses. MIRAGE is a randomized last-level cache design intended to provide the security abstraction of a fully associative cache while retaining practical set-indexed lookup. Its defining mechanism is the decoupling of tag placement from data replacement: addresses are randomized through a keyed block cipher, tags are placed in a skewed-associative tag store with extra invalid entries, and every cache fill is intended to evict a uniformly random resident data line from the entire cache rather than from a small conflicting set. The design was introduced as a defense against conflict-based side-channel attacks, especially Prime+Probe and related eviction-set methods, by attempting to eliminate meaningful set conflicts altogether (Saileshwar et al., 2020).
1. Origins, security objective, and design rationale
MIRAGE was proposed in the context of shared processor caches, where conventional set-associative LLCs enable conflict-based side channels because each address maps to exactly one set and replacement is confined to a small group of ways. Earlier randomized designs, including CEASER and Scatter-Cache, randomized indexing but still selected victims from relatively small conflicting subsets, which left residual avenues for eviction-set discovery and conflict-based attacks. MIRAGE’s stated security goal is stronger: every miss should induce a “Global Eviction,” meaning eviction of a uniformly random line from the entire cache, so that no subset of lines constitutes a useful eviction set (Saileshwar et al., 2020).
The original paper characterizes this as a practical fully-associative design. The central claim is that MIRAGE achieves the security of a fully associative cache with random replacement while avoiding the lookup cost of a naive CAM-like implementation. To do so, it uses a set-partitioned tag organization but a globally randomized data replacement mechanism, thereby separating placement from replacement. The same work reports that violations of full associativity, interpreted as set-conflicts, occur less than once in to years depending on the configuration, and that the design incurs limited slowdown and extra storage relative to a non-secure cache (Saileshwar et al., 2020).
A recurrent distinction in the later literature is between conflict-based leakage and occupancy-based leakage. MIRAGE was explicitly designed to defeat the former. Subsequent papers agree that this is the relevant design center, but disagree sharply on whether the same mechanisms also introduce exploitable occupancy side channels.
2. Core architecture and access path
At a high level, MIRAGE splits the LLC into a tag store and a data store. In the original formulation, the data store is a single array of cache lines, while the tag store is organized as two independent skews. Each tag entry contains metadata and a forward pointer into the data store, while each data entry contains a reverse pointer back to the corresponding tag entry. This indirection is the key architectural device that allows a line installed in one tag-set location to point to an arbitrarily chosen data-store slot (Saileshwar et al., 2020).
Incoming physical addresses are randomized by a keyed block cipher. In one description, two independent block ciphers, such as PRESENT or PRINCE, are applied to a 64-bit physical address to derive one set in each skew; in another, AES-128 or PRINCE-64 is used as the randomizing function. The low-order index bits of the cipher output define the set index, and the cryptographic uniformity of the cipher is treated as the basis for modeling the mapping as a random hash over sets (Chakraborty et al., 2023).
On lookup, both candidate sets are probed in parallel, and a hit yields the forward pointer used to access the data store. On a miss, MIRAGE chooses between the candidate sets using a load-aware or occupancy-aware policy. If an invalid tag entry is available in the chosen set, the incoming line uses that tag entry. A global eviction then selects one resident data-store line uniformly at random, invalidates the corresponding tag through the reverse pointer, and reuses the freed data slot for the new line. This is the mechanism by which MIRAGE attempts to decouple the incoming address from the identity of the victim line (Saileshwar et al., 2020).
A later evaluation summarizes a reference configuration as a 16 MB LLC with 131 K lines, two skews, and tag-store associativity of $8$ ways in one skew and $6$ ways in the other, with a fully associative data store managed via random replacement. That account emphasizes an operational detail: on every miss—regardless of whether the tag store entry is invalid or the set is full—the implementation evicts one uniformly random line from the entire data store and invalidates its tag, and in practice invalid entries are quickly exhausted so that nearly all replacements become global evictions (Chakraborty et al., 2023).
3. Probabilistic model, extra invalid tags, and the dispute over conflict misses
The original MIRAGE analysis models tag occupancy using a bucket-and-ball abstraction. Buckets correspond to tag-store sets and balls correspond to inserted lines. Under uniform random placement and a birth–death approximation, the paper argues that with power-of-two choices and extra ways, the probability of a set ever overflowing decays super-exponentially. For one representative parameterization, a detailed analysis with extra ways leads to the claim that the probability any bucket overflows is less than , which underlies MIRAGE’s security argument against conflict-based side channels (Saileshwar et al., 2020).
This analysis was challenged in a short note that argues the original bucket-and-ball model contains two fallacies. First, it is said to ignore the extra invalid tags actually provisioned per set: a true set-associative collision would require filling all ways in at least one set, not merely crossing from to . Second, the note argues that the symmetry assumptions of the birth–death chain do not model an attacker who can bias insertions toward the same sibling-set pair. In that critique, the correct quantity is the probability of an -way multi-collision in a given bucket pair, which is claimed to be negligibly small for realistic 0, and corrected simulations are reported to show no 12-way collisions even after more than 1 throws (Chakraborty et al., 2023).
A related rebuttal to the HPCA 2023 paper makes a different but complementary argument. It attributes the reported conflict misses to two faulty assumptions: an invalid initial cache state in which tags begin valid with probability 2, causing some sets to start full, and a buggy implementation of the PRESENT cipher that yields highly non-uniform set-index distributions. After correcting the initial state and using AES or PRINCE, that paper reports no conflict miss observed in 3 billion insertions at 4 and standard deviation of set occupancies consistent with the uniform-hash model rather than the skewed distribution seen with the buggy cipher (Saileshwar et al., 2023).
Taken together, these exchanges establish a relatively narrow point of agreement. MIRAGE’s claims against classic conflict-based eviction-set attacks depend critically on proper initialization, uniform cryptographic indexing, and faithful modeling of the extra invalid tags and two-choice placement. Within that scope, the later debate has centered less on whether MIRAGE preserves its intended conflict-miss behavior under correct modeling than on whether the same architecture leaks via occupancy.
4. Performance model and implementation costs
The original evaluation reports an 8-core in-order x86 system with a private L1 and L2 hierarchy and a shared 16 MB, 16-way LLC. In that setup, MIRAGE increases LLC lookup latency from 24 cycles to 28 cycles, attributed to two PRINCE computations and one extra cycle for pointer indirection. Over 58 workloads, the reported normalized weighted-speedup is 5, corresponding to a 2.0% slowdown. Storage overhead is reported as 17–20% extra relative to a non-secure cache, depending on the configuration, and the total LLC size increases from 17.28 MB to 20.80 MB in one tabulated design point (Saileshwar et al., 2020).
A later systematic evaluation revisits the performance picture and argues that contemporary benchmarking strategies for randomized caches are not directly comparable because of differing cache configurations, benchmark suites, and implementation-specific assumptions. It proposes a uniform benchmarking strategy and reexamines MIRAGE alongside CEASER, CEASER-S, Scatter-Cache, and Sass-cache. In that account, the original gem5 study reported average IPC overhead below 5%, typical L2 miss-rate increases of 1–2%, and added cache-access latency of roughly 1–3 cycles for ScatterCache and MIRAGE. However, the same work argues that an artifact-evaluated gem5 implementation contained a “Scenario-A” that behaved as a software-managed fully-associative fill until a vacant-slot queue emptied, so many workloads did not experience the advertised global-eviction cost. After a short “cache massaging” warm-up that exhausts invalid tags, MIRAGE’s true random replacement is reported to have a larger IPC and miss-rate penalty, exceeding that of both the baseline and ScatterCache (Chakraborty et al., 2023).
These performance results suggest a bifurcation between the idealized design point and the realized simulator behavior. The original paper emphasizes modest latency and storage costs for a principled security gain. Later work argues that faithful steady-state evaluation must account for the behavior after invalid tags are exhausted and global evictions dominate. A plausible implication is that MIRAGE’s practical cost depends strongly on whether the implementation spends substantial time in a pre-global-eviction regime.
5. Occupancy side channels, covert communication, and fingerprinting
The main post-2023 shift in the MIRAGE literature is the move from conflict-based security to occupancy-based security. One short note argues that MIRAGE’s global eviction policy leaks the total amount of victim cache activity even when set-conflict attacks remain infeasible. The attack occupies only a small fraction of the cache, then observes how many of the attacker’s resident lines are evicted during victim execution. In the simulator described there, an attacker initially fills 10,000 lines in a 131,072-line data store, retains about 9,600 valid lines after its own accesses, and then uses post-victim miss counts as a noisy estimator of victim insertions. For 6 victim accesses, the reported miss count is approximately 450; for 7, approximately 750. The same work extends this mechanism to a 1-bit covert channel with threshold decoding near 600 misses and reports idealized bandwidth near 2.5 Mb/s with bit error below 2% in simulation, as well as template-based workload fingerprinting with false positives under 5% for neighboring templates spaced by at least 1,000 accesses (Chakraborty et al., 2023).
A broader systematic study generalizes this argument across randomized cache designs and treats cache occupancy as a distinct attack surface. In that evaluation, MIRAGE is said to amplify occupancy attacks because compulsory global eviction on each miss provides a direct coupling between victim insertions and attacker losses. Relative to a baseline cache and ScatterCache, MIRAGE reportedly requires only about 10% LLC occupancy, with 8 K lines, to obtain an error-free 1-bit covert channel. The same work describes byte-level channels in which mappings from 9 K through $8$0 K victim accesses generate non-overlapping miss distributions and thus enable 3 bits per interval, and it reports that eight SPEC2017 programs produce clearly separated cross-core fingerprints when the attacker occupies only 10% of the cache after artifact-corrected cache massaging (Chakraborty et al., 2023).
The security interpretation of these results is comparatively stable across occupancy-focused work. MIRAGE’s extra-way provisioning and random tag mapping are treated as effective against classic eviction-set construction, but the compulsory or near-compulsory global eviction policy is viewed as a leakage source at a coarser granularity: not which set the victim accessed, but how much new cache occupancy the victim generated. This distinction is central to later critiques and proposed mitigations.
6. AES key-recovery claims, modeling disputes, and later addenda
The most contentious later question is whether occupancy leakage in MIRAGE extends beyond covert channels and fingerprinting to AES key recovery. An addendum to the systematic evaluation states that the original USENIX Security 2025 work considered three threat assumptions—covert channels, process fingerprinting, and AES key recovery—and reports that under original MIRAGE, guessing entropy of the correct AES key reduces from 128 to at most 32 within $8$1 traces, with $8$2 for approximately 150k traces. The same addendum evaluates a patched variant, MIRAGE$8$3, which re-seeds the global eviction map $8$4 with fresh randomness at each power-on or cache flush. It reports that the amortized performance overhead of reseeding is negligible, but that a Welch’s t-test on timing traces still yields $8$5 and $8$6, so the null hypothesis of indistinguishability is rejected and leakage remains measurable (Chakraborty et al., 19 Oct 2025).
That addendum argues that static per-boot randomization is insufficient because all encryptions in a session still share the same global eviction map, leaving temporal correlations intact. Its proposed design lessons therefore emphasize elimination of shared LLC contention, fine-grained randomization, and uniform benchmarking methodology rather than one-time reseeding (Chakraborty et al., 19 Oct 2025).
A direct rebuttal contests this conclusion and attributes the reported AES leakage to flawed simulation methodology. According to that paper, the occupancy-based AES attack used a constant seed to initialize the random number generator before each encryption, forcing every encryption to evict the same deterministic sequence of cache lines. Under this model, the reported profiler-versus-victim heatmaps show average Pearson correlation around 0.72 and the correct key appears recoverable. When the seed is randomized realistically, however, the paper reports that correlation drops to at most 0.03, probe-time distributions for different ciphertext-dependent accesses broadly overlap with noise on the order of $8$7 K cycles, and guessing entropy remains above 90% in all tested configurations, including both 512 B and 64 KB L1 settings (Cao et al., 14 Aug 2025).
The resulting controversy is not about MIRAGE’s basic architecture but about faithful modeling of its randomness. One line of work holds that occupancy channels are intrinsic to any shared resource and that MIRAGE remains vulnerable even after patching. The opposing line holds that realistic eviction randomness overwhelms the signal needed for AES key recovery, so the reported leakage is an artifact of replayed or attacker-influenced RNG state. This suggests that the literature distinguishes between low-bandwidth occupancy effects that are broadly acknowledged and strong cryptanalytic claims that remain disputed.
7. Appraisal, limitations, and mitigation directions
Across the literature, MIRAGE’s principal strength is consistently framed as resilience to eviction-set creation. Its cryptographic address randomization, skewed tag-store organization, extra invalid tags, and global data-store replacement are repeatedly described as mechanisms that suppress or render vanishingly improbable the set-conflict events required by classic Prime+Probe-style attacks (Saileshwar et al., 2020).
The principal limitation identified in later work is the same mechanism’s interaction with occupancy. If every miss forces or nearly forces a global eviction, then the attacker’s own eviction count can act as a proxy for victim insertion volume. This is the basis of the covert-channel, fingerprinting, and disputed AES-key-recovery analyses. Proposed mitigation directions in the occupancy-focused papers include avoiding unconditional eviction on every insert by switching to on-demand eviction, introducing noise through dummy accesses or randomized delays, partitioning the data store, throttling cross-process eviction rates, combining randomized indexing with process-exclusive partitions, and exploring hybrid local-versus-global replacement policies (Chakraborty et al., 2023).
The open problem, as stated in the later evaluations, is to design a randomized cache with efficiency comparable to modern set-associative LLCs while resisting both contention-based and occupancy-based attacks. MIRAGE occupies an important position in that agenda because it cleanly demonstrates the trade-off: a cache can be made highly resistant to conflict-based leakage by approximating full associativity through global random eviction, but doing so may expose, or appear to expose, higher-level occupancy channels unless contention itself is eliminated or randomized at a finer temporal granularity (Chakraborty et al., 2023).
