--- title: 'Yukthi Opus: BlockHammer DRAM Protection' url: https://www.emergentmind.com/topics/yukthi-opus-yo type: topic --- # Yukthi Opus: BlockHammer DRAM Protection 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 arXiv:2102.05981 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 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 ```python # Data structures: active CBF, passive CBF, history buffer HB 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 [2102.05981]. Source: https://www.emergentmind.com/topics/yukthi-opus-yo