Stop! Hammer time

Abstract

Rowhammer attacks exploit electromagnetic interference among nearby DRAM cells to flip bits, corrupting data and altering system behavior. Unfortunately, DRAM vendors have opted for a blackbox approach to preventing these bit flips, exposing little information about in-DRAM mitigations. Despite vendor claims that their mitigations prevent Rowhammer, recent work bypasses these defenses to corrupt data. Further work shows that the Rowhammer problem is actually worsening in emerging DRAM and posits that system-level support is needed to produce adaptable and scalable defenses. Accordingly, we argue that the systems community can and must drive a fundamental change in Rowhammer mitigation techniques. In the short term, cloud providers and CPU vendors must work together to supplement limited in-DRAM mitigations-ill-equipped to handle rising susceptibilitywith their own mitigations. We propose novel hardware primitives in the CPU's integrated memory controller that would enable a variety of efficient software defenses, offering flexible safeguards against future attacks. In the long term, we assert that major consumers of DRAM must persuade DRAM vendors to provide precise information on their defenses, limitations, and necessary supplemental solutions. CCS CONCEPTS• Security and privacy → Systems security; Security in hardware.

Bit-Exact ECC Recovery (BEER): Determining DRAM On-Die ECC Functions by Exploiting DRAM Data Retention Characteristics

“…Unfortunately, similar to efforts that improve DRAM access latency and refresh timings discussed in Sections 4.2.2 and 4.1.2, deploying these methods in practice is impractical for most consumers. These observations are consistent with prior works [45,46,231] that discuss the difficulty in practically determining and relying on this information without support from DRAM manufacturers.…”

“…Although stronger in-DRAM error mitigations are effective against growing error rates [142,224], they introduce new overheads and challenges for consumers. For example, neither on-die ECC nor target row refresh correct all errors, and the remaining errors (e.g., uncorrectable errors) are difficult for consumers to predict and mitigate because their manifestation depends on the particular on-die ECC and/or TRR mechanism used by a given chip [23,32,38,40,41,46,115,152,229,231]. As a result, DRAM consumers face errors that are growing in both magnitude and complexity, making reliability a key design concern for continued DRAM scaling.…”

“…Maximum number of rows affected by hammering one or more row(s) [28,29,107,231,300,396] HC first or RowHammer Threshold Minimum number of RowHammer accesses required to induce bit-flips [28,29,107,118,306] Table 4: Examples of key test results and error models from prior works that study and/or optimize commodity DRAM.…”

An Experimental Analysis of RowHammer in HBM2 DRAM Chips

“…Key Problem. Many prior works (e.g., [1,98,102,106,107,110,112,116,117,125,134,135]) propose using a set of counters to track the activation counts of potential aggressor rows (counter-based mechanisms). Using counters to determine rows that reach close to RowHammer thresholds and taking mitigating actions accordingly can prevent RowHammer bitflips at low performance and energy overheads.…”