2507.18581

# PRACtical: Subarray-Level Counter Update and Bank-Level Recovery Isolation for Efficient PRAC Rowhammer Mitigation **Authors**: Ravan Nazaraliyev Saber Ganjisaffar Nurlan Nazaraliyev Nael Abu-Ghazaleh > University of California, Riverside rnaza005, sganj003, nnaza008, ## Abstract As DRAM density continues to scale, the Rowhammer vulnerability increases in severity due to heightened charge leakage, which lowers the activation threshold required to induce bit flips. To mitigate this risk, industry-standard solutions have shifted from memory controller-based row activation counters, which require large SRAM storage with significant area and power overheads, to in-DRAM row activation counters. The DDR5 JEDEC standard incorporates a modified DRAM architecture featuring per-row activation counters (PRAC) and an Alert Back-Off (ABO) signal that notifies the memory controller (MC) to trigger mitigation mechanisms. However, PRAC introduces a performance overheads by incrementing counters during the precharge operation, adding an additional delay to the precharge phase. Furthermore, when the ABO signal is triggered upon a row reaching the Alert threshold, RFM ab indiscriminately stalls all memory requests at the memory channel level, even when only a single bank is being accessed heavily, leading to unnecessary performance degradation. In this work, we propose PRACtical, an optimized approach to improving the performance of existing PRAC+ABO mechanisms while maintaining security guarantees. To reduce counter update latency, we introduce a centralized increment circuit, allowing the memory controller to proceed with subsequent activations to other subarrays without suffering the increment delays. To minimize unnecessary memory stalls and make the system resilient against memory performance attacks based on channel stalling upon Alert, we enhance RFM ab with bank-level granularity, enabling the memory controller to selectively stall only the affected banks rather than the entire memory channel. This is achieved by introducing a register in the DRAM that shows the banks under attack upon an Alert signal. Our proposed techniques improve the performance over state of the art opportunistic PRAC and ABO, by 8% (20% max). Additionally, PRACtical saves an average of 19% energy relative to PRAC+ABO. PRACtical is resilient to performance attacks, showing less than 6% slowdown on an aggressive performance attack, while providing the same security as PRAC+ABO. DRAM, Rowhammer, PRAC, ABO ## 1. Introduction Rowhammer (Cojocar et al., 2019; de Ridder et al., 2021; Mutlu and Kim, 2019; Kim et al., 2014a) is a well-known serious vulnerability affecting DRAM: repeated access to one or more target rows can induce bit flips in adjacent rows. The bit flips occur due to charge leakage from repeated activations of a DRAM row, which can accelerate charge leakage in nearby memory cells, causing their state to change. When a row is activated a sufficient number of times within a single refresh interval, it may corrupt the contents of nearby rows. The estimated minimum number of such activations that could induce a bit flip is referred to as the Rowhammer Threshold, denoted by $N_RH$ . As DRAM technology has scaled to smaller feature sizes, $N_RH$ has significantly decreased—from approximately 140K activations in earlier DDR3 devices to as low as 4.8K in LPDDR4 modules (Kim et al., 2014a, 2020); it is expected to drop further in future generations. Concerningly, the significant drop in $N_RH$ leads to a noticeable increase in the frequency of DRAM bit flips (Loughlin et al., 2021). Accordingly, mitigation strategies must continuously evolve to remain effective against increasingly demanding and sophisticated threat conditions. DRAM plays a critical role in determining the performance of memory-intensive workloads, leading to the well known memory wall (Wulf and McKee, 1995; Gholami et al., 2024; Ghose et al., 2019). As Rowhammer threats continue to increase with memory scaling, the proposed mitigations have come at a substantial cost to DRAM performance. JEDEC (JEDEC, 2024a) has recently introduced a new standard mitigation mechanism for the Rowhammer vulnerability in DDR5 memory devices. This mechanism incorporates two key components: Per-Row Activation Counters (PRAC) (JEDEC, 2024b) and Alert Back-Off (ABO) protocol. PRAC, inspired by the Panopticon framework (Bennett et al., 2021), implements an in-DRAM architectural enhancement where each row is extended to store an activation counter. When the number of activations to a row exceeds a predefined Alert threshold, the mechanism should trigger mitigation for that row and its neighboring rows. This mechanism enables localized, row-level tracking without incurring the area and power overhead associated with external SRAM-based counters (Qureshi, [n. d.]; Saxena and Qureshi, 2024). The ABO protocol (JEDEC, 2024b) complements PRAC by providing a signaling mechanism through which the DRAM device can notify the memory controller (MC) when a critical activation threshold is crossed. The MC sends all-bank RFM (RFM ab) triggering targeted refresh operations, thereby preventing potential bit flips. While the PRAC+ABO framework marks a significant improvement in integrated, hardware-supported Rowhammer mitigations under reduced thresholds (Canpolat et al., 2025; Qureshi and Qazi, 2024; Woo et al., 2025), it also introduces several critical limitations that compromise both performance and scalability, particularly in high-performance or multi-threaded environments. <details> <summary>x1.png Details</summary>  ### Visual Description # Technical Document Analysis of Diagram ## Diagram Overview The image presents a comparative analysis of memory access patterns and timing in a dual-subarray system, comparing three operational modes: "Unsafe Baseline," "PRAC+ABO," and "PRACTical (this work)." The diagram is divided into two primary sections: **(a)** showing raw timing configurations and **(b)** illustrating method comparisons with explicit timing annotations. --- ## Section (a): Timing Configurations ### Components - **Subarray A/B**: Two parallel memory subarrays (A and B) with identical ACT-RAS-PRE sequences. - **ACT**: Green hexagon (address activation) - **RAS**: Blue hexagon (row activation) - **PRE**: Red hexagon (precharge) - **Time Axis**: Horizontal axis marked in nanoseconds (ns) ### Key Observations 1. **Subarray A** consistently shows ACT-RAS-PRE sequences aligned across all three subsections. 2. **Subarray B** exhibits delayed ACT-RAS-PRE sequences relative to Subarray A: - **Subsection 1**: 15ns delay between Subarray A and B - **Subsection 2**: 10ns delay between Subarray A and B - **Subsection 3**: 50ns delay between Subarray A and B 3. **Unsafe Baseline**: No explicit timing annotations, but implied by lack of RFM/ABO components. ### Legend (Implicit) - Green = ACT - Blue = RAS - Red = PRE --- ## Section (b): Method Comparison ### Components - **Banks A/B**: Two memory banks with identical ACT-RAS-PRE sequences. - **RFM**: Red rectangle (Refresh Memory) - **ABO**: Black line (Address Before Operation) - **Time Axis**: Horizontal axis with explicit timing markers ### Key Observations 1. **Unsafe Baseline**: - ACT-RAS-PRE sequences in both banks - No RFM/ABO components - Implied timing: ~350ns total cycle 2. **PRAC+ABO**: - ACT-RAS-PRE sequences in both banks - ABO line at 180ns - RFM rectangle spanning 180ns–350ns - Total cycle: ~350ns 3. **PRACTical (this work)**: - ACT-RAS-PRE sequences in both banks - ABO line at 10ns - RFM rectangle spanning 10ns–180ns - Total cycle: ~180ns ### Legend (Explicit) - Red = RFM - Black = ABO - Green = ACT - Blue = RAS - Red = PRE --- ## Spatial Grounding & Trend Verification ### Section (a) - **Legend Position**: Right-aligned with diagram - **Color Consistency**: - ACT (green) always precedes RAS (blue) - PRE (red) follows RAS in all sequences - **Timing Trends**: - Subarray B delays increase from 15ns → 10ns → 50ns across subsections - No overlap between Subarray A and B sequences ### Section (b) - **Legend Position**: Right-aligned with diagram - **Color Consistency**: - RFM (red) always follows ABO (black) - ACT-RAS-PRE sequences precede RFM/ABO components - **Timing Trends**: - PRAC+ABO adds 180ns RFM phase to baseline - PRACTical reduces total cycle by 170ns (350ns → 180ns) --- ## Critical Data Points | Component | Subarray A | Subarray B | Method | Timing (ns) | |-----------------|------------|------------|-----------------|-------------| | ACT-RAS-PRE | 0 | 15/10/50 | Unsafe Baseline | 0 | | ABO | - | - | PRAC+ABO | 180 | | RFM | - | - | PRAC+ABO | 350 | | ABO | - | - | PRACTical | 10 | | RFM | - | - | PRACTical | 180 | --- ## Language Analysis - **Primary Language**: English (98% of text) - **Secondary Language**: None detected - **Technical Terminology**: - ACT: Address Activation - RAS: Row Activation - PRE: Precharge - RFM: Refresh Memory - ABO: Address Before Operation --- ## Conclusion The diagram demonstrates a 170ns performance improvement in the PRACTical method compared to PRAC+ABO, achieved through earlier ABO timing (10ns vs 180ns) and reduced RFM duration. Subarray B consistently exhibits delayed operations relative to Subarray A, with varying delay magnitudes across different system configurations. </details> Figure 1. Comparison of baseline DRAM (top), PRAC+ABO (middle), and the proposed design (bottom). PRAC+ABO introduces (a) access latency from counter update overhead and (b) all-bank stalls due to coarse-grained RFM recovery. The proposed mechanism mitigates both by enabling subarray-level PRAC updates and bank-level mitigation. The gray regions illustrate the performance improvements enabled by the proposed approach. Register read operation takes 10ns in PRACtical in part (b). First, the integration of PRAC requires architectural modifications that impact critical DRAM timing parameters (Hassan et al., 2024; JEDEC, 2024a). Specifically, the logic responsible for updating the per-row counters introduces an additional latency of around 5 ns to the row cycle time ( $t_RC$ ). Even more significantly, the precharge timing ( $t_RP$ ) is extended from 15 ns to 36 ns to accommodate the read-modify-write (RMW) operations needed for per-row counter updates. These modifications directly affect memory access latency and throughput, especially in workloads with high row buffer conflicts, as illustrated in Figure 1 (a) (Baseline vs. PRAC+ABO). Second, after ABO is signalled to MC from DRAM, MC sends RFM ab command to DRAM for recovery. This command operates at the memory channel granularity. Therefore, the memory controller must conservatively stall all requests across the entire channel, even if only a single bank is affected, as illustrated in the middle row of Figure 1 (b). Since all banks undergo recovery, even in the absence of an actively hammered (hot) row, the mechanism opportunistically refreshes potential victim rows to preemptively mitigate future attacks. Our analysis reveals that this opportunistic strategy results in a threefold increase in recovery refreshes, underscoring the inefficiency and potential redundancy of these additional operations. We further observe that, across a set of memory-intensive benchmarks, on average, only 1.16 out of 64 banks need recovery at any given time (See § 3.2). Consequently, the remaining banks are unnecessarily stalled, leading to avoidable performance degradation. This coarse-grained design limits memory-level parallelism, degrading performance and responsiveness in scenarios where finer-grained mitigation would suffice. While the PRAC+ABO mechanism represents meaningful progress toward an in-DRAM Rowhammer mitigation, it introduces two key performance-related drawbacks: (1) increased memory access latency due to counter update overhead, and (2) channel-wide stalls caused by the coarse granularity of RFM ab. These challenges do not undermine the mechanism’s ability to prevent Rowhammer bit flips, but they do limit its efficiency and suitability for performance-sensitive systems. As such, there is a pressing need for a more fine-grained, low-overhead mitigation framework that minimizes latency and preserves DRAM throughput while maintaining effective protection. To address the performance and energy limitations of the existing PRAC+ABO framework, we propose PRACtical — a minimal and efficient redesign that improves both responsiveness and scalability of PRAC+ABO. This new design introduces two key enhancements. First, it leverages subarray-level increment logic to decouple counter updates from global precharge timing, allowing subsequent activations to proceed in other subarrays without incurring the additional latency associated with PRAC’s read-modify-write operations. While prior works have explored and leveraged subarray-level parallelism to enhance memory performance and efficiency (Kim et al., 2012; Hassan et al., 2024), the introduction of the PRAC standard imposes new constraints that limit such parallelism. In this work, we demonstrate that with modest modifications to the DRAM circuitry, it is possible to restore a degree of subarray parallelism by overlapping the activation of a new row with the counter update of the previously accessed row. This significantly reduces access delay and enables known subarray-level parallelism for per-row counter updates. Second, PRACtical provides a new RFM command called RFM_MASK that eliminates stalling every bank once ABO is signalled from DRAM to MC, thereby ensuring that only the affected banks are stalled in response to a threshold violation. This fine-grained control minimizes unnecessary interference with unrelated memory traffic and improves overall system throughput. PRACtical makes small modifications to the memory controller and DRAM. Together, these enhancements enable precise, low-latency and low-energy Rowhammer mitigation with minimal disruption to normal DRAM operations, as demonstrated in the bottom row of Figure 1 (a) and (b). Our performance evaluation, detailed in Section 6, utilizing DRAM simulation with Ramulator (Luo et al., 2023b), demonstrates that PRACtical achieves mean performance improvement of 8% over opportunistic PRAC+ABO for high-performance and memory-intensive applications while maintaining the security guarantees of PRAC+ABO-based mitigations (Canpolat et al., 2025; Woo et al., 2025; Qureshi and Qazi, 2024). In summary, the key contributions of this paper are: - We identify two major performance bottlenecks in the PRAC+ABO mechanism: precharge-induced latency caused by PRAC updates, and coarse-grained channel-wide stalling due to RFM ab. - We propose a centralized increment circuit that enables subarray-level parallelism, minimizing the counter update overhead during precharge. - We introduce a bank-level recovery scheme that minimizes unnecessary stalls by isolating mitigation to the affected bank. - We integrate these two mechanisms into PRACtical, a low-overhead Rowhammer mitigation framework that improves performance while preserving the security guarantees of PRAC+ABO. - We evaluate PRACtical using Ramulator, showing lower performance overheads compared to PRAC+ABO with minimal hardware modifications. ## 2. Background <details> <summary>x2.png Details</summary>  ### Visual Description # Technical Diagram Analysis: DRAM Architecture ## Overview The image depicts a hierarchical representation of DRAM (Dynamic Random-Access Memory) architecture, divided into three primary sections: 1. **DRAM Module** (Top-left) 2. **DRAM Bank** (Top-right) 3. **Subarray/PRAC** (Bottom-left) with **DRAM Cell** inset (Bottom-right) --- ## 1. DRAM Module ### Components: - **Memory Controller** (Vertical white bar on the left) - Connects to **I/O Circuitry** (White rectangle with "I/O Circuitry" label) - **DRAM Rank** (Gray rectangle) - Contains multiple **Chip** components (Stacked gray rectangles with "Chip" labels) - **Connections**: - Dashed lines indicate hierarchical relationships between Memory Controller → I/O Circuitry → DRAM Rank → Chip --- ## 2. DRAM Bank ### Components: - **Subarray** (Teal rectangles) - Two instances labeled "Subarray" - **Local Row Buffer** (White rectangles) - Three instances labeled "Local Row Buffer" - **Global Row Buffer** (Gray rectangle) - Positioned at the bottom of the DRAM Bank - **Decoders**: - **Global Decoder** (Vertical white bar on the left) - **Row Decoder** (Vertical white bar adjacent to Global Decoder) - **PRAC** (Pink vertical bar on the right) - Contains **Per-row Counters** (Pink rectangles with "+" symbols) - **Connections**: - Vertical lines connect Subarrays to Local Row Buffers - Dashed lines link Local Row Buffers to Global Row Buffer - PRAC connects to Global Row Buffer via a "+" symbol --- ## 3. Subarray/PRAC ### Subarray Structure: - **Grid Layout**: - 4x4 matrix of **Bitline** connections (White circles with red lines) - **Row Decoder** (Vertical white bar on the left) - **PRAC Column**: - Pink vertical bar with **Per-row Counters** (Pink rectangles) - **Local Row Buffer**: - White rectangle at the bottom of the Subarray - **Worldline** (Red horizontal line): - Connects Bitlines to PRAC ### DRAM Cell Inset: - **Components**: - **Bitline** (Vertical black line) - **Transistor** (Gray horizontal line with "Transistor" label) - **Capacitor** (Gray vertical line with "Capacitor" label) - **Worldline** (Red horizontal line connecting Bitline and Transistor) --- ## Color Coding & Spatial Grounding | Component | Color | Spatial Position | |--------------------|-------------|---------------------------------| | DRAM Module | Blue | Top-left quadrant | | DRAM Bank | Gray | Top-right quadrant | | Subarray | Teal | Bottom-left quadrant | | PRAC | Pink | Right side of Subarray/DRAM Bank| | DRAM Cell | Black/Red | Bottom-right inset | --- ## Key Trends & Data Points 1. **Hierarchical Flow**: - Memory Controller → I/O Circuitry → DRAM Rank → Chip (DRAM Module) - Subarray → Local Row Buffer → Global Row Buffer (DRAM Bank) - Bitline → Transistor → Capacitor (DRAM Cell) 2. **PRAC Functionality**: - Per-row Counters (PRAC) monitor individual Subarray rows - Connected to Global Row Buffer via summation ("+") symbol 3. **DRAM Cell Structure**: - Worldline acts as a control line for the Transistor - Capacitor stores charge for data retention --- ## Notes - No explicit data table or numerical values present. - All labels and components are in English. - Diagram emphasizes structural relationships over quantitative data. </details> Figure 2. DRAM Organization and Per-Row Activation Counter (PRAC) extension. In this section, we provide an overview of key background topics, including DRAM architecture, the Rowhammer vulnerability, and existing mitigation strategies. We also describe the PRAC+ABO mechanism introduced in the DDR5 standard, which forms the basis for our proposed performance enhancements. ### 2.1. DRAM Architecture and Parameters Modern DRAM is organized hierarchically into ranks, banks, subarrays, rows, and columns, as illustrated in Figure 2. At the top of this hierarchy, the memory controller communicates with DRAM modules via a dedicated memory channel. Each module is composed of one or more ranks, which share access to the memory channel in a time-multiplexed fashion. A rank comprises several DRAM chips, and each chip contains multiple banks. Within each bank are numerous subarrays, forming the fundamental building blocks of memory storage. Each subarray is implemented as a two-dimensional array of cells, accessed via rows (wordlines) and columns (bitlines). A single DRAM cell includes a capacitor, which holds a bit of data as an electric charge, and an access transistor that enables read and write operations. Each subarray contains its own local row buffer, which temporarily holds the contents of an activated row. Only one subarray at a time can forward its data to the global row buffer shared across the bank, enabling read and write operations to proceed. To access data, the memory controller issues an Activate (ACT) command, which opens a specific row by transferring its contents into the row buffer. Subsequent read or write operations are performed on this open row, resulting in a low-latency row hit. If a different row within the same bank must be accessed, the current row must first be closed using a Precharge (PRE) command, which restores the contents of the row buffer to the array and resets the bitlines. DRAM access behavior is governed by a set of well-defined timing parameters specified by the JEDEC standard (JEDEC, 2024a), as summarized in Table 1. We use DDR5-3200AN timings. For example, the Row Access Strobe (RAS) latency defines the minimum delay between an ACT and a subsequent PRE command within the same bank. Additionally, to maintain data integrity, DRAM cells require periodic refreshing within a retention window denoted as $t_REFW$ , typically 32ms. To amortize the cost of refresh, DRAM divides its cells into 8192 refresh groups, and a Refresh (REF) command is issued every $t_REFI$ = 3900ns to refresh one group at a time. | $t_RAS$ | Minimum time a row must be kept open | 32ns | 16ns | | --- | --- | --- | --- | | $t_RP$ | Time to precharge an open row | 15ns | 36ns | | $t_RC$ | Time between successive ACTs to a bank | 47ns | 52ns | | $t_RTP$ | Minimum time for a PRE after a RD to the same bank | 7.5ns | 5ns | | $t_WR$ | minimum time for a PRE after a WR to the same bank | 30ns | 10ns | Table 1. DRAM Timing Standards ### 2.2. Read Disturbance Attacks Modern DRAM is increasingly vulnerable to read disturbance effects, where the act of accessing one memory row can inadvertently influence the integrity of data stored in nearby rows. This phenomenon arises from the shrinking physical dimensions of DRAM cells and the reduced noise margins between them. As manufacturing processes continue to scale, the isolation between adjacent rows weakens, making DRAM cells more susceptible to charge leakage and electromagnetic coupling. The most prominent example of a read disturbance attack is Rowhammer (Kim et al., 2014a), where an attacker repeatedly activates (i.e., opens) a single DRAM row, known as the aggressor row, within a refresh interval. If the number of activations exceeds a certain threshold, electrical interference can induce bit flips in adjacent victim rows. Since its discovery, Rowhammer has been shown to compromise system security in various ways, including enabling privilege escalation (Seaborn and Dullien, 2015), breaking isolation between virtual machines (Razavi et al., 2016), and subverting browser-based sandboxes (Gruss et al., 2016). Beyond Rowhammer, newer variants continue to expose the fragility of DRAM. RowPress (Luo et al., 2023a) demonstrates that simply holding a row open for an extended duration—without repeated activations—can cause similar disturbance effects in neighboring rows. This shows that both temporal access frequency and row residency time can lead to data corruption, expanding the threat model beyond traditional Rowhammer. The security implications of these attacks are severe. Bit flips in sensitive memory structures such as page tables, kernel space, or encryption keys can be exploited to gain arbitrary code execution, bypass memory isolation, or compromise confidentiality (Frigo et al., 2020; Gruss et al., 2018; Razavi et al., 2016; Gruss et al., 2016). To mitigate read disturbance attacks, a wide range of defenses have been proposed. These typically follow a two-phase approach: (1) Detecting aggressor rows, using techniques such as memory controller-based row activation counters (Kim et al., 2021), probabilistic sampling (Son et al., 2017; Kim et al., 2014a), or in-DRAM tracking (Jaleel et al., 2024b; Qureshi et al., 2024); and (2) Applying preventive measures, such as Target Row Refresh (TRR) (Marazzi et al., 2022; Frigo et al., 2020), domain-aware memory allocation (Saxena et al., 2024b), or row remapping (Saxena et al., 2024a). While many of these defenses are effective at reducing bit flips, they often incur significant performance overheads and hardware complexity, especially when mitigation is applied conservatively to avoid false negatives. As DRAM continues to scale and disturbance thresholds fall, there is a growing need for efficient, low-latency, and fine-grained mitigation mechanisms that preserve performance without compromising reliability or security. ### 2.3. PRAC and ABO in Modern DRAM Standards To address the growing threat of Rowhammer attacks, recent JEDEC standards have introduced two complementary in-DRAM mitigation mechanisms: Per-Row Activation Counter (PRAC) and Alert Back-Off (ABO). These mechanisms aim to detect and mitigate malicious or excessive row activations efficiently, while remaining scalable for high-density DRAM systems. #### 2.3.1. PRAC This feature is designed to mitigate Rowhammer attacks with minimal area and power overhead by embedding activation tracking directly within the DRAM array. Specifically, PRAC extends each DRAM row with a dedicated activation counter. Every time a row is precharged, its corresponding counter is incremented by the increment logic in the global row buffer shared between all subarrays within a bank, as illustrated in Figure 2. This increment operation is performed during the precharge phase and is implemented as a read-modify-write (RMW) sequence at the bank level. When a precharge command (PRE) is issued, the DRAM bank reads the activation counter of the recently accessed row, updates its value, and writes it back before deactivating the wordline. This sequence introduces additional latency to the precharge operation, requiring DRAM timing parameters to be extended to accommodate the counter update overhead. While PRAC enables fine-grained tracking of row activations without relying on external memory controller storage, its bank-wide RMW implementation creates performance bottlenecks by delaying subsequent accesses to other non-conflicting subarrays until the counter update completes, as illustrated in top and middle rows of the Figure 1 (a). The performance impact of this overhead is analyzed in detail in Section 3. #### 2.3.2. ABO This mechanism complements PRAC by providing a signaling interface between the DRAM device and the memory controller. When a PRAC counter in any bank reaches a pre-defined threshold, the corresponding bank sends an ABO signal to notify the memory controller that mitigation is needed. Upon receiving the ABO signal, the memory controller initiates a pre-recovery phase lasting 180ns, during which it continues to serve memory requests normally as shown in Figure 3. After this window, the controller issues an RFM ab command to trigger targeted mitigation. Each RFM ab command incurs a latency of 350ns and applies to all banks in the channel (typically 64 banks). During this period, the memory controller stalls requests to the channel while the banks perform recovery operations, such as refreshing victim rows, as shown in the middle row of Figure 1 (b). If multiple banks reach the threshold in close succession, the memory controller may need to issue multiple RFM commands, each separated by a recovery window. This can amplify the performance impact, especially under aggressive access patterns that frequently trigger mitigation events. To prevent back-to-back ABO signals, the protocol requires a minimum number of ACT commands between two consecutive alerts. In Figure 3, this value is denoted by $n$ . It also corresponds to the number of required RFM operations, as each RFM can service only a limited number of victim rows per invocation. After all RFM commands are completed, one additional ACT is permitted. The allowed values for $n$ are 1, 2, or 4, as illustrated by PRAC-1, PRAC-2, and PRAC-4 in Figure 3, as well as in Figures in Sections 3 and 6. Consequently, the minimum and maximum ABO intervals range from 350ns to 1500ns, each preceded by a fixed 180ns pre-recovery window. <details> <summary>x3.png Details</summary>  ### Visual Description # Technical Document Extraction: System Phase Diagram ## Diagram Overview The image depicts a **timeline-based system phase diagram** illustrating memory controller behavior across three operational phases. The diagram uses color-coded hexagonal blocks to represent command sequences and includes temporal annotations. --- ## Key Components & Labels ### Axes - **X-axis (Phases)**: - Labeled "Phases" with three distinct sections: 1. **Normal Operation** (left) 2. **Memory Ctrl. Stops Sending Requests** (center) 3. **Normal Operation** (right) - Dashed vertical lines separate phases. - **Y-axis (PRAC Levels)**: - Three levels labeled: - PRAC-1 (n = 1) - PRAC-2 (n = 2) - PRAC-4 (n = 4) - Positioned from top to bottom. ### Legend - **Color Coding**: - **Green (#4ECDC4)**: `ACT` commands - **Red (#FF4500)**: `RFM` commands - Located at the top of the diagram. --- ## Temporal Annotations 1. **Pre-Recovery Phase**: - Marked with a red arrow labeled `ABO`. - Duration: **180 ns** (noted above the first phase). 2. **RFM Command Timing**: - Each `RFM` command takes **350 ns** (noted above the second phase). 3. **ACT Command Timing**: - `ACT` commands are unlabeled but implied to occur in the first and third phases. --- ## Command Sequences by PRAC Level ### PRAC-1 (n = 1) - **Phase 1 (Normal Operation)**: - 3 `ACT` commands (green blocks). - **Phase 2 (Memory Ctrl. Stops Sending Requests)**: - 1 `RFM` command (red block). - **Phase 3 (Normal Operation)**: - 1 `ACT` command (green block). ### PRAC-2 (n = 2) - **Phase 1**: - 3 `ACT` commands. - **Phase 2**: - 2 `RFM` commands. - **Phase 3**: - 2 `ACT` commands. ### PRAC-4 (n = 4) - **Phase 1**: - 3 `ACT` commands. - **Phase 2**: - 4 `RFM` commands. - **Phase 3**: - 4 `ACT` commands. --- ## Key Trends 1. **RFM Command Scaling**: - Number of `RFM` commands increases linearly with PRAC level (`n`): - PRAC-1: 1 `RFM` - PRAC-2: 2 `RFM` - PRAC-4: 4 `RFM` 2. **ACT Command Consistency**: - `ACT` commands remain constant at **3** during the first phase across all PRAC levels. - Post-Memory Ctrl., `ACT` commands match the PRAC level (`n`): - PRAC-1: 1 `ACT` - PRAC-2: 2 `ACT` - PRAC-4: 4 `ACT` 3. **Phase Transitions**: - The Memory Ctrl. phase introduces `RFM` commands, which are absent in the initial Normal Operation phase. - After the Memory Ctrl. phase, the system resumes `ACT` commands in the final Normal Operation phase. --- ## Spatial Grounding - **Legend Position**: Top-center (x = 0.5, y = 1.0 in diagram coordinates). - **PRAC Level Order**: Top-to-bottom (PRAC-1 > PRAC-2 > PRAC-4). - **Phase Boundaries**: Dashed vertical lines at x = 0.3 and x = 0.7. --- ## Data Table Reconstruction | PRAC Level | Phase 1 (ACT) | Phase 2 (RFM) | Phase 3 (ACT) | |------------|---------------|---------------|---------------| | PRAC-1 | 3 | 1 | 1 | | PRAC-2 | 3 | 2 | 2 | | PRAC-4 | 3 | 4 | 4 | --- ## Notes - **No Other Languages Detected**: All text is in English. - **Critical Annotation**: The `ABO` label (red arrow) indicates a system-wide pre-recovery event preceding Phase 1. - **Temporal Constraints**: RFM commands are explicitly timed at 350 ns, while ACT command durations are unspecified but implied to be shorter (given their placement in Normal Operation phases). This diagram illustrates a memory controller's response to abnormal conditions (ABO), with PRAC levels determining the number of RFM commands issued during error recovery. </details> Figure 3. Alert-back-off (ABO) overview ### 2.4. Mitigations Based On PRAC+ABO Several recent works build on the PRAC+ABO framework to strengthen its security guarantees and reduce its performance overheads. In this paper, we focus on three representative designs—Chronus (Canpolat et al., 2025), QPRAC (Woo et al., 2025), and MOAT (Qureshi and Qazi, 2024) —which propose distinct approaches to improving the effectiveness and efficiency of in-DRAM RowHammer mitigation. Chronus (Canpolat et al., 2025) introduces architectural modifications to decouple PRAC counter updates from the critical path of DRAM access. By relocating per-row counters to a dedicated metadata subarray, Chronus reduces the serialization overhead associated with precharge operations. It also proposes enhancements to the ABO protocol by holding the alert signal until all mitigations are complete, ensuring stronger coordination between DRAM and the memory controller. QPARC (Woo et al., 2025) revisits PRAC’s security model as originally proposed in the Panopticon framework (Bennett et al., 2021), and identifies two new attack vectors that exploit timing gaps in counter updates. To address this, it introduces a priority-based queue that tracks frequently accessed rows and schedules them for mitigation through ABO. This queuing mechanism enables timely and targeted mitigation while preserving compatibility with the existing PRAC+ABO interface. MOAT (Qureshi and Qazi, 2024) focuses on simplifying mitigation logic by replacing queue-based designs with a tracking mechanism. It uses two SRAM registers to monitor one hot row at a time, applying proactive refreshes below a configurable threshold and issuing ABO signals when the threshold is exceeded. While MOAT reduces hardware complexity, it may face limitations under workloads with multiple simultaneous hot rows. ## 3. PRAC+ABO Limitations and Motivation While PRAC+ABO provides a low-cost, JEDEC-standardized approach for in-DRAM Rowhammer mitigation, it introduces significant performance bottlenecks and security risks due to its coarse-grained design. This section presents a detailed analysis of the overheads introduced by PRAC updates and ABO-triggered channel-wide stalls. We also show how these issues can be exploited by adversaries to launch memory performance attacks. All insights are derived from cycle-accurate simulations, as described in Section 5. ### 3.1. Impact of PRAC Updates on DRAM Latency PRAC extends each DRAM row with an activation counter that is incremented during the Precharge (PRE) command using a read-modify-write (RMW) operation, as illustrated in Figure 2. This update is performed at the bank level, using logic typically located near the global row buffer. As a result, when a PRE command is issued, the DRAM must first read, modify, and write back the counter value associated with the activated row before deactivating the wordline and returning to an idle state. This serialization delays subsequent memory operations, even when they target non-conflicting subarrays. To accommodate this RMW sequence, DRAM timing parameters are modified. Specifically, the precharge latency increases from 15ns to 36ns, and the activation-to-activation interval ( $t_RC$ ) increases from 47ns to 52ns. Interestingly, the row active time ( $t_RAS$ ) is reduced from 32ns to 16ns, partially offsetting the impact. Nevertheless, the increase in $t_RC$ introduces a minimum 5ns delay between successive row activations — particularly impactful in workloads with high row buffer conflicts. To quantify this impact, we evaluated a set of memory-intensive workloads under two timing configurations: (1) a baseline DRAM configuration using standard DDR5 timings, and (2) a PRAC-enabled configuration with updated timings, as specified in Table 1. The results, shown in Figure 4, indicate that workloads experience an average slowdown of 6%, with a maximum of close to 20% for 462.libquantum. These slowdowns are primarily attributed to increased latency introduced by PRAC counter updates, particularly in scenarios involving frequent row activations within the same bank. Although the row access time increases by only 10% (from 47ns to 52ns), the observed system-level performance overhead can reach up to 20%. This discrepancy arises because rows are not always precharged immediately after access. In many cases, a row remains open for extended durations due to row buffer policy, reducing the impact of a longer row access time. However, the increased precharge latency, nearly a 100% increase in the PRE timing, becomes the dominant contributor to performance degradation, especially when frequent rows are not immediately precharged. We also evaluated multiple Alert thresholds (64, 128, and 256) and observed only minor variations in slowdown across these configurations. This suggests that the performance degradation is largely due to static timing overheads from PRAC’s counter update logic, rather than the dynamic triggering of ABO or mitigation procedures. As expected, applications with low row conflict rates, such as 447_dealII and 444_namd, exhibited significantly less performance impact. Observation 1: The updated DDR5 timings introduce performance overhead, slowing down benign workloads by geometric mean of 6%. <details> <summary>x4.png Details</summary>  ### Visual Description # Technical Document Analysis: Normalized Slowdown Bar Chart ## Chart Title **Normalized Slowdown** ## Legend - **Threshold 64**: Blue bars - **Threshold 128**: Orange bars - **Threshold 256**: Green bars - **GeoMean**: Red dashed line at 5.81% ## Axis Labels - **X-axis**: Categories (e.g., `grep_map0`, `wc_map0`, `tpch6`, `tpch17`, `tpcc64`, `429_mcf`, `434_zeusmp`, `436_cactusADM`, `444_gobmk`, `447_deall`, `450_soplex`, `456_hmmer`, `458_sjeng`, `459_GemsFDTD`, `462_liquantum`, `470_lbm`, `471_omnetpp`, `473_astar`, `481_wrf`, `483_xalancbmk`, `500_perlbench`, `502_gcc`, `505_mcf`, `507_cactuBSSN`, `508_namd`, `510_parest`, `511_povray`, `519_lbm`, `520_omnetpp`, `526_blender`, `531_deepsjeng`, `538_imagic`, `541_leela`, `544_nab`, `557_xz`, `401_bzip2`, `437_leslie3d`, `482_sphinx3`, `489_fotonik3d`, `494_wc8443`, `464_h264ref`, `525_x264`) - **Y-axis**: **Normalized Slowdown** (values: 0.0, 2.5, 5.0, 7.5, 10.0, 12.5, 15.0, 17.5, 20.0) ## Key Trends 1. **Threshold 256 (Green)**: - Consistently exhibits the highest normalized slowdown across most categories. - Peaks at `459_GemsFDTD` (~21.0) and `507_cactuBSSN` (~18.0). - Shows significant variability, with some categories (e.g., `447_deall`, `508_namd`) having minimal slowdown. 2. **Threshold 128 (Orange)**: - Generally lower than Threshold 256 but higher than Threshold 64. - Peaks at `459_GemsFDTD` (~20.5) and `507_cactuBSSN` (~17.5). - Shows moderate variability, with some categories (e.g., `447_deall`, `508_namd`) having minimal slowdown. 3. **Threshold 64 (Blue)**: - Typically the lowest slowdown across categories. - Peaks at `459_GemsFDTD` (~19.5) and `507_cactuBSSN` (~17.0). - Shows minimal variability, with most categories clustering near the GeoMean line. 4. **GeoMean Line (Red Dashed)**: - Horizontal reference at **5.81%**. - Most categories (e.g., `447_deall`, `508_namd`, `538_imagic`) fall below this line, indicating lower-than-average slowdown. - Categories like `459_GemsFDTD` and `507_cactuBSSN` exceed the GeoMean significantly. ## Spatial Grounding - **Legend Position**: Top-right corner. - **Color Consistency**: - Blue bars (Threshold 64) match the legend. - Orange bars (Threshold 128) match the legend. - Green bars (Threshold 256) match the legend. ## Component Isolation 1. **Header**: Chart title and legend. 2. **Main Chart**: Bar chart with three data series (Thresholds 64, 128, 256) and a GeoMean reference line. 3. **Footer**: No additional text or components. ## Data Table Reconstruction | Category | Threshold 64 | Threshold 128 | Threshold 256 | |--------------------|--------------|---------------|---------------| | `grep_map0` | ~2.0 | ~2.0 | ~2.0 | | `wc_map0` | ~1.5 | ~1.5 | ~1.5 | | `tpch6` | ~5.0 | ~5.5 | ~6.0 | | `tpch17` | ~10.0 | ~10.5 | ~11.0 | | `tpcc64` | ~9.0 | ~9.5 | ~10.0 | | `429_mcf` | ~16.0 | ~16.5 | ~17.0 | | `434_zeusmp` | ~14.0 | ~14.5 | ~15.0 | | `436_cactusADM` | ~11.0 | ~11.5 | ~12.0 | | `444_gobmk` | ~2.0 | ~2.0 | ~2.0 | | `447_deall` | ~0.5 | ~0.5 | ~0.5 | | `450_soplex` | ~8.0 | ~8.5 | ~9.0 | | `456_hmmer` | ~5.0 | ~5.5 | ~6.0 | | `458_sjeng` | ~2.0 | ~2.0 | ~2.0 | | `459_GemsFDTD` | ~19.5 | ~20.5 | ~21.0 | | `462_liquantum` | ~10.0 | ~10.5 | ~11.0 | | `470_lbm` | ~11.0 | ~11.5 | ~12.0 | | `471_omnetpp` | ~16.0 | ~16.5 | ~17.0 | | `473_astar` | ~9.0 | ~9.5 | ~10.0 | | `481_wrf` | ~0.1 | ~0.1 | ~0.1 | | `483_xalancbmk` | ~3.0 | ~3.0 | ~3.0 | | `500_perlbench` | ~3.0 | ~3.0 | ~3.0 | | `502_gcc` | ~2.0 | ~2.0 | ~2.0 | | `505_mcf` | ~7.0 | ~7.5 | ~8.0 | | `507_cactuBSSN` | ~17.0 | ~17.5 | ~18.0 | | `508_namd` | ~1.0 | ~1.0 | ~1.0 | | `510_parest` | ~1.0 | ~1.0 | ~1.0 | | `511_povray` | ~0.1 | ~0.1 | ~0.1 | | `519_lbm` | ~12.0 | ~12.5 | ~13.0 | | `520_omnetpp` | ~9.0 | ~9.5 | ~10.0 | | `526_blender` | ~1.0 | ~1.0 | ~1.0 | | `531_deepsjeng` | ~1.0 | ~1.0 | ~1.0 | | `538_imagic` | ~0.1 | ~0.1 | ~0.1 | | `541_leela` | ~0.2 | ~0.2 | ~0.2 | | `544_nab` | ~0.2 | ~0.2 | ~0.2 | | `557_xz` | ~8.0 | ~8.5 | ~9.0 | | `401_bzip2` | ~4.0 | ~4.5 | ~5.0 | | `437_leslie3d` | ~6.0 | ~6.5 | ~7.0 | | `482_sphinx3` | ~5.0 | ~5.5 | ~6.0 | | `489_fotonik3d` | ~4.0 | ~4.5 | ~5.0 | | `494_wc8443` | ~2.0 | ~2.0 | ~2.0 | | `464_h264ref` | ~1.5 | ~1.5 | ~1.5 | | `525_x264` | ~0.5 | ~0.5 | ~0.5 | ## Notes - **Data Extraction**: All values are approximate, derived from bar heights relative to the Y-axis. - **Trend Verification**: - Threshold 256 consistently shows the highest slowdown, with peaks in `459_GemsFDTD` and `507_cactuBSSN`. - Threshold 64 and 128 show moderate variability, with most categories clustering near the GeoMean. - **No Missing Data**: All categories and thresholds are represented. </details> Figure 4. Percentage slow-down due to the increase in the latency of PRE command. PRACtical proposes reducing the performance overhead of PRAC by performing counter updates within the local row buffers of individual subarrays. Modern DRAM architectures commonly adopt a density-optimized open-bitline structure (Keeth et al., 2007; Itoh, 2001; Chang et al., 2016; Luo et al., 2020), which places sense amplifiers on both sides of a subarray and allows adjacent subarrays to share these amplifiers. As a result, when a subarray is performing a counter update, the memory controller must delay not only accesses to that subarray but also to its neighboring subarrays. To evaluate the practical impact of this constraint, we measure the percentage of subarray conflicts relative to total row buffer conflicts. Assuming a configuration with 256 subarrays per bank, Figure 5 presents the ratio of subarray conflicts, including those involving adjacent subarrays, to total row buffer conflicts. The results demonstrate that subarray conflicts are relatively rare, accounting for only 1.24% on average across a diverse set of workloads. This observation indicates that enabling PRAC updates at the subarray level can enhance performance by permitting concurrent accesses to subarrays that are not involved in counter updates. <details> <summary>x5.png Details</summary>  ### Visual Description # Technical Document Analysis: Subarray Conflict Ratio Chart ## 1. Labels and Axis Titles - **Title**: "Subarray Conflict Ratio (%)" - **X-Axis**: - Labels: - 434_zeusmp, tpcc64, 429_mcf, 436_cactusADM, 519_lbm, 435_gromacs, 557_xz, jp2_decode, 525_x264, ycsb_cserver, 445_gobmk, 444_namd, 473_astar, 500_perlbench, tpch2, 526_blender, 401_bzip2, 510_parest, 538_imagic, 520_omnetpp, h264_encode, 549_fotonik3d, jp2_encode, 433_milc, 437_leslie3d, 541_leela, 458_sjeng, tpch6, 447_deall, grep_map0, 523_xalancbmk, 531_deepsjeng, 450_soplex, 508_namd, 482_sphinx3, 464_h264ref, tpch17, 483_xalancbmk, wc_8443, 544_nab, ycsb_abgsave, 481_wrf, 462_liquantum, ycsb_aserver, 403_gcc, 502_gcc, 456_hmmer, wc_map0, 507_cactuBSSN, 471_omnetpp, 511_povray, ycsb_eserver, ycsb_bserver, ycsb_GemsFDTD, 459_GemsFDTD, ycsb_deserver, 505_mcf, 470_lbm - Ticks: 0%, 2%, 4%, 6%, 8%, 10% - **Y-Axis**: "Subarray Conflict Ratio (%)" - **Legend**: Not visible in the image. However, the red dashed line is labeled "GeoMean: 1.24%". ## 2. Categories and Sub-Categories - **X-Axis Categories**: - All labels listed above (60 total). - **Y-Axis Categories**: - Numerical values: 0%, 2%, 4%, 6%, 8%, 10%. ## 3. Embedded Text - **GeoMean Label**: "GeoMean: 1.24%" (red dashed line). ## 4. Data Table - **No explicit data table** is present. Data is represented as bars in the chart. ## 5. Legend Color/Label Verification - **Legend Color**: Not visible. However, the red dashed line corresponds to the "GeoMean: 1.24%" label. - **Data Point Colors**: All bars are blue, matching the implied legend for "Subarray Conflict Ratio (%)". ## 6. Spatial Grounding - **Legend Placement**: Not visible in the image. - **Bar Colors**: Blue (matches the implied legend for "Subarray Conflict Ratio (%)"). ## 7. Trend Verification - **Visual Trends**: - Most bars are below the GeoMean line (1.24%). - **Highest Bars**: - 435_gromacs (~9%). - h264_encode (~5.8%). - tpch6 (~5.5%). - 462_liquantum (~3.1%). - 456_cactuBSSN (~2.6%). - 502_gcc (~1.5%). - **Lowest Bar**: 464_h264ref (~0.1%). ## 8. Component Isolation - **Header**: Title "Subarray Conflict Ratio (%)". - **Main Chart**: - Bars representing subarray conflict ratios. - Red dashed line for GeoMean (1.24%). - **Footer**: "GeoMean: 1.24%" label. ## 9. Additional Notes - **No other languages** are present in the image. - **No data table** is explicitly shown; data is represented visually as bars. - **All labels and axis markers** are transcribed as per the image. </details> Figure 5. Ratio(%) of Subarray conflicts. ### 3.2. Inefficiency of Channel-Wide Stall of RFM ab The ABO mechanism notifies the memory controller when a row’s activation count crosses the threshold. After the 180ns pre-recovery period, the controller issues an RFM ab command, triggering a 350ns stall across the entire memory channel even if only a small subset of banks require mitigation. This coarse-grained stall mechanism is overly conservative. Across a wide range of benign workloads, our measurements show that, on average, only 1.16 out of 64 banks require mitigation when an ABO signal is raised (Figure 7) and maximum of 4 banks need mitigation across all recovery periods (Figure 8). As a result, over 90% of the banks are unnecessarily stalled during each recovery phase, significantly reducing memory-level parallelism and penalizing threads accessing unaffected banks. Although a bank may not require recovery, i.e., it does not contain any hot rows, the issuance of the RFM ab command blocks memory accesses to all banks within the channel. To utilize this otherwise idle period, prior works (Qureshi and Qazi, 2024; Canpolat et al., 2025; Woo et al., 2025) adopt opportunistic mitigation strategies. These strategies proactively refresh potential victim rows whose counters are likely to reach the critical threshold in the near future. Specifically, upon issuance of RFM ab, each bank refreshes rows adjacent to the row with the highest activation count (i.e., the most likely aggressor), thereby ensuring that banks do not remain idle and reducing the need for issuing additional RFM ab commands in the future. However, this approach introduces inefficiencies. Not all of the refreshes performed are strictly necessary, leading to redundant operations. To quantify this overhead, we compare the number of total RFM refreshes that are strictly required to those actually performed under opportunistic mitigation. As shown in Figure 6, the results, aggregated as the geometric mean across multiple PRAC variants (PRAC-1, PRAC-2, PRAC-4) and thresholds (64, 128, 256), demonstrate that opportunistic mitigation incurs more than a 3× increase in RFM refreshes. This analysis underscores a significant trade-off: while opportunistic mitigation reduces idle bank time and preempts future violations, it comes at the cost of approximately 70% higher RFM -related energy consumption in DRAM. <details> <summary>x6.png Details</summary>  ### Visual Description # Technical Document Extraction: Bar Chart Analysis ## 1. Chart Identification - **Type**: Bar Chart - **Title**: "Threshold" - **Primary Purpose**: Comparing refresh rates across different thresholds and categories ## 2. Legend Analysis - **Position**: Top of chart - **Color-Coded Labels**: - Blue: Threshold 64 - Orange: Threshold 128 - Green: Threshold 256 - Gray: Geomean - **Spatial Grounding**: - X-axis: Categories (Prac-1, Prac-2, Prac-4, All) - Y-axis: Numerical values (0-4) ## 3. Axis Labels - **X-axis**: - Categories: Prac-1, Prac-2, Prac-4, All - Label: "Refreshes Comparison" - **Y-axis**: - Scale: 0 to 4 (increment: 1) - Label: "Refreshes Comparison" ## 4. Data Points & Trends ### Prac-1 - **Threshold 64 (Blue)**: ~2.63 - **Threshold 128 (Orange)**: ~2.75 - **Threshold 256 (Green)**: ~2.45 - **Geomean (Gray)**: 2.63 - **Trend**: Orange > Blue = Gray > Green ### Prac-2 - **Threshold 64 (Blue)**: 3.03 - **Threshold 128 (Orange)**: 3.15 - **Threshold 256 (Green)**: ~2.75 - **Geomean (Gray)**: 3.03 - **Trend**: Orange > Blue = Gray > Green ### Prac-4 - **Threshold 64 (Blue)**: 3.70 - **Threshold 128 (Orange)**: 3.85 - **Threshold 256 (Green)**: ~3.15 - **Geomean (Gray)**: 3.70 - **Trend**: Orange > Blue = Gray > Green ### All - **Geomean (Gray)**: 3.09 - **Note**: No bars for thresholds 64/128/256 in "All" category ## 5. Key Observations 1. **Threshold Correlation**: Higher thresholds (128 > 64 > 256) generally show increasing refresh rates 2. **Geomean Pattern**: Matches Threshold 64 values in all categories except "All" 3. **Category Progression**: - Prac-1 (lowest values) - Prac-2 (mid-range) - Prac-4 (highest values) - All (aggregated Geomean) ## 6. Structural Components - **Header**: Chart title "Threshold" with legend - **Main Chart**: - Four vertical bar groups (one per category) - Four color-coded bars per group (except "All") - **Footer**: None present ## 7. Data Table Reconstruction | Category | Threshold 64 | Threshold 128 | Threshold 256 | Geomean | |----------|--------------|---------------|---------------|---------| | Prac-1 | 2.63 | 2.75 | 2.45 | 2.63 | | Prac-2 | 3.03 | 3.15 | 2.75 | 3.03 | | Prac-4 | 3.70 | 3.85 | 3.15 | 3.70 | | All | - | - | - | 3.09 | ## 8. Language Notes - **Primary Language**: English - **No Additional Languages Detected** ## 9. Critical Validation Checks 1. **Color Consistency**: All legend colors match bar colors in chart 2. **Trend Verification**: - Orange bars consistently highest - Green bars consistently lowest - Blue/Gray bars show identical values in each category 3. **Spatial Accuracy**: - Legend positioned above chart - Y-axis values aligned with bar heights ## 10. Missing Elements - No data table present in original image - No textual annotations explaining Geomean calculation - No units specified for refresh rates </details> Figure 6. Comparison of number of RFM refreshes for opportunistic mitigation for PRAC-1, 2, and 4 and thresholds of 64, 128, and 256. Observation 2: In benign workloads, fewer than 10% of banks require mitigation during an ABO-triggered recovery period, while opportunistic mitigation performs 3x more recovery refreshes than needed. <details> <summary>x7.png Details</summary>  ### Visual Description # Technical Document Analysis of Bar Chart ## Image Description The image is a **bar chart** comparing the **average number of banks needing mitigation** across multiple categories and thresholds. The chart uses **patterned bars** (solid, diagonal, crosshatch) to distinguish between three PRAC versions (PRAC-1, PRAC-2, PRAC-4) and their associated thresholds (64, 128, 256). The y-axis represents the metric, while the x-axis lists categorical labels. --- ## Key Trends and Data Points 1. **General Pattern**: - Most bars hover around **1.00**, indicating minimal mitigation needs for most categories. - **450.soplex** exhibits a significant outlier, with values reaching **~1.12** for PRAC-4 (Th=64). 2. **Threshold Effects**: - Higher thresholds (e.g., Th=256) generally correlate with **lower values** compared to lower thresholds (e.g., Th=64). - Example: PRAC-1 (Th=64) values are consistently higher than PRAC-1 (Th=128/256). 3. **Category-Specific Observations**: - **450.soplex**: PRAC-4 (Th=64) peaks at **~1.12**, while other thresholds drop to ~1.00. - **437.leslie3d**: PRAC-1 (Th=64) shows a slight increase (~1.01) compared to other thresholds. - **470.lbm**: PRAC-4 (Th=64) has a minor spike (~1.01). --- ## Legend and Axis Labels - **Legend** (top-right): - **PRAC-1**: Dark blue (solid bars). - **PRAC-2**: Gray (diagonal bars). - **PRAC-4**: Red (crosshatch bars). - Thresholds: 64, 128, 256. - **X-Axis Labels** (categories): - 429.mcf, 433.milc, 434.zeusmp, 437.leslie3d, 450.soplex, 459.GemsFDTD, 470.lbm, 519.lbm, 520.omnetpp, 549.fotonik3d, bfs_cm2003, bfs_dblp, bfs_ny, gups, h264_encode. - **Y-Axis Label**: `Avg. Num. of Banks Needing Mitigation` --- ## Data Table Reconstruction | Category | PRAC-1 (Th=64) | PRAC-1 (Th=128) | PRAC-1 (Th=256) | PRAC-2 (Th=64) | PRAC-2 (Th=128) | PRAC-2 (Th=256) | PRAC-4 (Th=64) | PRAC-4 (Th=128) | PRAC-4 (Th=256) | |--------------------|----------------|-----------------|-----------------|----------------|-----------------|-----------------|----------------|-----------------|-----------------| | 429.mcf | ~1.01 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | | 433.milc | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | | 434.zeusmp | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | | 437.leslie3d | ~1.01 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | | 450.soplex | ~1.10 | ~1.00 | ~1.00 | ~1.11 | ~1.00 | ~1.00 | ~1.12 | ~1.00 | ~1.00 | | 459.GemsFDTD | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | | 470.lbm | ~1.01 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.01 | ~1.00 | ~1.00 | | 519.lbm | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | | 520.omnetpp | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | | 549.fotonik3d | ~1.01 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.01 | ~1.00 | ~1.00 | | bfs_cm2003 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | | bfs_dblp | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | | bfs_ny | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | | gups | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | | h264_encode | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | ~1.00 | --- ## Spatial Grounding and Verification - **Legend Placement**: Top-right corner, aligned with bar patterns. - **Color Consistency**: - PRAC-1 (dark blue) = solid bars. - PRAC-2 (gray) = diagonal bars. - PRAC-4 (red) = crosshatch bars. - **Trend Verification**: - PRAC-4 (Th=64) consistently shows the highest values (e.g., 450.soplex: ~1.12). - Thresholds inversely correlate with values (e.g., PRAC-1 Th=64 > Th=128 > Th=256). --- ## Conclusion The chart highlights that **PRAC-4 (Th=64)** generally requires the most mitigation, with **450.soplex** being the most critical category. Thresholds significantly influence mitigation needs, with higher thresholds reducing the average number of banks requiring intervention. </details> Figure 7. Average number of banks that need mitigation on an ABO signal for benign workloads 429.mcf 433.milc 434.zeusmp 437.leslie3d 450.soplex 459.GemsFDTD 470.lbm 519.lbm 520.omnetpp 549.fotonik3d bfs_cm2003 bfs_dblp bfs_ny gups h264_encode $0 0$ $1$ $2$ $3$ $4$ Max Num. of Banks Needing Mitigation PRAC-1 PRAC-2 PRAC-4 Figure 8. Maximum number of banks that need mitigation on an ABO signal for benign workloads. ### 3.3. Exploiting ABO: Performance Attacks The coarse-grained nature of the ABO protocol introduces a new form of unfairness in DRAM systems, making them susceptible to performance slowdown attacks. Because the ABO signal triggers channel-wide stalls without identifying the specific bank responsible for the excessive activation, a malicious actor can exploit this limitation to repeatedly disrupt system-level memory access. In particular, an attacker can intentionally issue frequent row activations to a single bank to induce an ABO event. Since the memory controller stalls the entire memory channel upon receiving an alert, without visibility into which bank requires mitigation, benign workloads distributed across other banks also suffer from the resulting stall. This lack of spatial granularity makes it extremely difficult to attribute the cause of the alert or to selectively suppress malicious access patterns, rendering existing defenses ineffective against such attacks. MOAT (Qureshi and Qazi, 2024) proposed the Torrent-of-Staggered-ALERT (TSA) attack, a performance degradation strategy that carefully coordinates ALERTs across multiple DRAM banks. In this attack, each bank repeatedly activates a small set of rows (e.g., rows A, B, C, D, E) to trigger an ALERT. Crucially, banks issue ACTs in a staggered fashion: a bank only initiates activation once all targeted rows in the previous bank have caused ALERTs and entered the mitigation phase. This serialized activation ensures that when one bank is under mitigation, other banks are forced to stall, as there are no eligible rows to activate without interference. This deliberate serialization of ALERTs forms a torrent of staggered mitigation events, significantly throttling memory concurrency. The attack was shown to reduce system throughput by 24% with four banks and up to 52% with 17 banks, aligning with the tFAW constraint. BreakHammer (Canpolat et al., 2024a) introduces a score-based mitigation framework that assigns a score to each hardware thread based on its contribution to Rowhammer mitigation events. This approach is particularly effective when mitigation logic is implemented within the MC, where score attribution can be performed at finer spatial granularity, such as individual banks or row activations. However, performance degradation attacks may evade detection under BreakHammer when mitigations are signaled via coarse-grained mechanisms such as the Alert Back-Off (ABO) signal. A broader class of memory performance degradation attacks exploits the observation that Rowhammer mitigations, such as recovery operations, are triggered more frequently at lower thresholds. As the mitigation frequency increases, overall system performance degrades significantly. To evaluate the performance cost associated with frequent mitigation, we study the impact of varying thresholds— 64, 32, and 16 as considered in prior works (Woo et al., 2025; Canpolat et al., 2025). Assuming a refresh interval (tREFI) of 3900 ns and a refresh operation latency (REF) of 410 ns, approximately 67 row activations can be issued within one tREFI interval. We consider a closed-row memory policy where each activated row is closed after access. For a realistic scenario, an attacker can alternate between two rows to issue repeated activations. Under a threshold of 64, this behavior can typically trigger one Alert per tREFI. For thresholds of 32 and 16, the number of ALERTs increases proportionally, allowing an attacker to induce two to three (or even four) ALERTs within the same interval. Based on this analysis, we evaluate performance degradation under scenarios involving one, two, and three ALERTs per tREFI duration to quantify the impact of aggressive mitigation triggering. As shown in Figure 9, even a single ABO event per interval results in a 20–30% slowdown for most applications. With three alerts per interval, performance degradation exceeds 80% in several cases. Interestingly, workloads such as h264_encode exhibit resilience due to their lower sensitivity to DRAM stalls, but most others are highly vulnerable. These results demonstrate that the lack of bank-level precision in ABO signaling can be exploited by attackers to inflict disproportionate slowdowns on benign threads, emphasizing the need for spatially-aware mitigation mechanisms. Observation 3: Coarse-grained ABO signaling enables attackers to trigger repeated channel-wide stalls, leading to excessive performance loss. <details> <summary>x8.png Details</summary>  ### Visual Description # Technical Document Analysis of Bar Chart ## Chart Overview The image is a **bar chart** comparing **normalized runtime** across three algorithms (1ABO, 2ABO, 3ABO) for 12 computational datasets. The chart uses vertical bars with distinct colors for each algorithm, plotted against a logarithmic scale of dataset identifiers on the x-axis. --- ### **Key Components** 1. **Legend** - Located at the **top-right corner** of the chart. - **Color coding**: - **Gray**: 1ABO - **Red**: 2ABO - **Blue**: 3ABO 2. **Axes** - **X-axis**: Dataset identifiers (logarithmic scale). - Labels: `429.mcf`, `433.milc`, `434.zeusmp`, `437.leslie3d`, `450.soplex`, `459.GemsFDTD`, `470.lbm`, `519.lbm`, `520.omnetpp`, `549.fotonik3d`, `bfs_cm2003`, `bfs_dblp`, `bfs_ny`, `gups`, `h264_encode`. - **Y-axis**: **Normalized Runtime** (0.0 to 1.0 in increments of 0.2). 3. **Bars** - Each dataset has **three bars** (one per algorithm). - **Color consistency**: - Gray bars (1ABO) are consistently the tallest. - Red bars (2ABO) are intermediate. - Blue bars (3ABO) are the shortest, except for `h264_encode`. --- ### **Key Trends** 1. **General Pattern** - **1ABO** (gray) dominates all datasets, with normalized runtime consistently above **0.7**. - **2ABO** (red) ranges between **0.45–0.55**. - **3ABO** (blue) is the lowest, typically below **0.3**, except for `h264_encode`. 2. **Exception** - For `h264_encode`: - **3ABO** (blue) surpasses **2ABO** (red) but remains below **1ABO** (gray). 3. **Visual Verification** - All bars align with the legend’s color assignments. - No dataset violates the 1ABO > 2ABO > 3ABO trend except `h264_encode`, where 3ABO > 2ABO. --- ### **Data Extraction** | Dataset | 1ABO (Gray) | 2ABO (Red) | 3ABO (Blue) | |---------------------|-------------|------------|-------------| | 429.mcf | ~0.75 | ~0.55 | ~0.25 | | 433.milc | ~0.72 | ~0.50 | ~0.20 | | 434.zeusmp | ~0.73 | ~0.52 | ~0.23 | | 437.leslie3d | ~0.72 | ~0.51 | ~0.24 | | 450.soplex | ~0.72 | ~0.50 | ~0.23 | | 459.GemsFDTD | ~0.71 | ~0.48 | ~0.21 | | 470.lbm | ~0.71 | ~0.49 | ~0.18 | | 519.lbm | ~0.71 | ~0.49 | ~0.19 | | 520.omnetpp | ~0.71 | ~0.50 | ~0.22 | | 549.fotonik3d | ~0.72 | ~0.51 | ~0.23 | | bfs_cm2003 | ~0.72 | ~0.52 | ~0.25 | | bfs_dblp | ~0.72 | ~0.52 | ~0.25 | | bfs_ny | ~0.72 | ~0.50 | ~0.24 | | gups | ~0.72 | ~0.48 | ~0.26 | | h264_encode | ~0.95 | ~0.90 | ~0.88 | --- ### **Spatial Grounding** - **Legend Position**: Top-right corner. - **Bar Alignment**: Colors match legend labels exactly. - **X-axis Order**: Datasets are listed in ascending order of identifier values (e.g., `429.mcf` to `h264_encode`). --- ### **Conclusion** The chart demonstrates that **1ABO** consistently exhibits the highest normalized runtime across all datasets, while **3ABO** is the most efficient except for `h264_encode`, where it outperforms **2ABO**. The data suggests algorithmic performance varies significantly by dataset type. </details> Figure 9. Percentage slowdown of benign applications when there is a 1, 2 and 3 ABO alerts happening in each tREFI ## 4. PRACtical Design and Implementation To overcome the limitations of PRAC+ABO, we introduce PRACtical—an enhanced version that builds upon the original framework. PRACtical extends the underlying mechanisms to significantly reduce performance overheads while maintaining the robust security guarantees offered by state-of-the-art Rowhammer mitigation techniques. This section presents an overview of the design and implementation of PRACtical. ### 4.1. Overview and Design Goals The core design principle of PRACtical is to minimize the performance overheads inherent in the original PRAC+ABO mechanism. Specifically, the design aims to achieve the following two objectives: 1. Reduce PRAC update latency through subarray-level decoupling. Enable subarray-level counter updates to allow overlapping the counter update time of a row with activation of the next row when rows are non-conflicting at subarray-level, eliminating the 21ns counter update delay. 1. Minimize unnecessary memory stalls with fine-grained recovery command. Refine RFM ab to operate at bank-level granularity, allowing the memory controller to stall only the affected banks instead of the entire channel. ### 4.2. Hardware Modifications PRACtical introduces minimal hardware modifications to enable fine-grained, low-latency RowHammer mitigation by enhancing the PRAC+ABO feature. First, to support subarray-level PRAC updates, the traditional bank-level increment logic, typically located near the global row buffer, is replaced with a centralized increment circuit that is connected to local row buffers in subarrays through a different bus (8-wire bus for 8-bit counters). This design allows counter updates without delaying the subsequent memory accesses to the memory bank that do not conflict at the subarray level. Correspondingly, the memory controller is extended with subarray mapping logic and an address decoder capable of identifying the target subarray for each memory request. Second, to enable fine-grained bank-level recovery stalling, the DRAM chip is modified to include a new control register called the Bank Alert (BA) register. This register contains one bit per bank, where each bit indicates whether a given bank has any rows with an activation number higher than the Alert threshold. The contents of the BA register are communicated to the memory controller and serve as a mask, allowing the controller to selectively stall only the requests to the banks under mitigation while continuing to issue commands to unaffected banks. ### 4.3. PRACtical Mechanism PRACtical introduces two core mechanisms to reduce the performance overheads associated with the PRAC+ABO framework while maintaining its security guarantees against RowHammer attacks. #### 4.3.1. Subarray-Level PRAC Updates <details> <summary>x9.png Details</summary>  ### Visual Description # Technical Document Extraction: Memory Controller and DRAM Bank Architecture ## Left Section: Memory Controller (Memory Ctrl.) Flowchart ### Components and Flow: 1. **Memory Access** - **Input**: Initiates memory access request. - **Output**: Triggers "Find Subarray ID" step. 2. **Find Subarray ID** - **Purpose**: Identifies the target subarray for memory access. - **Output**: Feeds into "SA Conflict?" decision node. 3. **SA Conflict?** (Decision Diamond) - **Yes Path**: - **PRAC Timing** (Step 3): - **Function**: Manages PRAC (Precharge to Active) timing constraints. - **Output**: Triggers "No Need to Wait for Subarray PRAC Update" (Step 4). - **No Path**: - **Loop**: Returns to "Find Subarray ID" (Step 1). 4. **No Need to Wait for Subarray PRAC Update** - **Function**: Confirms subarray is ready for access without PRAC delay. - **Output**: Completes memory access cycle. ### Color Coding: - **Pink**: Decision nodes and timing steps (e.g., "SA Conflict?", "PRAC Timing"). - **Green**: Final confirmation step ("No Need to Wait..."). --- ## Right Section: DRAM Bank Architecture ### Hierarchical Structure: 1. **Global Row Decoder** - **Input**: Receives row address signals. - **Output**: Routes signals to individual subarrays. 2. **Subarrays** (2 instances shown) - **Structure**: - **Blue Blocks**: Represent subarray memory cells. - **Pink Counters**: Track access operations (e.g., row activations). - **Connections**: - Linked to **Local Row Buffers** via vertical lines. 3. **Local Row Buffers** (2 instances) - **Function**: Temporarily store data during row access. - **Connections**: - Feed into **Global Row Buffer** via horizontal lines. 4. **Global Row Buffer** - **Role**: Aggregates data from all local buffers for output. - **Output**: Final data path marked with a "+" symbol. ### Spatial Grounding: - **Vertical Flow**: - Global Row Decoder → Subarrays → Local Row Buffers → Global Row Buffer. - **Color Legend**: - **Blue**: Subarrays. - **Gray**: Buffers (Local/Global). - **Pink**: Counters. --- ## Key Observations: 1. **Memory Controller Logic**: - Prioritizes conflict resolution ("SA Conflict?") to optimize PRAC timing. - Avoids unnecessary delays via conditional checks. 2. **DRAM Bank Design**: - Hierarchical buffering (local → global) minimizes latency. - Counters enable real-time monitoring of access patterns. 3. **Integration**: - Memory controller coordinates with DRAM bank via subarray ID resolution. - PRAC timing management ensures synchronization between controller and bank. ## Notes: - No numerical data or trends present; diagram focuses on architectural flow and component interactions. - All labels and textual elements transcribed verbatim. - Color coding aligns with component roles (e.g., pink for timing/counters). </details> Figure 10. PRACtical adds subarray-level PRAC increment logic to enable independent counter updates and avoid bank-wide stalls across all subarrays. This mechanism improves subarray-level parallelism by enabling PRAC counter updates at the subarray level, rather than enforcing bank-wide delays. In the original PRAC design, counter updates introduce additional latency, particularly during precharge operations, because the increment logic is shared at the bank level. This design forces all subarrays within the bank to stall while the update completes. PRACtical addresses this limitation by introducing a centralized PRAC increment logic that connects to the local row buffers of all subarrays, as illustrated in Figure 10. Upon receiving a memory access request, the memory controller computes the subarray identifier (Subarray ID) for the target row 1. If the new request targets the same subarray or nearby subarray that is currently undergoing a PRAC update (i.e. subarray conflict) 2, the controller applies the required timing constraints to ensure that the update completes before issuing a new activation 3. In contrast, if the access targets a different non-conflicting subarray, the controller can proceed with the activation command immediately, without waiting for the PRAC update to finish 4. In this case, counter value of the precharged row is forwarded to the increment unit and the entire row is transferred from the global to the local row buffer. This precharge operation takes 15 ns to complete. After this delay, the increment circuit updates the counter and transmits the new value to the corresponding local row buffer via a dedicated counter data bus. This approach allows subarrays to operate independently, preventing unrelated memory accesses from being delayed by PRAC updates in other subarrays, as illustrated in Figure 11. As a result, PRACtical reduces access latency, particularly in workloads that exhibit diverse subarray access patterns. <details> <summary>x10.png Details</summary>  ### Visual Description # Technical Document Extraction: Subarray Timing Diagram ## Diagram Overview The image depicts a timing diagram comparing two subarrays (A and B) with three components: ACT (green), RAS (blue), and PRE (red). The x-axis represents time in nanoseconds (ns), and the y-axis distinguishes between Subarray A and Subarray B. --- ## Key Labels and Axis Markers - **X-axis**: - Title: `time (ns)` - Markers: `31`, `52`, `83`, `104` - **Y-axis**: - Labels: `Subarray A` (top), `Subarray B` (bottom) - **Legend**: - Located at the top-right corner. - Colors: - Green: `ACT` - Blue: `RAS` - Red: `PRE` --- ## Component Flow and Conflict Analysis ### Subarray A 1. **Conflict Scenario**: - Components `ACT` (31 ns), `RAS` (52 ns), and `PRE` (83 ns) overlap with a `PRE` component starting at 52 ns. - Conflict is marked with a clock symbol between `52 ns` and `83 ns`. - Visual overlap indicates timing incompatibility. 2. **Component Positions**: - `ACT`: Starts at `31 ns` - `RAS`: Starts at `52 ns` - `PRE`: Starts at `83 ns` ### Subarray B 1. **No Conflict Scenario**: - Components `ACT` (52 ns), `RAS` (83 ns), and `PRE` (104 ns) are spaced without overlap. - Visual separation confirms no timing conflicts. 2. **Component Positions**: - `ACT`: Starts at `52 ns` - `RAS`: Starts at `83 ns` - `PRE`: Starts at `104 ns` --- ## Trend Verification - **Subarray A**: - `ACT` and `RAS` components precede `PRE`, but their overlap with `PRE` creates a conflict. - Time progression: `31 → 52 → 83 ns` with overlapping intervals. - **Subarray B**: - Components are sequentially spaced: `52 → 83 → 104 ns` with no overlap. --- ## Spatial Grounding - **Legend Position**: Top-right corner (coordinates: `[x=900, y=50]` relative to diagram). - **Conflict Marker**: Dashed line with clock symbol between `52 ns` and `83 ns` in Subarray A. - **Component Colors**: - Green (`ACT`) matches Subarray A’s first component. - Blue (`RAS`) matches Subarray A’s second component. - Red (`PRE`) matches Subarray A’s third component and Subarray B’s third component. --- ## Conclusion The diagram illustrates timing conflicts in Subarray A due to overlapping components, while Subarray B avoids conflicts through sequential spacing. Critical time markers (`31`, `52`, `83`, `104 ns`) and component labels (`ACT`, `RAS`, `PRE`) are explicitly defined. </details> Figure 11. Illustration of conflicting (top row) and non-conflicting (bottom row) memory accesses across subarrays, demonstrating how PRACtical uses parallelism by avoiding unnecessary delay. #### 4.3.2. Bank-Level Stall for Recovery <details> <summary>x11.png Details</summary>  ### Visual Description # Technical Diagram Analysis: Memory Control and DRAM Rank System ## Diagram Overview The image depicts a technical system diagram illustrating memory control operations and DRAM rank management. The diagram is divided into two primary sections: **Memory Ctrl.** (left) and **DRAM Rank** (right), with bidirectional interactions between them. --- ## Left Section: Memory Ctrl. ### Components and Flow 1. **Trigger RFM** (Red Box) - Label: `Trigger RFM` - Spatial Position: Top-left corner of the left section - Connection: Arrows point to: - `Send RFM_MASK Command` (Gray Box) - `Send DRAM Commands Based on BA Mask` (Green Box) 2. **Send RFM_MASK Command** (Gray Box) - Label: `Send RFM_MASK Command` - Spatial Position: Directly below `Trigger RFM` - Connection: Arrows point to: - `Bank Alert (BA) Register` (Right Section) - `Send DRAM Commands Based on BA Mask` (Green Box) 3. **Send DRAM Commands Based on BA Mask** (Green Box) - Label: `Send DRAM Commands Based on BA Mask` - Spatial Position: Bottom-left corner of the left section - Connection: Arrows point to: - `Send BA to Mem Ctrl.` (Gray Box, Right Section) ### Timing Information - **180 ns Delay**: Indicated between `Trigger RFM` and `Send RFM_MASK Command` with a clock icon. --- ## Right Section: DRAM Rank ### Components and Flow 1. **Bank 1** (Highlighted in Red) - Label: `Bank 1` - Icon: Hammer with lightning bolts (symbolizing "under attack") - Spatial Position: First bank in the sequence - Connection: Arrows point to: - `Bank Alert (BA) Register` (Right Section) 2. **Bank 2 to Bank n** (Light Blue Boxes) - Labels: `Bank 2`, `Bank n` - Spatial Position: Middle and rightmost banks - Connection: No direct arrows; part of the DRAM rank array. 3. **Bank Alert (BA) Register** (Binary Sequence) - Label: `Bank Alert (BA) Register` - Binary Values: `1 0 ... 0` (with `n-1` as the last index) - Spatial Position: Right side of the diagram - Connection: Arrows point to: - `Send BA to Mem Ctrl.` (Gray Box, Right Section) 4. **Send BA to Mem Ctrl.** (Gray Box) - Label: `Send BA to Mem Ctrl.` - Spatial Position: Bottom-center of the right section - Connection: Arrows point to: - `Send DRAM Commands Based on BA Mask` (Left Section) --- ## Step-by-Step Process (Numbered Labels) 1. **ABO** (Step 1) - Label: `ABO` (Red text) - Connection: Dotted arrow from `Bank 1` to `Bank Alert (BA) Register` 2. **180 ns Delay** (Step 2) - Label: `180 ns` - Connection: Between `Trigger RFM` and `Send RFM_MASK Command` 3. **Bank Alert (BA) Register** (Step 3) - Label: `Bank Alert (BA) Register` - Binary Sequence: `1 0 ... 0` 4. **Send BA to Mem Ctrl.** (Step 4) - Label: `Send BA to Mem Ctrl.` - Connection: From `Bank Alert (BA) Register` to `Send DRAM Commands Based on BA Mask` 5. **Send DRAM Commands Based on BA Mask** (Step 5) - Label: `Send DRAM Commands Based on BA Mask` - Connection: From `Send BA to Mem Ctrl.` back to `Memory Ctrl.` --- ## Color Coding and Legend - **Red**: Indicates critical components (`Trigger RFM`, `Bank 1` under attack). - **Gray**: Represents command/control operations (`Send RFM_MASK Command`, `Send BA to Mem Ctrl.`). - **Green**: Denotes actions based on Bank Alert (`Send DRAM Commands Based on BA Mask`). - **Light Blue**: Neutral DRAM banks (`Bank 2` to `Bank n`). --- ## Key Trends and Data Points - **Attack Simulation**: `Bank 1` is explicitly marked as "under attack" with a hammer icon, suggesting a focus on security or fault tolerance. - **Binary Alert System**: The `Bank Alert (BA) Register` uses a binary sequence (`1 0 ... 0`) to indicate active alerts, with only the first bank (`Bank 1`) flagged. - **Cyclic Interaction**: The system forms a closed loop between `Memory Ctrl.` and `DRAM Rank`, with timing constraints (180 ns) ensuring synchronization. --- ## Spatial Grounding - **Legend Colors**: - Red: `Trigger RFM`, `Bank 1` - Gray: `Send RFM_MASK Command`, `Send BA to Mem Ctrl.` - Green: `Send DRAM Commands Based on BA Mask` - Light Blue: `Bank 2` to `Bank n` - **Binary Sequence**: `1 0 ... 0` in the `Bank Alert (BA) Register` indicates a single active alert (Bank 1). --- ## Conclusion This diagram outlines a memory control system that detects attacks on DRAM banks (specifically Bank 1), generates alerts via a binary register, and dynamically adjusts DRAM commands based on the Bank Alert Mask (BA Mask). The 180 ns delay ensures precise timing for command execution. </details> Figure 12. Bank-Level Recovery Stall in PRACtical Using the Bank Alert (BA) Register and RFM_MASK. PRACtical addresses the limitation of coarse-grained mitigation in the original PRAC+ABO framework by introducing bank-level recovery stall, enabling the memory controller to restrict mitigation only to the affected banks rather than stalling the entire memory channel. This selective mitigation is made possible through the use of a BA register, which functions as a mask to identify and isolate banks requiring Rowhammer mitigation as illuatrated in Figure 12. When the PRAC counter of a bank exceeds the Alert threshold, the DRAM device sends the ABO signal to the memory controller 1. Upon receiving this signal, the memory controller enters a pre-recovery window, lasting 180 nanoseconds, during which it continues to process memory requests as normal 2. After this window, the controller issues RFM ab command to the DRAM to initiate recovery. PRACtical repurposes this command into a new command, termed RFM_MASK (Masked Refresh Management), which performs two key functions; it initiates recovery and functions as a register read command. First, the RFM_MASK command triggers the in-DRAM recovery mechanism for the affected bank 3. Second, it returns the contents of the BA register to the memory controller, indicating which banks are currently under mitigation 4. The BA register is reset once it is read. After its reset, a bank can set the corresponding bit in the register. The controller uses this information as a bitmask to manage access granularity during recovery. For any new memory request, the memory controller checks whether the target bank is marked as active in the BA register. If the request targets an unaffected bank, the controller proceeds to issue the command without delay. However, if the request targets a bank under recovery, the controller stalls the request until the mitigation phase completes 5. Figure 13 illustrates how PRACtical leverages bank-level recovery stall to improve memory parallelism during RFM refreshes. In this example, Bank 1 exceeds the Alert threshold and triggers an ABO signal, initiating a short pre-recovery phase followed by the recovery phase. The banks modify their own bits in the register. Bank 1 will set its bit to 1. Upon receiving the RFM_MASK command the DRAM sends the contents of the BA register (0b1001) to the MC, which encodes the mitigation status of all banks. The BA mask in this case indicates that Bank 1 is under mitigation. As a result, the memory controller selectively stalls requests to Bank 1 while continuing to issue accesses to unaffected Banks 2 and 3. This fine-grained handling contrasts with the baseline PRAC+ABO design, where all banks would be stalled upon any ABO event. PRACtical thus reduces unnecessary interference and improves memory-level concurrency during mitigation. <details> <summary>x12.png Details</summary>  ### Visual Description # Technical Diagram Analysis ## Diagram Overview The image depicts a memory access timing diagram with three memory banks (A, B, C) and a Bank Address (BA) register. The diagram illustrates access patterns over time with specific annotations for memory operations. ## Key Components 1. **Memory Banks** - **Bank A**: Contains two access periods with a red "RFM" (Read/Modify/Write) operation between them - **Bank B**: Single continuous access period - **Bank C**: Single continuous access period 2. **BA Register** - Binary representation: `100` - Legend indicates Bank A is active during this time period 3. **Annotations** - **ABO Arrow**: Points to "Pre-Recovery" phase in Bank A's access sequence - **RFM Mask**: Highlights the red "RFM" operation in Bank A ## Temporal Analysis - **X-axis**: Time progression (left to right) - **Y-axis**: Memory banks (A, B, C) - **Time Segments**: - Pre-Recovery phase (annotated by ABO arrow) - RFM operation (red section in Bank A) - Subsequent access periods in all banks ## Color Coding - **Green**: Standard memory access periods - **Red**: RFM (Read/Modify/Write) operation - **Gray**: Binary representation in BA Register ## Spatial Grounding - **Legend Position**: Top-right corner - **BA Register**: Binary `100` corresponds to active Bank A - **RFM Mask**: Red section in Bank A's timeline ## Trend Verification 1. **Bank A**: - Pattern: Access → RFM → Access - RFM operation occurs between two access periods 2. **Bank B**: - Continuous access throughout the timeline 3. **Bank C**: - Continuous access throughout the timeline ## Data Table Reconstruction | Bank | Binary State | Access Pattern | |------|--------------|-------------------------| | A | 1 | Access → RFM → Access | | B | 0 | Continuous Access | | C | 0 | Continuous Access | ## Component Isolation 1. **Header**: BA Register binary representation (`100`) 2. **Main Chart**: Memory bank access timelines with RFM annotation 3. **Footer**: Time axis progression ## Critical Observations 1. The BA Register's `100` binary state directly correlates with Bank A's active status during the RFM operation 2. The ABO arrow indicates a recovery phase occurring between Bank A's access periods 3. The RFM operation in Bank A creates a temporal gap in its access sequence compared to Banks B and C ## Language Declaration All text in the diagram is in English. No non-English content detected. </details> Figure 13. In this example, Bank 1 triggers ABO and enters recovery. Based on the BA mask, accesses to Banks 1 are stalled, while Banks 2 and 3 remain accessible. ## 5. Experimental Methodology We utilize a cycle-accurate, open-source memory simulator, Ramulator 2.0 (Luo et al., 2023b; SAFARI Research Group, 2021). Our evaluation is on the existing PRAC+ABO framework and our proposed solution, PRACtical. We use the provided PRAC+ABO with RFM in Ramulator2.0. Furthermore, we evaluate Chronus (Canpolat et al., 2025) with PRACtical and compare the performance. Table 2. Simulator Configurations | CPU | 4-core, 4.2 GHz, 128-entry instruction window | | --- | --- | | Last-Level Cache | 2MB per core, total 8MB (16-way set-associative) | | Memory Controller | 32-entry read/write queues | | Scheduling: FR-FCFS + Cap of 4 | | | Address mapping: MOP | | | Main Memory | DDR5 DRAM, 1 channel, 2 ranks, 8 bank groups, | | 4 banks/group, 64K rows/bank | | System configuration is presented in table 2. We use a pool of traces from SPEC CPU2006 (spe, 2006), SPEC CPU2017 (spe, 2017), TPC (Transaction Processing Performance Council, 2025), MediaBench (Fritts et al., 2009) and YCSB (Cooper et al., 2010). The category of each trace is determined based on row buffer conflict per kilo instructions (RBMPKI). The traces are divided into High (H: $≥$ 10 RBMPKI), Medium (M: 2–10 RBMPKI), and Low (L: $<$ 2 RBMPKI) memory usage, as shown in Table 3. For evaluation, we use 4 different traces to form groups of HHHH, MMMM, LLLL, HHMM, MMLL, and LLHH as mixed workloads, represented in Table 4. For evaluation, we use 10 workloads from each group and run 100M instructions for simulation. Our simulation configuration aligns with previous wroks (Olgun et al., 2024; Canpolat et al., 2025; Woo et al., 2025). <details> <summary>x13.png Details</summary>  ### Visual Description # Technical Document Analysis of Chart Image ## Chart Overview The image depicts a **grouped bar chart** comparing normalized speedup values across 60 categories (`Mix0` to `Mix59`). The chart uses **patterned bars** (solid, crosshatch) with distinct colors to represent different data series, as defined in the legend. --- ### Axis Labels and Scale - **X-axis**: Labeled with categories `Mix0` to `Mix59` (60 total). - **Y-axis**: Labeled "Normalized Speedup" with a scale from **0.0 to 1.2** in increments of 0.2. - **Legend**: Located in the **top-right corner**, mapping colors/patterns to data series: - **T64, Prac-1**: Blue (solid) - **T128, Prac-1**: Orange (crosshatch) - **T256, Prac-1**: Green (solid) - **T64, Prac-2**: Blue (solid) - **T128, Prac-2**: Orange (crosshatch) - **T256, Prac-2**: Green (solid) - **T64, Prac-4**: Blue (solid) - **T128, Prac-4**: Orange (crosshatch) - **T256, Prac-4**: Green (solid) --- ### Key Trends and Data Points 1. **General Range**: - Most bars cluster between **1.0 and 1.2** on the y-axis. - Peaks and troughs vary slightly across categories. 2. **Highest Peaks**: - **Mix10**: Reaches ~1.2 (highest observed value). - **Mix30**: ~1.15. - **Mix50**: ~1.1. 3. **Lowest Values**: - **Mix55**: Dips to ~0.95 (lowest observed value). - **Mix20** and **Mix40**: ~1.0. 4. **Pattern Consistency**: - All bars for a given data series (e.g., `T64, Prac-1`) share the same color and pattern. - Example: `T64, Prac-1` (blue solid) consistently appears across all `Mix` categories. --- ### Component Isolation 1. **Header**: No explicit title is visible in the image. 2. **Main Chart**: - 60 vertical groups of bars (one per `Mix` category). - Each group contains **9 bars** (one per legend entry). 3. **Footer**: - X-axis labels (`Mix0` to `Mix59`) are evenly spaced. --- ### Data Table Reconstruction (Approximate) | Mix Category | T64, Prac-1 | T128, Prac-1 | T256, Prac-1 | T64, Prac-2 | T128, Prac-2 | T256, Prac-2 | T64, Prac-4 | T128, Prac-4 | T256, Prac-4 | |--------------|-------------|--------------|--------------|-------------|--------------|--------------|-------------|--------------|--------------| | Mix0 | ~1.05 | ~1.10 | ~1.08 | ~1.03 | ~1.07 | ~1.09 | ~1.02 | ~1.06 | ~1.04 | | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | | Mix59 | ~1.08 | ~1.12 | ~1.10 | ~1.06 | ~1.10 | ~1.12 | ~1.05 | ~1.09 | ~1.07 | *Note: Values are approximate based on visual estimation of bar heights.* --- ### Spatial Grounding and Accuracy Checks - **Legend Position**: Top-right corner (confirmed). - **Color/Pattern Matching**: - Example: `T64, Prac-1` (blue solid) matches all blue solid bars. - `T128, Prac-1` (orange crosshatch) aligns with orange crosshatched bars. - **Trend Verification**: - Most data series exhibit **flat trends** with minor fluctuations. - Exceptions: `T64, Prac-1` shows a slight upward trend in later `Mix` categories. --- ### Conclusion The chart compares normalized speedup values across 60 `Mix` categories for 9 distinct data series. While most values cluster tightly between 1.0 and 1.2, notable peaks and troughs occur at specific `Mix` indices. The legend ensures clear differentiation of data series via color and pattern. </details> Figure 14. Performance evaluation of PRACtical using normalized speedup over PRAC+ABO | High (H) | 429.mcf, 433.milc, 434.zeusmp, 450.soplex, 459.GemsFDTD, 462.libquantum, 470.lbm, 482.sphinx3, 483.xalancbmk, 510.parest, 519.lbm, 549.fotonik3d, gups, 520.omnetpp | | --- | --- | | Medium (M) | 436.cactusADM, 473.astar, 507.cactuBSSN, 557.xz, jp2_decode, jp2_encode, tpcc64, tpch17, tpch2, wc_8443, wc_map0, ycsb_aserver, ycsb_bserver, ycsb_cserver, ycsb_eserver | | Low (L) | 401.bzip2, 403.gcc, 435.gromacs, 444.namd, 445.gobmk, 447.dealII, 456.hmmer, 458.sjeng, 481.wrf, 500.perlbench, 502.gcc, 508.namd, 511.povray, 523.xalancbmk, 526.blender, 538.imagick, 541.leela, 544.nab, grep_map0, tpch6, ycsb_abgsave | Table 3. Grouping of Benchmarks by Memory Usage | HHHH | Mix0 to 9 | | --- | --- | | MMMM | Mix10 to 19 | | LLLL | Mix20 to 29 | | HHMM | Mix30 to 39 | | MMLL | Mix40 to 49 | | LLHH | Mix50 to 59 | Table 4. Mapping of Workload Types to Mixed Types ## 6. Evaluation In this section we evaluate the performance improvements and compare results against similar state-of-the-art works. First, PRACtical is compared against standard PRAC with an Alert Back-Off signal to show performance benefit over standard JEDEC specifications. Then, we evaluate PRACtical’s effectiveness on one PRAC+ABO-based solution, QPRAC. We also show how resilient PRACtical is to chain attacks 3.3. ### 6.1. Performance and Energy Evaluation <details> <summary>x14.png Details</summary>  ### Visual Description # Technical Document Extraction: Performance Speedup Analysis ## Chart Type Bar chart comparing performance speedup percentages across different PRAC categories and computational thresholds. ## Axes Labels - **X-axis**: PRAC categories (`PRAC-1`, `PRAC-2`, `PRAC-4`, `All`) - **Y-axis**: `Performance Speedup (%)` (range: 0–8.5%, increments of 2%) ## Legend - **Title**: `Threshold` - **Entries**: - `64` (blue) - `128` (orange) - `256` (green) - `Geomean` (gray) ## Spatial Grounding - Legend positioned at the **top-right** of the chart. - Colors of bars match legend entries exactly (e.g., blue = 64, orange = 128, etc.). ## Data Points and Trends ### PRAC-1 - **64**: 7.1% (blue bar, lowest value) - **128**: 7.8% (orange bar, moderate increase) - **256**: 8.0% (green bar, peak) - **Geomean**: 7.7% (gray bar, slight decline from 256) ### PRAC-2 - **64**: 7.9% (blue bar, near peak) - **128**: 8.0% (orange bar, stable) - **256**: 8.0% (green bar, stable) - **Geomean**: 8.0% (gray bar, flat) ### PRAC-4 - **64**: 8.4% (blue bar, highest value) - **128**: 8.3% (orange bar, slight decline) - **256**: 8.2% (green bar, further decline) - **Geomean**: 8.3% (gray bar, recovers slightly) ### All - **Geomean**: 8.0% (gray bar, singular value) ## Key Observations 1. **Threshold Impact**: - Higher thresholds (256) generally yield higher speedups than lower thresholds (64, 128) in most PRAC categories. - Exceptions: PRAC-1 shows a slight decline from 256 to Geomean (8.0% → 7.7%). 2. **PRAC Category Performance**: - `PRAC-4` achieves the highest speedup (8.4% at 64 threshold). - `PRAC-1` has the lowest baseline speedup (7.1% at 64 threshold). 3. **Geomean Consistency**: - `Geomean` values stabilize at ~8.0% across all categories except PRAC-1. ## Missing Elements - No explicit chart title (only legend title "Threshold" is present). - No secondary y-axis or annotations beyond bar labels. ## Language All text is in **English**. No non-English content detected. </details> Figure 15. Performance Comparison of PRACtical and opportunistic PRAC+ABO for recoveries of 1, 2, and 4 and thresholds of 64, 128, and 256 PRACtical vs. PRAC+ABO. The performance evaluation results comparing PRACtical with the standard (opportunistic) PRAC+ABO framework are presented in Figure 14 and geometric mean results are shown in Figure 15. The evaluation includes both PRACtical and PRAC across configurations with n=1,2, and 4 RFM s as PRAC-1, PRAC-2, and PRAC-4, respectively, with Alert thresholds of 64, 128, and 256. We use a suite of mixed workloads composed of traces with high, medium, and low memory usage characteristics. The results demonstrate that PRACtical outperforms the baseline PRAC+ABO framework. Along the mixes, high and medium memory intensity combinations showcase more speedup (up to 20%). Mean values show that PRACtical provides 7-9% better performance. This performance improvement benefits mostly from subarray-level PRAC updates. The overhead was 6% on average. Hence, PRACtical has 2-3% performance improvement due to bank-level recovery stalling. Although this performance improvement might seem very low, the critical target of this optimization is to eliminate energy inefficiency. Energy Comparison. In this evaluation, we compare the energy consumption of PRACtical and PRAC+ABO with opportunistic mitigation. Figure 16 depicts the difference in the energy consumption due to extra RFM refreshes of opportunistic mitigation. The results align with our expectations; while the opportunistic mode of PRAC+ABO improves performance by preemptively refreshing rows before they become hot, it also introduces a large number of unnecessary refreshes, significantly increasing energy consumption. On average, across all evaluated recovery and threshold configurations, opportunistic PRAC+ABO consumes 19% more energy compared to PRACtical. Across different configurations of recoveries (1,2, and 4) and thresholds, the values slightly vary. The biggest difference happens with PRAC-4 (rec=4), and the threshold 64, which aligns with the observation of the most unnecessary RFM refreshes in sec 3. These findings underscore a fundamental trade-off: while opportunistic mitigation strategies can minimize performance degradation by anticipating high-activation rows early, this comes at the cost of substantially increased energy usage, reducing the overall efficiency of the memory system. <details> <summary>x15.png Details</summary>  ### Visual Description # Technical Document Analysis: Energy Efficiency Comparison Chart ## Chart Type Bar chart comparing energy efficiency metrics across different Prac categories and thresholds. ## Axes - **X-axis (Categories):** - Prac-1 - Prac-2 - Prac-4 - All - **Y-axis (Values):** - Energy Comparison (%) - Range: 0.0% to 20.0% (in 2.5% increments) - Labels: Numerical percentages (e.g., 18.6%, 19.1%) ## Legend - **Location:** Top of the chart - **Color-Coded Thresholds:** - **Blue (#1f77b4):** 64 - **Orange (#ff7f0e):** 128 - **Green (#2ca02c):** 256 - **Gray (#9467bd):** Geomean ## Data Points & Trends ### Prac-1 - **Threshold 64 (Blue):** 18.3% - **Threshold 128 (Orange):** 18.5% - **Threshold 256 (Green):** 18.6% - **Geomean (Gray):** 18.6% - *Trend:* Gradual increase from 64 to 256 thresholds, with Geomean matching the highest threshold. ### Prac-2 - **Threshold 64 (Blue):** 19.5% - **Threshold 128 (Orange):** 19.0% - **Threshold 256 (Green):** 19.0% - **Geomean (Gray):** 19.1% - *Trend:* Slight decline from 64 to 128/256 thresholds, with Geomean slightly higher than 128/256. ### Prac-4 - **Threshold 64 (Blue):** 20.8% - **Threshold 128 (Orange):** 19.3% - **Threshold 256 (Green):** 19.2% - **Geomean (Gray):** 19.7% - *Trend:* Sharp drop from 64 to 128/256 thresholds, with Geomean significantly higher than individual thresholds. ### All - **Geomean (Gray):** 19.0% - *Trend:* Single data point representing aggregated Geomean across all Prac categories. ## Key Observations 1. **Threshold Impact:** - Higher thresholds (256) generally show lower energy efficiency than lower thresholds (64/128), except in Prac-4 where 64 outperforms others. 2. **Geomean Consistency:** - Geomean values are consistently higher than individual thresholds in Prac-2 and Prac-4, suggesting a balancing effect. 3. **Aggregation ("All"):** - The "All" category Geomean (19.0%) is lower than Prac-4's Geomean (19.7%), indicating variability across Prac categories. ## Spatial Grounding - **Legend Position:** Top-center, aligned with x-axis categories. - **Bar Alignment:** Each Prac category has four bars (64, 128, 256, Geomean), except "All," which has only Geomean. ## Component Isolation - **Header:** Chart title ("Threshold") and legend. - **Main Chart:** Four grouped bars per Prac category (except "All"). - **Footer:** Y-axis labels and percentage increments. ## Data Table Reconstruction | Category | Threshold 64 (%) | Threshold 128 (%) | Threshold 256 (%) | Geomean (%) | |----------|------------------|-------------------|-------------------|-------------| | Prac-1 | 18.3 | 18.5 | 18.6 | 18.6 | | Prac-2 | 19.5 | 19.0 | 19.0 | 19.1 | | Prac-4 | 20.8 | 19.3 | 19.2 | 19.7 | | All | - | - | - | 19.0 | ## Language Notes - **Primary Language:** English (all labels, axis titles, and annotations). - **No Additional Languages Detected.** </details> Figure 16. Energy Comparison of PRACtical and PRAC for recoveries of 1, 2, and 4 and thresholds of 64, 128, and 256 PRACtical vs Baseline architecture. In this evaluation, we assess the performance of PRACtical in comparison to a baseline architecture, where the baseline represents a DRAM system without any Rowhammer mitigation mechanisms. As illustrated in Figure 17, PRACtical achieves performance levels nearly identical to the baseline. The only observable performance degradation is a minor slowdown of approximately 1%, which occurs under the configuration with a recovery count of 1 or 2 RFM s and a threshold of 64. This minimal overhead demonstrates that PRACtical introduces negligible performance penalties, effectively maintaining baseline performance even in the presence of Rowhammer protection. <details> <summary>x16.png Details</summary>  ### Visual Description # Technical Document Analysis: Performance Speedup Chart ## Chart Overview The image is a **grouped bar chart** titled **"Performance Speedup"**. It compares performance metrics across different computational thresholds (64, 128, 256) and a geometric mean (Geomean) across four categories: **PRAC-1**, **PRAC-2**, **PRAC-4**, and **All**. --- ## Axes and Labels - **X-Axis**: Categories: `PRAC-1`, `PRAC-2`, `PRAC-4`, `All` Labels are evenly spaced and centered under each group of bars. - **Y-Axis**: Title: `Performance Speedup` Scale: `0.0` to `1.0` in increments of `0.2` Dotted gridlines at `0.2`, `0.4`, `0.6`, `0.8`, `1.0`. - **Legend**: Position: Top of the chart Colors and Labels: - `64` (blue) - `128` (orange) - `256` (green) - `Geomean` (gray) --- ## Data Points and Trends ### Key Observations: 1. **All Bars Reach Maximum Value**: - Every bar (for all thresholds and categories) reaches `1.0` on the y-axis. - This indicates **100% performance speedup** across all configurations. 2. **Geomean Consistency**: - The `Geomean` (gray) bar matches the value of `1.0` for all categories, confirming it is the geometric mean of the thresholds (64, 128, 256). 3. **Uniform Performance**: - No variation exists between thresholds (`64`, `128`, `256`) or categories (`PRAC-1`, `PRAC-2`, `PRAC-4`, `All`). - All bars are **flat at 1.0**, showing no upward or downward trend. --- ## Spatial Grounding and Color Verification - **Legend Colors**: - `64` (blue) matches the leftmost bar in each group. - `128` (orange) matches the second bar. - `256` (green) matches the third bar. - `Geomean` (gray) matches the rightmost bar in each group. - **Spatial Placement**: - Legend is positioned at the **top** of the chart, above the x-axis labels. - Bars are grouped vertically under each x-axis category. --- ## Component Isolation ### Header: - Title: `Performance Speedup` - Legend: Thresholds (`64`, `128`, `256`) and `Geomean`. ### Main Chart: - **X-Axis Categories**: - `PRAC-1`: All bars at `1.0`. - `PRAC-2`: All bars at `1.0`. - `PRAC-4`: All bars at `1.0`. - `All`: Single gray bar (Geomean) at `1.0`. ### Footer: - No additional text or annotations. --- ## Data Table Reconstruction | Category | 64 | 128 | 256 | Geomean | |------------|------|------|------|---------| | PRAC-1 | 1.0 | 1.0 | 1.0 | 1.0 | | PRAC-2 | 1.0 | 1.0 | 1.0 | 1.0 | | PRAC-4 | 1.0 | 1.0 | 1.0 | 1.0 | | All | - | - | - | 1.0 | --- ## Conclusion The chart demonstrates **uniform performance speedup** across all tested thresholds and categories, with no discernible variation. The geometric mean (`Geomean`) aligns perfectly with the individual thresholds, reinforcing the consistency of the results. All data points are explicitly labeled as `1.0`, indicating optimal performance. </details> Figure 17. Performance Comparison of PRACtical and Baseline architecture for recoveries of 1, 2, and 4 and thresholds of 64, 128, and 256. Baseline architecture refers to no mitigation. Non-opportunistic PRAC+ABO vs PRACtical. We have shown that opportunistic mitigation has a wide energy-performance trade-off. In order to save performance, PRAC+ABO can be non-opportunistic, meaning that upon recovery (during RFM ab), only the banks, that have rows with activation count equal to greater than Alert threshold, are undergoing recovery procedure. As expected, the banks that have all rows with counters less than Alert threshold will stay idle during this period, downgrading the performance. However, this method ensures only necessary number of refresh operations are performed, saving the energy. The results are shown in Figure 15. Our evaluation considers thresholds of 64, 128, and 256, with a configuration of 1, 2, and 4 RFM s per recovery. Across all combinations of recovery mechanisms (denoted as RFM s) and thresholds, we observe an average performance improvement of approximately 20%. The lowest performance gain, around 10%, occurs when the threshold is set to 256 and only one RFM recovery is employed. In contrast, the highest performance improvement is observed under the configuration with a threshold of 64 and one RFM recovery, where performance improves by more than 50%. <details> <summary>x17.png Details</summary>  ### Visual Description # Technical Document Analysis: Performance Speedup Chart ## Chart Overview The image is a **grouped bar chart** titled **"Threshold"**, comparing performance speedup percentages across different computational thresholds (64, 128, 256) and a geometric mean (Geomean) across three PRAC categories (PRAC-1, PRAC-2, PRAC-4) and an aggregated "All" category. --- ### **Legend & Color Mapping** - **Legend Position**: Top of the chart. - **Color-Coded Thresholds**: - **Blue**: Threshold = 64 - **Orange**: Threshold = 128 - **Green**: Threshold = 256 - **Gray**: Geomean (geometric mean of thresholds) - **Verification**: All bar colors strictly align with the legend (e.g., PRAC-1's blue bar = 20.7%, orange = 12.1%, green = 9.5%, gray = 13.4%). --- ### **Axis Labels** - **X-Axis**: Categories labeled as `PRAC-1`, `PRAC-2`, `PRAC-4`, and `All`. - **Y-Axis**: Labeled **"Performance Speedup (%)"**, ranging from 0% to 50% in 10% increments. - **Gridlines**: Dashed horizontal lines at every 10% increment. --- ### **Data Points & Trends** #### **PRAC-1** - **Threshold 64 (Blue)**: 20.7% - **Threshold 128 (Orange)**: 12.1% - **Threshold 256 (Green)**: 9.5% - **Geomean (Gray)**: 13.4% - **Trend**: Speedup decreases as threshold increases. Geomean (13.4%) lies between 12.1% and 9.5%, consistent with geometric mean calculation. #### **PRAC-2** - **Threshold 64 (Blue)**: 32.1% - **Threshold 128 (Orange)**: 15.8% - **Threshold 256 (Green)**: 10.7% - **Geomean (Gray)**: 17.6% - **Trend**: Similar decreasing pattern. Geomean (17.6%) aligns with geometric mean of 32.1%, 15.8%, and 10.7%. #### **PRAC-4** - **Threshold 64 (Blue)**: 52.3% - **Threshold 128 (Orange)**: 22.4% - **Threshold 256 (Green)**: 13.1% - **Geomean (Gray)**: 24.8% - **Trend**: Highest speedup at threshold 64. Geomean (24.8%) reflects geometric mean of 52.3%, 22.4%, and 13.1%. #### **All** - **Geomean (Gray)**: 20.3% - **Trend**: Represents an aggregated geometric mean across all PRAC categories. No bars for thresholds 64, 128, or 256. --- ### **Key Observations** 1. **Threshold Impact**: Higher thresholds (256) consistently yield lower speedups across all PRAC categories. 2. **Geomean Behavior**: The geometric mean (gray bars) provides a normalized performance metric, balancing the effects of varying thresholds. 3. **PRAC-4 Dominance**: PRAC-4 exhibits the highest speedup at threshold 64 (52.3%), suggesting it is optimized for lower thresholds. 4. **Aggregated Data**: The "All" category isolates the Geomean (20.3%), likely representing a system-wide average. --- ### **Structural Notes** - **Chart Type**: Grouped bar chart with four categories on the x-axis. - **Data Representation**: Each PRAC category has three bars (thresholds 64, 128, 256) and one Geomean bar. The "All" category only includes the Geomean. - **Visual Clarity**: Color coding and gridlines enhance readability of performance differences. --- ### **Conclusion** The chart illustrates how performance speedup varies with computational thresholds across different PRAC configurations. The geometric mean provides a consistent benchmark, while PRAC-4 demonstrates the highest efficiency at lower thresholds. No textual data beyond the legend, axis labels, and embedded percentages is present. </details> Figure 18. Performance Comparison of PRACtical and non-opportunistic PRAC for recoveries of 1, 2, and 4 and thresholds of 64, 128, and 256 Chronus equipped with PRACtical vs. PRAC. Chronus (Canpolat et al., 2025) optimizes the counter update mechanism in DRAM by relocating per-row activation counters to a dedicated, independent subarray. While this design introduces additional energy overhead, since each row activation results in two separate row accesses (one for the target row and one for the corresponding counter row) and occupies valuable DRAM space, it effectively eliminates the performance penalty typically incurred by in-place counter updates. In this evaluation, we integrate the PRACtical bank stalling mechanism and subarray-level PRAC update into the Chronus architecture and compare the combined approach against the Chronus with an opportunistic PRAC+ABO framework. As shown in Figure 19, the hybrid Chronus+PRACtical implementation achieves the same performance as the base implementation with PRAC+ABO. These results demonstrate that simple and energy efficient PRACtical can indeed have the same result as expensive and inefficient base design. Note that even though the PRACtical has a small PRAC overhead due to subarray conflicts, this is negligible in complete design. Also note that the Chronus has more energy difference due to double row activation, which incurs an additional 19.07% energy consumption for each row access. We can conclude that PRACtical can achieve same (even better at lower thresholds) performance with very low energy consumption. <details> <summary>x18.png Details</summary>  ### Visual Description # Technical Document Extraction: Normalized Speedup Analysis ## Chart Overview - **Type**: Bar Chart - **Title**: Normalized Speedup - **Background**: White - **Grid**: Dashed gray lines ## Axes - **X-Axis (Horizontal)**: - Label: Threshold - Categories: 16, 20, 32, 64, 128, 256 - Tick Marks: Aligned with bar centers - **Y-Axis (Vertical)**: - Label: Normalized Speedup - Range: 0.0 to 1.2 - Increment: 0.2 - Tick Marks: Dashed lines ## Data Points | Threshold | Normalized Speedup | |-----------|--------------------| | 16 | 1.10 | | 20 | 1.05 | | 32 | 1.01 | | 64 | 1.00 | | 128 | 1.00 | | 256 | 1.00 | ## Visual Trends - **Bar Heights**: - Decreasing trend from left to right (1.10 → 1.00). - Stabilizes at 1.00 for thresholds ≥ 64. - **Color**: All bars are blue (no legend present). ## Spatial Grounding - **Legend**: Not applicable (no legend in the chart). - **Bar Placement**: - X-axis: Centered under each threshold label. - Y-axis: Aligned with speedup values. ## Component Isolation 1. **Header**: Chart title ("Normalized Speedup") at the top. 2. **Main Chart**: - Bars with labeled values. - Axes with gridlines. 3. **Footer**: No additional text or elements. ## Notes - No textual blocks, tables, or non-English content present. - All data points are explicitly labeled on the bars. - No missing or inferred values; all information is directly extracted from the chart. </details> Figure 19. Normalized performance of Chronus implemented with PRACtical over PRAC+ABO. ### 6.2. Hardware Overhead and Complexity Analysis In this section, we discuss the practicality perspective of the proposed solution, PRACtical. Specifically, we discuss the practicality of PRACtical in two aspects: changes to JEDEC standards and the area overhead of changes. Changes to JEDEC Standards: PRACtical requires several architectural modifications to both the DRAM device and the memory controller (MC) interface. The most critical modification is to decouple the increment circuit from the global circuit and connect it to the subarray’s local row buffers. Another required modification stems from the fact that MCs typically lack knowledge of the subarray mapping within each DRAM bank. However, this can be addressed with a dedicated register in DRAM that holds subarray mapping information. Then, at boot time, the MC can read these registers and store the corresponding mapping functions in its internal registers for use during execution. Additionally, another hardware extension involves introducing a single register that maintains one bit per bank to track whether the bank needs mitigation. For a 64-bank channel, this mechanism requires only a 64-bit register, making it a low-overhead enhancement. Area Overhead of Increment Circuit: PRACtical introduces two critical modifications to the DRAM architecture: (1) an increment unit and its control path integrated into local row buffers, and (2) an n-bit register to represent the bank mask in an n-bank DIMM. In our evaluation setup, the DIMM consists of 64 banks, which requires an 8-byte (64-bit) register to track bank-level status. The first modification decouples the increment logic from the global row buffer and shares it across local row buffers. Since the counter update overlaps with the activation of the next row, it must be routed to the correct subarray. To enable this, we need to have an additional global row address decoder that maps addresses to subarray IDs and row addresses within subarrays, along with an additional comparator in each subarray to resolve subarray ID matches. This ensures that counter updates can be independently delivered, even when the comparator is concurrently needed for the next precharge operation. We evaluate the area overhead of this modification using CACTI (Balasubramonian et al., 2017) and Synopsys Design Compiler (Synopsys Inc., 2023), and find it to be only 0.03%, making it negligible. ### 6.3. Security Evaluation Resilience against Memory Slowdown Attacks. In Section 3.3, we stated that the current PRAC+ABO design is vulnerable to MOAT’s Torrent-of-Staggered-Alerts attack (Qureshi and Qazi, 2024), which exploit the channel-wide stalling behavior of the ABO protocol. Besides, an attacker can trigger an Alert on a single bank to stall the entire memory channel frequently to cause performance attacks. PRACtical mitigates this vulnerability by restricting the Alert-induced stall to only the affected bank. As a result, the effectiveness of performance attack is significantly diminished, as it relies on a single bank being capable of blocking the entire channel. <details> <summary>x19.png Details</summary>  ### Visual Description # Technical Document Analysis: Normalized Performance Comparison ## Chart Description The image is a **clustered bar chart** comparing normalized performance metrics across 12 computational systems using three optimization methods: **1ABO**, **2ABO**, and **3ABO**. The chart uses distinct colors for each method: - **Blue**: 1ABO - **Orange**: 2ABO - **Purple**: 3ABO ### Key Components 1. **X-Axis**: Labeled with system identifiers (e.g., `429_mcf`, `433_milc`, `434_zeusmp`, etc.). 2. **Y-Axis**: Labeled **"Normalized Performance"** with a scale from **0.0 to 1.0** in increments of 0.2. 3. **Legend**: Positioned at the **top center** of the chart, explicitly mapping colors to methods. 4. **Bars**: Three bars per system, grouped by method, with heights proportional to normalized performance. --- ## Data Extraction ### System Performance Trends All systems exhibit **near-peak performance** (values clustered between **0.94 and 1.0**), with minimal variation between methods. Key observations: - **Highest Performance**: `h264_encode` (3ABO: **1.0**). - **Lowest Performance**: `549_fotonik3d` (3ABO: **~0.94**). - **Consistency**: Most systems show **<0.03 difference** between methods. ### System-Specific Values | System | 1ABO (Blue) | 2ABO (Orange) | 3ABO (Purple) | |-------------------|-------------|---------------|---------------| | 429_mcf | ~0.98 | ~0.97 | ~0.96 | | 433_milc | ~0.97 | ~0.96 | ~0.96 | | 434_zeusmp | ~0.98 | ~0.97 | ~0.96 | | 437_leslie3d | ~0.98 | ~0.97 | ~0.96 | | 450_soplex | ~0.99 | ~0.99 | ~0.99 | | 459_GemsFDTD | ~0.97 | ~0.96 | ~0.95 | | 470_ibm | ~0.98 | ~0.97 | ~0.96 | | 519_ibm | ~0.97 | ~0.96 | ~0.95 | | 520_omnetpp | ~0.96 | ~0.95 | ~0.94 | | 549_fotonik3d | ~0.95 | ~0.94 | ~0.94 | | h264_encode | ~1.0 | ~1.0 | **1.0** | | Geomean | ~0.98 | ~0.97 | ~0.96 | --- ## Spatial Grounding & Validation - **Legend Position**: Top-center (confirmed via visual alignment). - **Color Consistency**: All bars match legend colors (e.g., `h264_encode` 3ABO bar is purple and reaches 1.0). - **Y-Axis Calibration**: Ticks at 0.0, 0.2, 0.4, 0.6, 0.8, 1.0 (explicitly labeled). --- ## Trend Verification - **1ABO (Blue)**: Slightly higher than 2ABO/3ABO in most systems (e.g., `450_soplex` peaks at ~0.99). - **2ABO (Orange)**: Intermediate performance, often matching 1ABO (e.g., `450_soplex`). - **3ABO (Purple)**: Consistently the lowest, except in `h264_encode` where it matches 1ABO/2ABO. --- ## Conclusion The chart demonstrates **high overall performance** across systems, with **1ABO** generally outperforming other methods. The **h264_encode** system achieves perfect normalized performance (1.0) with 3ABO, while **549_fotonik3d** shows the weakest results. All methods exhibit tight clustering, suggesting minimal sensitivity to optimization choice in most cases. </details> Figure 20. Normalized performance of PRACtical for each single benign benchmark when there is a performance attack. To evaluate PRACtical’s robustness, we repeated the performance attack experiments on a PRACtical-enabled system. The results, shown in Figure 20, use the motivation set—consisting of high memory-intensity, single-trace workloads. Under PRAC+ABO, the attack-induced slowdowns reached over 80%, severely degrading the performance of benign workloads. In contrast, PRACtical demonstrates strong resilience to such memory-based performance attacks. The system experiences an average (geometric mean) slowdown of less than 6%. This is primarily due to the attacker operating on the same banks accessed by these benchmarks. The most slowdown happens when attacker can induce 3 ABO stalls per tREFI s. Even in these cases, the maximum observed slowdown remains below 6%, which is considered a tolerable level for secure memory systems. Security of PRACtical: While PRAC+ABO alone does not constitute a complete security solution on its own. Any secure Rowhammer mitigation framework built upon PRAC+ABO must use a policy to ensure that any DRAM bank exceeding the activation threshold is properly mitigated. From this perspective, PRACtical is designed to preserve this baseline security requirement while delivering improved performance and energy efficiency. PRACtical targets optimizations in two key components of the PRAC+ABO framework: the per-row activation counter (PRAC) and the Alert-back-off signaling mechanism. PRACtical counter updates are committed in parallel with subarray accesses by leveraging a centralized increment circuitry, in conjunction with a memory controller that maintains subarray mappings. PRACtical provides memory with an alert signal to notify MC to stall requests at the bank level. Since we change channel-level blocking to bank-level blocking, we discuss the following potential security issue. Since PRACtical allows access to non-mitigated banks, this potentially provides an attacker with an opportunity during the recovery for a period to send more activations to a target bank that is close to the Alert threshold. As an example, assume bank A sets its bit in RFM_MASK and sends alert and bank B is in normal operation of serving requests with its highest activation count close to the threshold, $T-1$ . While the mitigation of bank A is performed, an attacker can send up to $N_\texttt{ACT}=\frac{t_{RFM\_MASK}}{t_RC}$ ACT s to bank B. $N_ACT$ is at most 6 since the RFM duration is 350ns and tRC is 52ns. Therefore, bank B will have rows with at most $T+5$ activation counts. PRACtical decreases the Alert threshold by this maximum value (5 in our system) to account for the worst-case scenario. If during recovery, the counter of a row in a bank reaches threshold, it sets the bit and sends the Alert signal. Once this recovery period is finished, in the next recovery, this bank also performs necessary mitigation. Since PRACtical uses a safe threshold, it guarantees the same security as the PRAC+ABO guarantees. In general, PRACtical does not need to lower the threshold. It can keep the ALERT threshold same, and have a second threshold that sets bank bits to 1 in BA register. Once there is row counter reaching the second threshold, its corresponding bank bit is set to 1. Once a row counter reaches the Alert threshold, an alert is sent to MC. For simplicity, we lower the threshold to lower and safe level. ## 7. Related Work This paper first eagerly analyzes the efficiency of the existing JEDEC PRAC+ABO using a diverse set of benchmarks and secondly proposes a new solution called PRACtical to improve the performance of memory operations while keeping the same security guarantees provided by PRAC+ABO standards. PRACtical is a transparent hardware solution and can be deeply related to other works, such as counter-tracking mechanisms, hardware and software mitigations, and so on. Counter-tracking mechanism. The concept of using activation counters was introduced and patented around by many works (Bains and Halbert, 2016; Kim et al., 2014b; Seyedzadeh et al., 2016, 2018; Lee et al., 2019; Kang et al., 2020; Qureshi et al., 2022; Woo et al., 2023). Later works (Park et al., 2020; Marazzi et al., 2022; Kim et al., 2022; Jaleel et al., 2024a) proposed secure in-DRAM tracking mechanisms to tackle energy and performance issues. Graphene (Park et al., 2020) designs lightweight RowHammer protection to identify the frequent inputs of incoming stream achieving near-zero performance-energy overhead. Mithril (Kim et al., 2022) is the first to propose DRAM-memory controller cooperative mitigation using in-DRAM tracking. Aamer Jaleel et al. (Jaleel et al., 2024a) proposes to manage trackers with probabilistic management policies like request-stream sampling and random evictions. PROTRR (Marazzi et al., 2022) uses frequent item counting to track aggressor rows in DRAM. DRAM Performance Mechanisms. Subarray-level parallelism has been investigated in several prior studies. Kim et al. (Kim et al., 2012) proposed subarray-level parallel memory access mechanisms to improve memory bandwidth and performance. Hassan et al. (Hassan et al., 2024) introduced a self-managing DRAM architecture that leverages the independence of subarrays to enable autonomous management within DRAM devices. Our approach is to eliminate the obscurity for subarray parallelism due to the increment circuit design in PRAC. Specifically, we propose modification of the circuit to enable overlapping only the counter update phase rather than the entire precharge phase with the subsequent activation, thereby minimizing performance overhead. Additionally, Chang et al. (Chang et al., 2014) explored subarray-level refresh operations, while HiRa (Yağlikçi et al., 2022) presents methods to reduce refresh latency by concurrently refreshing two rows connected to distinct charge restoration circuitries. BreakHammer (Canpolat et al., 2024a) removes the performance overhead of Rowhammer attacks by identifying and throttling hardware threats that frequently triggter preventive actions. Slowdown Attacks. Due to the impact of DRAM on performance, the research community has long explored threats that exploit shared memory subsystems to degrade performance, often in the form of Denial-of-Service (DoS) attacks (Mutlu, 2007). While recent Rowhammer mitigation mechanisms aim to enhance system reliability, they can inadvertently introduce substantial performance overheads, particularly when relying on aggressive repair strategies such as frequent refreshes (Bhati et al., 2015; Mukundan et al., 2013) or row remapping (Saxena et al., 2024a). Different works (Nazaraliyev et al., 2025; Woo and Nair, 2025; Canpolat et al., 2024b) describe ways to exploit RH mitigation for performance and side channel attacks. ## 8. Conclusion In this paper, we tackle the performance and energy overhead inherent in PRAC+ABO. We propose PRACtical, a novel PRAC+ABO enhancement featuring a two-level optimization that enables subarray-level counter updates and allows DRAM banks to mitigate RowHammer independently without stalling. PRACtical introduces minimal hardware changes—namely, centralized increment circuit connected to subarray and a single global register, called bank-alert register, where each bit indicates whether a specific bank needs a mitigation — enabling the memory controller to continue serving requests to unaffected banks. Our evaluations show that PRACtical improves performance by a geomean of 8% and saves energy by an average of 20% over PRAC+ABO. Its performance is same as the baseline - no mitigation architecture and energy consumption is minimal. Overall, PRACtical provides an efficient and practical enhancement to PRAC+ABO, balancing performance and security with low hardware overhead. ## References - (1) - spe (2006) 2006. Standard Performance Evaluation Corporation (SPEC) CPU2006 Benchmark Suite. http://www.spec.org/cpu2006/. Accessed: 2025-04-10. - spe (2017) 2017. Standard Performance Evaluation Corporation (SPEC) CPU2017 Benchmark Suite. http://www.spec.org/cpu2017. Accessed: 2025-04-10. - Aweke et al. (2016) Zelalem Birhanu Aweke, Salessawi Ferede Yitbarek, Rui Qiao, Reetuparna Das, Matthew Hicks, Yossi Oren, and Todd Austin. 2016. ANVIL: Software-based protection against next-generation rowhammer attacks. ACM SIGPLAN Notices 51, 4 (2016), 743–755. - Bains and Halbert (2016) Kuljit S Bains and John B Halbert. 2016. Distributed row hammer tracking. US Patent 9,299,400. - Balasubramonian et al. (2017) Rajeev Balasubramonian, Andrew B Kahng, Naveen Muralimanohar, Ali Shafiee, and Vaishnav Srinivas. 2017. CACTI 7: New tools for interconnect exploration in innovative off-chip memories. ACM Transactions on Architecture and Code Optimization (TACO) 14, 2 (2017), 1–25. - Bennett et al. (2021) Tanj Bennett, Stefan Saroiu, Alec Wolman, and Lucian Cojocar. 2021. Panopticon: A complete in-dram rowhammer mitigation. In Workshop on DRAM Security (DRAMSec), Vol. 22. 110. - Bhati et al. (2015) Ishwar Bhati, Zeshan Chishti, Shih-Lien Lu, and Bruce Jacob. 2015. Flexible auto-refresh: Enabling scalable and energy-efficient DRAM refresh reductions. In Proceedings of the 42nd Annual International Symposium on Computer Architecture. 235–246. - Canpolat et al. (2024a) Oğuzhan Canpolat, A Giray Yağlıkçı, Ataberk Olgun, Ismail Emir Yuksel, Yahya Can Tuğrul, Konstantinos Kanellopoulos, Oğuz Ergin, and Onur Mutlu. 2024a. Breakhammer: Enhancing rowhammer mitigations by carefully throttling suspect threads. In 2024 57th IEEE/ACM International Symposium on Microarchitecture (MICRO). IEEE, 915–934. - Canpolat et al. (2025) Oğuzhan Canpolat, A Giray Yağlıkçı, Geraldo F Oliveira, Ataberk Olgun, Nisa Bostancı, İsmail Emir Yüksel, Haocong Luo, Oğuz Ergin, and Onur Mutlu. 2025. Chronus: Understanding and Securing the Cutting-Edge Industry Solutions to DRAM Read Disturbance. arXiv preprint arXiv:2502.12650 (2025). - Canpolat et al. (2024b) Oğuzhan Canpolat, A Giray Yağlıkçı, Geraldo F Oliveira, Ataberk Olgun, Oğuz Ergin, and Onur Mutlu. 2024b. Understanding the security benefits and overheads of emerging industry solutions to dram read disturbance. arXiv preprint arXiv:2406.19094 (2024). - Chang et al. (2016) Kevin K Chang, Prashant J Nair, Donghyuk Lee, Saugata Ghose, Moinuddin K Qureshi, and Onur Mutlu. 2016. Low-cost inter-linked subarrays (LISA): Enabling fast inter-subarray data movement in DRAM. In 2016 IEEE International Symposium on High Performance Computer Architecture (HPCA). IEEE, 568–580. - Chang et al. (2014) Kevin Kai-Wei Chang, Donghyuk Lee, Zeshan Chishti, Alaa R. Alameldeen, Chris Wilkerson, Yoongu Kim, and Onur Mutlu. 2014. Improving DRAM performance by parallelizing refreshes with accesses. In 2014 IEEE 20th International Symposium on High Performance Computer Architecture (HPCA). 356–367. https://doi.org/10.1109/HPCA.2014.6835946 - Cojocar et al. (2019) Lucian Cojocar, Kaveh Razavi, Cristiano Giuffrida, and Herbert Bos. 2019. Exploiting correcting codes: On the effectiveness of ecc memory against rowhammer attacks. In 2019 IEEE Symposium on Security and Privacy (SP). IEEE, 55–71. - Cooper et al. (2010) Brian F Cooper, Adam Silberstein, Erwin Tam, Raghu Ramakrishnan, and Russell Sears. 2010. Benchmarking cloud serving systems with YCSB. In Proceedings of the 1st ACM symposium on Cloud computing. 143–154. - de Ridder et al. (2021) Finn de Ridder, Pietro Frigo, Emanuele Vannacci, Herbert Bos, Cristiano Giuffrida, and Kaveh Razavi. 2021. $\{$ SMASH $\}$ : Synchronized many-sided rowhammer attacks from $\{$ JavaScript $\}$ . In 30th USENIX Security Symposium (USENIX Security 21). 1001–1018. - Frigo et al. (2020) Pietro Frigo, Emanuele Vannacc, Hasan Hassan, Victor Van Der Veen, Onur Mutlu, Cristiano Giuffrida, Herbert Bos, and Kaveh Razavi. 2020. TRRespass: Exploiting the many sides of target row refresh. In 2020 IEEE Symposium on Security and Privacy (SP). IEEE, 747–762. - Fritts et al. (2009) Jason E Fritts, Frederick W Steiling, Joseph A Tucek, and Wayne Wolf. 2009. MediaBench II video: Expediting the next generation of video systems research. Microprocessors and Microsystems 33, 4 (2009), 301–318. - Gholami et al. (2024) Amir Gholami, Zhewei Yao, Sehoon Kim, Coleman Hooper, Michael W. Mahoney, and Kurt Keutzer. 2024. AI and Memory Wall. IEEE Micro 44, 3 (2024), 33–39. https://doi.org/10.1109/MM.2024.3373763 - Ghose et al. (2019) Saugata Ghose, Tianshi Li, Nastaran Hajinazar, Damla Senol Cali, and Onur Mutlu. 2019. Demystifying complex workload-dram interactions: An experimental study. Proceedings of the ACM on Measurement and Analysis of Computing Systems 3, 3 (2019), 1–50. - Gruss et al. (2018) Daniel Gruss, Moritz Lipp, Michael Schwarz, Daniel Genkin, Jonas Juffinger, Sioli O’Connell, Wolfgang Schoechl, and Yuval Yarom. 2018. Another flip in the wall of rowhammer defenses. In 2018 IEEE Symposium on Security and Privacy (SP). IEEE, 245–261. - Gruss et al. (2016) Daniel Gruss, Clémentine Maurice, and Stefan Mangard. 2016. Rowhammer. js: A remote software-induced fault attack in javascript. In Detection of Intrusions and Malware, and Vulnerability Assessment: 13th International Conference, DIMVA 2016, San Sebastián, Spain, July 7-8, 2016, Proceedings 13. Springer, 300–321. - Hassan et al. (2022) Hasan Hassan, Ataberk Olgun, A Giray Yaglikci, Haocong Luo, and Onur Mutlu. 2022. A case for self-managing dram chips: Improving performance, efficiency, reliability, and security via autonomous in-dram maintenance operations. arXiv (2022), 2207–13358. - Hassan et al. (2024) Hasan Hassan, Ataberk Olgun, A Giray Yağlıkçı, Haocong Luo, Onur Mutlu, and ETH Zurich. 2024. Self-Managing DRAM: A Low-Cost Framework for Enabling Autonomous and Efficient DRAM Maintenance Operations. In 2024 57th IEEE/ACM International Symposium on Microarchitecture (MICRO). IEEE, 949–965. - Itoh (2001) Kiyoo Itoh. 2001. VLSI Memory Chip Design. Springer. - Jaleel et al. (2024a) Aamer Jaleel, Stephen W Keckler, and Gururaj Saileshwar. 2024a. Probabilistic tracker management policies for low-cost and scalable rowhammer mitigation. arXiv preprint arXiv:2404.16256 (2024). - Jaleel et al. (2024b) Aamer Jaleel, Gururaj Saileshwar, Stephen W Keckler, and Moinuddin Qureshi. 2024b. Pride: Achieving secure rowhammer mitigation with low-cost in-dram trackers. In 2024 ACM/IEEE 51st Annual International Symposium on Computer Architecture (ISCA). IEEE, 1157–1172. - JEDEC (2020) JEDEC. 2020. JESD79-5: DDR5 SDRAM Standard. - JEDEC (2024a) JEDEC. 2024a. JEDEC Updates JESD79-5C DDR5 SDRAM Standard: Elevating Performance and Security for Next-Gen Technologies. https://www.jedec.org/news/pressreleases/jedec-updates-jesd79-5cddr5-sdram-standard-elevating-performance-and-security Accessed: 2025-03-31. - JEDEC (2024b) JEDEC. 2024b. JESD79-5C: DDR5 SDRAM Standard. - Kang et al. (2020) Ingab Kang, Eojin Lee, and Jung Ho Ahn. 2020. CAT-TWO: Counter-based adaptive tree, time window optimized for DRAM row-hammer prevention. IEEE Access 8 (2020), 17366–17377. - Keeth et al. (2007) Brent Keeth, R. Jacob Baker, Scott Benton, and Brian Johnson. 2007. DRAM Circuit Design: Fundamental and High-Speed Topics (2nd ed.). Wiley-IEEE Press. - Kim et al. (2014b) Dae-Hyun Kim, Prashant J Nair, and Moinuddin K Qureshi. 2014b. Architectural support for mitigating row hammering in DRAM memories. IEEE Computer Architecture Letters 14, 1 (2014), 9–12. - Kim et al. (2020) Jeremie S Kim, Minesh Patel, A Giray Yağlıkçı, Hasan Hassan, Roknoddin Azizi, Lois Orosa, and Onur Mutlu. 2020. Revisiting rowhammer: An experimental analysis of modern dram devices and mitigation techniques. In 2020 ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA). IEEE, 638–651. - Kim et al. (2021) Kwangrae Kim, Jeonghyun Woo, Junsu Kim, and Ki-Seok Chung. 2021. Hammerfilter: Robust protection and low hardware overhead method for rowhammer. In 2021 IEEE 39th International Conference on Computer Design (ICCD). IEEE, 212–219. - Kim et al. (2022) Michael Jaemin Kim, Jaehyun Park, Yeonhong Park, Wanju Doh, Namhoon Kim, Tae Jun Ham, Jae W Lee, and Jung Ho Ahn. 2022. Mithril: Cooperative row hammer protection on commodity dram leveraging managed refresh. In 2022 IEEE International Symposium on High-Performance Computer Architecture (HPCA). IEEE, 1156–1169. - Kim et al. (2014a) Yoongu Kim, Ross Daly, Jeremie Kim, Chris Fallin, Ji Hye Lee, Donghyuk Lee, Chris Wilkerson, Konrad Lai, and Onur Mutlu. 2014a. Flipping bits in memory without accessing them: An experimental study of DRAM disturbance errors. ACM SIGARCH Computer Architecture News 42, 3 (2014), 361–372. - Kim et al. (2012) Yoongu Kim, Vivek Seshadri, Donghyuk Lee, Jamie Liu, and Onur Mutlu. 2012. A case for exploiting subarray-level parallelism (SALP) in DRAM. ACM SIGARCH Computer Architecture News 40, 3 (2012), 368–379. - Konoth et al. (2018) Radhesh Krishnan Konoth, Marco Oliverio, Andrei Tatar, Dennis Andriesse, Herbert Bos, Cristiano Giuffrida, and Kaveh Razavi. 2018. $\{$ ZebRAM $\}$ : Comprehensive and compatible software protection against rowhammer attacks. In 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18). 697–710. - Lee et al. (2019) Eojin Lee, Ingab Kang, Sukhan Lee, G Edward Suh, and Jung Ho Ahn. 2019. TWiCe: Preventing row-hammering by exploiting time window counters. In Proceedings of the 46th International Symposium on Computer Architecture. 385–396. - Loughlin et al. (2021) Kevin Loughlin, Stefan Saroiu, Alec Wolman, and Baris Kasikci. 2021. Stop! hammer time: rethinking our approach to rowhammer mitigations. In Proceedings of the Workshop on Hot Topics in Operating Systems. 88–95. - Luo et al. (2023a) Haocong Luo, Ataberk Olgun, Abdullah Giray Yağlıkçı, Yahya Can Tuğrul, Steve Rhyner, Meryem Banu Cavlak, Joël Lindegger, Mohammad Sadrosadati, and Onur Mutlu. 2023a. Rowpress: Amplifying read disturbance in modern dram chips. In Proceedings of the 50th Annual International Symposium on Computer Architecture. 1–18. - Luo et al. (2020) Haocong Luo, Taha Shahroodi, Hasan Hassan, Minesh Patel, A Giray Yağlıkçı, Lois Orosa, Jisung Park, and Onur Mutlu. 2020. CLR-DRAM: A low-cost DRAM architecture enabling dynamic capacity-latency trade-off. In 2020 ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA). IEEE, 666–679. - Luo et al. (2023b) Haocong Luo, Yahya Can Tuğrul, F Nisa Bostancı, Ataberk Olgun, A Giray Yağlıkçı, and Onur Mutlu. 2023b. Ramulator 2.0: A modern, modular, and extensible dram simulator. IEEE Computer Architecture Letters 23, 1 (2023), 112–116. - Marazzi et al. (2022) Michele Marazzi, Patrick Jattke, Flavien Solt, and Kaveh Razavi. 2022. Protrr: Principled yet optimal in-dram target row refresh. In 2022 IEEE Symposium on Security and Privacy (SP). IEEE, 735–753. - Misra and Gries (1982) Jayadev Misra and David Gries. 1982. Finding repeated elements. Science of computer programming 2, 2 (1982), 143–152. - Mukundan et al. (2013) Janani Mukundan, Hillery Hunter, Kyu-hyoun Kim, Jeffrey Stuecheli, and José F Martínez. 2013. Understanding and mitigating refresh overheads in high-density DDR4 DRAM systems. ACM SIGARCH Computer Architecture News 41, 3 (2013), 48–59. - Mutlu and Kim (2019) Onur Mutlu and Jeremie S Kim. 2019. Rowhammer: A retrospective. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 39, 8 (2019), 1555–1571. - Mutlu (2007) Thomas Moscibroda Onur Mutlu. 2007. Memory performance attacks: Denial of memory service in multi-core systems. In USENIX security. - Nazaraliyev et al. (2025) Ravan Nazaraliyev, Yicheng Zhang, Sankha Baran Dutta, Andres Marquez, Kevin Barker, and Nael Abu-Ghazaleh. 2025. Not so Refreshing: Attacking GPUs using RFM Rowhammer Mitigation. In 34th USENIX Security Symposium (USENIX Security 25). - Olgun et al. (2024) Ataberk Olgun, Yahya Can Tugrul, Nisa Bostanci, Ismail Emir Yuksel, Haocong Luo, Steve Rhyner, Abdullah Giray Yaglikci, Geraldo F Oliveira, and Onur Mutlu. 2024. $\{$ ABACuS $\}$ : $\{$ All-Bank $\}$ Activation Counters for Scalable and Low Overhead $\{$ RowHammer $\}$ Mitigation. In 33rd USENIX Security Symposium (USENIX Security 24). 1579–1596. - Park et al. (2020) Yeonhong Park, Woosuk Kwon, Eojin Lee, Tae Jun Ham, Jung Ho Ahn, and Jae W Lee. 2020. Graphene: Strong yet lightweight row hammer protection. In 2020 53rd Annual IEEE/ACM International Symposium on Microarchitecture (MICRO). IEEE, 1–13. - Qureshi ([n. d.]) Moinuddin Qureshi. [n. d.]. AutoRFM: Scaling Low-Cost In-DRAM Trackers to Ultra-Low Rowhammer Thresholds. ([n. d.]). - Qureshi and Qazi (2024) Moinuddin Qureshi and Salman Qazi. 2024. Moat: Securely mitigating rowhammer with per-row activation counters. arXiv preprint arXiv:2407.09995 (2024). - Qureshi et al. (2024) Moinuddin Qureshi, Salman Qazi, and Aamer Jaleel. 2024. MINT: Securely mitigating rowhammer with a minimalist in-dram tracker. In 2024 57th IEEE/ACM International Symposium on Microarchitecture (MICRO). IEEE, 899–914. - Qureshi et al. (2022) Moinuddin Qureshi, Aditya Rohan, Gururaj Saileshwar, and Prashant J Nair. 2022. Hydra: enabling low-overhead mitigation of row-hammer at ultra-low thresholds via hybrid tracking. In Proceedings of the 49th Annual International Symposium on Computer Architecture. 699–710. - Razavi et al. (2016) Kaveh Razavi, Ben Gras, Erik Bosman, Bart Preneel, Cristiano Giuffrida, and Herbert Bos. 2016. Flip feng shui: Hammering a needle in the software stack. In 25th USENIX Security Symposium (USENIX Security 16). 1–18. - SAFARI Research Group (2021) SAFARI Research Group. 2021. Ramulator V2.0. https://github.com/CMU-SAFARI/ramulator2. - Saileshwar et al. (2022) Gururaj Saileshwar, Bolin Wang, Moinuddin Qureshi, and Prashant J Nair. 2022. Randomized row-swap: mitigating row hammer by breaking spatial correlation between aggressor and victim rows. In Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems. 1056–1069. - Saxena et al. (2024a) Anish Saxena, Saurav Mathur, and Moinuddin Qureshi. 2024a. Rubix: Reducing the overhead of secure rowhammer mitigations via randomized line-to-row mapping. In Proceedings of the 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2. 1014–1028. - Saxena and Qureshi (2024) Anish Saxena and Moinuddin Qureshi. 2024. Start: Scalable tracking for any rowhammer threshold. In 2024 IEEE International Symposium on High-Performance Computer Architecture (HPCA). IEEE, 578–592. - Saxena et al. (2022) Anish Saxena, Gururaj Saileshwar, Prashant J Nair, and Moinuddin Qureshi. 2022. Aqua: Scalable rowhammer mitigation by quarantining aggressor rows at runtime. In 2022 55th IEEE/ACM International Symposium on Microarchitecture (MICRO). IEEE, 108–123. - Saxena et al. (2024b) Anish Saxena, Walter Wang, and Alexandros Daglis. 2024b. Preventing Rowhammer Exploits via Low-Cost Domain-Aware Memory Allocation. arXiv preprint arXiv:2409.15463 (2024). - Schroeder et al. (2009a) Bianca Schroeder, Eduardo Pinheiro, and Wolf-Dietrich Weber. 2009a. DRAM errors in the wild: a large-scale field study. SIGMETRICS Perform. Eval. Rev. 37, 1 (June 2009), 193–204. https://doi.org/10.1145/2492101.1555372 - Schroeder et al. (2009b) Bianca Schroeder, Eduardo Pinheiro, and Wolf-Dietrich Weber. 2009b. DRAM errors in the wild: a large-scale field study. In Proceedings of the Eleventh International Joint Conference on Measurement and Modeling of Computer Systems (Seattle, WA, USA) (SIGMETRICS ’09). Association for Computing Machinery, New York, NY, USA, 193–204. https://doi.org/10.1145/1555349.1555372 - Seaborn and Dullien (2015) Mark Seaborn and Thomas Dullien. 2015. Exploiting the DRAM rowhammer bug to gain kernel privileges. Black Hat 15, 71 (2015), 2. - Seyedzadeh et al. (2016) Seyed Mohammad Seyedzadeh, Alex K Jones, and Rami Melhem. 2016. Counter-based tree structure for row hammering mitigation in DRAM. IEEE Computer Architecture Letters 16, 1 (2016), 18–21. - Seyedzadeh et al. (2018) Seyed Mohammad Seyedzadeh, Alex K Jones, and Rami Melhem. 2018. Mitigating wordline crosstalk using adaptive trees of counters. In 2018 ACM/IEEE 45th Annual International Symposium on Computer Architecture (ISCA). IEEE, 612–623. - Son et al. (2017) Mungyu Son, Hyunsun Park, Junwhan Ahn, and Sungjoo Yoo. 2017. Making DRAM stronger against row hammering. In Proceedings of the 54th Annual Design Automation Conference 2017. 1–6. - Synopsys Inc. (2023) Synopsys Inc. 2023. Synopsys Design Compiler User Guide. Synopsys Inc. https://www.synopsys.com/ Version Y-2023.03. - Transaction Processing Performance Council (2025) Transaction Processing Performance Council. 2025. TPC Benchmarks. http://www.tpc.org/. Accessed: 2025-04-10. - Woo et al. (2025) Jeonghyun Woo, Chris S Lin, Prashant J Nair, Aamer Jaleel, and Gururaj Saileshwar. 2025. Qprac: Towards secure and practical prac-based rowhammer mitigation using priority queues. arXiv preprint arXiv:2501.18861 (2025). - Woo and Nair (2025) Jeonghyun Woo and Prashant J Nair. 2025. Dapper: A performance-attack-resilient tracker for rowhammer defense. arXiv preprint arXiv:2501.18857 (2025). - Woo et al. (2023) Jeonghyun Woo, Gururaj Saileshwar, and Prashant J Nair. 2023. Scalable and secure row-swap: Efficient and safe row hammer mitigation in memory systems. In 2023 IEEE International Symposium on High-Performance Computer Architecture (HPCA). IEEE, 374–389. - Wulf and McKee (1995) Wm A Wulf and Sally A McKee. 1995. Hitting the memory wall: Implications of the obvious. ACM SIGARCH computer architecture news 23, 1 (1995), 20–24. - Yağlikçi et al. (2021) A Giray Yağlikçi, Minesh Patel, Jeremie S Kim, Roknoddin Azizi, Ataberk Olgun, Lois Orosa, Hasan Hassan, Jisung Park, Konstantinos Kanellopoulos, Taha Shahroodi, et al. 2021. Blockhammer: Preventing rowhammer at low cost by blacklisting rapidly-accessed dram rows. In 2021 IEEE International Symposium on High-Performance Computer Architecture (HPCA). IEEE, 345–358. - Yağlikçi et al. (2022) A. Giray Yağlikçi, Ataberk Olgun, Minesh Patel, Haocong Luo, Hasan Hassan, Lois Orosa, Oğuz Ergin, and Onur Mutlu. 2022. HiRA: Hidden Row Activation for Reducing Refresh Latency of Off-the-Shelf DRAM Chips. In 2022 55th IEEE/ACM International Symposium on Microarchitecture (MICRO). 815–834. https://doi.org/10.1109/MICRO56248.2022.00062