In-DRAM Rowhammer mitigation requires three resources: space (to track aggressor rows), time (to perform mitigation), and energy (to refresh victim rows). An ideal in-DRAM mitigation must minimize all three overheads. Recent randomized trackers, such as MINT, can perform tracking with negligible storage overheads. However, they perform mitigation proactively and frequently, which incurs significant performance and energy overheads at low thresholds. Recently, JEDEC introduced Per-Row Activation Counters (PRAC) and ALERT Back Off (ABO) protocol to obtain the time for mitigation reactively, as needed. While PRAC+ABO minimizes the time and energy overheads of mitigation, PRAC incurs significant changes to the DRAM array and significant performance overhead (6.5% on average) due to increased memory timings to update the PRAC counters. Our goal is to develop an efficient in-DRAM mitigation that has low storage, performance, and energy overheads. Our paper proposes MIRZA, the first low-cost reactive in-DRAM mitigation. MIRZA relies on MINT to track aggressor rows. However, instead of proactively doing mitigation at regular intervals (via REF or RFM), MIRZA uses ABO to reactively obtain the time required for mitigation. To avoid frequent ABO, MIRZA employs Coarse-Grained Filtering to disable mitigations if the activation count is below a certain Filtering Threshold. To tolerate a threshold of 1K, MIRZA requires a storage overhead of only 196 bytes of SRAM per bank. Compared to MINT, MIRZA reduces the mitigation overheads by 28.5×. Compared to PRAC, MIRZA has 45× lower area overheads and negligible slowdown (0.36% average slowdown vs. 6.5% for PRAC).

This paper focuses on Memory-Controller (MC) side Rowhammer mitigation.MC-side mitigation consists of two parts: First, a tracker to identify the aggressor rows.Second, a command to let the MC inform the DRAM chip to perform victim-refresh for the specified aggressor row.To facilitate this, prior works assumed a per-bank Nearby Row Refresh (NRR) command.However, JEDEC standards did not support NRR.Instead, JEDEC introduced Directed Refresh Management (DRFM), which can simultaneously perform mitigations for one row each in 8 (DRFMsb) or 32 (DRFMab) banks.As DRFM stalls 8-32 banks, it incurs high overheads.For example, at a threshold of 2K, PARA incurs a slowdown of 3.9% with NRR, 12.7% with DRFMsb, and 49% with DRFMab.Although counter-based trackers can avoid these slowdowns, they require significant storage.The goal of our paper is to reduce the performance and storage overheads of MC-based mitigations by using properties of DRFM.Our paper proposes DREAM, DRFM-Aware Rowhammer Mitigation.We propose two variants of DREAM.Our first design, DREAM-R, reduces the performance overhead of randomized trackers by increasing the time between sampling the row and issuing a DRFM.The delay allows other banks the time to sample their own rows, thereby increasing the number of rows mitigated under a single DRFM.DREAM-R reduces the average performance overhead of PARA from 12.7% (DRFMsb) to 4.24% and MINT from 15.9% (DRFMsb) to 2.1%.We bound the impact of delayed DRFM on the tolerated Rowhammer threshold.Our second design DREAM-C, reduces the storage for counter-based trackers by leveraging the fact that DRFM can concurrently mitigate several rows.DREAM-C forms a gang containing 32-256 rows, randomly selected equally from all the 32 banks, and allocates a single counter for the entire gang.DREAM-C reduces the storage required at a threshold of 500 to only 1KB/bank, which is 8x lower than Graphene while avoiding the complexity of CAM lookups and incurring negligible slowdown.We also show that DREAM compares favorably to PRAC. CCS Concepts• Security and privacy → Security in hardware.