Spatial Blacklist Mechanism

• Spatial blacklist mechanism is a memory controller-based solution that uses dual counting Bloom filters and an activation history buffer to enforce safe activation thresholds in DRAM.
• It leverages sliding window tracking of row activations to ensure no row exceeds the RowHammer limit within a refresh interval while maintaining low performance overhead.
• Empirical evaluations demonstrate minimal performance penalties on benign workloads and deterministic protection against RowHammer compared to probabilistic alternatives.

A spatial blacklist mechanism is a memory controller-based approach for preventing RowHammer-induced bit-flips in DRAM devices by selectively throttling accesses to rapidly-activated rows. The state-of-the-art implementation, exemplified by BlockHammer, deploys area-efficient dual counting Bloom filters and an activation history buffer to ensure no individual row is activated more than a set safe threshold in any DRAM refresh interval. This mechanism is hardware-agnostic, incurs minimal performance and energy penalty for benign workloads, and provides deterministic immunity to both known and new RowHammer attack patterns (Yağlıkçı et al., 2021).

1. Architectural Principles and Data Structures

Spatial blacklist mechanisms, as implemented in BlockHammer, reside entirely in the off-chip memory controller. The memory controller intercepts every DRAM row-activation (ACT) command and uses a module termed "RowBlocker" to determine whether issuing the command would violate RowHammer safety.

RowBlocker consists of two core per-rank (and per-bank) structures:

• Dual Counting Bloom Filters (D-CBF): These are used to track, approximately but efficiently, the rate of per-row activations over a rolling time window. Each D-CBF is a pair of counting Bloom filters (CBF₀, CBF₁) designed to facilitate sliding window semantics with minimal area and performance cost.
• Activation History Buffer (RowBlocker-HB): A small, content-addressable FIFO maintaining the short-term activation history of any row currently blacklisted. Its purpose is to guarantee a minimum delay between successive activations of the same row once it is flagged.

The architectural flow is such that before an ACT command is issued, RowBlocker checks, in parallel, the D-CBF for blacklisting status and RowBlocker-HB for recent activations. Only if a row is not simultaneously blacklisted and recently activated is the command forwarded to DRAM.

2. Counting Bloom Filters and Blacklisting Semantics

The counting Bloom filter operates as a compact set of $m$ counters indexed by $k$ independent hash functions. For each row activation, the row address is inserted into all hash-derived locations in both filters. The per-row approximate count is given by the minimum of all $k$ corresponding counters. This approach yields no false negatives (no row with actual activation count ≥ threshold is missed), though false positives can occur due to aliasing.

To provide sliding-window coverage for the DRAM refresh interval (e.g., $t_{\mathrm{REFW}} = 64\,\mathrm{ms}$), BlockHammer interleaves two CBFs: one active (serving queries), one passive. On each activation, both filters are updated. At each epoch boundary (E = 0.5·CBF-lifetime), the active filter is cleared, and the filters swap roles. Thus, any activation within the most recent two epochs remains tracked, never undercounted within the window.

Empirical parameters for false-positive control are $m=1024$ counters per CBF per bank and $k=4$ hash functions, ensuring a false-positive rate $P_{\mathrm{fp}} < 0.01\%$ for realistic workloads. This minimization is critical to avoid undue throttling of benign applications.

3. Blacklisting Policy and Threshold Mechanism

Blacklisting policy is tightly coupled to the DRAM device’s certified RowHammer threshold ($RH$)—the maximum allowable activations of a row per refresh window that do not cause adjacent cell bit-flips. The principal parameters and relations are:

• $t_{\mathrm{REFW}}$: DRAM refresh window (e.g., 64 ms)
• $RH$: RowHammer threshold (e.g., 32 K activations)
• $BL$: Blacklisting threshold ($BL < RH$; e.g., 8 K)
• $E$: Bloom filter epoch length ($E = t_{\mathrm{REFW}}$)
• $RC$: Minimum activate-to-activate interval for the DRAM bank (e.g., 46.25 ns)

A row is blacklisted as soon as its count in the active D-CBF reaches $BL$. For as long as count$(r) \geq BL$ in at least one D-CBF, the row remains blacklisted. Upon filter reset at epoch boundary, blacklisting persists if the threshold is still exceeded in the remaining filter.

To guarantee that no row exceeds $RH$ activations in $t_{\mathrm{REFW}}$, BlockHammer enforces a minimum delay, $\Delta$, between successive activations of a blacklisted row, calculated as:

$$\Delta = \frac{E - (BL\cdot RC)}{(E/t_{\mathrm{REFW}})\cdot RH - BL}$$

This ensures no adversarial access pattern can manipulate counts across epochs to violate the upper bound.

4. Algorithmic Operation and Pseudocode

The workflow is governed by cycle-driven updates and per-access safety checks:

1. Epoch Tick: At each epoch boundary, the active CBF is cleared, and filter roles swap.
2. Activation Check: For each requested ACT command, the controller checks (i) if the row is blacklisted (D-CBF count $≥ BL$), and (ii) if it was recently activated ($<\Delta$) using the RowBlocker-HB.
3. Command Delay/Issuance: If both checks are positive, ACT is delayed until it becomes safe; otherwise, it proceeds.
4. Tracking Update: Upon ACT issuance, D-CBF and RowBlocker-HB are updated accordingly.
5. History Buffer Housekeeping: Entries older than $\Delta$ in RowBlocker-HB are invalidated.

The pseudocode provided in the source block summarizes this logic (Yağlıkçı et al., 2021).

5. Performance, Security, and Comparative Evaluation

Evaluation using the Ramulator simulator and detailed DRAMPower models on SPEC, YCSB, and synthetic attack workloads shows:

• Benign Workloads: <0.7% performance overhead; DRAM energy remains within ±0.6% of baseline.
• Under Attack: Weighted speedup for benign workloads increases by an average 45% (up to 61.9%), DRAM energy drops by 28.9% (up to 33.8%) versus baseline.
• False Positives: D-CBF false positive rates are empirically <0.01% with current parameters; smaller CBFs increase penalties due to higher aliasing.
• Worst-case penalties: Delay $\Delta$ can peak at 7.7 µs (for $BL=8$K, $RC=46$ ns, $t_{\mathrm{REFW}}=64$ ms). Median/90th percentile delays in mistakenly throttled benign accesses are 1.7/3.9 µs, well below typical QoS requirements (1 ms).

Competing mechanisms such as PARA incur higher performance losses with probabilistic safety, and TWiCe, though area-efficient at baseline, becomes costly at low $RH$ and cannot throttle bandwidth under attack, causing harsher impacts on benign workloads.

Mechanism	No-Attack Perf Cost	Under Attack: Perf	Security Guarantee
BlockHammer	<0.7%	+45.0% (benign)	Deterministic
PARA	1–2%	No improvement	Probabilistic
TWiCe	0%*	Benign suffer	Probabilistic

*with high area/energy at lower $RH$

A plausible implication is that the spatial blacklist approach is particularly attractive for commercial deployments that require strong, DRAM-agnostic RowHammer protection with minimal disruption to existing code.

6. Design Trade-offs and Limitations

Key dimensions:

• Bloom Filter Sizing: Increasing the number of counters ($m$) and hash functions ($k$) reduces false positives but increases area.
• Threshold Selection ($BL$): Must be set below $RH$ (for safety), but high enough above the 99th percentile of benign activation rates (e.g., $\approx314$/64ms in studies) to avoid benign throttling.
• Delay Penalty ($\Delta$): Tighter security (lower $BL$) raises delay for blacklisted rows but is two orders of magnitude below common tail-latency targets in tested workloads.
• Scalability: Ultra-low $RH$ requirements (sub-1K) necessitate larger CBF and HB sizes, increasing marginal area/energy utilization, but empirical results indicate this overhead remains below that of existing alternatives.

This suggests spatial blacklisting is tunable to targeted DRAM vulnerabilities but must be carefully provisioned in high-contention environments or for emerging ultra-dense DRAM variants.

7. Context, Significance, and Future Directions

Spatial blacklist mechanisms—as realized in BlockHammer—demonstrate that deterministic RowHammer protection is feasible without DRAM vendor cooperation or microarchitectural modification. The approach is robust even against newly-devised attack strategies, integrating smoothly with memory controller logic and scaling to multiprogrammed, memory-intensive environments (Yağlıkçı et al., 2021).

Open research questions include adaptation to future memory protocols with variable refresh rates, hardware support for even larger sliding windows, and integration with system-level threat monitoring. A plausible implication is that, as DRAM densities continue to increase, the area/performance efficiency of spatial blacklists may further distinguish them from reactive refresh and probabilistic neighbor-refresh schemes.