This paper was converted on www.awesomepapers.org from LaTeX by an anonymous user.
Want to know more? Visit the Converter page.

Mithril: Cooperative Row Hammer Protection on Commodity DRAM Leveraging Managed Refresh

Michael Jaemin Kim†  Jaehyun Park†  Yeonhong Park‡  Wanju Doh§  Namhoon Kim†
Tae Jun Ham‡  Jae W. Lee‡  Jung Ho Ahn†§
Dept. of {Intelligence and Information†, Computer Science and Engineering‡}, Prog. in Artificial Intelligence§ Seoul National University {michael604, wogus20002, ilil96, wj.doh, sirius0323, taejunham, jaewlee, gajh}@snu.ac.kr
Abstract

Since its public introduction in the mid-2010s, the Row Hammer (RH) phenomenon has drawn significant attention from the research community due to its security implications. Although many RH-protection schemes have been proposed by processor vendors, DRAM manufacturers, and academia, they still have shortcomings. Solutions implemented in the memory controller (MC) incur increasingly higher costs due to their conservative design for the worst case in terms of the number of DRAM banks and RH threshold to support. Meanwhile, DRAM-side implementation either has a limited time margin for RH-protection measures or requires extensive modifications to the standard DRAM interface. Recently, a new command for RH-protection has been introduced in the DDR5/LPDDR5 standards, referred to as refresh management (RFM). RFM enables the separation of the tasks for RH-protection to both MC and DRAM by having the former generate an RFM command at a specific activation frequency and the latter take proper RH-protection measures within a given time window. Although promising, no existing study presents and analyzes RFM-based solutions for RH-protection. In this paper, we propose Mithril, the first RFM interface-compatible, DRAM-MC cooperative RH-protection scheme providing deterministic protection guarantees. Mithril has minimal energy overheads for common use cases without adversarial memory access patterns. We also introduce Mithril+, an optional extension to provide minimal performance overheads at the expense of a tiny modification to the MC, while utilizing existing DRAM commands.

I Introduction

Row Hammer (RH) has been critical DRAM reliability and security vulnerabilities that have troubled the industry for almost a decade. This refers to a phenomenon in which a certain frequently activated row (aggressor) results in bit-flips in the corresponding adjacent rows (victims). In particular, RH is incurred when the activation rate exceeds the RH threshold (F​l​i​pT​HFlip_{TH}). RH is especially dangerous as it breaks the basic integrity guarantee in the computer system and can be abused in various attack scenarios [1, 18, 13, 46, 12, 55, 59].

The criticality of this problem has motivated many RH-protection solutions. There exist several software-based solutions [4, 8, 55, 20, 31], but such of these typically incurs a high-performance cost and have limited coverage (i.e., only effective against a specific attack scenario). For these reasons, architectural solutions have emerged as promising alternatives.

One of the important design decisions for an architectural RH-protection scheme is to determine where to implement the proposed solution within the system. In practice, most RH-protection solutions are either implemented in an on-die memory controller (MC) or a DRAM device. For example, Graphene [43], BlockHammer [56], and PARA [30] have been proposed for implementation on the processor-side MC, whereas TWiCe [32] and industry-oriented RH-protection schemes [40, 15] are implemented in DRAM. Unfortunately, both choices have their own drawbacks.

First, the MC-side implementation needs to provision RH-protection resources for the worst-case scenario, where the expected F​l​i​pT​HFlip_{TH} level is very low and the processor is connected to the maximum number of DRAM banks it supports. As a result, this strategy tends to require a large extra area for the counter structures utilized by the RH-protection mechanism. DRAM-side implementations are free from such concerns, as F​l​i​pT​HFlip_{TH} of a specific DRAM is more accurately estimated by DRAM vendors, and the resource usage is proportional to the number of DRAM banks because on-DRAM RH-protection schemes are often deployed on a per-bank or per-DIMM basis. However, such on-DRAM protection schemes have interface issues. To secure the time margin for the extra operations for potential RH victim rows, DRAM-side schemes must either request the MC to generate non-standard adjacent row refresh (ARR) commands or perform extra operations during the auto-refresh process (ordinary DRAM operation) in a way transparent to the MC. The former mechanism breaks the abstraction that DRAM is a passive device, whereas the latter [15], referred to as the time-margin-stealing method, is not always possible depending on DRAM characteristics such as the time margin during the auto-refresh process.

Refresh Management (RFM) is a newly added extension for the latest DDR5 and LPDDR5 interfaces [23, 22], allowing the DRAM-side implementation of an RH-protection solution to cooperate smoothly with an MC. An MC sends an RFM command at a specific activation frequency to a target DRAM bank without specifying a target row. The DRAM-side RH-protection scheme exploits the time margin provided by the RFM command to undertake necessary operations. This cooperation between the MC and DRAM effectively avoids the critical drawbacks of MC- or DRAM-side only implementations.

TABLE I: Categorization of existing Row Hammer mitigation schemes and Mithril
  Mitigation Scheme
Protection Guarantee
Remedy
Implementation Location
Tracking Mechanism
PARA [30] Probabilistic ARR MC Probabilistic Approach
CBT [49, 48] Deterministic ARR MC Grouped Counter Approach
TWiCe [32, 33] Deterministic ARR (feedback-augmented) DRAM (buffer-chip) Streaming Algo. (Lossy-Counting)
Graphene [43] Deterministic ARR MC Streaming Algo. (Counter-based Summary)
BlockHammer [56] Deterministic Throttling MC Streaming Algo. (Count-min Sketch)
Mithril Deterministic RFM DRAM (co-op with MC) Streaming Algo. (Counter-based Summary)
 

Despite its promising traits, the applicability of RFM as an RH-protection scheme has not been publicly verified or properly evaluated to the best of our knowledge. A prior probabilistic scheme [30] can be trivially applied. However, prior deterministic (guaranteeing not to exceed F​l​i​pT​HFlip_{TH}) schemes cannot be directly applied to the RFM interface. Prior ARR-based schemes reactively issue a command targeting a specific row when the activation count reaches a scheme-specific predefined threshold. However, given its periodicity, the RFM interface is prone to the worst-case scenario where a large number of rows will simultaneously require a preventive refresh in a short time period, unlike the ARR-based schemes. Thus, prior approaches are not compatible with the RFM interface.

In this paper, we propose Mithril, a novel RFM-compatible, deterministic RH-protection scheme that exploits MC and DRAM in a cooperative manner. To avoid the aforementioned concentration of rows to refresh for RH-protection, we utilize a greedy approach when selecting the target row to refresh upon every RFM command. We investigate the effective use of streaming algorithms [38] (Section III) and provide a new mathematical proof through which we guarantee deterministic protection by maintaining the greedy selection scheme (Section IV and Appendix).

Finally, we propose 1) a hardware scheme to obviate the need for counter table resets, which were mandatory in prior studies; 2) an algorithmic optimization for energy savings; and 3) an extension to the RFM interface to mitigate the performance overhead by exploiting the memory access patterns of ordinary workloads.

The key contributions of this paper are as follows:

  • •

    We propose Mithril, the first RFM-based RH-protection scheme with deterministic safety guarantees, exploiting a modified Counter-based Summary algorithm [37, 36].

  • •

    We provide a rigorous mathematical proof of the modified algorithm and the RH safety of Mithril.

  • •

    We suggest energy and performance optimization techniques that exploit the memory access patterns of common, non-adversarial workloads.

II Background

II-A DRAM Refresh

DRAM stores a single bit in a cell, composed of one capacitor and one access transistor [41]. These cells are organized into rows and columns. A DRAM row, the cells of which share a wordline, is the granularity of the activation (ACT) and precharge (PRE), respectively allowing and disallowing read or write operations on the row. The read and write operation involves accessing a certain number of columns in an activated row. DRAM is composed of multiple banks. Each bank allows independent ACT, PRE, read, and write operations. Multiple banks form a rank, which shares the memory channel with other ranks and the memory controller (MC) at the host side.

Due to the inherent characteristic of a DRAM cell capacitor, by which the stored charge leaks over time, the cell value must be restored periodically [7, 5]. This type of periodic restoration, referred to as an auto-refresh, is initiated at every refresh (REF) command within the tRFC (refresh time) period. Every DRAM row must be refreshed at least once during every refresh window period (tREFW) to be safe from this charge retention problem. In modern DRAM devices (e.g., DDR5 [23]), all rows in a single bank are divided into typically 8,192 groups. A group is refreshed in every time interval tREFI (refresh interval).

II-B Row Hammer Phenomenon

Row Hammer (RH) refers to a phenomenon in which repetitive activations of a specific row (aggressor) lead to bit flips in physically nearby rows (victims) [39, 30, 42, 57]. A bit flip is observable when the ACT count reaches a certain RH threshold (F​l​i​pT​HFlip_{TH}) without being refreshed inside a tREFW time window. Because two aggressors can simultaneously affect a single victim, F​l​i​pT​H/2\nicefrac{{Flip_{TH}}}{{2}} ACTs on each aggressor can cause a bit flip (double-sided attack). The F​l​i​pT​HFlip_{TH} value varies depending on different chips, generations, and/or DRAM manufacturers [29]. The RH problem has worsened following the current scale-down trend of fabrication technology, due to the intensified inter-cell interference. Recent studies [15, 29] reported that F​l​i​pT​HFlip_{TH} has been reduced to a mere several thousand ACTs. It has also been observed that non-adjacent rows affect the victim rows when activated frequently, which degrades the effective F​l​i​pT​HFlip_{TH}.

II-C Classifying Prior RH Mitigation Schemes

As shown in Table I, existing architectural RH-protection schemes all have four important criteria of a 1) protection guarantee, 2) type of remedy, 3) implementation location, and 4) tracking mechanism.

II-C1 Protection Guarantee

There exist two different types of RH-protection guarantees, deterministic and probabilistic. The deterministic guarantee ensures RH-protection by guaranteeing that a victim row is always refreshed before the number of ACTs exceeds F​l​i​pT​HFlip_{TH} on its aggressors, either by an extra preventive refresh or the normal auto-refresh. This type utilizes a counter structure to track the aggressor row and deals with it by applying a certain remedy. The main drawback of a deterministic scheme is its higher area overhead due to the large counter structure.

The probabilistic guarantee prevents RH with a certain probability. The probabilistic approach has its strength in the minimal area overhead. However, the performance overhead is exacerbated severely when the target F​l​i​pT​HFlip_{TH} level is lowered or when the number of DRAM devices in the system increases. It does not provide a deterministic protection guarantee, either.

II-C2 Remedies of Prior RH-protection Schemes

Prior works exploited one of two remedies, adjacent row refresh (ARR) or throttling. ARR refers to a type of command that the MC issues to DRAM with an explicit target row address (either aggressor or victim) at a required moment. It triggers an extra preventive refresh on the potential RH victim rows within the time margin provided by the command. This differs from the normal REF command, which is row-agnostic and periodic. Prior RH-protection schemes that exploited ARR either issued commands based on some probability [30, 52, 58] or when the ACT count of a certain aggressor exceeds a scheme-specific predefined threshold, which is assumed to be hazardous. However, ARR is not practically applicable because it either requires a new interface that breaks the abstraction of a passive DRAM device or requires the MC to become the sole manager of RH-protection. In fact, a command with a similar concept was once proposed in DDR4, but is now deprecated.

Throttling is a method by which the MC delays the frequency of activation on an aggressor starting at the moment of identification for a defined time. The duration and intensity of the delay are adjusted to guarantee RH-protection. After the initial suggestion of such methodology [17], a deterministic RH-protection scheme utilizing the throttling method was proposed [56]. However, leveraging throttling requires system-level support along with more complex MC scheduling and makes the system vulnerable to adversarial patterns (details in Section 10).

II-C3 Implementation Location

Prior RH-protection schemes are all located either on the MC-side or the DRAM-side. MC-side implementation has strength in that it utilizes a superior logic process with a larger area budget. However, it has the following major drawbacks. First, it requires a conservatively high number of counter structures to populate. The counter table of the deterministic scheme is typically allocated per DRAM bank. The latest CPU servers, such as Intel Ice Lake, support up to 1,024 banks per socket (8 channels ×\times 8 ranks ×\times 16 banks). This number could increase further if we consider 3D stacked DRAM devices or future generations. Despite the fact that fully populating 1,024 banks may be unlikely, the counter structures must be designed to support the worst case. Second, MC-side implementation must protect against a conservatively low target F​l​i​pT​HFlip_{TH} value. The target F​l​i​pT​HFlip_{TH} varies greatly depending on the manufacturer, generation, or even the device. Considering that most deterministic schemes must be tuned to the target F​l​i​pT​HFlip_{TH} at the time of their design, they must protect against pessimistic F​l​i​pT​HFlip_{TH} values.

DRAM-side implementation typically relies on an extra preventive refresh on a potential RH victim row. However, it is difficult to secure adequate uninterrupted time to execute preventive refreshes in the conventional MC-DRAM interface. Previous DRAM-side RH-protection schemes attempted to address this problem with either a feedback-augmented ARR command [32] or via the auto-refresh time-margin stealing method [15]. The former is similar to the normal ARR command issued by MCs but requires that DRAM halt the MC for a certain amount of time. There exist some methods of feedback from DRAM to MC, such as an ALERT_n signal, but these require more pins to deliver additional alert types to support the DRAM-side RH-protection scheme. The latter method, auto-refresh time-margin stealing, invisibly executes a preventive refresh during the normal auto-refresh operation. Although not requiring any feedback path, it has a limited time margin that can be stolen and thus cannot be scaled to a low F​l​i​pT​HFlip_{TH} value.

Refer to caption
Figure 1: (a) Example of main-memory organization with the RFM interface-, and (b) the issue logic of RFM.
TABLE II: Symbols and their descriptions used for DRAM refresh, RH, and RFM
  Symbol Description
  tREFW Per row auto-refresh interval (e.g., 32ms or 64ms)
F​l​i​pT​HFlip_{TH} RH threshold
R​F​MT​HRFM_{TH} RFM threshold
Preventive refresh Extra refresh of potential RH victim rows. Executed during ARR, RFM command, or hidden under auto-refresh.
   

II-C4 Tracking Mechanism and Streaming Algorithms

Each RH-protection scheme has its own tracking mechanism to identify the aggressor or victim rows with high ACT counts. The tracking mechanism of a probabilistic scheme is often insignificant. However, for a deterministic scheme, it is crucial to choose an effective tracking mechanism to minimize the area overhead of the counter structure. One class of tracking mechanisms is based on streaming algorithms [38], which are most effective when estimating the ACT counts of rows when the counter table size is limited. Multiple prior works [32, 43, 56] explicitly leverage or can be interpreted as based on such streaming algorithms.

The streaming algorithm was first invented and developed unrelated to the RH problem in the field of data mining to analyze fast and dense data streams with limited memory. A certain subset of the algorithms estimates the total number of occurrences per input element. Considering the fact the ACT commands with an address are “streamed” from the MC to DRAM, a subset of the streaming algorithms can be utilized to estimate the ACT count per row address. Thus, they are suitable as an effective tracking mechanism of an RH-protection scheme. They report the approximate number of occurrences for each element (address), referred to as the estimated count, instead of the actual count. Generally, the resolution (or the error) of the algorithm is higher (lower) when more memory is used.

Several other works [49, 48, 26] use the different approach of a grouped counter. They allocate multiple rows to a single counter to reduce the area overhead of the tracking mechanism. They optimize further by dynamically adjusting the allocation or by utilizing the characteristics of DRAM.

II-D RFM Interface as a New Remedy

The RFM interface has been newly introduced as an alternative remedy that allows for DRAM-MC cooperation. It is suggested as the primary means of RH-protection by the JEDEC committee [24, 25]. The RH-protection scheme resides on the DRAM-side while the MC provides a periodic but DRAM-row agnostic time margin to the DRAM bank. Periodic here is not based on time but on the number of ACTs over a single DRAM bank. Figure 1 shows an example of a main-memory organization scheme using an RFM interface and RFM issue logic. An MC has a Rolling Accumulated ACT (RAA) counter per bank that keeps track of the number of ACTs on its bank. When the RAA count reaches the RFM threshold (R​F​MT​HRFM_{TH}) set by the DRAM device, the MC issues an RFM command only to the corresponding bank and resets the RAA counter for the target bank. The larger the R​F​MT​HRFM_{TH}, the lower the frequency of the RFM command, which reduces the effect on the system performance. At every RFM command issue, the recipient bank receives a time margin (tRFM) during which no disturbance from any other regular operation is guaranteed.

A key difference with regard to the prior ARR command is that RFM is row agnostic and periodic (i.e., it cannot be issued in a bursty way). In a sense, it can be seen as an extension of the time-margin stealing method. The format of an RFM command is similar to that of a per-bank REF command [23, 22] specifying the bank to apply RFM, but not a certain row. Therefore, it requires minimal additional complexity to the MC. The symbols related to DRAM refresh, RH, and RFM are summarized in Table II-C3.

III Investigating RFM-based Schemes

RFM as a remedy for RH-protection allows for DRAM-side implementation with MC cooperation, eliminating multiple drawbacks of MC-side- or DRAM-side-only implementation. First, RFM can minimize the aforementioned overkill of the MC-side-only implementation because it can use an accurate prediction of F​l​i​pT​HFlip_{TH} and even set the R​F​MT​HRFM_{TH} value after testing the manufactured DRAM chip. It also scales according to the number of DRAM devices that are actually attached to the host. Second, RFM also provides a standard interface that a DRAM-side RH-protection scheme can utilize to gain an additional time margin for RH preventive refreshes. The ARR command assumed in many prior works is not supported in the recent DDR interface. RFM is newly being adopted and is now recommended as the primary method for RH-protection [25, 24].

III-A Incompatibility of Prior Approaches

Although promising, prior approaches based on ARR are not effective in RFM because RFM is vulnerable to the concentration of victim rows that require a preventive refresh. The ARR-based scheme has its own predefined threshold value directly related to the target F​l​i​pT​HFlip_{TH}. When its tracking mechanism detects the ACT count of an aggressor row reaching the predefined threshold, it immediately issues an ARR command and executes preventive refreshes to guarantee the deterministic RH safety. For example, Graphene with ARR can provide safety for F​l​i​pT​HFlip_{TH} that is linear to the predefined threshold (red line in Figure 2). Even if the predefined threshold is low, the relationship between predefined threshold and F​l​i​pT​HFlip_{TH} does not change.

However, when this ARR-based approach is applied to the RFM interface, there is a limit to F​l​i​pT​HFlip_{TH} that is guaranteed to be safe regardless of how low the predefined threshold is set (see Figure 2). With the same prior approach, one scheme could set a predefined threshold and buffer the aggressor rows that reach it. Then, when the subsequent RFM command is issued, the postponed preventive refresh can be executed on the corresponding adjacent victim rows. However, such a scheme is vulnerable when multiple aggressor rows reach the predefined threshold in a short period. For example, when the predefined threshold is 2K and the R​F​MT​HRFM_{TH} is reasonably set to 64 (see Section VI), the safe F​l​i​pT​HFlip_{TH} becomes 20K, not 10K. This occurs because 310 rows can reach 2K in a single tREFW period; thus the last buffered row must wait through (310×\times64) ACTs.

Refer to caption
Figure 2: Ineffectiveness of RFM-Graphene compared to the original ARR-Graphene. Note that the inverse of the predefined threshold indicates a larger table size with a lower resolution.

III-B Greedy Selection

To prevent the concentration of victim rows requiring a preventive refresh in an RFM-based scheme, it is necessary to properly select the target row and refresh its victims, even if the ACT count of the row has not reached F​l​i​pT​HFlip_{TH} or another predefined threshold. In particular, we propose the use of the greedy selection of a target row upon every RFM command for the RFM-based scheme.

An intuitive method for the proper selection of a row at every RFM command is to greedily choose the row with the highest estimated ACT count based on the tracking mechanism. Also, after choosing the row and refreshing its victims, it is logical to reset or minimize the estimated ACT count of the selected row to assist with the decision at the next RFM command, as the actual ACT count is now 0 after the refresh. Based on this simple basic principle, we search for the proper tracking mechanism.

III-C Counter-based Summary

Refer to caption
Figure 3: Counter-based Summary (CbS) algorithm operation.

We choose to use some variant of streaming algorithms for the RFM-based RH-protection scheme. While the grouped counter approach was effective in ARR-based work, it is no longer efficient in RFM (Section III-D). To support the greedy selection policy properly, the streaming algorithm must link the actual ACT count to the lower and upper bound of the estimated ACT count. We explain this in detail with an example.

Counter-based Summary (CbS) algorithm [37, 36, 2] is a representative streaming algorithm that matches such needs. The CbS algorithm has a table of entries, each holding an address and a counter. When the queried address hits an entry in the table (on-table), the counter in the corresponding entry is incremented by one. When it misses the table (off-table), it replaces the address of the entry with the minimum counter value in the table with the queried address. It then increments its counter by one (see Figure 3). Due to its monotonically increasing nature and swapping, the accumulated counter value above the minimum in the table belongs to the currently written address. In contrast, the ones below the minimum cannot find their source.

On-Table Addr:​E​s​t​i​m​a​t​e​d​C​o​u​n​t\displaystyle\text{On-Table\ Addr:}\ Estimated\ Count =W​r​i​t​t​e​n​C​o​u​n​t​e​r​V​a​l​u​e\displaystyle=Written\ Counter\ Value Off-Table Addr:​E​s​t​i​m​a​t​e​d​C​o​u​n​t\displaystyle\vspace{-0.18in}\text{Off-Table\ Addr:}\ Estimated\ Count =M​i​n\displaystyle=Min A​c​t​u​a​l​C​o​u​n​t\displaystyle Actual\ Count ≤E​s​t​i​m​a​t​e​d​C​o​u​n​t(1)\displaystyle\leq Estimated\ Count\,\,\;\;\;\;\;\;(1) E​s​t​i​m​a​t​e​d​C​o​u​n​t\displaystyle Estimated\ Count ≤A​c​t​u​a​l​C​o​u​n​t+M​i​n​(2)\displaystyle\leq Actual\ Count+Min\;\;(2)

The CbS algorithm reports the estimated (ACT) count of an on-table address with its written counter value, whereas the count of an off-table address is estimated with the minimum value in the entire table. Inequalities (1) and (2) correspondingly show the lower-bound and upper-bound of the estimated count in relation to the actual (ACT) count. Min denotes the minimum counter value in the table.

First, based on the lower bound (inequality (1)) of the estimated count, the RH-protection scheme is able to act upon an inaccurate, yet conservatively large ACT value. This allows the scheme to provide deterministic safety [32, 43, 56]. Second, the upper-bound (inequality (2)) of the estimated count is also necessary to decrement the estimated count of the greedily selected row at the RFM command, where the actual ACT count is now 0. Without this upper-bound, the estimated count cannot be decremented safely. The lossy-counting algorithm used in TWiCe [32] also has both the lower and upper bound of the estimated counts, but is less efficient algorithmically (as is later shown in Figure 6). It causes fewer preventive refreshes at the cost of a higher area overhead. Thus, we choose the CbS algorithm as the basic building block of our tracking mechanism.

There exists other streaming algorithms that only have a lower bound of the estimated count, such as Count-min Sketch [11], but it can only be used in throttling based works such as BlockHammer [56]. Others that do not have the lower bound such as Sticky-sampling [35] or Count-sketch [11] cannot provide deterministic safety.

Refer to caption
Figure 4: Mithril hardware implementation. An identical Mithril module with the logic and CAM structure is populated per bank, at every DRAM chip. Here, ①, ②, and ③ denote the high-level command flow.

III-D Grouped Counter Approach

The grouped counter approach was another type of tracking mechanism in ARR-based works. However, prior works that augmented this methodology are not compatible with or efficient at the RFM interface. CBT [49, 48] is the representative scheme of this type. First, it cannot utilize the RFM opportunities during its tree construction phase. Suppose it chooses to refresh a group prematurely that is not fully split. In such a case, it will have to refresh many rows too conservatively. Second, even after the tree is constructed, having a leaf node of a size larger than eight rows will not fit into a single tRFM period, leading to the stacking of refresh loads. CAT-TWO [26], which extends CBT, may guarantee that a leaf is small (covering a single row) enough, but only at the cost of a higher area overhead.

Refer to caption
Figure 5: Sequence of ACT and RFM commands and the corresponding update of the Mithril table. ①, ②, and ③ correspond to those in Figure 4.

III-E Probabilistic RFM-based Scheme

An RFM-compatible probabilistic RH-protection scheme (henceforth PARFM) can be built in a manner similar to PARA [30]. Whenever an RFM command arrives, PARFM randomly samples a single aggressor row among the last R​F​MT​HRFM_{TH} ACTs. PARFM’s protection capability depends solely on R​F​MT​HRFM_{TH}. By adjusting R​F​MT​HRFM_{TH} properly, PARFM can guarantee probabilistic safety on the target F​l​i​pT​HFlip_{TH}. However, as F​l​i​pT​HFlip_{TH} decreases, PARFM requires a lower R​F​MT​HRFM_{TH} than those in deterministic RFM-based schemes to maintain a high safety probability, leading to greater performance and energy overhead. We discuss this further in Section VI.

IV Mithril

Based on the investigation of the RFM-based RH-protection schemes in Section III, we present Mithril, the first RFM-interface-compatible RH-protection scheme providing a deterministic protection guarantee. It exploits a modified CbS algorithm for counter management.

IV-A Organization

The Mithril logic in each DRAM bank is composed of a counter structure (henceforth the Mithril table), two pointers (M​a​x​P​t​rMaxPtr and M​i​n​P​t​rMinPtr), and the control logic (Figure 4). To be more specific, the Mithril table comprises two CAM structures, one storing the row address and the other the ACT count. Each ACT counter is directly related to a single row address. The M​a​x​P​t​rMaxPtr and M​i​n​P​t​rMinPtr pointers are also employed as index pointing registers. The Mithril structure including the CAMs and logic must be equipped in every bank at every DRAM chip (Figure 4).

IV-B Operation

Figure 5 illustrates how Mithril manages the corresponding Mithril table and the two pointers, M​a​x​P​t​rMaxPtr and M​i​n​P​t​rMinPtr. The Mithril logic of the corresponding DRAM bank is informed at every ACT command (with an address) or RFM command (without an address). If the Mithril logic receives an ACT command, the count CAM, M​a​x​P​t​rMaxPtr, and M​i​n​P​t​rMinPtr are updated. To be more specific, first, Mithril checks if the address table already tracks the activated row address. If so, the associated ACT counter is incremented by one. When the row address misses, the address of the entry indicated by M​i​n​P​t​rMinPtr is replaced with the requesting row address, and its counter is incremented by one. If affected, M​a​x​P​t​rMaxPtr and M​i​n​P​t​rMinPtr are updated at each step to point correspondingly to the correct maximum and minimum. Thus far, the operation is identical to that of the original CbS algorithm.

When the Mithril logic instead receives an RFM command, Mithril selects the entry pointed via M​a​x​P​t​rMaxPtr (greedy-selection). It performs a preventive refresh for the two victim rows associated with this entry, identified as the prime candidates of the aggressor rows. Then, the counter value is decremented to the table’s minimum value pointed by M​i​n​P​t​rMinPtr. M​a​x​P​t​rMaxPtr is also updated correspondingly. The new M​a​x​P​t​rMaxPtr must be found during the RFM time window.

IV-C Mathematical Proof of Protection Guarantee

Mithril guarantees RH safety by preventing the ACT count of any row from reaching F​l​i​pT​HFlip_{TH} by continuing the greedy selection and preventive refresh processes. This contradicts prior works which triggered a preventive refresh at the exact hazardous moment where a row reaches a predefined threshold ACT value. To prove the deterministic safety of Mithril, we initially prove that continuously applying greedy selection and preventive refresh processes creates an upper bound in the rate of the estimated ACT count increment during tREFW. That upper bound is defined by an equation with Ne​n​t​r​yN_{entry} (the number of Mithril counter entries) and R​F​MT​HRFM_{TH}, as follows:

Theorem 1. Within any tREFW, an increase in the estimated count for any single row is bounded to MM, which is a function of Ne​n​t​r​yN_{entry} and R​F​MT​HRFM_{TH}.

M=∑k=1Ne​n​t​r​yR​F​MT​Hk+R​F​MT​HNe​n​t​r​y​(tREFW​(1−tRFCtREFI)tRC×R​F​MT​H+tRFM−2)\displaystyle M=\sum_{k=1}^{N_{entry}}\frac{RFM_{TH}}{k}+\frac{RFM_{TH}}{N_{entry}}\left(\frac{\text{tREFW}(1-\frac{\text{tRFC}}{\text{tREFI}})}{\text{tRC}\times RFM_{TH}+\text{tRFM}}-2\right)

Then, by setting Ne​n​t​r​yN_{entry} and R​F​MT​HRFM_{TH} so that MM is less than (F​l​i​pT​HFlip_{TH}/2), Mithril can deterministically prevent RH from experiencing double-sided attacks. The detailed proof of Theorem 1 is provided in the Appendix (Section IX).

IV-D Configuring Ne​n​t​r​yN_{entry} and R​F​MT​HRFM_{TH}

There are multiple possible Mithril configurations for a single target F​l​i​pT​HFlip_{TH} because both Ne​n​t​r​yN_{entry} and R​F​MT​HRFM_{TH} can change to satisfy M<F​l​i​pT​H/2M<Flip_{TH}/2. Figure 6 plots (Ne​n​t​r​yN_{entry}, R​F​MT​HRFM_{TH}) pairs that satisfy this condition for various F​l​i​pT​HFlip_{TH} values (e.g., 1.5K, 3.125K, …, 50K). First, a trade-off is depicted between Ne​n​t​r​yN_{entry} and R​F​MT​HRFM_{TH} regardless of F​l​i​pT​HFlip_{TH}. The decreased Ne​n​t​r​yN_{entry} implies less area usage but results in a lower R​F​MT​HRFM_{TH}, incurring more performance and energy overhead due to more frequent issuing of RFM commands. This trade-off exists for all instances of F​l​i​pT​HFlip_{TH}, but the appearance of the curve differs across various F​l​i​pT​HFlip_{TH} values. A scheme similar to Mithril but based on a Lossy-counting algorithm is also noted at F​l​i​pT​HFlip_{TH} values of 50K and 25K, which clearly demonstrates a larger table for a given F​l​i​pT​HFlip_{TH}.

When F​l​i​pT​HFlip_{TH} is sufficiently high (e.g., larger than 12.5K), it is possible to set R​F​MT​HRFM_{TH} to approximately 256 at a relatively small Ne​n​t​r​yN_{entry}. Then, Mithril can achieve RH-protection with relatively low area, performance, and energy overhead. In contrast, when F​l​i​pT​HFlip_{TH} is low, maintaining the low performance/energy overhead (i.e., sufficiently large R​F​MT​HRFM_{TH}) requires a substantially larger Ne​n​t​r​yN_{entry}. Overall, this is a trade-off that a DRAM vendor must consider when determining Ne​n​t​r​yN_{entry}. The target F​l​i​pT​HFlip_{TH} level can be adjusted by tweaking the R​F​MT​HRFM_{TH} value even if Ne​n​t​r​yN_{entry} is fixed. This flexibility can be handy when the scheme must be built based on the predicted F​l​i​pT​HFlip_{TH} level and thus a fixed area, as it can avoid excessive performance/energy overhead.

IV-E Wrapping Mithril Counters

The absolute counter value of the Mithril table can increase in an unbounded manner during its run-time, which complicates the hardware implementation. Prior works solved this issue by periodically resetting the entire table [43, 32] or by using a duplicate counter table in an interleaving fashion [56]; these two strategies lead to two-fold degradation of the predefined threshold level (from F​l​i​pT​H/2Flip_{TH}/2 to F​l​i​pT​H/4Flip_{TH}/4) and the area, respectively. However, Mithril can avoid this. Unlike prior approaches, Mithril does not require the absolute value of the estimated count. Instead, we require the relative difference of the estimated count in the minimum estimated count on the Mithril table. Moreover, due to the operational behavior of Mithril, the maximum difference between the M​a​x​P​t​rMaxPtr and M​i​n​P​t​rMinPtr counter values is always bounded. Therefore, we adopt a wrapping counter for Mithril table implementation. If we provision enough bits capable of expressing a value larger than the maximum difference in the table, the wrapping counter can always correctly identify the relative size relationship among Mithril table entries. Through this implementation, we acquire a two-fold benefit.

Refer to caption
Figure 6: Each line denotes the possible configuration of Ne​n​t​r​yN_{entry} (represented by the counter table size) and R​F​MT​HRFM_{TH} that can protect victim rows against RH at the given F​l​i​pT​HFlip_{TH} value. The RFM-based scheme built with a Lossy-Counting algorithm is also indicated by the dotted lines.

V Enhancing Mithril Further

V-A Adaptive Refresh

Section IV assumed that Mithril performs a preventive refresh for every RFM command. However, if Mithril can successfully distinguish a benign memory access pattern from an RH attack pattern, we can skip some of the RFM commands. We find that the difference between the M​a​x​P​t​rMaxPtr and the M​i​n​P​t​rMinPtr count values is an effective identifier of such different patterns. Thus, we propose to perform a preventive refresh only when this difference exceeds a certain threshold (A​dT​HAd_{TH}). This is referred to as an adaptive refresh policy.

The difference between the M​a​x​P​t​rMaxPtr and the M​i​n​P​t​rMinPtr count values serves as a decent proxy of possible RH attacks, as large difference implies a high concentration of memory accesses to a small number of rows. Therefore, if A​dT​HAd_{TH} is set large enough, Mithril with the adaptive refresh policy can effectively filter out the ACT patterns observed by normal workloads. Figure 7 shows the effectiveness of the adaptive refresh policy, nearly eliminating additional energy overhead with benign workloads (see Section VI for the details of the experimental setup).

Refer to caption
Figure 7: Relative dynamic energy overhead and additional Ne​n​t​r​yN_{entry} against the default Mithril (0 A​dT​HAd_{TH}) for four different A​dT​HAd_{TH} levels.

Among the multiple A​dT​HAd_{TH} values, we can identify that the adaptive refresh policy is effective at the range of 100 to 200 in all cases. We seek the root cause in the cross-play of memory access patterns of ordinary workloads and the DRAM row size. Multithreaded or memory-intensive workloads often exhibit large-object-sweep behavior that results in main-memory accesses (Figure 8(a)). In such a case, memory accesses are concentrated on a small number of rows in a short time period (Figure 8(b)) while being rather evenly distributed over the entire footprint overall. Although such an access pattern may possess high DRAM row locality, inter-process/thread conflicts can cause a high rate of ACT per memory access (Figure 8(c)). Here, the number of concentrated ACTs would be similar to the number of streaming RDs/WRs, which would be 128 for an 8KB DRAM row and a 64B cache line size. This matches the range of the effective adaptive threshold values, although the exact value must be determined empirically.

The adaptive refresh policy causes a slight deterioration of the bound MM (Theorem 1), thus inducing a higher area or performance cost to ensure the same effect as the baseline. However, such an effect is minimal unless A​dT​HAd_{TH} is very high. Figure 7 shows a small increase in Ne​n​t​r​yN_{entry}, a maximum of 12% at only a very low F​l​i​pT​HFlip_{TH} value. Proof of the adjusted bound can be derived from Theorem 1 but is omitted here due to a lack of space.

Refer to caption
Figure 8: Example of a large object sweep pattern of lbm in SPEC CPU2017: (a) the memory access pattern in the large time window, (b) magnified to a small window, (c) the activation pattern in the small window.

V-B Mithril+

The adaptive refresh policy allows Mithril to skip a preventive refresh even when the RFM command is issued by the memory controller. By doing so, Mithril can reduce energy consumption but not the performance overhead. Regardless of whether a DRAM component actually performs refreshes, the MC will continue to issue RFM commands at every R​F​MT​HRFM_{TH} ACT.

Inspired by such a limitation, we propose an optional, more invasive extension of Mithril, termed Mithril+, which prevents the MC from issuing unnecessary RFM commands. Mithril+ utilizes the mode register in the DRAM device, which is flagged when the difference between M​a​x​P​t​rMaxPtr and M​i​n​P​t​rMinPtr is smaller than the values of A​dT​HAd_{TH}. At every R​F​MT​HRFM_{TH}, MC reads the flag using the JEDEC-standard MRR (Mode Register Read) command, determining whether or not to issue the RFM command. With this interface, Mithril+ can substantially minimize the performance overhead in the common case of ordinary workloads at the expense of a modification to the RFM interface.

V-C Non-adjacent Row Hammer

Mithril can follow approaches similar to those in prior works [43, 56] with regard to handling a non-adjacent RH by adjusting the MM value and the number of rows required to execute a preventive refresh. When the range of the RH effect is one (double-sided attack, which we have assumed thus far for Mithril), MM smaller than F​l​i​pT​H/2Flip_{TH}/2 is safe. However, when the range is broader, MM must be smaller than F​l​i​pT​H/(a​g​g​r​e​g​a​t​e​d​R​H​e​f​f​e​c​t)Flip_{TH}/(aggregated\ RH\ effect) for non-adjacent aggressors. Within the range of 3, the aggregated RH effect is 3.5 [56], with six victim rows to execute a preventive refresh.

VI Evaluation

TABLE III: Architectural parameters for simulation
       Core Configurations (16 cores)
  Core 3.6 GHz 4-way OOO cores
LLC 16 MB
       Memory System Configurations
  Module DDR5-4800
Channel 2 channels
Configuration 1 rank; 32 banks per rank
Scheduling BLISS [53]
Page-Policy Minimalist-open [27]
tRFC, tRC, tRFM 295 ns, 48.64 ns, 97.28 ns
tRCD, tRP, tCL 16.64 ns
 

We evaluate the performance, energy, and area overhead of Mithril and Mithril+ in comparison with the RFM-interface-compatible PARFM and BlockHammer, as well as the RFM-interface-non-compatible PARA, CBT, TWiCe, and Graphene.

VI-A Experimental Setup

Methodology: The performance overhead is evaluated based on McSimA+ [3]. Table III summarizes the experimental setup. We use the normalized aggregate IPC as the performance metric, where the baseline is the aggregate IPC without applying any RH-protection scheme for a workload. We count the number of ACTs, PREs, and executed preventive refreshes to calculate the dynamic energy dissipation. First, we synthesize the RTL implementation of the Mithril module using the TSMC 40 nm standard cell library with the Synopsys Design Compiler. The area overhead is scaled down to DRAM 20 nm and then again scaled up 10×\times [14] to conservatively take the inferior DRAM process into account. The hardware energy consumption of Mithril is also derived from the synthesis.

Workloads: We use 1) normal, 2) multi-sided RH, and 3) BlockHammer-performance-adversarial workloads for evaluation. We use both multi-programmed and multi-threaded workloads for normal workloads, reporting their geo-mean values. From SPEC CPU2017, we extract 100M instruction traces [51] and render two different workloads, mix-high and mix-blend, each of which comprises 16 traces of memory-intensive and randomly selected workloads, respectively. We execute 400M instructions in total. We also evaluate three different multi-threaded benchmarks (FFT and RADIX from SPLASH-2 [44] and PageRank from GAP [6]).

We configure a multi-sided RH attack that targets multiple victims [15, 16], typically 32 in total. The adversarial pattern for BlockHammer in performance is configured to blacklist specific profiled rows that share the CBF (counting bloom filter) entry with the benign threads. Each is activated just enough to reach the blacklist threshold. This effectively throttles benign workloads, especially memory-intensive types. Each RH attack or adversarial pattern runs simultaneously with the 15 other benign workloads.

Configurations: We select up to three different Mithril and Mithril+ (Ne​n​t​r​yN_{entry}, R​F​MT​HRFM_{TH}) configurations for each F​l​i​pT​HFlip_{TH}, ranging from 50K to 1.5K. Recently observed [29] F​l​i​pT​HFlip_{TH} values are approximately 5K, but 1.5K is reachable considering the continued scaling of process technology and the non-adjacent RH. At high F​l​i​pT​HFlip_{TH} values of 50K and 25K, R​F​MT​HRFM_{TH} at fixed to 256 given that Ne​n​t​r​yN_{entry} is already low. At the lowest F​l​i​pT​HFlip_{TH} of 1.5K, R​F​MT​HRFM_{TH} is fixed at 32 because a higher R​F​MT​HRFM_{TH} value results in an overly high Ne​n​t​r​yN_{entry}. We use a value of 200 for A​dT​HAd_{TH} as the default value. For PARFM, R​F​MT​HRFM_{TH} is fixed to satisfy a failure probability of 10−1510^{-15} (a typical consumer memory reliability target [56, 9, 10, 21, 34, 45]) for 64 banks within a 32ms time period (tREFW) for each F​l​i​pT​HFlip_{TH}. The probability degrades if the number of banks to support increases.

We reconfigure BlockHammer111 BlockHammer uses a pair of interleaved counting bloom filters (CBFs) similar to Count-min Sketch algorithm. Each CBF is reset at every CBF lifetime (tC​B​Ft_{CBF}), which typically matches tREFW. There exists a certain blacklist threshold (NB​LN_{BL}) of ACT that triggers a delay on a certain row when it is surpassed. The delay time (tD​e​l​a​yt_{Delay}) is calculated as (tC​B​F−NB​L×tRC)/(F​l​i​pT​H−NB​L)(t_{CBF}-N_{BL}{\times}\text{tRC})/(Flip_{TH}-N_{BL}). Thread-level scheduling support is built on top of these to throttle the aggressor thread itself. to match our simulation environment and our target F​l​i​pT​HFlip_{TH} values. For (CBF size, NB​LN_{BL}) pairs, we used (1K, 17.1K), (1K, 8.6K), (1K, 4.3K), (2K, 2.1K), (4K, 1.1K), and (8K, 0.49K) for F​l​i​pT​HFlip_{TH} from 50K to 1.5K. Under our system of four banks per thread, the number of ACTs per row easily exceeds 700 (as opposed to 109 ACTs in the original BlockHammer system with more banks per thread [56]), especially for memory-intensive workloads. Because NB​LN_{BL} must be lower than F​l​i​pT​H/2Flip_{TH}/2 (750 for a F​l​i​pT​HFlip_{TH} value of 1.5K), it is difficult to set an appropriate NB​LN_{BL} value that distinguishes benign accesses from aggressor accesses and fulfill RH-protection at a F​l​i​pT​HFlip_{TH} value of 1.5K while also incurring minimal performance overhead.

Other prior schemes not compatible with RFM are also configured for a fair comparison with Mithril. TWiCe and Graphene are configured using the equations provided in each work to be applied to the DDR5 specification. PARA is configured to satisfy a failure probability of 10−1510^{-15}. CBT is configured to follow the configuration in the original work [49, 48].

Refer to caption
Figure 9: The relative performance and area overhead of Mithril and Mithril+.

VI-B The Overheads of Mithril and Mithril+

Mithril+ shows nearly zero performance overhead at all F​l​i​pT​HFlip_{TH} levels. The performance of Mithril degrades, with the amount depending on the target F​l​i​pT​HFlip_{TH} and R​F​MT​HRFM_{TH} configurations. There exists a performance-area trade-off for every F​l​i​pT​HFlip_{TH}, which is amplified as F​l​i​pT​HFlip_{TH} value becomes smaller.

Mithril can support the recently observed F​l​i​pT​HFlip_{TH} values of approximately 6.25K [29] with an R​F​MT​HRFM_{TH} of 128, which results in performance overhead of less than 0.5% and a table size per bank of 1KB. Mithril can also support lower F​l​i​pT​HFlip_{TH} values, though at the cost of around 2% of the performance and 4KB of area overhead. The area overhead of Mithril+ is identical to that of Mithril, with only negligible performance overhead.

VI-C Comparison with Other Interface-Compatible Schemes

Refer to caption
Figure 10: (a), (b), and (c): Relative performance at normal workloads, under a multi-sided RH-attack, and BlockHammer-adversarial patterns; (d) Relative dynamic energy at normal workloads; and (e) Area overhead of BlockHammer and Mithril.

Figure 10 shows the performance and the energy overhead of other RFM-interface-compatible schemes of PARFM and BlockHammer on multiple workloads for F​l​i​pT​HFlip_{TH} values ranging from 50K to 1.5K. First, on normal workloads (Figure 10(a)), both Mithril+ and Mithril show small performance degradation of less than 2%, superior to that of both PARFM and BlockHammer. BlockHammer is particularly vulnerable at the low F​l​i​pT​HFlip_{TH} of 1.5K because it is prone to misidentifying benign threads and throttling them under such a condition.

Second, at the multi-sided RH (Figure 10(b)), BlockHammer exhibits a better aggregate IPC of up to 5% for higher F​l​i​pT​HFlip_{TH} values, but it degrades again at a low F​l​i​pT​HFlip_{TH} value. This occurs because when BlockHammer successfully identifies RH attacking threads and throttles them, benign threads can benefit in return. However, this again leads to vulnerabilities during misclassifications when F​l​i​pT​HFlip_{TH} is lower than, for instance, 1.5K. The performance of Mithril and PARFM are agnostic with regard to the access patterns.

Lastly, regarding the performance of BlockHammer with an adversarial pattern (Figure 10(c)), the performance of BlockHammer degrades severely, with as much as a 17% drop in the aggregate IPC. This implies the possibility of a critical performance (not RH) attack on systems equipped with BlockHammer, as its throttling feature works as a double-edged sword depending on how effectively it identifies RH attacking threads.

The energy overhead of Mithril and Mithril+ are less than 0.4%, even when F​l​i​pT​HFlip_{TH} is 1.5K. These values are much smaller than that of PARFM and slightly higher than that of BlockHammer (Figure 10(d)). This occurs because the adaptive refresh policy successfully identifies ordinary workloads, skipping many of the RFM commands and not triggering additional preventive refreshes. PARFM shows the energy overhead in cases when every RFM command triggers a preventive refresh. BlockHammer causes only minimal logic energy because it is a throttling-based scheme.

The table size overhead of Mithril is much smaller than that of BlockHammer at all F​l​i​pT​HFlip_{TH} levels. Figure 10(e) shows the table size overhead for each scheme. PARFM is omitted due to its negligible overhead, and that of Mithril+ is identical to Mithril. The table size of Mithril is up to 60×\times and a minimum of 4×\times smaller than that of BlockHammer at all F​l​i​pT​HFlip_{TH} levels. The table size comparison is discussed further in Section VI-E.

VI-D Comparison with Interface Non-Compatible Schemes

Refer to caption
Figure 11: Relative performance at (a) normal workloads and (b) multi-sided RH-attack; (c): Relative dynamic energy at normal workloads.

Mithril and Mithril+ also show competitive performance and energy overhead compared to the RFM-non-compatible prior works of PARA, CBT, TWiCe, and Graphene. Under both normal workloads and a multi-sided RH attack situation (Figure 11(a), (b)), Mithril+ shows performance degradation of less than 0.2%, comparable to those of TWiCe, Graphene, or CBT. The performance degradation of Mithril is worse than those of other schemes but is limited to less than 2% even at the low F​l​i​pT​HFlip_{TH} of 1.5K. The energy overhead of Mithril is comparable to those of TWiCe and Graphene at less than 1% even when F​l​i​pT​HFlip_{TH} is 1.5K (Figure 11(c)).

VI-E Table Size Overhead

TABLE IV: Per Bank Table Size Comparison (KB)
 
Scheme
50K
25K
12.5K
6.25K
3.125K
1.5K
CBT @ MC 0.47 0.97 2.0 4.12 8.5 17.5
Graphene @ MC 0.14 0.21 0.51 0.99 1.92 3.7
BlockHammer @ MC 3.75 3.5 3.25 6.0 11.0 20.0
TWiCe @ buffer chip 2.79 5.08 9.54 18.27 35.29 71.26
Mithril-256 @ DRAM 0.08 0.17 0.41 1.45 - -
Mithril-128 @ DRAM 0.07 0.15 0.34 0.84 3.76 -
Mithril-64 @ DRAM 0.07 0.14 0.3 0.68 1.78 -
Mithril-32 @ DRAM 0.06 0.13 0.27 0.57 1.38 4.64
 

Mithril-(256/128/64/32) denote different R​F​MT​HRFM_{TH} values ranging from 256 to 32.

We report the counter table size of each scheme in units of KB per bank (see Table VI-E). While MC-side schemes benefit from their use of faster transistors, abundant wiring resources, and a relaxed area budget, the number of total banks is much higher (1,024), and the target F​l​i​pT​HFlip_{TH} must be pessimistic. DRAM-side schemes benefit from fewer banks (32) to support per device and more accurate F​l​i​pT​HFlip_{TH} values, but they are hindered by slower transistors and a tighter area/wiring budget.

Mithril shows lower or competitive area overhead in terms of the KB per bank, reaching 0.024m​m2mm^{2} when F​l​i​pT​HFlip_{TH} equals 6.25K. This represents 1% of a single DDR5 chip [28] when multiplied by 32 to cover 32 banks per chip. While both Graphene and Mithril share fundamentally the same CbS algorithm as their tracking mechanism, their table size overhead differs for several reasons. First, as an advantage for Mithril, it does not require a table reset due to the wrapping counter scheme, resulting in two-fold reduction. Also, the per-entry bit width of the counter CAM is smaller in Mithril because the maximum value is bounded to MM (Theorem 1), which is smaller than the Graphene case for maximum number of ACTs in the tREFW window. At a F​l​i​pT​HFlip_{TH} value of 1.5K, we ensure that R​F​MT​HRFM_{TH} is small to minimize the performance drop, resulting in increased Ne​n​t​r​yN_{entry} and area overhead.

VII Related Work

Row Hammer (RH) on Real Systems: RH has been shown to be able to bypass all system memory protection schemes, allowing adversaries to compromise the confidentiality and integrity of actual systems. In 2015, Google [47] demonstrated that a user-level program could breach the system-level security of a typical PC by exploiting the RH vulnerability of the system. A number of successful attacks followed [47], including those compromising mobile devices [54, 55] and servers [19, 13, 46], thus breaking the authentication process and damaging the entire system, even when a system protects memory locations near sensitive data [59]. Because RH undermines the fundamental principle of memory isolation, it has been regarded as a serious threat, drawing mitigation proposals from software, architecture, and hardware levels.

Architectural Proposals to Mitigate RH: There have been deterministic [50, 26, 32, 43, 56] and probabilistic [30, 52, 58] schemes proposed to mitigate RH attacks at the architecture level. Among these, [58, 52, 50] are susceptible to adversarial DRAM access patterns. TWiCe [32] and CAT-TWO [26] are relatively free from this susceptibility but require an order of magnitude more storage to track aggressor rows compared to Graphene [43]. PARA [30] incurs low performance and energy overhead, whereas it is also extremely area-efficient as it does not require counters to trace aggressor rows. Yet, the protection is probabilistic in nature; even if the probability is quite small, there is a non-zero probability that a victim row will not be refreshed after reaching its RH threshold. BlockHammer [56] uses a throttling approach backed up with thread-level MC scheduling.

VIII Conclusion

Here, we propose Mithril, a DRAM-side, RFM-compatible, efficient scheme that provides deterministic safety against Row Hammer attacks. First, we show that the conventional algorithms and methodologies used in previous architectural RH-prevention schemes are not compatible with the RFM command introduced in the latest DRAM specifications, such as DDR5 and LPDDR5. By mathematical defining the maximum bound of activation count without a refresh in a tREFW time window, we guarantee safety at a specific F​l​i​pT​HFlip_{TH} value. The devised adaptive refresh policy decreases the energy overhead by exploiting the row activation patterns of ordinary workloads. Moreover, we proposed Mithril+, which requires a slight modification of the RFM interface. It utilizes the existing DRAM command to skip the sending of RFM commands, which can significantly reduce the performance overhead of Mithril. Our evaluation demonstrates that Mithril achieves a significantly low energy overhead in all cases compared to PARFM, whereas it incurs slightly higher performance overhead. Mithril+ shows not only low energy overhead but also significantly lower performance overhead such that it is comparable to Graphene, a state-of-the-art RH-prevention scheme that does not support RFM.

Acknowledgment

This work was supported by Institute of Information & communications Technology Planning & Evaluation (IITP) grant funded by the Korea government (MSIT) (2020-0-01300, Development of AI-specific Parallel High-speed Memory Interface, and 2021-0-01343, Artificial Intelligence Graduate School Program (Seoul National University)). Jung Ho Ahn is the corresponding author.

IX Appendix

IX-A Proof for Theorem 1

Theorem 1. Within any tREFW, an increase in the estimated count for any single row is bounded to MM, which is a function of Ne​n​t​r​yN_{entry} and R​F​MT​HRFM_{TH}.

M=∑k=1Ne​n​t​r​yR​F​MT​Hk+R​F​MT​HNe​n​t​r​y​(tREFW​(1−tRFCtREFI)tRC×R​F​MT​H+tRFM−2)\displaystyle M=\sum_{k=1}^{N_{entry}}\frac{RFM_{TH}}{k}+\frac{RFM_{TH}}{N_{entry}}\left(\frac{\text{tREFW}(1-\frac{\text{tRFC}}{\text{tREFI}})}{\text{tRC}\times RFM_{TH}+\text{tRFM}}-2\right)

Refer to caption
Figure 12: Example case illustrating how the estimated count is updated between two consecutive RFM intervals.

Henceforth, Ne​n​t​r​yN_{entry} is replaced by NN. Also, WW represents the maximum number of RFM intervals (the period between two consecutive RFM commands) within a tREFW. It is computed as follows:

W=⌈(tREFW−(tREFW/tREFI)×tRFC)/(tRC×R​F​MT​H+tRFM)⌉\displaystyle W=\left\lceil(\text{tREFW}-(\text{tREFW}/\text{tREFI})\times\text{tRFC})/(\text{tRC}\times RFM_{TH}+\text{tRFM})\right\rceil

Suppose cj​[i]c_{j}[i] is the ii-th largest estimated count in the Mithril table at the beginning of the jj-th RFM interval (1≤i≤N,1≤j≤W1\leq i\leq N,1\leq j\leq W). cj′​[i]c^{\prime}_{j}[i] is the ii-th largest estimated count in the table at the end of the jj-th RFM interval. Figure 12 illustrates a prime example of such notations. Then, the following Lemmas hold true:

Lemma 1. cj′​[i]=cj+1​[i−1]c^{\prime}_{j}[i]=c_{j+1}[i-1] Proof: At the end of each RFM interval, one of the entries with the largest estimated count (i.e., cj′​[1]c^{\prime}_{j}[1]) becomes the target for the RFM refresh, and its estimated count is reset to the minimum count in the table. Thus, the ranks of all other entries are increased by one after the RFM refresh.

Lemma 2. ∑i=1kcj′​[i]≤∑i=1kcj​[i]+R​F​MT​H\sum_{i=1}^{k}c^{\prime}_{j}[i]\leq\sum_{i=1}^{k}c_{j}[i]+RFM_{TH} for 1≤k≤N1\leq k\leq N Proof: Considering that there are R​F​MT​HRFM_{TH} ACTs within each RFM interval and cj′​[i]c^{\prime}_{j}[i] is larger than or equal to cj​[i]c_{j}[i] for all values of ii by definition, the following holds true: ∑i=1kcj′​[i]\displaystyle\sum_{i=1}^{k}c^{\prime}_{j}[i] =∑i=1Ncj′​[i]−∑i=k+1Ncj′​[i]\displaystyle=\sum_{i=1}^{N}c^{\prime}_{j}[i]-\sum_{i=k+1}^{N}c^{\prime}_{j}[i] =∑i=1Ncj​[i]+R​F​MT​H−∑i=k+1Ncj′​[i]\displaystyle=\sum_{i=1}^{N}c_{j}[i]+RFM_{TH}-\sum_{i=k+1}^{N}c^{\prime}_{j}[i] =∑i=1kcj​[i]−∑i=k+1N(cj′​[i]−cj​[i])+R​F​MT​H\displaystyle=\sum_{i=1}^{k}c_{j}[i]-\sum_{i=k+1}^{N}(c^{\prime}_{j}[i]-c_{j}[i])+RFM_{TH} ≤∑i=1kcj​[i]+R​F​MT​H\displaystyle\leq\sum_{i=1}^{k}c_{j}[i]+RFM_{TH}

Lemma 3. ∑i=1kcj​[i]≤∑i=1kcj−1​[i]+R​F​MT​H\sum_{i=1}^{k}c_{j}[i]\leq\sum_{i=1}^{k}c_{j-1}[i]+RFM_{TH} for 1≤k≤N1\leq k\leq N Proof: This is an obvious extension of Lemma 2 because ∑i=1kcj​[i]≤∑i=1kcj−1′​[i]\sum_{i=1}^{k}c_{j}[i]\leq\sum_{i=1}^{k}c^{\prime}_{j-1}[i]. In other words, an RFM refresh always decreases the sum of the top kk counter values in the table.

Lemma 4. ∑i=1kcj​[i]≤kk+1​(∑i=1k+1cj−1​[i]+R​F​MT​H)\sum_{i=1}^{k}c_{j}[i]\leq\frac{k}{k+1}(\sum_{i=1}^{k+1}c_{j-1}[i]+RFM_{TH}) for 1≤k≤N−11\leq k\leq N-1 Proof: Using Lemma 1, Lemma 2, and the fact that cj−1′​[1]≥cj−1′​[i]c^{\prime}_{j-1}[1]\geq c^{\prime}_{j-1}[i] for all ii, the following holds true: ∑i=1kcj​[i]\displaystyle\sum_{i=1}^{k}c_{j}[i] =∑i=2k+1cj−1′​[i]\displaystyle=\sum_{i=2}^{k+1}c^{\prime}_{j-1}[i] =∑i=1k+1cj−1′​[i]−cj−1′​[1]\displaystyle=\sum_{i=1}^{k+1}c^{\prime}_{j-1}[i]-c^{\prime}_{j-1}[1] ≤∑i=1k+1cj−1′​[i]−1k+1​∑i=1k+1cj−1′​[i]\displaystyle\leq\sum_{i=1}^{k+1}c^{\prime}_{j-1}[i]-\frac{1}{k+1}\sum_{i=1}^{k+1}c^{\prime}_{j-1}[i] =kk+1​∑i=1k+1cj−1′​[i]\displaystyle=\;\frac{k}{k+1}\sum_{i=1}^{k+1}c^{\prime}_{j-1}[i] ≤kk+1​(∑i=1k+1cj−1​[i]+R​F​MT​H)\displaystyle\leq\;\frac{k}{k+1}\left(\sum_{i=1}^{k+1}c_{j-1}[i]+RFM_{TH}\right)

With these Lemmas, we are ready to prove Theorem 1. Proving Theorem 1 is equivalent to proving the following: cW′​[1]−c1​[N]≤M​ for given ​c1​[1],…,c1​[N]\displaystyle c^{\prime}_{W}[1]-c_{1}[N]\leq M\text{~{}for given~{}}c_{1}[1],...,c_{1}[N]

This works because any row’s estimated count that is increased during the WW RFM intervals is obviously less than the difference between the largest estimated count at the end (cW′​[1]c^{\prime}_{W}[1]) and the smallest estimated count at the beginning (c1​[N]c_{1}[N]). Accordingly, we can obtain the upper bound for cW′​[1]c^{\prime}_{W}[1] as follows:

cW′​[1]\displaystyle c^{\prime}_{W}[1] ≤cW[1]+RFMT​H(∵ Lemma 2)\displaystyle\leq c_{W}[1]+RFM_{TH}\;\;\;(\because\text{~{}Lemma 2}) ≤12(∑i=12cW−1[i]+RFMT​H)+RFMT​H(∵ Lemma 4)\displaystyle\leq\frac{1}{2}\left(\sum_{i=1}^{2}c_{W-1}[i]+RFM_{TH}\right)+RFM_{TH}\;\;\;(\because\text{~{}Lemma 4}) ≤13(∑i=13cW−2[i]+RFMT​H)+∑k=12R​F​MT​Hk(∵ Lemma 4)\displaystyle\leq\frac{1}{3}\left(\sum_{i=1}^{3}c_{W-2}[i]+RFM_{TH}\right)+\sum_{k=1}^{2}\frac{RFM_{TH}}{k}\;\;\;(\because\text{~{}Lemma 4})

Repeatedly applying Lemma 4 for a total of N−1N-1 times, we obtain the following inequality:

cW′​[1]\displaystyle c^{\prime}_{W}[1] ≤1N​(∑i=1NcW−N+1​[i]+R​F​MT​H)+∑k=1N−1R​F​MT​Hk\displaystyle\leq\frac{1}{N}\left(\sum_{i=1}^{N}c_{W-N+1}[i]+RFM_{TH}\right)+\sum_{k=1}^{N-1}\frac{RFM_{TH}}{k} =1N​(∑i=1NcW−N+1​[i])+∑k=1NR​F​MT​Hk\displaystyle=\frac{1}{N}\left(\sum_{i=1}^{N}c_{W-N+1}[i]\right)+\sum_{k=1}^{N}\frac{RFM_{TH}}{k}

At this point, we can no longer apply Lemma 4 and instead apply Lemma 3 (k=Nk=N) W−NW-N times.

cW′​[1]\displaystyle c^{\prime}_{W}[1] ≤∑i=1Nc1​[i]N+(W−N)​R​F​MT​HN+∑k=1NR​F​MT​Hk\displaystyle\leq\frac{\sum_{i=1}^{N}c_{1}[i]}{N}+\frac{(W-N)RFM_{TH}}{N}+\sum_{k=1}^{N}\frac{RFM_{TH}}{k} =∑i=1Nc1​[i]N+M−N−2N​R​F​MT​H\displaystyle=\frac{\sum_{i=1}^{N}c_{1}[i]}{N}+M-\frac{N-2}{N}RFM_{TH}

Earlier, we showed that proving Theorem 1 is equivalent to proving cW′​[1]−c1​[N]≤Mc^{\prime}_{W}[1]-c_{1}[N]\leq M. With the above equation, proving the following is the only step left to prove Theorem 1:

∑i=1Nc1​[i]N−c1​[N]≤N−2N​R​F​MT​H\displaystyle\frac{\sum_{i=1}^{N}c_{1}[i]}{N}-c_{1}[N]\leq\frac{N-2}{N}RFM_{TH}

Here, the left-hand side can be represented as follows.

∑i=1Nc1​[i]N−c1​[N]=∑i=1Nc1​[i]−N​c1​[N]N=∑i=1N(c1​[i]−c1​[N])N\displaystyle\frac{\sum_{i=1}^{N}c_{1}[i]}{N}-c_{1}[N]=\frac{\sum_{i=1}^{N}c_{1}[i]-Nc_{1}[N]}{N}=\frac{\sum_{i=1}^{N}(c_{1}[i]-c_{1}[N])}{N}

The upper bound of ∑i=1N(cj​[i]−cj​[N])\sum_{i=1}^{N}(c_{j}[i]-c_{j}[N]) for any jj-th RFM interval can be obtained by contradiction. We assume that ∑i=1N(cj​[i]−cj​[N])\sum_{i=1}^{N}(c_{j}[i]-c_{j}[N]) is maximized when jj is mm and that the difference between cm​[1]c_{m}[1] and cm​[N]c_{m}[N] is greater than R​F​MT​HRFM_{TH}. Then, the following holds:

cm−1′​[1]−cm−1′​[N]≥cm−1′​[2]−cm−1′​[N]=cm​[1]−cm​[N]>R​F​MT​H\displaystyle\begin{split}c^{\prime}_{m-1}[1]-c^{\prime}_{m-1}[N]&\;\geq\;c^{\prime}_{m-1}[2]-c^{\prime}_{m-1}[N]\\ &\;=\;c_{m}[1]-c_{m}[N]\;>\;RFM_{TH}\\ \end{split} (3)

At the end of the (mm-1)-th RFM interval, cm−1′​[1]c^{\prime}_{m-1}[1] is reduced to cm−1′​[N]c^{\prime}_{m-1}[N] by RFM. Therefore

∑i=1N(cm​[i]−cm​[N])\displaystyle\sum_{i=1}^{N}(c_{m}[i]-c_{m}[N]) =∑i=1N(cm−1′​[i]−cm−1′​[N])−(cm−1′​[1]−cm−1′​[N])\displaystyle=\sum_{i=1}^{N}(c^{\prime}_{m-1}[i]-c^{\prime}_{m-1}[N])-(c^{\prime}_{m-1}[1]-c^{\prime}_{m-1}[N]) =∑i=1N(cm−1​[i]−cm−1​[N])+R​F​MT​H−(cm−1′​[1]−cm−1′​[N])\displaystyle=\sum_{i=1}^{N}(c_{m-1}[i]-c_{m-1}[N])+RFM_{TH}-(c^{\prime}_{m-1}[1]-c^{\prime}_{m-1}[N]) <∑i=1N(cm−1[i]−cm−1[N])(∵(3))\displaystyle<\sum_{i=1}^{N}(c_{m-1}[i]-c_{m-1}[N])\;\;\;(\because~{}\text{(\ref{eq:diff_c1_cN})})

This contradicts the contention that ∑i=1N(cj​[i]−cj​[N])\sum_{i=1}^{N}(c_{j}[i]-c_{j}[N]) is maximized when jj is mm. Therefore, if ∑i=1N(cj​[i]−cj​[N])\sum_{i=1}^{N}(c_{j}[i]-c_{j}[N]) is maximized when jj is mm, the difference between cm​[1]c_{m}[1] and cm​[N]c_{m}[N] is less than or equal to R​F​MT​HRFM_{TH}. Then, we obtain the following inequality:

∑i=1N(c1​[i]−c1​[N])N\displaystyle\frac{\sum_{i=1}^{N}(c_{1}[i]-c_{1}[N])}{N} ≤∑i=1N(cm​[i]−cm​[N])N\displaystyle\leq\frac{\sum_{i=1}^{N}(c_{m}[i]-c_{m}[N])}{N} =∑i=1N−2(cm​[i]−cm​[N])N(∵cm[N−1]=cm[N])\displaystyle=\frac{\sum_{i=1}^{N-2}(c_{m}[i]-c_{m}[N])}{N}\;\;\;(\because~{}c_{m}[N-1]=c_{m}[N]) ≤∑i=1N−2(cm​[1]−cm​[N])N\displaystyle\leq\frac{\sum_{i=1}^{N-2}(c_{m}[1]-c_{m}[N])}{N} ≤(N−2)​R​F​MT​HN\displaystyle\leq\frac{(N-2)RFM_{TH}}{N}

IX-B Finding New MM for Adaptive Refresh

If the adaptive refresh policy (Section V-A) is applied to Mithril, Lemmas 1 and 4 in Section IX-A no longer hold because the preventive refresh may not occur at the end of the RFM interval. The modified MM (henceforth M′M^{\prime}) for the adaptive refresh is as follows.

Theorem 2. When the adaptive refresh is applied to Mithril, an increase in the estimated count for any single row within any tREFW is bounded to M′M^{\prime}, which is a function of Ne​n​t​r​yN_{entry}, R​F​MT​HRFM_{TH}, and A​dT​HAd_{TH}.

M′\displaystyle M^{\prime} =∑k=1nR​F​MT​Hk+(W−n∗+Ne​n​t​r​y−2)​R​F​MT​H+(Ne​n​t​r​y−n∗)​A​dT​HNe​n​t​r​y\displaystyle=\sum_{k=1}^{n}\frac{RFM_{TH}}{k}+\frac{(W-n^{*}+N_{entry}-2)RFM_{TH}+(N_{entry}-n^{*})Ad_{TH}}{N_{entry}} ∗W=⌈(tREFW−(tREFW/tREFI)×tRFC)/(tRC×RFMT​H+tRFM)⌉\displaystyle*\;W=\left\lceil(\text{tREFW}-(\text{tREFW}/\text{tREFI})\times\text{tRFC})/(\text{tRC}\times RFM_{TH}+\text{tRFM})\right\rceil ∗n∗=⌈(Ne​n​t​r​y×RFMT​H)/(RFMT​H+AdT​H)⌉\displaystyle*\;n^{*}=\lceil(N_{entry}\times RFM_{TH})/(RFM_{TH}+Ad_{TH})\rceil

At the end of any jj-th RFM interval, the preventive refresh does not occur if the difference between cj′​[1]c^{\prime}_{j}[1] and cj′​[N]c^{\prime}_{j}[N] is less than A​dT​HAd_{TH}. Considering that the preventive refresh may not occur, we modify Lemma 4 to Lemmas 5 and 6 as follows:

Lemma 5. If cj−1′​[1]−cj−1′​[N]>A​dT​Hc^{\prime}_{j-1}[1]-c^{\prime}_{j-1}[N]>Ad_{TH}, then ∑i=1kcj​[i]≤kk+1​(∑i=1k+1cj−1​[i]+R​F​MT​H)\sum_{i=1}^{k}c_{j}[i]\leq\frac{k}{k+1}(\sum_{i=1}^{k+1}c_{j-1}[i]+RFM_{TH}) for 1≤k≤N−11\leq k\leq N-1

Proof: If cj−1′​[1]−cj−1′​[N]>A​dT​Hc^{\prime}_{j-1}[1]-c^{\prime}_{j-1}[N]>Ad_{TH}, the preventive refresh occurs at the end of the (jj-1)-th RFM interval, so we can derive the same result as Lemma 4.

Lemma 6. If cj−1′​[1]−cj−1′​[N]≤A​dT​Hc^{\prime}_{j-1}[1]-c^{\prime}_{j-1}[N]\leq Ad_{TH}, then ∑i=1kcj​[i]≤kN​(∑i=1Ncj−1​[i]+R​F​MT​H+(N−k)​A​dT​H)\sum_{i=1}^{k}c_{j}[i]\leq\frac{k}{N}\left(\sum_{i=1}^{N}c_{j-1}[i]+RFM_{TH}+(N-k)Ad_{TH}\right) for 1≤k≤N−11\leq k\leq N-1

Proof: Because RFM does not occur at the jj-th RFM interval, cj​[i]=cj−1′​[i]c_{j}[i]=c^{\prime}_{j-1}[i] for 1≤i≤N1\leq i\leq N. Then, the following holds true.

∑i=1Ncj​[i]\displaystyle\sum_{i=1}^{N}c_{j}[i] =∑i=1Ncj−1′​[i]\displaystyle=\sum_{i=1}^{N}c^{\prime}_{j-1}[i] =∑i=1kcj−1′​[i]+∑i=k+1Ncj−1′​[i]\displaystyle=\sum_{i=1}^{k}c^{\prime}_{j-1}[i]+\sum_{i=k+1}^{N}c^{\prime}_{j-1}[i] ≥∑i=1kcj−1′​[i]+(N−k)​cj−1′​[N]\displaystyle\geq\sum_{i=1}^{k}c^{\prime}_{j-1}[i]+(N-k)c^{\prime}_{j-1}[N] ≥∑i=1kcj−1′​[i]+(N−k)​(cj−1′​[1]−A​dT​H)\displaystyle\geq\sum_{i=1}^{k}c^{\prime}_{j-1}[i]+(N-k)(c^{\prime}_{j-1}[1]-Ad_{TH}) ≥∑i=1kcj−1′​[i]+(N−k)​(1k​∑i=1kcj−1′​[i]−A​dT​H)\displaystyle\geq\sum_{i=1}^{k}c^{\prime}_{j-1}[i]+(N-k)\left(\frac{1}{k}\sum_{i=1}^{k}c^{\prime}_{j-1}[i]-Ad_{TH}\right) ≥Nk​∑i=1kcj−1′​[i]−(N−k)​A​dT​H\displaystyle\geq\frac{N}{k}\sum_{i=1}^{k}c^{\prime}_{j-1}[i]-(N-k)Ad_{TH} ∑i=1kcj​[i]\displaystyle\sum_{i=1}^{k}c_{j}[i] =∑i=1kcj−1′​[i]\displaystyle=\sum_{i=1}^{k}c^{\prime}_{j-1}[i] ≤kN​(∑i=1Ncj−1′​[i]+(N−k)​A​dT​H)\displaystyle\leq\frac{k}{N}\left(\sum_{i=1}^{N}c^{\prime}_{j-1}[i]+(N-k)Ad_{TH}\right) ≤kN​(∑i=1Ncj−1​[i]+R​F​MT​H+(N−k)​A​dT​H)\displaystyle\leq\frac{k}{N}\left(\sum_{i=1}^{N}c_{j-1}[i]+RFM_{TH}+(N-k)Ad_{TH}\right)

Similar to Theorem 1, proving Theorem 2 is equivalent to proving cW′​[1]−c1​[N]≤M′c^{\prime}_{W}[1]-c_{1}[N]\leq M^{\prime}. For some arbitrary number nn smaller than WW, assume that the preventive refresh does not occur at the nn-th last RFM interval (i.e., the (W−nW-n)-th RFM interval) and that the preventive refresh occurs at all the subsequent RFM intervals. Even with the adaptive refresh, Lemmas 2 and 3 are still true.

If nn is greater than NN, the upper bound of cW′​[1]−c1​[N]c^{\prime}_{W}[1]-c_{1}[N] is equivalent to MM (the result of Theorem 1). We can obtain this result by applying Lemma 5 (equivalent to Lemma 4) for N−1N-1 times and applying Lemma 3 for W−NW-N times to cW′​[1]c^{\prime}_{W}[1].

Otherwise, if nn is less than or equal to NN, we first repeatedly apply Lemma 5 for a total of n−1n-1 times to obtain the upper bound of cW′​[1]c^{\prime}_{W}[1]:

cW′​[1]\displaystyle c^{\prime}_{W}[1] ≤cW[1]+RFMT​H(∵ Lemma 2)\displaystyle\leq c_{W}[1]+RFM_{TH}\;\;\;(\because\text{~{}Lemma 2}) ≤12(∑i=12cW−1[i]+RFMT​H)+RFMT​H(∵ Lemma 5)\displaystyle\leq\frac{1}{2}\left(\sum_{i=1}^{2}c_{W-1}[i]+RFM_{TH}\right)+RFM_{TH}\;\;\;(\because\text{~{}Lemma 5}) ≤13(∑i=13cW−2[i]+RFMT​H)+∑k=12R​F​MT​Hk(∵ Lemma 5)\displaystyle\leq\frac{1}{3}\left(\sum_{i=1}^{3}c_{W-2}[i]+RFM_{TH}\right)+\sum_{k=1}^{2}\frac{RFM_{TH}}{k}\;\;\;(\because\text{~{}Lemma 5}) ⋮\displaystyle\hskip 108.405pt\vdots ≤1n​(∑i=1ncW−n+1​[i]+R​F​MT​H)+∑k=1n−1R​F​MT​Hk\displaystyle\leq\frac{1}{n}\left(\sum_{i=1}^{n}c_{W-n+1}[i]+RFM_{TH}\right)+\sum_{k=1}^{n-1}\frac{RFM_{TH}}{k} =1n​(∑i=1ncW−n+1​[i])+∑k=1nR​F​MT​Hk\displaystyle=\frac{1}{n}\left(\sum_{i=1}^{n}c_{W-n+1}[i]\right)+\sum_{k=1}^{n}\frac{RFM_{TH}}{k}

At this point, we have to apply Lemma 6.

cW′​[1]\displaystyle c^{\prime}_{W}[1] ≤1N​(∑i=1NcW−n​[i]+R​F​MT​H+(N−n)​A​dT​H)+∑k=1nR​F​MT​Hk\displaystyle\leq\frac{1}{N}\left(\sum_{i=1}^{N}c_{W-n}[i]+RFM_{TH}+(N-n)Ad_{TH}\right)+\sum_{k=1}^{n}\frac{RFM_{TH}}{k}

Then, we apply Lemma 3 (k=Nk=N) for W−n−1W-n-1 times.

cW′​[1]\displaystyle c^{\prime}_{W}[1] ≤1N​(∑i=1Nc1​[i]+(W−n)​R​F​MT​H+(N−n)​A​dT​H)+∑k=1nR​F​MT​Hk\displaystyle\leq\frac{1}{N}\left(\sum_{i=1}^{N}c_{1}[i]+(W-n)RFM_{TH}+(N-n)Ad_{TH}\right)+\sum_{k=1}^{n}\frac{RFM_{TH}}{k}

The maximum value of ∑i=1N(cj​[i]−cj​[N])\sum_{i=1}^{N}(c_{j}[i]-c_{j}[N]) is equivalent to that in the proof of Theorem 1. Then, the following holds true.

cW′​[1]−c1′​[N]\displaystyle c^{\prime}_{W}[1]-c^{\prime}_{1}[N] ≤1N​(∑i=1N(c1​[i]−c1​[N])+(W−n)​R​F​MT​H+(N−n)​A​dT​H)\displaystyle\leq\frac{1}{N}\left(\sum_{i=1}^{N}(c_{1}[i]-c_{1}[N])+(W-n)RFM_{TH}+(N-n)Ad_{TH}\right) +∑k=1nR​F​MT​Hk\displaystyle\;\;\;\;\,+\sum_{k=1}^{n}\frac{RFM_{TH}}{k} ≤1N​((N−2)​R​F​MT​H+(W−n)​R​F​MT​H+(N−n)​A​dT​H)\displaystyle\leq\frac{1}{N}\left((N-2)RFM_{TH}+(W-n)RFM_{TH}+(N-n)Ad_{TH}\right) +∑k=1nR​F​MT​Hk\displaystyle\;\;\;\;\,+\sum_{k=1}^{n}\frac{RFM_{TH}}{k} ≤1N​((N−2+W−n)​R​F​MT​H+(N−n)​A​dT​H)+∑k=1nR​F​MT​Hk​(4)\displaystyle\leq\frac{1}{N}\left((N-2+W-n)RFM_{TH}+(N-n)Ad_{TH}\right)+\sum_{k=1}^{n}\frac{RFM_{TH}}{k}\;\;\;(4)

Suppose M′​[n]M^{\prime}[n] is the right side of the inequality (4) for 1≤n≤N1\leq n\leq N. Note that M′​[N]=MM^{\prime}[N]=M, which is the upper bound of cW′​[1]−c1​[N]c^{\prime}_{W}[1]-c_{1}[N] when nn is greater than NN (which is the same as the value when the adaptive refresh is not applied). Now, we need to find the nn value maximizing M′​[n]M^{\prime}[n]. For 2≤n≤N2\leq n\leq N, the difference between M′​[n]M^{\prime}[n] and M′​[n−1]M^{\prime}[n-1] is as follows:

M′​[n]−M′​[n−1]=R​F​MT​Hn−R​F​MT​H+A​dT​HN\displaystyle M^{\prime}[n]-M^{\prime}[n-1]=\frac{RFM_{TH}}{n}-\frac{RFM_{TH}+Ad_{TH}}{N}

(M′​[n]−M′​[n−1])(M^{\prime}[n]-M^{\prime}[n-1]) is a decreasing function with respect to nn. Thus, the largest nn (i.e., n∗n^{*}) satisfying M′​[n]>M′​[n−1]M^{\prime}[n]>M^{\prime}[n-1] is given by n∗=⌈(N×R​F​MT​H)/(R​F​MT​H+A​dT​H)⌉n^{*}=\lceil(N\times RFM_{TH})/(RFM_{TH}+Ad_{TH})\rceil, and it maximizes M′​[n]M^{\prime}[n]. Finally, we can prove Theorem 2 as follows:

cW′​[1]−cW′​[N]\displaystyle c^{\prime}_{W}[1]-c^{\prime}_{W}[N] ≤∑k=1n∗R​F​MT​Hk+(W−n∗+N−2)​R​F​MT​H+(N−n∗)​A​dT​HN\displaystyle\leq\sum_{k=1}^{n^{*}}\frac{RFM_{TH}}{k}+\frac{(W-n^{*}+N-2)RFM_{TH}+(N-n^{*})Ad_{TH}}{N} =M′\displaystyle=M^{\prime} ∗M′=M′[n∗]\displaystyle\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!\!*\;M^{\prime}=M^{\prime}[n^{*}]

IX-C PARFM Probability of Failure

A PARA-inspired, intuitive form of a probabilistic prevention scheme, PARFM, is deployable under the RFM interface. Whenever an RFM command arrives, PARFM randomly samples a single aggressor row among the last R​F​MT​HRFM_{TH} activations and executes the preventive refresh on its victims. The probability of being selected for a row depends on the ratio of its ACTs on the last R​F​MT​HRFM_{TH} activations. PARFM’s protection capability depends on R​F​MT​HRFM_{TH}, which determines the sampling rate.

Failure probability of PARFM requires two major modifications on the original method of PARA: the worst-case ACT pattern and mathematical formulation. First, the number of rows to activate depends on the given R​F​MT​HRFM_{TH} value, while the worst-case ACT pattern of PARA was to activate a single row continuously. Suppose only a single row is activated under PARFM. In that case, it will always be selected at the next RFM command, and its victims will receive the preventive refresh. From the attacker’s perspective, the cost-effectiveness in minimizing the PARFM selection and quickly reaching F​l​i​pT​HFlip_{TH} is expressed as the following (where jj denotes the number of ACTs for a single row in a single R​F​MT​HRFM_{TH} activation interval):

Cost-effectiveness:​(1−jR​F​MT​H)1/j\displaystyle\text{Cost-effectiveness:}\ \left(1-\frac{j}{RFM_{TH}}\right)^{1/j} (5)

Because this is a monotonically decreasing function and the R​F​MT​HRFM_{TH} period that the row is not activated can be ignored (it does not contribute to reaching the F​l​i​pT​HFlip_{TH} ACTs), activating a row only a single time for every R​F​MT​HRFM_{TH} is the most cost-effective pattern. We thus base our further formulation on that the R​F​MT​HRFM_{TH} number of different rows are activated once every R​F​MT​HRFM_{TH} period.

Compared to PARA, the mathematical formula also must be different. The following formula is the accurate probability of failure for a single DRAM bank in a tREFW time window. F​a​i​l​(1)Fail(1) denotes the failure probability where a single row fails. F​a​i​l​(2)Fail(2) denotes the failure probability where two different rows fail in a tREFW window and so on. Based on Equation (5), a uniform distribution of ACTs on the activated rows is assumed.

Bank failure probability:​C1R​F​MT​H​F​a​i​l​(1)−C2R​F​MT​H​F​a​i​l​(2)\displaystyle\text{Bank failure probability:}\ {}_{\scalebox{0.65}{$RFM_{TH}$}}C_{1}Fail(1)-{}_{\scalebox{0.65}{$RFM_{TH}$}}C_{2}Fail(2) +C3R​F​MT​H​F​a​i​l​(3)−C4R​F​MT​H​F​a​i​l​(4)​…\displaystyle+{}_{\scalebox{0.65}{$RFM_{TH}$}}C_{3}Fail(3)-{}_{\scalebox{0.65}{$RFM_{TH}$}}C_{4}Fail(4)\ \dots

F​a​i​l​(1)Fail(1) can be calculated using the following recurrence equation where P​[i]P[i] denotes the failure probability at the i-th RFM command:

P​[i]=P​[i−1]+1R​F​MT​H​(1−1R​F​MT​H)F​l​i​pT​H/2​(1−P​[i−F​l​i​pT​H/2−1])\displaystyle P[i]=P[i-1]+\frac{1}{\scalebox{0.75}{$RFM_{TH}$}}(1-\frac{1}{\scalebox{0.75}{$RFM_{TH}$}})^{Flip_{TH}/2}(1-P[i-\scalebox{0.75}{$Flip_{TH}/2$}-1])

The initial condition is as follows.

P​[i]={0for 0≤i≤F​l​i​pT​H2−1(1−1R​F​MT​H)F​l​i​pT​H/2for i=F​l​i​pT​H2\displaystyle P[i]=\begin{dcases*}0&for $0\ {\leq}\ i\ {\leq}\ {\frac{Flip_{TH}}{2}}-1$\\ \left(1-\frac{1}{RFM_{TH}}\right)^{Flip_{TH}/2}&for $i=\frac{Flip_{TH}}{2}$\\ \end{dcases*}

We acquire F​a​i​l​(1)Fail(1) by calculating the last P​[i]P[i] in a tREFW window. F​a​i​l​(2)Fail(2) is much smaller than F​a​i​l​(1)Fail(1) because the F​l​i​pT​HFlip_{TH} value exceeds over 1K even at the most pessimistic RH vulnerability. The probability of more than one row reaching the F​l​i​pT​HFlip_{TH} ACT value without being refreshed is much less likely compared to that of a single row. Therefore, we estimate the probability of failure (upper-bound) with only the first term of bank failure probability. Using the bank failure probability, we can acquire the system failure probability based on the number of banks that can be simultaneously attacked (Nb​a​n​k​sN_{banks}).

System Failure Probability:​ 1−(1−F​a​i​l​(1))Nb​a​n​k​s\displaystyle\text{System Failure Probability:}\ 1-(1-Fail(1))^{N_{banks}}

In our experimental system of 2 ranks of 32 banks each, a total of 22 banks can be activated satisfying the tFAW constraints. In Section VI-A, we properly set the R​F​MT​HRFM_{TH} value on each target F​l​i​pT​HFlip_{TH}; therefore, our system failure probability is lower than 10−1510^{-15}.

References

  • [1] M. T. Aga, Z. B. Aweke, and T. Austin, “When Good Protections Go Bad: Exploiting Anti-DoS Measures to Accelerate Rowhammer Attacks,” in IEEE International Symposium on Hardware Oriented Security and Trust (HOST), 2017.
  • [2] P. K. Agarwal, G. Cormode, Z. Huang, J. M. Phillips, Z. Wei, and K. Yi, “Mergeable Summaries,” ACM Transactions on Database Systems (TODS), vol. 38, no. 4, 2013.
  • [3] J. Ahn, S. Li, S. O, and N. P. Jouppi, “McSimA+: A Manycore Simulator with Application-level+ Simulation and Detailed Microarchitecture Modeling,” in ISPASS, 2013.
  • [4] Z. B. Aweke, S. F. Yitbarek, R. Qiao, R. Das, M. Hicks, Y. Oren, and T. Austin, “ANVIL: Software-Based Protection Against Next-Generation Rowhammer Attacks,” in ASPLOS, 2016.
  • [5] R. Balasubramonian, Innovations in the Memory System.   Morgan & Claypool Publishers, 2019.
  • [6] S. Beamer, K. Asanovic, and D. A. Patterson, “The GAP Benchmark Suite,” CoRR, vol. abs/1508.03619, 2015.
  • [7] I. Bhati, M. Chang, Z. Chishti, S. Lu, and B. Jacob, “DRAM Refresh Mechanisms, Penalties, and Trade-Offs,” IEEE Transactions on Computers, vol. 65, no. 1, 2016.
  • [8] F. Brasser, L. Davi, D. Gens, C. Liebchen, and A. R. Sadeghi, “CAn’T Touch This: Software-only Mitigation Against Rowhammer Attacks Targeting Kernel Memory,” in 26th USENIX Conference on Security Symposium, 2017.
  • [9] Y. Cai, S. Ghose, E. F. Haratsch, Y. Luo, and O. Mutlu, “Error Characterization, Mitigation, and Recovery in Flash-memory-based Solid-state Drives,” Proceedings of the IEEE, vol. 105, no. 9, 2017.
  • [10] Y. Cai, E. F. Haratsch, O. Mutlu, and K. Mai, “Error Patterns in MLC NAND Flash Memory: Measurement, Characterization, and Analysis,” in Design, Automation & Test in Europe Conference & Exhibition (DATE).   IEEE, 2012.
  • [11] M. Charikar, K. Chen, and M. Farach-Colton, “Finding Frequent Items in Data Streams,” in Proceedings of the 29th International Colloquium on Automata, Languages and Programming, 2002.
  • [12] L. Cojocar, J. Kim, M. Patel, L. Tsai, S. Saroiu, A. Wolman, and O. Mutlu, “Are We Susceptible to Rowhammer? An End-to-End Methodology for Cloud Providers,” in IEEE Symposium on Security and Privacy (S&P), 2020.
  • [13] L. Cojocar, K. Razavi, C. Giuffrida, and H. Bos, “Exploiting Correcting Codes: On the Effectiveness of ECC Memory Against Rowhammer Attacks,” in IEEE Symposium on Security and Privacy (S&P), 2019.
  • [14] F. Devaux, “The True Processing in Memory Accelerator,” in IEEE Hot Chips 31 Symposium.   IEEE Computer Society, 2019.
  • [15] P. Frigo, E. Vannacci, H. Hassan, V. van der Veen, O. Mutlu, C. Giuffrida, H. Bos, and K. Razavi, “TRRespass: Exploiting the Many Sides of Target Row Refresh,” in IEEE Symposium on Security and Privacy (S&P), 2020.
  • [16] ““Half-Double”: Next-Row-Over Assisted Rowhammer,” https://github.com/google/hammer-kit/blob/main/20210525_half_double.pdf, Google, 2021.
  • [17] Z. Greenfield and L. Tomer, “Throttling Support for Row-hammer Counters,” U.S. Patent 9251885, Feb. 2016.
  • [18] D. Gruss, M. Lipp, M. Schwarz, D. Genkin, J. Juffinger, S. O’Connell, W. Schoechl, and Y. Yarom, “Another Flip in the Wall of Rowhammer Defenses,” in IEEE Symposium on Security and Privacy (S&P), 2017.
  • [19] D. Gruss, C. Maurice, and S. Mangard, “Rowhammer.js: A Remote Software-Induced Fault Attack in JavaScript,” in Detection of Intrusions and Malware, and Vulnerability Assessment, 2016.
  • [20] G. Irazoqui, T. Eisenbarth, and B. Sunar, “MASCAT: Preventing Microarchitectural Attacks Before Distribution,” in Proceedings of the 8th ACM Conference on Data and Application Security and Privacy, 2018.
  • [21] JEDEC, “Failure Mechanisms and Models for Semiconductor Devices,” 2019.
  • [22] JEDEC, “LPDDR5 Standard JESD209-5,” 2019.
  • [23] JEDEC, “DDR5 SDRAM,” 2020.
  • [24] JEDEC, “Near-Term DRAM Level RowHammer Mitigation,” 2021.
  • [25] JEDEC, “System Level RowHammer Mitigation,” 2021.
  • [26] I. Kang, E. Lee, and J. Ahn, “CAT-TWO: Counter-Based Adaptive Tree, Time Window Optimized for DRAM Row-Hammer Prevention,” IEEE Access, vol. 8, 2020.
  • [27] D. Kaseridis, J. Stuecheli, and L. K. John, “Minimalist Open-page: A DRAM Page-mode Scheduling Policy for the Many-core Era,” in MICRO, 2011.
  • [28] D. Kim, M. Park, S. Jang, J.-Y. Song, H. Chi, G. Choi, S. Choi, J. Kim, C. Kim, K. Kim, K. Koo, S. Song, Y. Kim, D. U. Lee, J. Lee, D. Kim, K. Kwon, M. Han, B. Choi, H. Kim, S. Ku, Y. Kim, J. Kim, S. Kim, Y. Seo, S. Oh, D. Im, H. Kim, J. Choi, J. Chung, C. Lee, Y. Lee, J.-H. Cho, J. Chun, and J. Oh, “A 1.1V 1ynm 6.4 Gb/s/pin 16Gb DDR5 SDRAM with a Phase-Rotator-Based DLL, High-Speed SerDes and RX/TX Equalization Scheme,” in IEEE International Solid-State Circuits Conference (ISSCC), 2019, pp. 380–382.
  • [29] J. Kim, M. Patel, A. G. Yaglikçi, H. Hassan, R. Azizi, L. Orosa, and O. Mutlu, “Revisiting RowHammer: An Experimental Analysis of Modern DRAM Devices and Mitigation Techniques,” in ISCA, 2020.
  • [30] Y. Kim, R. Daly, J. Kim, C. Fallin, J. H. Lee, D. Lee, C. Wilkerson, K. Lai, and O. Mutlu, “Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors,” in ISCA, 2014.
  • [31] R. K. Konoth, M. Oliverio, A. Tatar, D. Andriesse, H. Bos, C. Giuffrida, and K. Razavi, “ZebRAM: Comprehensive and Compatible Software Protection Against Rowhammer Attacks,” in 13th USENIX Symposium on Operating Systems Design and Implementation, 2018.
  • [32] E. Lee, I. Kang, S. Lee, G. E. Suh, and J. Ahn, “TWiCe: Preventing Row-hammering by Exploiting Time Window Counters,” in ISCA, 2019.
  • [33] E. Lee, S. Lee, G. E. Suh, and J. Ahn, “TWiCe: Time Window Counter Based Row Refresh to Prevent Row-Hammering,” IEEE Computer Architecture Letters, vol. 17, no. 1, 2018.
  • [34] Y. Luo, S. Ghose, Y. Cai, E. F. Haratsch, and O. Mutlu, “Enabling Accurate and Practical Online Flash Channel Modeling for Modern MLC NAND Flash Memory,” IEEE Journal on Selected Areas in Communications, vol. 34, no. 9, 2016.
  • [35] G. S. Manku and R. Motwani, “Approximate Frequency Counts over Data Streams,” in Proceedings of the 28th International Conference on Very Large Data Bases, 2002.
  • [36] A. Metwally, D. Agrawal, and A. El Abbadi, “Efficient Computation of Frequent and Top-k Elements in Data Streams,” in Proceedings of the 10th International Conference on Database Theory, 2005.
  • [37] J. Misra and D. Gries, “Finding Repeated Elements,” Science of Computer Programming, vol. 2, no. 2, 1982.
  • [38] S. Muthukrishnan, Data Streams: Algorithms and Applications.   Now Publishers Inc., 2005.
  • [39] O. Mutlu and J. S. Kim, “RowHammer: A Retrospective,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 39, no. 8, 2019.
  • [40] B. Nale and C. E. Cox, “Refresh Command Control for Host Assist of Row Hammer Mitigation,” U.S. Patent 10950288B2, Mar. 2021.
  • [41] S. O, Y. H. Son, N. S. Kim, and J. Ahn, “Row-buffer Decoupling: A Case for Low-latency DRAM Microarchitecture,” in ISCA, 2014.
  • [42] K. Park, C. Lim, D. Yun, and S. Baeg, “Experiments and Root Cause Analysis for Active-precharge Hammering Fault in DDR3 SDRAM under 3x nm Technology,” Microelectronics Reliability, vol. 57, 2016.
  • [43] Y. Park, W. Kwon, E. Lee, T. J. Ham, J. Ahn, and J. W. Lee, “Graphene: Strong yet Lightweight Row Hammer Protection,” in MICRO, 2020.
  • [44] PARSEC Group, “A Memo on Exploration of SPLASH-2 Input Sets,” in Princeton University, 2011.
  • [45] M. Patel, J. S. Kim, and O. Mutlu, “The Reach Profiler (REAPER): Enabling the Mitigation of DRAM Retention Failures via Profiling at Aggressive Conditions,” in ISCA, 2017.
  • [46] K. Razavi, B. Gras, E. Bosman, B. Preneel, C. Giuffrida, and H. Bos, “Flip Feng Shui: Hammering a Needle in the Software Stack,” in 25th USENIX Conference on Security Symposium, 2016.
  • [47] M. Seaborn and T. Dullien, “Exploiting the DRAM Rowhammer Bug to Gain Kernel Privileges,” https://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html, 2015.
  • [48] S. M. Seyedzadeh, A. K. Jones, and R. Melhem, “Counter-Based Tree Structure for Row Hammering Mitigation in DRAM,” IEEE Computer Architecture Letters, vol. 16, no. 1, 2017.
  • [49] S. M. Seyedzadeh, A. K. Jones, and R. Melhem, “Mitigating Wordline Crosstalk using Adaptive Trees of Counters,” in ISCA, 2018.
  • [50] S. M. Seyedzadeh, A. K. Jones, and R. Melhem, “Mitigating Wordline Crosstalk Using Adaptive Trees of Counters,” in ISCA, 2018.
  • [51] T. Sherwood, E. Perelman, G. Hamerly, and B. Calder, “Automatically Characterizing Large Scale Program Behavior,” in ASPLOS, 2002.
  • [52] M. Son, H. Park, J. Ahn, and S. Yoo, “Making DRAM Stronger Against Row Hammering,” in Proceedings of the 54th Annual Design Automation Conference, 2017.
  • [53] L. Subramanian, D. Lee, V. Seshadri, H. Rastogi, and O. Mutlu, “BLISS: Balancing Performance, Fairness and Complexity in Memory Access Scheduling,” IEEE Transactions on Parallel and Distributed Systems, vol. 27, no. 10, 2016.
  • [54] V. van der Veen, Y. Fratantonio, M. Lindorfer, D. Gruss, C. Maurice, G. Vigna, H. Bos, K. Razavi, and C. Giuffrida, “Drammer: Deterministic Rowhammer Attacks on Mobile Platforms,” in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, 2016.
  • [55] V. van der Veen, M. Lindorfer, Y. Fratantonio, H. Pillai, G. Vigna, C. Kruegel, H. Bos, and K. Razavi, “GuardiON: Practical Mitigation of DMA-Based Rowhammer Attacks on ARM,” in 15th International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment (DIMVA), 2018.
  • [56] A. G. Yaglikci, M. Patel, J. Kim, R. AziziBarzoki, J. Park, H. Hassan, A. Olgun, L. Orosa, K. Kanellopoulos, T. Shahroodi, S. Ghose, and O. Mutlu, “BlockHammer: Preventing RowHammer at Low Cost by Blacklisting Rapidly-Accessed DRAM Rows,” in HPCA, 2021.
  • [57] T. Yang and X. Lin, “Trap-Assisted DRAM Row Hammer Effect,” IEEE Electron Device Letters, vol. 40, no. 3, 2019.
  • [58] J. M. You and J.-S. Yang, “MRLoc: Mitigating Row-hammering Based on Memory Locality,” in Proceedings of the 56th Annual Design Automation Conference, 2019.
  • [59] Z. Zhang, Y. Cheng, D. Liu, S. Nepal, Z. Wang, and Y. Yarom, “PThammer: Cross-User-Kernel-Boundary Rowhammer through Implicit Accesses,” in MICRO, 2020.