Memory Band-Aid: A Principled Rowhammer Defense-in-Depth

mering [2] . At the same time, both the research community and industry have investigated ways to mitigate these attacks. The focus of industry research on Rowhammer mitigations was mainly on mitigations in hardware. A central reason is that hardware-level mitigations can be self-contained within the DRAM module or involve only the DRAM module and the memory controller. Hence, a DRAM vendor can, without coordinating with software vendors or releasing software themselves, deploy a hardware-level mitigation in a new DRAM chip generation, transparent to the remainder of the system. Furthermore, hardware mitigation can be very efficient: Rowhammer access pattern detection can be implemented directly in hardware and when necessary, the hardware, in particular the DRAM module and the memory controller, can very quickly take action (e.g., refresh victim rows within a few nanoseconds) [1], [3] . However, hardware-level mitigation mechanisms suffer from two shortcomings. First, they do not apply to already deployed systems and require a long time to be implemented in commodity systems as they require changes in the hardware. Second, hardware-level mitigations can fundamentally become stale as (1) newer DRAM chips get more vulnerable to Rowhammer [4], (2) new aspects of the Rowhammer phenomenon are discovered [5], and (3) new attacks are developed [6]-[10]. Researchers repeatedly refined their attacks to bypass the hardware mitigations deployed to secure DRAM. An early mitigation was to increase the refresh rate [1]. However, this approach significantly reduces the performance, increases power consumption, and does not prevent Rowhammer attacks [1] . ECC RAM is also not suitable for defending against Rowhammer attacks since it can only correct a single bit per word. Cojocar et al. [11] demonstrated a reliable Rowhammer attack against ECC DIMMs. For DDR4, the industry developed Target Row Refresh (TRR), which tracks DRAM accesses and refreshes potential victim rows. Several studies [6], [7], [10], [12], [13] found ways to bypass TRR using more advanced hammering patterns. Even on systems with Per-Row Activation Counting (PRAC), a hardware mitigation defined in the DDR5 specification, Jattke et al. [14] observed bit flips. Thus, some commodity systems remain vulnerable to Rowhammer attacks, requiring mitigations beyond the existing hardware solutions. In this paper, we present Memory Band-Aid, a principled software-level defense-in-depth against Rowhammer, requiring Abstract-Rowhammer bit flips i n D RAM e nable s oftware attackers to fully compromise a great variety of systems. Hardware mitigations can be precise and efficient, but they suffer from long deployment cycles and very limited or no update capabilities. Consequently, refined a ttack m ethods h ave r epeatedly bypassed deployed hardware protections, leaving commodity systems vulnerable to Rowhammer attacks. In this paper, we present Memory Band-Aid, a principled defense-in-depth against Rowhammer. Memory Band-Aid is no replacement for long-term, efficient h ardware m itigations, but instead a defense-in-depth that is activated when hardware mitigations are insufficient f or a s pecific sy stem ge neration. For this purpose, Memory Band-Aid introduces per-thread and perbank rate limits for DRAM accesses in the memory controller, ensuring that the minimum number of row activations for Rowhammer bit flips cannot be reached. We implement a proofof-concept of Memory Band-Aid on Ubuntu Linux and test it on 2 Intel and 2 AMD systems, building on global bandwidth limits due to the lack of per-bank limits in current hardware. Using this PoC, we find t hat a f ull i mplementation i ncluding minor hardware changes would have a low overhead of 0 % to 9.4 % on a collection of realistic Phoronix macro-benchmarks. In a micro-benchmark to cause DRAM pressure, we observe a slowdown by a factor of 1 to 5.1. Both overheads only apply to untrusted, throttled workloads, e.g., all userspace programs or only selected sandboxes, such as those in browsers. Especially as Memory Band-Aid can be enabled on demand, we conclude that Memory Band-Aid is an important defense-in-depth that should be deployed in practice as a second defense layer.