Randomizing the mapping of memory addresses to cache locations is a promising approach for protecting computer systems against cache attacks. Multiple randomized caches have been proposed recently, with the aim of preventing adversaries from creating eviction sets - collections of addresses that compete with target memory addresses on cache space. However, Purnal et al. (IEEE SP 2021) demonstrated the Prime+ Prune+ Probeattack, which allows attackers to efficiently build generalized eviction sets, enabling target memory address eviction with a high probability. As the complexity of constructing eviction set is a key factor in randomized cache design, the Prime+prune+probe attack significantly reduces the security bounds of these randomizing designs. Since the Prime+prune+probe attack is probabilistic, generalized eviction sets often get stuck after repeated use, making them ineffective for typical cache attack settings. Prior works have noticed this behavior and proposed mitigation approaches. These approaches are based on evicting members of the eviction set from the cache, either probabilistically, using random memory accesses, or directly, using dedicated flush instructions. However, these proposals do not analyze the effectiveness of the techniques or evaluate their success. In this work we revisit Prime+prune+probe and analyze it in light of the possibility of eviction sets getting stuck. We observe that flushing does not behave as anticipated in realistic cache architectures, where invalid cache lines are filled first before evicting other lines. We further propose a new technique for allowing repeated attacks - combining random noise with flushing. We conduct an in-depth analysis of all discussed techniques and compare their complexity attacking an AES T-table implementation. We find that combining probabilistic eviction with flushing outperforms the traditional approaches by a factor of two, allowing attackers to increase the granularity and observe victim processes even better than in prior works.

The Spectre attack revealed a critical security threat posed by speculative execution and since then numerous related attacks have been discovered and exploited to leak secrets across process boundaries. As the primary cause of the attack is deeply rooted in the microarchitectural processor design, mitigating speculative execution attacks with minimal impact on performance is far from straightforward. For example, various countermeasures have been proposed to limit speculative execution for certain instruction patterns, however, resulting in severe performance overheads. In this paper, we propose a set of code transformations to reduce the number of speculatively executed instructions and therefore significantly reduce the performance overhead of various countermeasures. We evaluate our code transformations combined with a hardware-based countermeasure in gem5. Our results demonstrate that our code transformations speed up the secure system by up to 16.6%.