Yukthi Opus: BlockHammer DRAM Protection

• Yukthi Opus (YO) is a framework that applies BlockHammer’s deterministic RowHammer mitigation via proactive throttling of high-frequency DRAM row activations.
• It employs dual time-interleaved counting Bloom filters and a row activation history buffer to track and delay excessive activations without altering DRAM internals.
• Empirical findings show that the mechanism maintains negligible performance/energy overhead under normal conditions while significantly mitigating attack-induced bit-flips.

Yukthi Opus (YO) is not directly addressed in the referenced material. However, the encyclopedia entry below synthesizes all foundational, factual, and methodological aspects present in (Yağlıkçı et al., 2021) regarding the BlockHammer mechanism and its spatial blacklist (RowBlocker-BL), providing comprehensive technical coverage appropriate for the specified audience.

BlockHammer’s spatial blacklist (“RowBlocker-BL”) is an architectural mechanism designed for deterministic, low-cost prevention of RowHammer-induced bit-flips on commodity DRAM, without requiring modifications to DRAM internals or proprietary device knowledge. The core principle is proactive throttling of “hot” rows: any DRAM row whose activation frequency meets or exceeds a configurable threshold within a rolling refresh window is blacklisted, and subsequent activations to such rows are selectively delayed. BlockHammer implements this guarantee using time-interleaved counting Bloom filters (CBFs) for space-efficient, false-negative-free tracking of row activation rates, coupled with a FIFO history buffer for temporal enforcement.

1. Mechanism Overview

BlockHammer’s RowBlocker-BL ensures RowHammer-safe operation by blacklisting rows that are activated above the blacklisting threshold (BL) within a rolling time window, thereby preventing any row from surpassing the RowHammer threshold (RH), which is the maximum number of activations within a DRAM refresh window (REFW; e.g., 64 ms) that could trigger bit-flips. Once a row is blacklisted (i.e., activation count ≥ BL), subsequent rapid activations are throttle-delayed by a computed interval (“Delay”). The scheme is configurable: BL is strictly less than RH (for example, RH = 32 K; BL = 8 K). The minimal enforced delay between two activations to a blacklisted row ensures that, globally, no row can ever reach RH activations in a single REFW.

Key technical aspects:

• Counting Bloom Filters (CBFs) are used to efficiently track per-row activation counts with zero false negatives.
• Dual-CBF time-interleaving provides rolling detection over sliding windows.
• Row Activation History Buffer (HB) maintains activation timestamps for enforcing delay on blacklisted rows.

2. Data Structures and Algorithms

Counting Bloom Filters (CBFs)

A CBF is parameterized by $m$ counters and $k$ independent hash functions, each mapping a row-ID to one counter slot per activation. Upon every activation of row $r$, the filter increments $k$ counters: $counter[i][h_i(r)]++$ for $i = 1...k$. The estimated activation count for $r$ is $\min_{i=1..k} counter[i][h_i(r)]$, guaranteeing no false negatives but subject to false positives (overcounts by aliasing). The false-positive rate $f$ is bounded by $f = (1 - e^{-k \cdot n / m})^k$ for $n$ distinct inserts.

Dual-CBF Interleaving

Two CBFs (active, passive) are maintained, each covering an epoch of duration $\tau$. On each row activation, inserts are performed into both filters. At every $\tau$ interval, the roles of active and passive are swapped, clearing the just-expired filter. Blacklist queries reference the active filter. This approach ensures all rows crossing BL in any rolling $2\tau$ are detected for at least $\tau$ more.

Row Activation History Buffer (HB)

A small FIFO HB (typically per rank) stores <rowID, timestamp> pairs for the last Delay interval. On each activate request, rapid reactivation is checked by CAM-style lookup; if detected, the request is delayed until Delay elapses since last activation.

Derivation of Delay

The delay guarantees that in any CBF lifetime $\tau$, no row can be activated more than $RH \cdot (\tau/REFW)$. By enforcing $BL < RH \cdot (\tau / REFW)$, a worst-case attacker firing BL activations as fast as row cycle (RC) apart, then waiting Delay between subsequent activations, is bounded:

$$Delay = \frac{\tau - BL \cdot RC}{RH \cdot (\tau / REFW) - BL}$$

High-Level Workflow

def onActivateRequest(row, time): if active.estimate(row) >= BL: if HB.contains(row): delayRequest(row) until row's last activation >= Delay ago issueACT(row) active.insert(row) passive.insert(row) HB.enqueue((row, time)) def onEpochBoundary(): clearingFilter = active clearingFilter.clearCounters() swap(active, passive)

3. Security, Correctness, and Overheads

RowBlocker-BL achieves deterministic protection due to the nonexistence of false negatives in CBFs. Every row exceeding BL activations is blacklisted, with delay guaranteeing that $RH$ is never exceeded within REFW. Analytical proofs in the source demonstrate the completeness of this guarantee. False positives (where benign rows are spuriously blacklisted due to CBF overcount) never compromise security; only performance for falsely blacklisted rows is mildly affected.

Overhead metrics include:

• False-positive rate: ≈0.01% for RH=32K (BL=8K, m=1K counters, k=4); up to 0.012% for RH=1K.
• Area: Total ≈0.14 mm² per rank (about 0.06% of a CPU die).
• Static power: ~22 mW (RH=32K).
• DRAM access-time overhead: <1 ns, absorbed by t_RCD/t_RP.
• Performance/energy (benign load): <0.7% slowdown, <0.6% DRAM energy increase.
• Under attack: Benign throughput increased by 45% on average (up to 61.9%), DRAM energy reduced by 29%; attack detection accuracy 99.98%.

4. Comparison with Prior Mitigation Schemes

BlockHammer’s approach differs fundamentally from prior mitigation strategies:

Mechanism	Protection Type	DRAM Modifications	Scalability/Overheads
PARA	statistical	none	High perf. cost as RH drops
CBT/TWiCe/Graphene	reactive refresh	none/limited	Area/power blow up at low RH
CATT/GuardION/ZebRAM	physical isolation	mapping/guard rows	Loss of capacity; proprietary req.
Per-row throttling	deterministic	none	High area overhead at scale
BlockHammer	deterministic	none	Sub-percent cost, full coverage

BlockHammer is the only known mechanism satisfying all four desiderata: full protection, commodity-DRAM compatibility, RH-scalability, and deterministic zero-failure security.

5. Experimental Evaluation Results

Empirical results demonstrate negligible overhead under benign conditions:

• Single-core (benign): No measurable slowdown or energy overhead.
• 8-core (benign): <0.5% slowdown, <0.6% DRAM energy change.
• 8-core (with one attacker): Weighted speedup of benign threads increased by 45.0% on average (max 61.9%), harmonic speedup by 56.2% (max 73.4%), maximum slowdown reduced by 22.7% (max 45.4%), DRAM energy reduced by 28.9% on average (max 33.8%).
• Scaling RH from 32K to 1K under attack: Performance gains for benign threads grow (+45% to +71%); compared schemes (PARA, TWiCe, Graphene) impart 1–3% slowdowns under similar conditions.

6. Limitations and Extensions

The scheme’s rare false positives (0.01–0.012%) cause only microsecond-scale delays; these can be reduced at modest area cost by increasing $m$ or $k$. Parameter sensitivity requires careful BL, $\tau$, and $m$ selection per RH; recipes for this tuning are provided (see Table A.1 in the paper). Prospective extensions include self-tuning of parameters in hardware and integration with OS-level scheduling via the exposed RowHammer Likelihood Index (RHLI), which can be utilized for thread isolation and migration. Scalability to multi-rank/channel architectures is achievable using batched clears and duplicated structures.

A plausible implication is that architectural integration of BlockHammer’s dual-CBF and HB design into future DRAM controllers could stabilize RowHammer protection as DRAM vulnerabilities escalate, without impeding standard DRAM process flows (Yağlıkçı et al., 2021).