# Leveraging Adversarial Detection to Enable Scalable and
Low Overhead RowHammer Mitigations

Oğuzhan Canpolat§$\dagger$ A. Giray Yağlıkçı§ Ataberk Olgun§ İsmail Emir
Yüksel§ Yahya Can Tuğrul§$\dagger$
Konstantinos Kanellopoulos§ Oğuz Ergin$\dagger$ Onur Mutlu§

§ _ETH Zürich_ $\dagger$_TOBB University of Economics and Technology_
$*$_SAFARI Research Group_

###### Abstract

RowHammer is a prime example of read disturbance in DRAM where repeatedly
accessing (hammering) a row of DRAM cells (DRAM row) induces bitflips in other
physically nearby DRAM rows. RowHammer solutions perform preventive actions
(e.g., refresh neighbor rows of the hammered row) that mitigate such bitflips
to preserve _memory isolation_ , a fundamental building block of security and
privacy in modern computing systems. However, preventive actions induce non-
negligible memory request latency and system performance overheads as they
interfere with memory requests in the memory controller. As shrinking
technology node size over DRAM chip generations exacerbates RowHammer, the
overheads of RowHammer solutions become prohibitively large. As a result, a
malicious program can effectively hog the memory system and deny service to
benign applications by causing many RowHammer preventive actions.

In this work, we tackle the performance overheads of RowHammer solutions by
tracking the generators of memory accesses that trigger RowHammer solutions.
To this end, we propose BreakHammer. BreakHammer cooperates with existing
RowHammer solutions to identify hardware threads that trigger preventive
actions. To do so, BreakHammer estimates the RowHammer likelihood of a thread,
based on how frequently it triggers RowHammer preventive actions. BreakHammer
limits the number of on-the-fly requests a thread can inject into the memory
system based on the thread’s RowHammer likelihood. By doing so, BreakHammer
significantly reduces the number of performed counter-measures, improves the
system performance by an average (maximum) of 48.7% (105.5%), and reduces the
maximum slowdown induced on a benign application by 14.6% with near-zero area
overhead (e.g., 0.0002% of a high-end processor’s chip area).

##  I Introduction

To ensure system reliability, security, and safety, it is critical to maintain
memory isolation: accessing a memory address should not cause unintended side-
effects on data stored on other addresses. Unfortunately, with aggressive
technology node scaling, dynamic random access memory (DRAM) [1], the
prevalent main memory technology, suffers from increased read disturbance:
accessing (reading) a DRAM cell degrades the data integrity of other
physically close and _unaccessed_ DRAM cells by exacerbating the unaccessed
cells’ inherent charge leakage and causing bitflips. _RowHammer_ is a prime
example of such DRAM read disturbance phenomenon where a DRAM row (i.e.,
victim row) can experience bitflips when a nearby DRAM row (i.e., aggressor
row) is repeatedly opened (i.e., hammered) [2, 3, 4, 5, 6, 7, 8, 9, 10, 11,
12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30,
31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49,
50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68,
69].

Many prior works demonstrate reliable attacks on a wide range of systems where
they exploit read disturbance to escalate privilege, leak private data, and
manipulate critical application outputs [2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12,
13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31,
32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50,
51, 52, 53, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81]. To make matters
worse, recent experimental studies [25, 33, 36, 37, 61, 10, 82] have found
that newer DRAM chip generations are more susceptible to read disturbance. For
example, chips manufactured in 2018-2020 can experience RowHammer bitflips
after an order of magnitude fewer row activations compared to the chips
manufactured in 2012-2013 [61]. As RowHammer worsens, ensuring reliable,
secure, and safe operation causes prohibitively large performance overheads
[61, 83, 84, 85]. Although RowHammer mitigation mechanisms can mitigate
RowHammer bitflips, they aggressively and even excessively perform time- and
energy-hungry operations to mitigate RowHammer (preventive actions) as fewer
DRAM row activations can induce RowHammer bitflips in newer DRAM chips. To
make matters worse, adversarial memory access patterns can be crafted to
trigger RowHammer mitigation mechanisms more and more frequently. Thus,
RowHammer mitigation mechanisms can convert RowHammer attacks to cause denial
of service to the memory requests of concurrently running benign applications
and incur large performance overheads. Therefore, it is critical to reduce the
performance overhead of such mechanisms to defend against both RowHammer
attacks and denial-of-service attacks that leverage preventive actions.

Goal. Our goal is to reduce the performance overhead of RowHammer mitigation
mechanisms by reducing the number of performed preventive actions _without_
compromising their security guarantees.

Key Idea. Our key idea is to estimate the RowHammer likelihood of hardware
threads based on how frequently they trigger preventive actions and to limit
the number of on-the-fly memory requests that a hardware thread can have
accordingly. To this end, we propose BreakHammer.111BreakHammer is analogous
to breakwater structure, which protects docks against tides, waves, and storm
surges; and consequently reduces their maintenance costs [86]. Similarly, our
mechanism, BreakHammer, protects the memory subsystem against the hammering
access patterns and, by doing so, reduces the overheads of RowHammer
mitigation mechanisms. BreakHammer cooperates with an existing RowHammer
mitigation mechanism and observes the RowHammer-preventive actions triggered
by each hardware thread, estimates the RowHammer likelihood of each hardware
thread, and reduces each thread’s on-the-fly request limits accordingly.
Meanwhile, the existing RowHammer mitigation mechanism operates as usual and
maintains security guarantees against RowHammer attacks. Therefore,
BreakHammer significantly reduces the number of necessary RowHammer preventive
actions by throttling the malicious threads’ memory requests _without_
compromising the RowHammer mitigation mechanism’s security guarantees.

Implementation. BreakHammer is implemented in the processor near the memory
controller and supports both memory controller-based and on-DRAM-die RowHammer
mitigation mechanisms. To showcase BreakHammer’s compatibility with various
types of existing RowHammer mitigation mechanisms, we implement BreakHammer
with five memory controller-based and two on-DRAM-die state-of-the-art
RowHammer mitigation mechanisms. BreakHammer observes the behavior of the
RowHammer mitigation mechanism in terms of the number of preventive actions
that block other memory accesses significantly, e.g., due to blocking a DRAM
bank during a row refresh or the memory channel due to transferring data.
BreakHammer flexibly adapts to various types of preventive actions performed
by different RowHammer mitigation mechanisms that we summarize under five
categories: 1) PARA [10], TwiCe [87], and Graphene [84] inject preventive
refresh operations, 2) AQUA [88] migrates the contents of DRAM rows to a
quarantine area, 3) Hydra [89] both injects a preventive refresh and
fetches/evicts row counters to/from a counter buffer, 4) REGA [90] modifies
the DRAM chip with a secondary row buffer to refresh rows in parallel, and 5)
on-DRAM-die RowHammer mitigation mechanisms [91, 92, 93, 42] require the
memory controller to issue refresh management (RFM) commands when a bank’s
activation count exceeds a threshold. To observe these preventive actions,
BreakHammer maintains a small set of metadata, where BreakHammer keeps track
of preventive action counts per hardware thread. BreakHammer observes the
distribution of these preventive actions across concurrently running hardware
threads and throttles the threads that cause most of the preventive actions.
To throttle a hardware thread, BreakHammer reduces the maximum on-the-fly
request count that the hardware thread can have. To do so, BreakHammer limits
the number of miss status holding registers (MSHRs) and load/store
instructions directly accessing main memory.

We evaluate BreakHammer and compare to eight state-of-the-art RowHammer
mitigation mechanisms. We show that BreakHammer improves the system throughput
by 1) 2.2% on average across 51 randomly selected workload mixes of varying
memory intensity groups without a malicious thread present, and 2) 48.7% on
average across 51 randomly selected workload mixes of varying memory intensity
groups including a malicious thread, respectively. We evaluate BreakHammer’s
hardware complexity using CACTI [94] and Synopsys Design Compiler [95].
BreakHammer is implemented in the memory controller and does not introduce any
changes to the DRAM chip design. Our results show that BreakHammer can be
implemented alongside the memory controller as it has a latency of 0.67ns,
which is lower than the minimum time window between two row activation
commands targeting different banks ($t_{RRD}{}$) (e.g., 2.5ns in DDR4 [96])
and incurs near-zero area overhead (i.e., 0.00042$mm^{2}$), which consumes
0.0002% of a high-end Intel Xeon processor’s chip area. We make the following
contributions:

  * •

We show that while RowHammer mitigation mechanisms avoid RowHammer bitflips,
their preventive actions can be exploited to reduce availability and cause
denial-of-service.

  * •

We show that it is possible to reduce the performance overheads of RowHammer
mitigation mechanisms by observing the time-consuming RowHammer preventive
actions, and throttling the threads that trigger these actions.

  * •

We propose BreakHammer, a memory controller-based low-cost mechanism that
provides both memory controller-based and on-DRAM-die RowHammer mitigation
mechanisms with throttling support.

  * •

We evaluate BreakHammer and show that it significantly reduces the performance
overhead of existing RowHammer mitigation mechanisms without compromising
their security guarantees at near-zero area overhead.

##  II Background

###  II-A DRAM Organization and Operation

Organization. Fig. 1 shows the hierarchical organization of a modern DRAM-
based main memory. The memory controller connects to a DRAM module over a
memory channel. A module contains one or multiple DRAM ranks that time-share
the memory channel. A rank consists of multiple DRAM chips Each DRAM chip has
multiple DRAM banks each of which contains multiple subarrays. A DRAM bank is
organized as a two-dimensional array of DRAM cells, where a row of cells is
called a DRAM row. A DRAM cell consists of 1) a storage capacitor, which
stores one bit of information in the form of electrical charge, and 2) an
access transistor.

Figure 1: DRAM organization

Operation. To access a DRAM row, the memory controller issues a set of
commands to DRAM over the memory channel. The memory controller sends an $ACT$
command to activate a DRAM row, which asserts the corresponding wordline and
loads the row data into the row buffer. Then, the memory controller can issue
$RD$/$WR$ command to read from/write into the DRAM row. Subsequent accesses to
the same row cause a row hit. To access a different row, the memory controller
must first close the bank by issuing a $PRE$ command. Therefore, accessing a
different row causes a row miss/conflict.

DRAM cells are inherently leaky and lose their charge over time due to charge
leakage in the access transistor and the storage capacitor. Thus, to maintain
data integrity, the memory controller periodically refreshes each row in a
time interval called time interval between two refresh operations targeting
the same row ($t_{REFW}{}$) ($32ms$ for DDR5 [97] and $64ms$ for DDR4 [96]).
To ensure all rows are refreshed every $t_{REFW}{}$, the memory controller
issues REF commands with a time interval called time interval between two
refresh commands ($t_{REFI}{}$) ($3.9\mu s$ for DDR5 [97] and $7.8\mu s$ for
DDR4 [96]).

Timing Parameters. To ensure correct operation, the memory controller must
obey specific timing parameters while accessing DRAM. In addition to
$t_{REFW}{}$ and $t_{REFI}{}$, we explain three timing parameters related to
the rest of the paper: i) the minimum time interval between two consecutive
ACT commands targeting the same bank ($t_{RC}$), ii) the minimum time needed
to issue a PRE command following an ACT command ($t_{RAS}$), and iii) the
minimum time needed to issue an ACT command following a PRE command
($t_{RP}$).

###  II-B DRAM Read Disturbance

As DRAM manufacturing technology node size shrinks, interference across rows
increases causing circuit-level read disturbance mechanisms. Two prime
examples of such read disturbance mechanisms are RowHammer [10] and RowPress
[82], where repeatedly activating (i.e., opening) a DRAM row (i.e., aggressor
row) or keeping the aggressor row active for a long time induces bitflips in
physically nearby rows (i.e., victim rows), respectively. To induce RowHammer
bitflips, an aggressor row needs to be activated more than a threshold value
called RowHammer threshold ($N_{RH}{}$). Several characterization studies [98,
10, 99, 54, 100, 55, 56, 57, 101, 102, 58, 59, 103, 60, 61, 62, 104, 46, 49,
63, 64, 65, 66, 67, 68, 69, 105, 106, 36, 25, 107, 33, 108, 109, 110, 82, 111]
show that as DRAM scaling continues to smaller nodes, DRAM chips are getting
more vulnerable to RowHammer (i.e., newer chips have lower $N_{RH}{}$ values).
For example, one can induce RowHammer bitflips with 4.8K activations in the
chips manufactured in 2020 [61] while a row needs to be activated 69.2K times
in older chips manufactured in 2013 [10]. To make matters worse, RowPress [82]
reduces $N_{RH}{}$ significantly (e.g., by orders of magnitudes).

DRAM Read Disturbance Mitigation Mechanisms. Many prior works propose
mitigation techniques [112, 113, 114, 115, 10, 116, 96, 117, 118, 119, 120,
121, 122, 123, 100, 124, 125, 126, 57, 101, 127, 87, 84, 93, 83, 36, 128, 42,
89, 129, 22, 130, 29, 131, 132, 103, 133, 134, 135, 136, 137, 138, 85, 88,
139, 140, 141, 142, 143, 144, 145, 146, 92, 147, 148, 149, 150, 151, 152, 153,
69, 90, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 91, 139, 164, 165,
166, 167] to protect DRAM chips against RowHammer bitflips leveraging
different approaches. These mechanisms perform two tasks: 1) execute a trigger
algorithm and 2) perform preventive actions. The trigger algorithm observes
the memory access patterns and triggers a preventive action based on the
result of a probabilistic or a deterministic process. The preventive action is
one of 1) preventively refreshing victim row [87, 168, 125, 128, 84, 133, 116,
120, 121, 122, 118, 112, 10, 124, 127, 93, 36, 42, 89, 92, 134, 135, 136,
137], 2) dynamically remapping aggressor rows [129, 88, 158, 156], and 3)
throttling unsafe accesses [115, 83]. Existing RowHammer mitigation mechanisms
can also prevent RowPress bitflips when their trigger algorithms are
configured to be more aggressive, which is practically equivalent to
configuring them for sub-1K $N_{RH}{}$ values [82]. Unfortunately, existing
RowHammer mitigation mechanisms incur prohibitively large performance
overheads at low $N_{RH}{}$ values (i.e., sub-1K) due to performing their
respective preventive actions more aggressively. Given that DRAM read
disturbance worsens with shrinking technology node size, $N_{RH}{}$ values are
expected to reduce even more. Therefore, reducing the performance overhead of
existing RowHammer mitigation mechanisms is critical.

##  III Motivation

Prior works [61, 84, 83] already show that existing RowHammer mitigations
incur prohibitively high performance overheads with the reduction of
$N_{RH}{}$ as manufacturing technology node size shrinks. We repeat this
analysis with four state-of-the-art RowHammer mitigation mechanisms, including
the ones that are more recent than the prior analyses. We conduct these
simulations following the methodology described in §VII for seven different
$N_{RH}{}$ values for 40 four-core multiprogrammed workloads randomly chosen
across benchmarks specified in §VII. Fig. 2 shows a bar plot where each box
represents a different RowHammer mitigation mechanism. The tested $N_{RH}{}$
values are on the x-axis, and system throughput in terms of weighted speedup
is on the y-axis.

Figure 2: Performance overheads of RowHammer mitigation mechanisms with
worsening RowHammer vulnerability

We make two observations from Fig. 2. First, system throughput significantly
reduces as DRAM chips get more vulnerable to read disturbance (i.e.,
$N_{RH}{}$ reduces) for all tested RowHammer mitigation mechanisms. Second,
among the tested RowHammer mitigation mechanisms, Hydra exhibits the least
performance overhead with a performance degradation of 12%. Hydra achieves the
least performance overhead at the expense of increasingly large chip area
overhead that reaches 56.5KB when configured for a dual rank system with 16
banks at each rank. From these observations, we conclude that RowHammer
mitigation mechanisms become more expensive as $N_{RH}{}$ decreases, and
reducing their performance overheads at low cost is critical.

In this work, we propose to provide the existing RowHammer mitigation
mechanisms with throttling support to reduce their performance overheads. No
prior work proposes throttling memory accesses for reducing the performance
overhead of existing RowHammer mitigation mechanisms. Only three prior works
[83, 115, 10] propose throttling memory accesses to mitigate RowHammer. Among
these works, only BlockHammer [83] proposes a solid mechanism. BlockHammer
aggressively throttles suspected memory accesses, including malicious and
benign accesses, to prevent RowHammer bitflips. As a result, BlockHammer
causes a large performance overhead on memory-intensive benign workloads as
DRAM chips become more vulnerable to RowHammer (Fig. 2). In contrast,
BreakHammer does _not_ rely on throttling to prevent RowHammer bitflips, and
thus BreakHammer does _not_ perform throttling as aggressively as BlockHammer,
reducing BreakHammer’s performance overhead on benign workloads.

##  IV BreakHammer

Overview. BreakHammer is designed to cooperate with RowHammer mitigation
mechanisms to reduce their performance overhead by limiting the number of
performed preventive actions _without_ compromising security guarantees.
BreakHammer’s key idea is to limit the number of on-the-fly memory requests a
thread can inject into the memory system based on the thread’s RowHammer
likelihood. BreakHammer has four key operations: BreakHammer 1) observes the
time-consuming actions of existing RowHammer mitigation mechanisms, 2)
identifies the hardware threads that frequently trigger these actions, then 3)
gradually reduces the memory resources (i.e., miss status holding registers
(MSHRs)) and 4) bandwidth usage of the identified threads. We implement
BreakHammer entirely within the memory controller, ensuring RowHammer-safe
operation without any proprietary information about or modifications to the
DRAM chips. Therefore, BreakHammer is compatible with all commodity DRAM
chips.

Fig. 3 shows a high-level overview of BreakHammer in a simplified generic
processor setup where multiple processor cores access the main memory through
the cache hierarchy or via direct memory access (DMA) unit. DRAM is accessed
through the memory controller, where the memory request scheduler is
responsible for issuing DRAM commands with respect to the DRAM communication
protocol (e.g., DDR4 [96]). The memory controller either implements a
RowHammer mitigation mechanism or issues special DRAM commands to provide on-
DRAM-die mitigation mechanisms with a time window to perform their preventive
actions.

Figure 3: BreakHammer high-level overview

BreakHammer consists of four key operations.

1

Observing preventive actions. BreakHammer observes the actions that the
RowHammer mitigation mechanism performs and maintains a scoreboard that counts
the number of time-consuming actions each hardware thread causes.

2

Detecting anomalies. BreakHammer implements an anomaly detection mechanism
that detects threads with unusually high time-consuming action counts. To do
so, BreakHammer identifies a hardware thread anomalous when the thread’s score
positively deviates beyond a threshold from the mean.

3

Linear scaling. BreakHammer calculates an on-the-fly memory request quota
proportional to resources (i.e., MSHRs) available to this thread.

4

Throttling memory usage. BreakHammer assigns the quota to the number of on-
the-fly requests of each thread. By doing so, BreakHammer alters the memory
access patterns so that the RowHammer mitigation mechanism performs less time-
consuming actions. Consequently, BreakHammer reduces the performance
degradation caused by the RowHammer mitigation mechanism.

Optional feedback to the system software. BreakHammer optionally exposes each
thread’s score to the system. The system software can access these scores
similarly to how it accesses hardware performance counters. By doing so,
BreakHammer supports associating these scores with software threads and
operating system thread contexts, which consequently enables tracking time-
consuming actions at a software thread granularity.

###  IV-A Observing Preventive Actions

BreakHammer works by analyzing the RowHammer mitigation overheads caused by
hardware threads. To do so, it requires comprehensive statistics on the
overall overheads caused by each hardware thread. To gather this data,
BreakHammer maintains an operation score counter for each hardware thread,
which monitors any time-consuming action that the RowHammer mitigation
mechanism performs. With this detailed system record, BreakHammer identifies
threads that abnormally reduce the system throughput by triggering preventive
actions. We explain how BreakHammer does so in the following step (§IV-B).

The score calculation depends on the implemented RowHammer mitigation
mechanism. Thus, we briefly describe the evaluated RowHammer mitigation
mechanisms to explain how we calculate the score for each mechanism.

PARA [10]. PARA probabilistically performs a preventive refresh operation when
the memory controller issues a row activation. PARA is _stateless_ (i.e., does
not keep track of any type of history or statistics). _Score Calculation:_
Since the activated row’s access history is _not_ relevant for PARA,
BreakHammer increments a hardware thread’s score when one of the thread’s
memory requests causes a preventive refresh operation.

Graphene [84]. Graphene implements the Misra-Gries frequent element finding
algorithm [169], which counts the number of activations for the most
frequently accessed DRAM rows. Graphene issues a preventive refresh when an
aggressor row’s activation count exceeds Graphene’s threshold. _Score
Calculation:_ BreakHammer increments a hardware thread’s score when one of the
thread’s memory requests activates an aggressor row, which makes the row’s
activation count exceed Graphene’s threshold and consequently leads to a
preventive refresh operation.

AQUA [88]. AQUA similarly implements the Misra-Gries frequent element finding
algorithm. AQUA migrates frequently accessed rows to a quarantine area in DRAM
to mitigate attacks. _Score Calculation:_ BreakHammer increments the hardware
thread’s score when one of the thread’s memory requests causes a row
migration.

Hydra [89]. Hydra implements a two-part tracking algorithm, where it initially
tracks an aggregated group of rows until a threshold is met and switches to
per-row tracking. Hydra tracks the per-row tracking table in DRAM and keeps a
small cache for it in the memory controller. When a per-row table entry
exceeds a threshold, a preventive refresh operation is performed. _Score
Calculation:_ BreakHammer increments a hardware thread’s score when one of the
thread’s memory requests causes a per-row cache miss, per-row cache eviction,
or a preventive refresh operation.

TWiCe [87]. TWiCe implements a counter entry table of frequent rows. Table
entries have a lifetime, and infrequent rows are periodically pruned with
auto-refresh operations. _Score Calculation:_ BreakHammer increments a
hardware thread’s score when one of the thread’s memory requests causes a
preventive refresh operation.

REGA [90]. REGA modifies the DRAM chip by adding an additional row buffer to
each subarray. REGA periodically performs round-robin refreshes based on
configurable activation frequency (i.e., $REGA_{T}$) using the second row
buffer while the requests are served using the first row buffer. _Score
Calculation:_ BreakHammer increments a hardware thread’s score by one for
every $REGA_{T}$ row activations it performs.

Refresh Management (RFM) and in-DRAM Mitigations [133, 97, 91, 92, 93]. The
DDR5 standard introduced the new _refresh management_ (RFM) command. The
memory controller sends the RFM command at a set activation frequency (e.g.,
once every 80 row activations to a bank). When the RFM is issued, the DRAM
takes necessary preventive actions within the given time window. _Score
Calculation:_ BreakHammer counts the total number of row activations each
hardware thread performs between two consecutive RFM commands and increments
the most activating hardware thread’s score.

###  IV-B Detecting Anomalies

BreakHammer identifies anomalies in the time-consuming RowHammer preventive
actions caused by threads, specifically targeting those actions that might
indicate attacker-induced activities (e.g., frequent preventive refresh). Once
such anomalies are detected, BreakHammer can then take necessary mitigation
measures to address these potential attackers and maintain system memory
bandwidth efficiency.

BreakHammer performs the detection by splitting the execution into uniformly
divided throttling epochs, where it performs outlier analysis to identify the
threads to take action against. BreakHammer can employ different mechanisms to
detect anomalies. We use thresholded multiplies of the mean algorithm for our
implementation. The thresholded multiplies of the mean throttling has three
tunable configuration parameters: 1) $TH_{length}$: length of the throttling
epoch, 2) $TH_{flat}$ (flat threshold): minimum score to consider, and 3)
$TH_{dynamic}$ (dynamic threshold): maximum allowed percent divergence from
the mean of all thread scores. Alg. 1 describes the anomaly detection
mechanism.

1

// $OpCtrs$: Operation counters for all threads

// $T_{i}$: Hardware thread that caused the operation

// $TH_{flat}$: Flat threshold

// $TH_{dynamic}$: Dynamic threshold

2 Function  _$incrThreadOp$($C$, $T_{i}$, $TH_{flat}$, $TH_{dynamic}$)_:

3 $OpCtrs$($T_{i}$) $\leftarrow$ $OpCtrs$($T_{i}$) + $1$

4 if  _$OpCtrs$($T_{i}$) $<$ $TH_{flat}$_ then

5 return

6 end if

7 if  _$OpCtrs$($T_{i}$) $>$ $(1+TH_{dynamic})*$ $mean$($OpCtrs$)_ then

8 $labelAnomaly$($T_{i}$)

9

10 end if

11

12

Algorithm 1 Throttled multiplies of the mean anomaly detection

Each time BreakHammer increments a thread’s operation counter (line 2), it
performs a series of checks to determine if the thread is causing an anomaly.
Initially, the incremented value is compared against $TH_{flat}$ (line 3). If
the counter exceeds this parameter, BreakHammer then calculates the mean of
all operations counters across threads (line 6) to determine if the last
increased counter positively deviates from the mean by a factor of
$TH_{dynamic}$ (line 7). Lastly, if the counter exceeds this threshold as
well, BreakHammer labels this thread’s operations as an anomaly (line 8) for
the remainder of the current window.

Time-interleaving-based continuous monitoring. Incrementing counters
eventually could have caused the counters to saturate, in which case
BreakHammer would mistakenly reduce the memory usage of benign workloads. To
avoid this issue, BreakHammer periodically resets its counters. To _not_ lose
information upon resetting counters, BreakHammer interleaves across two sets
of counters similar to what prior works do [83, 170]. Fig. 4 demonstrates how
BreakHammer time-interleaves across two sets of counters.

Figure 4: Time interleaving across BreakHammer’s two sets of counters

We assign two counters to each thread in BreakHammer. During a throttling
epoch, both counters of a thread are incremented concurrently with every
preventive action taken by the thread. However, only one of these counters,
named as the active counter (e.g., the counter in the counter set 1 in the
beginning in Fig. 4), responds to queries regarding throttling decisions. At
the end of each epoch, only the current active counter is reset (e.g., the
first reset in Fig. 4 resets counters in the counter set 1). With the reset,
the other counter becomes the active counter (e.g., counters in the counter
set 2 in Fig. 4 after the first reset) for the next epoch. Because the newly
active counters were already trained with the preventive actions that took
place in the previous epoch, they start responding queries with already
trained values. This method ensures a continuous monitoring of each thread’s
activity across throttling epochs.

###  IV-C Filtering and Linear Scaling

BreakHammer assigns an on-the-fly memory request quota to hardware threads
that are detected as outliers. BreakHammer memory request quota assignment has
two tunable configuration parameters: 1) $P_{initial}$: initial reduce factor,
and 2) $P_{consequtive}$: consecutive reduce parameter. When BreakHammer
detects an outlier thread can (i) begin to be throttled (i.e., _not_ throttled
in the last window) or (ii) continue to be throttled (i.e., throttled in the
last window). On-the-fly memory request quota is calculated with Equation 1.

$\begin{cases}Q_{i}\times P_{initial}&\text{(i) $T_{i}$ was not throttled}\\\
max(Q_{i}-P_{consequtive},0)&\text{(ii) $T_{i}$ was throttled}\end{cases}$ (1)

Here, $T_{i}$ and $Q_{i}$ denote the hardware thread $i$ and hardware thread
$i$’s on-the-fly memory request quota, respectively. BreakHammer reduces the
on-the-fly memory request quota of (i) threads beginning to be throttled by a
factor of $P_{initial}$. For threads (ii) continuing to be throttled,
BreakHammer reduces the on-the-fly memory request quota by a constant
$P_{consequtive}$ until they reach 0 and no longer make new memory requests.

###  IV-D Throttling Memory Usage

BreakHammer regulates the memory requests made by hardware threads when an
outlier is detected. This regulation is crucial to ensure efficient
utilization of memory resources across threads. To do so, BreakHammer
throttles threads that exceed their on-the-fly memory request quotas. This can
be achieved by limiting one or both of 1) the number of MSHRs the outlier
thread can allocate in the caches, and 2) the number of unresolved memory
instructions (e.g., load, store, and clflush) in the instruction window.

We use (1) as our throttling action for two reasons: First, by limiting MSHRs,
BreakHammer allows the outlier thread to continue accessing memory locations
that result in MSHR hits within the cache hierarchy. Since these requests are
already being resolved, they don’t pose a problem for the thread’s memory
access. Second, BreakHammer is implemented inside the memory controller.
Because of its placement, it is easier to communicate with caches rather than
cores, as similar to prior work [171, 172, 173, 174, 175, 176, 83].

##  V Security Analysis

We analyze BreakHammer’s security in the contexts of RowHammer attacks and
denial-of-service (DoS) attacks.

Security Against RowHammer Attacks. BreakHammer is _not_ a RowHammer defense
by itself, but it is a mechanism that reduces the performance overheads
incurred by existing RowHammer defenses (§VIII). BreakHammer does _not_
interfere with any of the triggering algorithms and the preventive actions
that the existing RowHammer mitigation mechanisms execute. Therefore, the
RowHammer mitigation mechanism provides its own security guarantees without
any disturbance or interference. When BreakHammer observes that the RowHammer
mitigation mechanism works aggressively (i.e., performs many preventive
actions) as a result of the memory accesses generated by one or few threads,
BreakHammer effectively reduces the memory requests coming from those threads
via its throttling approach. Meanwhile, RowHammer mitigation mechanism keeps
executing its triggering algorithm on the memory accesses that contain fewer
requests from the suspected threads. Consequently, the RowHammer mitigation
mechanism performs preventive actions less aggressively _without_ compromising
any security guarantees. In contrast, a system designer can _optionally_
leverage BreakHammer’s performance benefits and achieve stronger security
against RowHammer at the same performance as implementing the RowHammer
mitigation mechanism without BreakHammer.

Security Against Denial-of-Service Attacks. BreakHammer increments a thread’s
counter whenever the thread causes a preventive action. Due to time-
interleaving-based continuous monitoring across two sets of counters similar
to what prior work does [83], BreakHammer successfully tracks all preventive
actions. Therefore, BreakHammer always detects a thread, which is responsible
for many preventive actions. As a hardware-level mechanism, BreakHammer does
_not_ kill a thread, but reduces its memory accesses. By doing so, BreakHammer
reduces the interference in the memory subsystem and prevents an attack
causing denial of memory services. BreakHammer does _not_ take any direct
action towards forcing an attacker thread to yield its core, which could have
eventually caused denial-of-service at the processor core level. To avoid
this, BreakHammer can optionally inform the countermeasures and CPU scheduling
algorithm in the system software with the identification of the attacker
threads. As we implement BreakHammer within the processor, this communication
is as simple as reading from BreakHammer’s counters, similar to reading a
performance counter.

##  VI Hardware Complexity

BreakHammer is implemented in the memory controller and does not introduce any
changes to the DRAM chip design. We evaluate BreakHammer’s hardware complexity
using CACTI [94] and Synopsys Design Compiler [95].

Area Analysis. BreakHammer utilizes two 32-bit counters per hardware thread,
which consume 0.000105$mm^{2}$ per memory channel, consuming an overall area
overhead of 0.0002% of the Intel Xeon processor’s chip area [177].

Latency Analysis. We implement BreakHammer in Chisel HDL and synthesize the
emitted Verilog HDL design using Synopsys Design Compiler [95] with a 65nm
process technology. Our BreakHammer implementation is fully pipelined where it
can observe new actions (e.g., memory access or preventive refresh) and make a
throttling decision every cycle with a pipeline latency of 8 cycles.222We note
that having a throttling latency in the order of a few nanoseconds is
insignificant as BreakHammer tracks adversarial threads and does _not_ try to
prevent on-the-fly memory accesses. According to our Chisel HDL model,
BreakHammer can be clocked at 1.5GHz ($\sim$0.67ns). This latency is faster
than the latency of regular memory controller operations as it is smaller than
$t_{RRD}{}$ (e.g., 2.5ns in DDR4 [96] and 5ns in DDR5 [97]).

##  VII Experimental Methodology

We evaluate BreakHammer’s effect on a DDR5-based memory subsystem’s
performance using cycle-level simulations. We use Ramulator2 [178, 179] for
the performance evaluation where BreakHammer is implemented with BlockHammer
[83], Graphene [84], Hydra [89], AQUA [88], TWiCe [87], PARA [10], REGA [90],
and an RFM command [159] memory controller extension.

Table I shows our system configuration. We assume a realistic quad-core
system, connected to a dual-rank memory with eight bank groups, each
containing two banks (32 banks in total). The memory controller employs the
FR-FCFS [180] scheduling algorithm with an FR-FCFS-cap of four.

TABLE I: Simulated System Configuration Processor |  $4.2\text{\,}\mathrm{GHz}$, {1,4} core, 4-wide issue, 128-entry instr. window
---|---
Last-Level Cache |  64-byte cache line, 8-way set-associative, $8\text{\,}\mathrm{MB}$
Memory Controller |  64-entry each read and write request queues; Scheduling policy: FR-FCFS [181, 182] with an FR-FCFS-cap of 4; Address mapping: MOP [183]
Main Memory |  DDR5, 1 channel, 2 rank, 8 bank groups, 2 banks/bank group, 65K rows/bank

Comparison Points. We pair BreakHammer with seven state-of-the-art RowHammer
mitigation mechanisms that provide RowHammer-safe operation: one is a
probabilistic mechanism [10], another four are deterministic mechanisms [84,
89, 87, 88] and the last utilizes the lastest RFM command [97]. We configure
all RowHammer mitigation mechanisms except RFM according to the methodology
described by their studies and scale them to target $N_{RH}$ values we use for
our evaluation. For RFM, we assume perfect RowHammer tracking [91, 184] in the
DRAM module and perform a mathematical analysis against the wave attack [93].
Fig. 5 presents our bank activation threshold to issue an RFM command
($RFM_{th}{}$) analysis for varying initial wave attack row counts. The x-axis
and the y-axis show the $RFM_{th}$ configuration and the maximum possible
activations on a single row possible, respectively. Each bar identifies a
different initial wave attack row count. Note that we do not use $RFM_{th}$
values higher than 80 for our configuration as the JEDEC DDR5 specification
[97] currently does _not_ support these values.

Figure 5: Maximum ACTs possible on a row without refresh for varying
$RFM_{rh}$ values

We configure our memory controller to send an RFM same bank command with the
highest possible activations based on our analysis in Fig. 5, e.g.,
$RFM_{th}={6}$ against $N_{RH}={64}$ as no starting wave attack size allows
the attacker to cause a bitflip by reaching 64 activations on a single row.

We compare BreakHammer paired versions of these seven RowHammer mitigation
mechanisms to their baseline implementations. We also compare BreakHammer
paired with PARA, AQUA, and RFM to BlockHammer, the current throttling-based
state-of-the-art RowHammer mitigation mechanism. Table II summarizes
BreakHammer’s configuration parameters for our evaluation.

TABLE II: BreakHammer Configuration Component | Parameters
---|---
Anomaly Observation |  Counter Size: $32$ bits
|  $TH_{length}:32$ ms
Anomaly Detection | $TH_{flat}:32$
| $TH_{dynamic}:0.65$
Linear Scaling | $P_{initial}:0.33$
| $P_{consequtive}:1$

Workloads. We evaluate BreakHammer with applications from five benchmark
suites: SPEC CPU2006 [185], SPEC CPU2017 [186], TPC [187], MediaBench [188],
and YCSB [189]. We group all applications into three memory intensity groups
based on their misses per kilo instructions (MPKIs). These groups are High
(H), Medium (M), and Low (L) for the lowest MPKI values of 60, 10, and 0,
respectively. Then, we create 51 balanced workload mixes of varying
application memory intensity combinations. We simulate these workloads until
each core executes 100M instructions. Table III summarizes MPKI and the
average number of rows with more than 64, 128, and 512 activations per 64ms
time window for the 8 most memory-intensive workloads. From this table, we
observe that many benign workloads are capable of triggering preventive
actions when the $N_{RH}$ is low enough.

TABLE III: Workload Characteristics
MPKI and Average Row Activations of 64+, 128+ and 512+ per 64 ms time window Workload | MPKI | ACT-64+ | ACT-128+ | ACT-512+
---|---|---|---|---
429.mcf | 68.27 | 2564 | 2564 | 2564
470.lbm | 28.09 | 7089 | 6596 | 664
462.libquantum | 25.95 | 1 | 0 | 0
549.fotonik3d | 25.28 | 10065 | 88 | 0
459.GemsFDTD | 24.93 | 10572 | 218 | 0
519.lbm | 24.37 | 5824 | 5455 | 2482
434.zeusmp | 22.24 | 11085 | 4825 | 292
510.parest | 17.79 | 803 | 185 | 94
Average | 29.615 | 6000.4 | 2491.4 | 762

##  VIII Performance Evaluation

We evaluate the performance overheads of BreakHammer when paired with seven
different RowHammer mitigation mechanisms and compare against 1) these
mechanisms without BreakHammer and 2) BlockHammer [83], which already
implements a throttling mechanism similar to BreakHammer. First, we evaluate
BreakHammer with multi-programmed workloads and show that, by throttling an
attacker’s requests, BreakHammer significantly improves the performance of
benign applications by 65.6% on average (with a maximum of 110.3%), compared
to both the baseline system and a system with the prior best-performing state-
of-the-art RowHammer mitigation mechanism. Second, we study BreakHammer’s
applicability when paired with seven state-of-the-art RowHammer mitigation
mechanisms to future DRAM chips that are vulnerable to very low RowHammer
thresholds. We observe that BreakHammer 1) incurs no overhead when all
applications are benign and 2) significantly reduces the performance overhead
of these mechanisms when a RowHammer attack is present at RowHammer thresholds
as low as 64. Third, we compare BreakHammer with BlockHammer as the RowHammer
threshold decreases and show that BreakHammer 1) outperforms BlockHammer and,
2) maintains a minimal area overhead with just two counters per thread whereas
BlockHammer requires a significantly growing history buffer.

###  VIII-A Under Attack

Fig. 6 presents the performance impact of BreakHammer when paired with seven
state-of-the-art RowHammer mitigation mechanisms on four core workloads with
an attacker present at $N_{RH}=1K$. The x-axis shows the memory intensity of
each application in the mix where H, M, L, and A denote High, Medium, Low, and
Attacker, respectively, alongside the geometric-mean (gmean) of the measured
metrics across these workloads. The y-axis shows the weighed instructions
committed per processor cycle (IPC) speedup of each workload normalized on the
baseline system that does _not_ implement any RowHammer mitigation mechanism,
and different bars for each workload represent a different RowHammer
mitigation mechanism 1) by itself (e.g., PARA) and 2) paired with BreakHammer
(e.g., PARA-BreakHammer).

Figure 6: BreakHammer’s impact on system performance for existing RowHammer
mitigation mechanisms

We make three observations from Fig. 6. First, BreakHammer increases the
average (maximum) performance of the non-attacker workloads by 65.6% (110.3%)
on the geometric mean. Second, BreakHammer is correctly able to detect and
throttle the attacker thread in all workloads. Third, BreakHammer mitigates
any system overheads caused by the seven state-of-the-art RowHammer mitigation
mechanisms. Based on these observations, we conclude that BreakHammer
significantly reduces the performance overhead of RowHammer mitigation when
combined with any of the seven mechanisms.

To show the applicability of BreakHammer on future DRAM chips where $N_{RH}$
keeps decreasing [63], we study the performance of BreakHammer at $N_{RH}$
values ranging from 4096 to 64. Fig. 7 presents the weighted IPC speedup of
BreakHammer when paired with seven state-of-the-art RowHammer mitigation
mechanisms on four core workloads with an attacker present for seven $N_{RH}$
values. The x-axis shows the different $N_{RH}$ values, the y-axis shows the
normalized weighed IPC speedup to the baseline with no RowHammer defense
mechanism, and each box identifies a RowHammer mitigation mechanism 1) by
itself or 2) paired with BreakHammer.

Figure 7: BreakHammer’s impact on system performance for existing RowHammer
mitigation mechanisms at various $N_{RH}$ values

We make three observations from Fig. 7. First, BreakHammer increases the
average (maximum) performance of the non-attacker workloads at all $N_{RH}$
values by 48.7% (105.2%). Second, RFM incurs a substantially increasing
overhead as $N_{RH}$ decreases even with _perfect_ RowHammer tracking, and it
has a constant 5% overhead for all $N_{RH}\geq 1024$ as the JEDEC
specification [97] does _not_ support $RFM_{th}$ values higher than 80. Third,
as the $N_{RH}$ values decrease BreakHammer maintains a speedup above the no
defense baseline for all mitigation mechanisms except for PARA at $N_{RH}=64$
and AQUA at $N_{RH}\leq 256$. PARA does _not_ have a row activation history,
where benign workloads accessing completely different rows also trigger
preventive refreshes. This causes BreakHammer to keep increasing the score of
all threads and makes it harder to detect the attacker. On the other hand,
AQUA uses row migration to provide security. This causes non-negligible
overheads as $N_{RH}$ decreases even for the remaining benign workloads after
the attacker is throttled. Based on these three observations we conclude that
_all_ of the seven state-of-the-art RowHammer mitigation mechanisms show an
increasing performance overhead as $N_{RH}$ decreases, and BreakHammer
provides significant performance benefits even exceeding the baseline with
_no_ mitigation.

To understand the effects of throttling on the total number of preventive
actions performed, we further study the preventive action counts333As REGA
performs shadow refreshes in parallel to row activations, we do _not_ include
REGA in this analysis, while we evaluate its performance overhead based on its
impact on DRAM timing constraints. of Graphene, Hydra, PARA, RFM, AQUA, and
TWiCe 1) by themselves, and 2) when paired with BreakHammer. Fig. 8 presents
the preventive actions of these mechanisms at seven different $N_{RH}$ values,
normalized to their default implementation actions at $N_{RH}=4K$. Each
subplot displays a different mechanism where the x-axis shows the different
$N_{RH}$ values, the y-axis shows the normalized preventive actions, pink and
purple lines represent the BreakHammer paired mechanisms and the baseline
mechanism, respectively.

Figure 8: BreakHammer’s impact on preventive actions performed for existing
RowHammer mitigation mechanisms

We make two observations from Fig. 8. First, BreakHammer decreases the
preventive action counts of all mechanisms at all $N_{RH}$ values by an
average (maximum) value of 72.5% (87.7%). Second, as $N_{RH}$ values decrease,
each mechanism shows a similar increase in their preventive action counts from
their baseline implementation. Based on these two observations we conclude
that all of the six RowHammer mitigation mechanisms issue a drastically
increasing number of preventive actions as $N_{RH}$ decreases, and BreakHammer
significantly reduces the overall preventive actions performed in the system.

To show the energy benefits of reducing the overall preventive actions by
throttling the attacker, we extend Ramulator 2.0 with DRAMPower [190] and
study the energy consumption of these workloads. Fig. 9 presents the
normalized energy values of BreakHammer when paired with seven state-of-the-
art RowHammer mitigation mechanisms on four core workloads with an attacker
present for seven $N_{RH}$ values. The x-axis shows the different $N_{RH}$
values, the y-axis shows the normalized total energy values to the baseline
with no RowHammer defense, and each box identifies a RowHammer mitigation 1)
by itself or 2) paired with BreakHammer.

Figure 9: BreakHammer’s impact on RowHammer attacker present energy
consumption for existing RowHammer mitigation mechanisms

We make three observations from Fig. 9. First, all of the studied seven
RowHammer mitigation mechanisms consume more energy with an average of 1.86x
increase as $N_{RH}$ decreases. Second, BreakHammer significantly reduces the
energy consumption of all seven RowHammer mitigation mechanisms at all
$N_{RH}$ values by an average (maximum) of 54.4% (79.3%). Three, across the
studied seven RowHammer mitigation mechanisms AQUA and RFM incur the highest
average energy overhead by 19.1x and 3.1x at $N_{RH}=64$, respectively. Based
on these three observations we conclude that all of the seven RowHammer
mitigation mechanisms incur increasing energy overheads as $N_{RH}$ decreases,
and BreakHammer significantly reduces the overall energy consumption when an
attacker is present.

###  VIII-B No Attack Multiprogrammed

To understand the performance effects of BreakHammer on workloads when no
RowHammer attacker is present, we evaluate BreakHammer on a four core system
with only benign applications. Fig. 10 presents the performance impact of
BreakHammer when paired with seven state-of-the-art RowHammer mitigation
mechanisms on four core workloads where all applications are benign at
$N_{RH}=64$. The x-axis shows the memory intensity of the applications in the
mix where H, M, and L denote High, Medium, and Low, respectively. The y-axis
shows the weighed IPC speedup normalized to the baseline with no defense and
each colored bar represents a different RowHammer mitigation mechanism 1) by
itself and, 2) paired with BreakHammer.

Figure 10: BreakHammer’s impact on system performance for existing RowHammer
mitigation mechanisms

We make three observations from Fig. 10. First, BreakHammer increases the
geometric average (maximum) performance of the non-attacker workloads by 2.2%
(4.5%). Second, AQUA [88] and PARA [10] introduce the largest overheads among
seven mechanisms by 74.2% and 60.5%, respectively. Based on these two
observations we conclude that BreakHammer does not worsen, and slightly
increases the performance of these seven RowHammer mitigation mechanisms
across benign workloads of varying memory intensities.

To further understand the performance effects of BreakHammer on benign
workloads at different $N_{RH}$ values, we evaluate BreakHammer on a four core
system with only benign applications at seven $N_{RH}$ values. Fig. 11
presents the weighted IPC speedup of BreakHammer when paired with seven state-
of-the-art RowHammer mitigation mechanisms on four core workloads where all
applications are benign for seven $N_{RH}$ values. The x-axis shows the
different $N_{RH}$ values, the y-axis shows the weighed IPC speedup, and each
bar identifies a RowHammer mitigation mechanism 1) by itself and, 2) paired
with BreakHammer.

Figure 11: BreakHammer’s impact on system performance for existing RowHammer
mitigation mechanisms at various $N_{RH}$ values

We make two observations from Fig. 11. First, BreakHammer improves the average
(maximum) system performance of all tested RowHammer defenses at $N_{RH}=64$.
Second, the speedup of all mechanisms decreases as we reduce $N_{RH}{}$. Based
on these two observations we conclude that BreakHammer improves system
performance of benign workloads at low $N_{RH}{}$ values while _not_
introducing any extra overhead at higher $N_{RH}{}$ values.

To study the memory latency effects of BreakHammer on benign workloads, we
evaluate BreakHammer on a four core system with only benign applications at
$N_{RH}=64$. Fig. 12 presents the memory latency percentiles of BreakHammer
when paired with seven state-of-the-art RowHammer mitigation mechanisms on
four core workloads where all applications are benign for $N_{RH}=64$. The
x-axis shows the different percentile $P_{N}$ values, the y-axis shows the
memory latency in nanoseconds, and each curve identifies the baseline and the
RowHammer mitigation mechanism 1) by itself and 2) paired with BreakHammer.
The background color indicates which mechanism causes a lower memory access
latency for a given percentile of accesses, e.g., a purple means that the
tested mechanism results in a lower memory access latency when used with
BreakHammer, compared to without BreakHammer.

Figure 12: BreakHammer’s impact on benign workload percentile memory latency
for existing RowHammer mitigations

From Fig. 12, we observe that BreakHammer incurs no overhead and reduces the
memory latency of all tested RowHammer defenses at all $P_{N}$ values for
$N_{RH}=64$.

###  VIII-C Comparison Against BlockHammer

BlockHammer is the state-of-the-art throttling based RowHammer mitigation
mechanism. It works by blacklisting rows and identifying threads that
frequently activate these rows. To understand the BreakHammer’s performance
benefits when compared to BlockHammer we study four core workloads with an
attacker present at seven $N_{RH}$ values.

Fig. 13 presents the harmonic IPC speedup of BlockHammer and BreakHammer when
paired with PARA, AQUA, and RFM on four core workloads with a RowHammer
attacker present at seven $N_{RH}$ values. The x-axis shows the different
$N_{RH}$ values, the y-axis shows the harmonic IPC speedup, and each line
identifies 1) BlockHammer or, 2) a RowHammer mitigation mechanism paired with
BreakHammer.

Figure 13: BreakHammer’s performance compared to BlockHammer [83], the state-
of-the-art throttling-based RowHammer mitigation mechanism

We make two observations from Fig. 13. First, BreakHammer enhanced mechanisms
outperform BlockHammer at all $N_{RH}$ values. Second, BlockHammer’s average
performance impact drastically drops from 1.58x speedup to 0.0045x speedup as
$N_{RH}$ values decrease. Based on these observations, we conclude that
BreakHammer outperforms BlockHammer, the previous state-of-the-art throttling
based mechanism at all $N_{RH}$ values even when combined with the _worst_
scaling RowHammer mitigations, i.e., AQUA, PARA, and RFM.

###  VIII-D Sensitivity to Configuration Parameters

BreakHammer’s thresholding has three tunable configuration parameters: (1)
$TH_{length}$: length of the throttling window (2) $TH_{flat}$ (flat
threshold): minimum score to consider a thread for throttling, and (3)
$TH_{dynamic}$ (dynamic threshold): maximum allowed percent divergence from
the mean of all thread scores before throttling. We set our mitigation window
to $t_{REFW}$ as prior work [83, 87].

To determine the flat threshold ($TH_{flat}$) we sweep our parameters from the
high threshold of 4096 down to 32. Fig. 14 shows the weighted IPC speedup of
BreakHammer normalized to the 4096 flat thresholded baseline system. Each
subplot presents a different $N_{RH}$ where the x-axis shows the flat
threshold configuration and the y-axis shows the normalized weighted IPC
speedup.

Figure 14: Sensitivity of BreakHammer’s performance to the flat threshold

We observe that the performance increases as the flat threshold decreases. To
not completely remove the flat threshold effect and allow possible noise at
low $N_{RH}$ values we stop our sweep at 32. We choose it as it outperforms
all other configurations.

##  IX Related Work

To our knowledge, this is the first work that provides the RowHammer
mitigation mechanisms with throttling support to reduce their performance
overheads. §VIII qualitatively and quantitatively compares BreakHammer with
the most relevant prior mechanisms. This section discusses other related
works.

On-die RowHammer Mitigations. DRAM manufacturers implement RowHammer
mitigation techniques, also known as Target Row Refresh (TRR), in commercial
DRAM chips [97, 96], but they do not openly disclose the specific designs.
Recent research shows that custom attack patterns can bypass these mechanisms
[36, 42, 43, 41, 13, 149]. With worsening RowHammer vulnerability, these
mechanisms need to perform an increasing number of preventive refresh
operations. To provide these mechanisms with the necessary time window, new
DRAM communication protocols (e.g., DDR5 [97]) require the memory controller
to issue refresh management (RFM) commands. §IV already explains how to couple
BreakHammer with on-DRAM-die mechanisms through RFM commands and §VIII
evaluates its performance benefits. Therefore, adopting BreakHammer is
sufficient to securely prevent RowHammer bitflips with low cost and without
on-die mitigations. To adopt BreakHammer in a system with TRR, BreakHammer
needs to track target row refreshes. Similar to all mitigations implemented in
the memory controller, BreakHammer requires information on how TRR works and
which rows it refreshes to accurately track activation counts. In such
systems, this information can be provided to BreakHammer to securely prevent
all RowHammer bitflips.

Hardware-based RowHammer Mitigations. Prior works propose a set of hardware-
based mitigations [112, 113, 114, 115, 10, 116, 96, 117, 118, 119, 120, 121,
122, 123, 100, 124, 125, 126, 57, 101, 127, 87, 84, 93, 83, 36, 128, 42, 89,
129, 22, 130, 29, 131, 132, 103, 133, 134, 135, 136, 137, 138, 85, 88, 139,
140, 141, 142, 143, 144, 145, 146, 92, 147, 148, 149, 150, 151, 152, 153, 69,
90, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 91, 139, 164, 165, 166,
167] to prevent RowHammer bitflips. A subset of these works [10, 127, 124,
191, 85, 150] proposes probabilistic preventive refresh mechanisms to mitigate
RowHammer at low area cost. Two prior works [192, 89] propose implementing
per-row counters to accurately track row activations. These works incur
increasingly large metadata overhead and either cause large area or
performance and energy overheads as we show in §III. Another group of prior
works [168, 125, 128, 87, 129, 88, 133, 135, 84, 193] propose using frequent
item counting algorithm Misra-Gries [169]. Another set of prior works [83, 10,
115] proposes throttling mechanisms that delay memory requests to prevent
RowHammer bitflips. Unlike these mechanisms, BreakHammer does not rely on
throttling to prevent RowHammer bitflips, and thus BreakHammer does not
perform throttling as aggressively, reducing BreakHammer’s performance and
area overheads.

Denial of Memory Service. Several prior works propose techniques for causing
and preventing denial of memory service [194, 195, 196, 173]. These works
tackle denial of memory services from the memory request scheduling
algorithms’ point of view and are oblivious to the effect of RowHammer
mitigation mechanisms that can be maliciously triggered. In contrast
BreakHammer tackles the performance overheads induced by RowHammer mitigation
mechanisms. Therefore, these mechanisms can be complemented with BreakHammer
to achieve better security against denial of memory services.

Other Uses of Throttling. Prior works on quality-of-service and fairness-
oriented architectures propose selectively throttling main memory accesses to
provide latency guarantees and/or improve fairness across applications (e.g.,
[176, 197, 198, 199, 200, 201]). These mechanisms are not designed to prevent
RowHammer attacks and thus do not interfere with a RowHammer attack when there
is no contention between memory accesses.

Other RowHammer Mitigations. Several software-based RowHammer mitigation
mechanisms propose to avoid hardware-level modifications. However, they cannot
monitor all memory requests. Thus, many of these mechanisms are defeated by
recent attacks [21, 14, 27, 31, 202, 35, 39]. Another set of mitigations [203,
204, 205, 206, 138, 148, 207, 140] implements integrity check mechanisms that
identify and correct potential bitflips. However, it is either not possible or
too costly to address all potential bitflips through these mechanisms.

##  X Conclusion

We tackle the worsening performance overhead of existing RowHammer solutions
by tracking the generators of memory accesses that trigger RowHammer
solutions. We propose BreakHammer. BreakHammer cooperates with exiting
RowHammer defenses, observes performed preventive actions, and identifies the
hardware threads that trigger these operations. BreakHammer estimates the
RowHammer-likelihood of each hardware thread and reduces its on-the-fly memory
requests. We showcase that BreakHammer is compatible with both memory
controller-based and on-DRAM-die RowHammer mitigation mechanisms by
implementing BreakHammer with six state-of-the-art RowHammer mitigation
mechanisms. Our experimental evaluation shows that BreakHammer significantly
reduces the number of performed counter-measures and improves the system
performance by an average (maximum) of 48.7% (105.2%). We hope and expect that
BreakHammer will allow researchers and engineers to build reliable, secure,
and safe DRAM-based systems while DRAM chips become more and more vulnerable
to RowHammer.

## References

  * [1] Robert H. Dennard.  Field-Effect Transistor Memory, 1968.
  * [2] Apostolos P Fournaris, Lidia Pocero Fraile, and Odysseas Koufopavlou.  Exploiting Hardware Vulnerabilities to Attack Embedded System Devices: A Survey of Potent Microarchitectural Attacks.  Electronics, 2017.
  * [3] Damian Poddebniak, Juraj Somorovsky, Sebastian Schinzel, Manfred Lochter, and Paul Rösler.  Attacking Deterministic Signature Schemes using Fault Attacks.  In EuroS&P, 2018.
  * [4] Andrei Tatar, Radhesh Krishnan Konoth, Elias Athanasopoulos, Cristiano Giuffrida, Herbert Bos, and Kaveh Razavi.  Throwhammer: Rowhammer Attacks Over the Network and Defenses.  In USENIX ATC, 2018.
  * [5] Sebastien Carre, Matthieu Desjardins, Adrien Facon, and Sylvain Guilley.  OpenSSL Bellcore’s Protection Helps Fault Attack.  In DSD, 2018.
  * [6] Alessandro Barenghi, Luca Breveglieri, Niccolò Izzo, and Gerardo Pelosi.  Software-Only Reverse Engineering of Physical DRAM Mappings for Rowhammer Attacks.  In IVSW, 2018.
  * [7] Zhenkai Zhang, Zihao Zhan, Daniel Balasubramanian, Xenofon Koutsoukos, and Gabor Karsai.  Triggering Rowhammer Hardware Faults on ARM: A Revisit.  In ASHES, 2018.
  * [8] Sarani Bhattacharya and Debdeep Mukhopadhyay.  Advanced Fault Attacks in Software: Exploiting the Rowhammer Bug.  In Fault Tolerant Architectures for Cryptography and Hardware Security. 2018.
  * [9] Mark Seaborn and Thomas Dullien.  Exploiting the DRAM Rowhammer Bug to Gain Kernel Privileges.  http://googleprojectzero.blogspot.com.tr/2015/03/exploiting-dram-rowhammer-bug-to-gain.html, 2015.
  * [10] 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.
  * [11] SAFARI Research Group.  RowHammer — GitHub Repository.  https://github.com/CMU-SAFARI/rowhammer, 2014.
  * [12] Mark Seaborn and Thomas Dullien.  Exploiting the DRAM Rowhammer Bug to Gain Kernel Privileges.  Black Hat, 2015.
  * [13] Victor van der Veen, Yanick Fratantonio, Martina Lindorfer, Daniel Gruss, Clementine Maurice, Giovanni Vigna, Herbert Bos, Kaveh Razavi, and Cristiano Giuffrida.  Drammer: Deterministic Rowhammer Attacks on Mobile Platforms.  In CCS, 2016.
  * [14] Daniel Gruss, Clémentine Maurice, and Stefan Mangard.  Rowhammer.js: A Remote Software-Induced Fault Attack in Javascript.  arXiv:1507.06955 [cs.CR], 2016.
  * [15] Kaveh Razavi, Ben Gras, Erik Bosman, Bart Preneel, Cristiano Giuffrida, and Herbert Bos.  Flip Feng Shui: Hammering a Needle in the Software Stack.  In USENIX Security, 2016.
  * [16] Peter Pessl, Daniel Gruss, Clémentine Maurice, Michael Schwarz, and Stefan Mangard.  DRAMA: Exploiting DRAM Addressing for Cross-CPU Attacks.  In USENIX Security, 2016.
  * [17] Yuan Xiao, Xiaokuan Zhang, Yinqian Zhang, and Radu Teodorescu.  One Bit Flips, One Cloud Flops: Cross-VM Row Hammer Attacks and Privilege Escalation.  In USENIX Security, 2016.
  * [18] Erik Bosman, Kaveh Razavi, Herbert Bos, and Cristiano Giuffrida.  Dedup Est Machina: Memory Deduplication as An Advanced Exploitation Vector.  In S&P, 2016.
  * [19] Sarani Bhattacharya and Debdeep Mukhopadhyay.  Curious Case of Rowhammer: Flipping Secret Exponent Bits Using Timing Analysis.  In CHES, 2016.
  * [20] Wayne Burleson, Onur Mutlu, and Mohit Tiwari.  Invited: Who is the Major Threat to Tomorrow’s Security? You, the Hardware Designer.  In DAC, 2016.
  * [21] Rui Qiao and Mark Seaborn.  A New Approach for RowHammer Attacks.  In HOST, 2016.
  * [22] Ferdinand Brasser, Lucas Davi, David Gens, Christopher Liebchen, and Ahmad-Reza Sadeghi.  Can’t Touch This: Software-Only Mitigation Against Rowhammer Attacks Targeting Kernel Memory.  In USENIX Security, 2017.
  * [23] Yeongjin Jang, Jaehyuk Lee, Sangho Lee, and Taesoo Kim.  SGX-Bomb: Locking Down the Processor via Rowhammer Attack.  In SOSP, 2017.
  * [24] Misiker Tadesse Aga, Zelalem Birhanu Aweke, and Todd Austin.  When Good Protections Go Bad: Exploiting Anti-DoS Measures to Accelerate Rowhammer Attacks.  In HOST, 2017.
  * [25] Onur Mutlu.  The RowHammer Problem and Other Issues We May Face as Memory Becomes Denser.  In DATE, 2017.
  * [26] Andrei Tatar, Cristiano Giuffrida, Herbert Bos, and Kaveh Razavi.  Defeating Software Mitigations Against Rowhammer: A Surgical Precision Hammer.  In RAID, 2018.
  * [27] Daniel Gruss, Moritz Lipp, Michael Schwarz, Daniel Genkin, Jonas Juffinger, Sioli O’Connell, Wolfgang Schoechl, and Yuval Yarom.  Another Flip in the Wall of Rowhammer Defenses.  In S&P, 2018.
  * [28] Moritz Lipp, Misiker Tadesse Aga, Michael Schwarz, Daniel Gruss, Clémentine Maurice, Lukas Raab, and Lukas Lamster.  Nethammer: Inducing Rowhammer Faults Through Network Requests.  arXiv:1805.04956 [cs.CR], 2018.
  * [29] Victor van der Veen, Martina Lindorfer, Yanick Fratantonio, Harikrishnan Padmanabha Pillai, Giovanni Vigna, Christopher Kruegel, Herbert Bos, and Kaveh Razavi.  GuardION: Practical Mitigation of DMA-Based Rowhammer Attacks on ARM.  In DIMVA, 2018.
  * [30] Pietro Frigo, Cristiano Giuffrida, Herbert Bos, and Kaveh Razavi.  Grand Pwning Unit: Accelerating Microarchitectural Attacks with the GPU.  In S&P, 2018.
  * [31] Lucian Cojocar, Kaveh Razavi, Cristiano Giuffrida, and Herbert Bos.  Exploiting Correcting Codes: On the Effectiveness of ECC Memory Against Rowhammer Attacks.  In S&P, 2019.
  * [32] Sangwoo Ji, Youngjoo Ko, Saeyoung Oh, and Jong Kim.  Pinpoint Rowhammer: Suppressing Unwanted Bit Flips on Rowhammer Attacks.  In ASIACCS, 2019.
  * [33] Onur Mutlu and Jeremie S Kim.  RowHammer: A Retrospective.  TCAD, 2019.
  * [34] Sanghyun Hong, Pietro Frigo, Yiğitcan Kaya, Cristiano Giuffrida, and Tudor Dumitraş.  Terminal Brain Damage: Exposing the Graceless Degradation in Deep Neural Networks Under Hardware Fault Attacks.  In USENIX Security, 2019.
  * [35] Andrew Kwong, Daniel Genkin, Daniel Gruss, and Yuval Yarom.  RAMBleed: Reading Bits in Memory Without Accessing Them.  In S&P, 2020.
  * [36] Pietro Frigo, Emanuele Vannacci, Hasan Hassan, Victor van der Veen, Onur Mutlu, Cristiano Giuffrida, Herbert Bos, and Kaveh Razavi.  TRRespass: Exploiting the Many Sides of Target Row Refresh.  In S&P, 2020.
  * [37] Lucian Cojocar, Jeremie Kim, Minesh Patel, Lillian Tsai, Stefan Saroiu, Alec Wolman, and Onur Mutlu.  Are We Susceptible to Rowhammer? An End-to-End Methodology for Cloud Providers.  In S&P, 2020.
  * [38] Zane Weissman, Thore Tiemann, Daniel Moghimi, Evan Custodio, Thomas Eisenbarth, and Berk Sunar.  JackHammer: Efficient Rowhammer on Heterogeneous FPGA–CPU Platforms.  arXiv:1912.11523 [cs.CR], 2020.
  * [39] Zhi Zhang, Yueqiang Cheng, Dongxi Liu, Surya Nepal, Zhi Wang, and Yuval Yarom.  PThammer: Cross-User-Kernel-Boundary Rowhammer through Implicit Accesses.  In MICRO, 2020.
  * [40] Fan Yao, Adnan Siraj Rakin, and Deliang Fan.  Deephammer: Depleting the Intelligence of Deep Neural Networks Through Targeted Chain of Bit Flips.  In USENIX Security, 2020.
  * [41] Finn de Ridder, Pietro Frigo, Emanuele Vannacci, Herbert Bos, Cristiano Giuffrida, and Kaveh Razavi.  SMASH: Synchronized Many-Sided Rowhammer Attacks from JavaScript.  In USENIX Security, 2021.
  * [42] Hasan Hassan, Yahya Can Tugrul, Jeremie S. Kim, Victor van der Veen, Kaveh Razavi, and Onur Mutlu.  Uncovering in-DRAM RowHammer Protection Mechanisms: A New Methodology, Custom RowHammer Patterns, and Implications.  In MICRO, 2021.
  * [43] Patrick Jattke, Victor van der Veen, Pietro Frigo, Stijn Gunter, and Kaveh Razavi.  Blacksmith: Scalable Rowhammering in the Frequency Domain.  In S&P, 2022.
  * [44] M Caner Tol, Saad Islam, Berk Sunar, and Ziming Zhang.  Toward Realistic Backdoor Injection Attacks on DNNs using RowHammer.  arXiv:2110.07683, 2022.
  * [45] Andreas Kogler, Jonas Juffinger, Salman Qazi, Yoongu Kim, Moritz Lipp, Nicolas Boichat, Eric Shiu, Mattias Nissler, and Daniel Gruss.  Half-Double: Hammering From the Next Row Over.  In USENIX Security, 2022.
  * [46] Lois Orosa, Ulrich Rührmair, A Giray Yaglikci, Haocong Luo, Ataberk Olgun, Patrick Jattke, Minesh Patel, Jeremie Kim, Kaveh Razavi, and Onur Mutlu.  SpyHammer: Using RowHammer to Remotely Spy on Temperature.  arXiv:2210.04084, 2022.
  * [47] Zhi Zhang, Wei He, Yueqiang Cheng, Wenhao Wang, Yansong Gao, Dongxi Liu, Kang Li, Surya Nepal, Anmin Fu, and Yi Zou.  Implicit Hammer: Cross-Privilege-Boundary Rowhammer through Implicit Accesses.  IEEE TDSC, 2022.
  * [48] Liang Liu, Yanan Guo, Yueqiang Cheng, Youtao Zhang, and Jun Yang.  Generating Robust DNN with Resistance to Bit-Flip based Adversarial Weight Attack.  IEEE TC, 2022.
  * [49] Yaakov Cohen, Kevin Sam Tharayil, Arie Haenel, Daniel Genkin, Angelos D Keromytis, Yossi Oren, and Yuval Yarom.  HammerScope: Observing DRAM Power Consumption Using Rowhammer.  In CCS, 2022.
  * [50] Mengxin Zheng, Qian Lou, and Lei Jiang.  TrojViT: Trojan Insertion in Vision Transformers.  arXiv:2208.13049, 2022.
  * [51] Michael Fahr Jr, Hunter Kippen, Andrew Kwong, Thinh Dang, Jacob Lichtinger, Dana Dachman-Soled, Daniel Genkin, Alexander Nelson, Ray Perlner, Arkady Yerukhimovich, et al.  When Frodo Flips: End-to-End Key Recovery on FrodoKEM via Rowhammer.  CCS, 2022.
  * [52] Youssef Tobah, Andrew Kwong, Ingab Kang, Daniel Genkin, and Kang G. Shin.  SpecHammer: Combining Spectre and Rowhammer for New Speculative Attacks.  In S&P, 2022.
  * [53] Adnan Siraj Rakin, Md Hafizul Islam Chowdhuryy, Fan Yao, and Deliang Fan.  DeepSteal: Advanced Model Extractions Leveraging Efficient Weight Stealing in Memories.  In S&P, 2022.
  * [54] Kyungbae Park, Donghyuk Yun, and Sanghyeon Baeg.  Statistical Distributions of Row-Hammering Induced Failures in DDR3 Components.  Microelectronics Reliability, 2016.
  * [55] Kyungbae Park, Chulseung Lim, Donghyuk Yun, and Sanghyeon Baeg.  Experiments and Root Cause Analysis for Active-Precharge Hammering Fault in DDR3 SDRAM under 3xnm Technology.  Microelectronics Reliability, 2016.
  * [56] Chulseung Lim, Kyungbae Park, and Sanghyeon Baeg.  Active Precharge Hammering to Monitor Displacement Damage Using High-Energy Protons in 3x-nm SDRAM.  TNS, 2017.
  * [57] Seong-Wan Ryu, Kyungkyu Min, Jungho Shin, Heimi Kwon, Donghoon Nam, Taekyung Oh, Tae-Su Jang, Minsoo Yoo, Yongtaik Kim, and Sungjoo Hong.  Overcoming the Reliability Limitation in the Ultimately Scaled DRAM using Silicon Migration Technique by Hydrogen Annealing.  In IEDM, 2017.
  * [58] Donghyuk Yun, Myungsang Park, Chulseung Lim, and Sanghyeon Baeg.  Study of TID Effects on One Row Hammering using Gamma in DDR4 SDRAMs.  In IRPS, 2018.
  * [59] Thomas Yang and Xi-Wei Lin.  Trap-Assisted DRAM Row Hammer Effect.  EDL, 2019.
  * [60] Andrew J. Walker, Sungkwon Lee, and Dafna Beery.  On DRAM RowHammer and the Physics on Insecurity.  IEEE TED, 2021.
  * [61] Jeremie S. Kim, Minesh Patel, Abdullah Giray Yağlıkçı, Hasan Hassan, Roknoddin Azizi, Lois Orosa, and Onur Mutlu.  Revisiting RowHammer: An Experimental Analysis of Modern Devices and Mitigation Techniques.  In ISCA, 2020.
  * [62] Lois Orosa, A Giray Yağlıkçı, Haocong Luo, Ataberk Olgun, Jisung Park, Hasan Hassan, Minesh Patel, Jeremie S. Kim, and Onur Mutlu.  A Deeper Look into RowHammer’s Sensitivities: Experimental Analysis of Real DRAM Chips and Implications on Future Attacks and Defenses.  In MICRO, 2021.
  * [63] A. Giray Yağlıkcı, Haocong Luo, Geraldo F De Oliviera, Ataberk Olgun, Minesh Patel, Jisung Park, Hasan Hassan, Jeremie S Kim, Lois Orosa, and Onur Mutlu.  Understanding RowHammer Under Reduced Wordline Voltage: An Experimental Study Using Real DRAM Devices.  In DSN, 2022.
  * [64] Mohammad Nasim Imtiaz Khan and Swaroop Ghosh.  Analysis of Row Hammer Attack on STTRAM.  In ICCD, 2018.
  * [65] S. Agarwal, H. Dixit, D. Datta, M. Tran, D. Houssameddine, D. Shum, and F. Benistant.  Rowhammer for Spin Torque based Memory: Problem or not?  In INTERMAG, 2018.
  * [66] Haitong Li, Hong-Yu Chen, Zhe Chen, Bing Chen, Rui Liu, Gang Qiu, Peng Huang, Feifei Zhang, Zizhen Jiang, Bin Gao, Lifeng Liu, Xiaoyan Liu, Shimeng Yu, H.-S. Philip Wong, and Jinfeng Kang.  Write Disturb Analyses on Half-Selected Cells of Cross-Point RRAM Arrays.  In IRPS, 2014.
  * [67] Kai Ni, Xueqing Li, Jeffrey A. Smith, Matthew Jerry, and Suman Datta.  Write Disturb in Ferroelectric FETs and Its Implication for 1T-FeFET AND Memory Arrays.  IEEE EDL, 2018.
  * [68] Paul R. Genssler, Victor M. van Santen, Jörg Henkel, and Hussam Amrouch.  On the Reliability of FeFET On-Chip Memory.  TC, 2022.
  * [69] Onur Mutlu, Ataberk Olgun, and A. Giray Yaglikci.  Fundamentally Understanding and Solving RowHammer.  In ASP-DAC, 2023.
  * [70] Hakan Aydin and Ahmet Sertbaş.  Cyber Security in Industrial Control Systems (ICS): A Survey of RowHammer Vulnerability.  Applied Computer Science, 2022.
  * [71] Koksal Mus, Yarkın Doröz, M Caner Tol, Kristi Rahman, and Berk Sunar.  Jolt: Recovering TLS Signing Keys via Rowhammer Faults.  Cryptology ePrint Archive, 2022.
  * [72] Jianxin Wang, Hongke Xu, Chaoen Xiao, Lei Zhang, and Yuzheng Zheng.  Research and Implementation of Rowhammer Attack Method based on Domestic NeoKylin Operating System.  In ICFTIC, 2022.
  * [73] Sam Lefforge.  Reverse Engineering Post-Quantum Cryptography Schemes to Find Rowhammer Exploits.  Master’s thesis, University of Arkansas, 2023.
  * [74] Michael J Fahr.  The Effects of Side-Channel Attacks on Post-Quantum Cryptography: Influencing FrodoKEM Key Generation Using the Rowhammer Exploit.  PhD thesis, University of Arkansas, 2022.
  * [75] Anandpreet Kaur, Pravin Srivastav, and Bibhas Ghoshal.  Work-in-Progress: DRAM-MaUT: DRAM Address Mapping Unveiling Tool for ARM Devices.  In CASES, 2022.
  * [76] Kunbei Cai, Zhenkai Zhang, and Fan Yao.  On the Feasibility of Training-time Trojan Attacks through Hardware-based Faults in Memory.  In HOST, 2022.
  * [77] Dawei Li, Di Liu, Yangkun Ren, Ziyi Wang, Yu Sun, Zhenyu Guan, Qianhong Wu, and Jianwei Liu.  CyberRadar: A PUF-based Detecting and Mapping Framework for Physical Devices.  arXiv:2201.07597, 2022.
  * [78] Arman Roohi and Shaahin Angizi.  Efficient Targeted Bit-Flip Attack Against the Local Binary Pattern Network.  In HOST, 2022.
  * [79] Felix Staudigl, Hazem Al Indari, Daniel Schön, Dominik Sisejkovic, Farhad Merchant, Jan Moritz Joseph, Vikas Rana, Stephan Menzel, and Rainer Leupers.  NeuroHammer: Inducing Bit-Flips in Memristive Crossbar Memories.  In DATE, 2022.
  * [80] Li-Hsing Yang, Shin-Shan Huang, Tsai-Ling Cheng, Yi-Ching Kuo, and Jian-Jhih Kuo.  Socially-Aware Collaborative Defense System against Bit-Flip Attack in Social Internet of Things and Its Online Assignment Optimization.  In ICCCN, 2022.
  * [81] Saad Islam, Koksal Mus, Richa Singh, Patrick Schaumont, and Berk Sunar.  Signature Correction Attack on Dilithium Signature Scheme.  In Euro S&P, 2022.
  * [82] 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.  RowPress: Amplifying Read Disturbance in Modern DRAM Chips.  In Proceedings of the 50th Annual International Symposium on Computer Architecture, 2023.
  * [83] A Giray Yağlıkçı, Minesh Patel, Jeremie S. Kim, Roknoddin Azizibarzoki, Ataberk Olgun, Lois Orosa, Hasan Hassan, Jisung Park, Konstantinos Kanellopoullos, Taha Shahroodi, Saugata Ghose, and Onur Mutlu.  BlockHammer: Preventing RowHammer at Low Cost by Blacklisting Rapidly-Accessed DRAM Rows.  In HPCA, 2021.
  * [84] Yeonhong Park, Woosuk Kwon, Eojin Lee, Tae Jun Ham, Jung Ho Ahn, and Jae W Lee.  Graphene: Strong yet Lightweight Row Hammer Protection.  In MICRO, 2020.
  * [85] A Giray Yağlikci, Ataberk Olgun, Minesh Patel, Haocong Luo, Hasan Hassan, Lois Orosa, Oğuz Ergin, and Onur Mutlu.  HiRA: Hidden Row Activation for Reducing Refresh Latency of Off-the-Shelf DRAM Chips.  In MICRO, 2022.
  * [86] Arthur De Graauw.  Ancient Port Structures. Parallels between the Ancient and the Modern.  Méditerranée. Revue géographique des pays méditerranéens/Journal of Mediterranean geography, 2022.
  * [87] Eojin Lee, Ingab Kang, Sukhan Lee, G Edward Suh, and Jung Ho Ahn.  TWiCe: Preventing Row-Hammering by Exploiting Time Window Counters.  In ISCA, 2019.
  * [88] Anish Saxena, Gururaj Saileshwar, Prashant J. Nair, and Moinuddin Qureshi.  AQUA: Scalable Rowhammer Mitigation by Quarantining Aggressor Rows at Runtime.  In MICRO, 2022.
  * [89] Moinuddin Qureshi, Aditya Rohan, Gururaj Saileshwar, and Prashant J Nair.  Hydra: Enabling Low-Overhead Mitigation of Row-Hammer at Ultra-Low Thresholds via Hybrid Tracking.  In ISCA, 2022.
  * [90] Michele Marazzi, Flavien Solt, Patrick Jattke, Kubo Takashi, and Kaveh Razavi.  REGA: Scalable Rowhammer Mitigation with Refresh-Generating Activations.  In S&P, 2023.
  * [91] Tanj Bennett, Stefan Saroiu, Alec Wolman, and Lucian Cojocar.  Panopticon: A Complete In-DRAM Rowhammer Mitigation.  In DRAMSec, 2021.
  * [92] Fabrice Devaux and Renaud Ayrignac.  Method and Circuit for Protecting a DRAM Memory Device from the Row Hammer Effect.  US Patent: 10,885,966, 2021.
  * [93] A. Giray Yağlıkçı, Jeremie S. Kim, Fabrice Devaux, and Onur Mutlu.  Security Analysis of the Silver Bullet Technique for RowHammer Prevention.  arXiv:2106.07084, 2021.
  * [94] Rajeev Balasubramonian, Andrew B. Kahng, Naveen Muralimanohar, Ali Shafiee, and Vaishnav Srinivas.  CACTI: An integrated cache and memory access time, cycle time, area, leakage, and dynamic power model.  https://www.hpl.hp.com/research/cacti/, 2017.
  * [95] Synopsys, Inc.  Synopsys Design Compiler.  https://www.synopsys.com/support/training/rtl-synthesis/design-compiler-rtl-synthesis.html.
  * [96] JEDEC.  JESD79-4C: DDR4 SDRAM Standard, 2020.
  * [97] JEDEC.  JESD79-5: DDR5 SDRAM Standard, 2020.
  * [98] Michael Redeker, Bruce F Cockburn, and Duncan G Elliott.  An Investigation into Crosstalk Noise in DRAM Structures.  In MTDT, 2002.
  * [99] Kyungbae Park, Sanghyeon Baeg, ShiJie Wen, and Richard Wong.  Active-Precharge Hammering on a Row-Induced Failure in DDR3 SDRAMs Under 3x nm Technology.  In IIRW, 2014.
  * [100] Chia Yang, Chen Kang Wei, Yu Jing Chang, Tieh Chiang Wu, Hsiu Pin Chen, and Chao Sung Lai.  Suppression of RowHammer Effect by Doping Profile Modification in Saddle-Fin Array Devices for Sub-30-nm DRAM Technology.  TDMR, 2016.
  * [101] Chia-Ming Yang, Chen-Kang Wei, Hsiu-Pin Chen, Jian-Shing Luo, Yu Jing Chang, Tieh-Chiang Wu, and Chao-Sung Lai.  Scanning Spreading Resistance Microscopy for Doping Profile in Saddle-Fin Devices.  IEEE Transactions on Nanotechnology, 2017.
  * [102] Chulseung Lim, Kyungbae Park, Geunyong Bak, Donghyuk Yun, Myungsang Park, Sanghyeon Baeg, Shi-Jie Wen, and Richard Wong.  Study of Proton Radiation Effect to Row Hammer Fault in DDR4 SDRAMs.  Microelectronics Reliability, 2018.
  * [103] SK Gautam, SK Manhas, Arvind Kumar, Mahendra Pakala, and Ellie Yieh.  Row Hammering Mitigation Using Metal Nanowire in Saddle Fin DRAM.  IEEE TED, 2019.
  * [104] Yichen Jiang, Huifeng Zhu, Dean Sullivan, Xiaolong Guo, Xuan Zhang, and Yier Jin.  Quantifying RowHammer Vulnerability for DRAM Security.  In DAC, 2021.
  * [105] Wei He, Zhi Zhang, Yueqiang Cheng, Wenhao Wang, Wei Song, Yansong Gao, Qifei Zhang, Kang Li, Dongxi Liu, and Surya Nepal.  WhistleBlower: A System-level Empirical Study on RowHammer.  IEEE Transactions on Computers, 2023.
  * [106] Sanghyeon Baeg, Donghyuk Yun, Myungsun Chun, and Shi-Jie Wen.  Estimation of the Trap Energy Characteristics of Row Hammer-Affected Cells in Gamma-Irradiated DDR4 DRAM.  IEEE Transactions on Nuclear Science, 2022.
  * [107] Onur Mutlu.  RowHammer.  https://people.inf.ethz.ch/omutlu/pub/onur-Rowhammer-TopPicksinHardwareEmbeddedSecurity-November-8-2018.pdf, 2018.
  * [108] Ataberk Olgun, Majd Osseiran, Abdullah Giray Yaglikci, Yahya Can Tugrul, Haocong Luo, Steve Rhyner, Behzad Salami, Juan Gomez Luna, and Onur Mutlu.  An Experimental Analysis of RowHammer in HBM2 DRAM Chips.  In DSN Disrupt, 2023.
  * [109] Ataberk Olgun, Hasan Hassan, A. Giray Yağlıkcı, Yahya Can Tuğrul, Lois Orosa, Haocong Luo, Minesh Patel, Ergin Oğuz, and Onur Mutlu.  DRAM Bender: An Extensible and Versatile FPGA-based Infrastructure to Easily Test State-of-the-art DRAM Chips.  TCAD, 2023.
  * [110] Longda Zhou, Jie Li, Zheng Qiao, Pengpeng Ren, Zixuan Sun, Jianping Wang, Blacksmith Wu, Zhigang Ji, Runsheng Wang, Kanyu Cao, and Ru Huang.  Double-sided Row Hammer Effect in Sub-20 nm DRAM: Physical Mechanism, Key Features and Mitigation.  In IRPS, 2023.
  * [111] Zhenrong Lang, Patrick Jattke, Michele Marazzi, and Kaveh Razavi.  Blaster: Characterizing the blast radius of rowhammer.  In 3rd Workshop on DRAM Security (DRAMSec) co-located with ISCA 2023. ETH Zurich, 2023.
  * [112] Apple Inc.  About the Security Content of Mac EFI Security Update 2015-001.  https://support.apple.com/en-us/HT204934, 2015.
  * [113] Hewlett-Packard Enterprise.  HP Moonshot Component Pack Version 2015.05.0, 2015.
  * [114] Lenovo Group Ltd.  Row Hammer Privilege Escalation, 2015.
  * [115] Zvika Greenfield and Tomer Levy.  Throttling Support for Row-Hammer Counters, 2016.
  * [116] Dae-Hyun Kim, Prashant J Nair, and Moinuddin K Qureshi.  Architectural Support for Mitigating Row Hammering in DRAM Memories.  CAL, 2014.
  * [117] Barbara Aichinger.  DDR Memory Errors Caused by Row Hammer.  In HPEC, 2015.
  * [118] Zelalem Birhanu Aweke, Salessawi Ferede Yitbarek, Rui Qiao, Reetuparna Das, Matthew Hicks, Yossi Oren, and Todd Austin.  ANVIL: Software-Based Protection Against Next-Generation Rowhammer Attacks.  In ASPLOS, 2016.
  * [119] K. Bains et al.  Row Hammer Refresh Command.  US Patents: 9,117,544 9,236,110 10,210,925, 2015.
  * [120] Kuljit Bains, John Halbert, Christopher Mozak, Theodore Schoenborn, and Zvika Greenfield.  Row Hammer Refresh Command, 2015.
  * [121] Kuljit S Bains and John B Halbert.  Distributed Row Hammer Tracking, 2016.
  * [122] Kuljit S Bains and John B Halbert.  Row Hammer Monitoring Based on Stored Row Hammer Threshold Value.  US Patent: 10,083,737, 2016.
  * [123] H. Gomez, A. Amaya, and E. Roa.  DRAM row-hammer attack reduction using dummy cells.  In NORCAS, 2016.
  * [124] Mungyu Son, Hyunsun Park, Junwhan Ahn, and Sungjoo Yoo.  Making DRAM Stronger Against Row Hammering.  In DAC, 2017.
  * [125] S. M. Seyedzadeh, A. K. Jones, and R. Melhem.  Mitigating Wordline Crosstalk Using Adaptive Trees of Counters.  In ISCA, 2018.
  * [126] Gorka Irazoqui, Thomas Eisenbarth, and Berk Sunar.  MASCAT: Stopping Microarchitectural Attacks Before Execution.  IACR Cryptology, 2016.
  * [127] Jung Min You and Joon-Sung Yang.  MRLoc: Mitigating Row-Hammering Based on Memory Locality.  In DAC, 2019.
  * [128] Ingab Kang, Eojin Lee, and Jung Ho Ahn.  CAT-TWO: Counter-Based Adaptive Tree, Time Window Optimized for DRAM Row-Hammer Prevention.  IEEE Access, 2020.
  * [129] Gururaj Saileshwar, Bolin Wang, Moinuddin Qureshi, and Prashant J Nair.  Randomized Row-Swap: Mitigating Row Hammer by Breaking Spatial Correlation Between Aggressor and Victim Rows.  In ASPLOS, 2022.
  * [130] Radhesh Krishnan Konoth, Marco Oliverio, Andrei Tatar, Dennis Andriesse, Herbert Bos, Cristiano Giuffrida, and Kaveh Razavi.  ZebRAM: Comprehensive and Compatible Software Protection Against Rowhammer Attacks.  In OSDI, 2018.
  * [131] Saru Vig, Sarani Bhattacharya, Debdeep Mukhopadhyay, and Siew-Kei Lam.  Rapid Detection of Rowhammer Attacks Using Dynamic Skewed Hash Tree.  In HASP, 2018.
  * [132] H. Hassan, M. Patel, J. S. Kim, A. G. Yağlıkçı, N. Vijaykumar, N. Mansouri Ghiasi, S. Ghose, and O. Mutlu.  CROW: A Low-Cost Substrate for Improving DRAM Performance, Energy Efficiency, and Reliability.  In ISCA, 2019.
  * [133] Michael Jaemin Kim, Jaehyun Park, Yeonhong Park, Wanju Doh, Namhoon Kim, Tae Jun Ham, Jae W Lee, and Jung Ho Ahn.  Mithril: Cooperative Row Hammer Protection on Commodity DRAM Leveraging Managed Refresh.  In HPCA, 2022.
  * [134] Gyu-Hyeon Lee, Seongmin Na, Ilkwon Byun, Dongmoon Min, and Jangwoo Kim.  CryoGuard: A Near Refresh-Free Robust DRAM Design for Cryogenic Computing.  In ISCA, 2021.
  * [135] Michele Marazzi, Patrick Jattke, Flavien Solt, and Kaveh Razavi.  ProTRR: Principled yet Optimal In-DRAM Target Row Refresh.  In S&P, 2022.
  * [136] Zhi Zhang, Yueqiang Cheng, Minghua Wang, Wei He, Wenhao Wang, Surya Nepal, Yansong Gao, Kang Li, Zhe Wang, and Chenggang Wu.  SoftTRR: Protect Page Tables against Rowhammer Attacks using Software-only Target Row Refresh.  In USENIX ATC, 2022.
  * [137] Biresh Kumar Joardar, Tyler K Bletsch, and Krishnendu Chakrabarty.  Learning to Mitigate RowHammer Attacks.  In DATE, 2022.
  * [138] Jonas Juffinger, Lukas Lamster, Andreas Kogler, Maria Eichlseder, Moritz Lipp, and Daniel Gruss.  CSI: Rowhammer–Cryptographic Security and Integrity against Rowhammer (to appear).  In S&P, 2023.
  * [139] Shuhei Enomoto, Hiroki Kuzuno, and Hiroshi Yamada.  Efficient Protection Mechanism for CPU Cache Flush Instruction Based Attacks.  IEICE Transactions on Information and Systems, 2022.
  * [140] Evgeny Manzhosov, Adam Hastings, Meghna Pancholi, Ryan Piersma, Mohamed Tarek Ibn Ziad, and Simha Sethumadhavan.  Revisiting Residue Codes for Modern Memories.  In MICRO, 2022.
  * [141] Samira Mirbagher Ajorpaz, Daniel Moghimi, Jeffrey Neal Collins, Gilles Pokam, Nael Abu-Ghazaleh, and Dean Tullsen.  EVAX: Towards a Practical, Pro-active & Adaptive Architecture for High Performance & Security.  In MICRO, 2022.
  * [142] Amir Naseredini, Martin Berger, Matteo Sammartino, and Shale Xiong.  ALARM: Active LeArning of Rowhammer Mitigations.  https://users.sussex.ac.uk/~mfb21/rh-draft.pdf, 2022.
  * [143] Biresh Kumar Joardar, Tyler K. Bletsch, and Krishnendu Chakrabarty.  Machine Learning-based Rowhammer Mitigation.  TCAD, 2022.
  * [144] Hasan Hassan, Ataberk Olgun, A Giray Yaglikci, Haocong Luo, and Onur Mutlu.  A Case for Self-Managing DRAM Chips: Improving Performance, Efficiency, Reliability, and Security via Autonomous in-DRAM Maintenance Operations.  arXiv:2207.13358, 2022.
  * [145] Zhenkai Zhang, Zihao Zhan, Daniel Balasubramanian, Bo Li, Peter Volgyesi, and Xenofon Koutsoukos.  Leveraging EM Side-Channel Information to Detect Rowhammer Attacks.  In S&P, 2020.
  * [146] Kevin Loughlin, Stefan Saroiu, Alec Wolman, and Baris Kasikci.  Stop! Hammer Time: Rethinking Our Approach to Rowhammer Mitigations.  In HotOS, 2021.
  * [147] Jin Han, Jungsik Kim, Dafna Beery, K Deniz Bozdag, Peter Cuevas, Amitay Levi, Irwin Tain, Khai Tran, Andrew J Walker, Senthil Vadakupudhu Palayam, et al.  Surround Gate Transistor With Epitaxially Grown Si Pillar and Simulation Study on Soft Error and Rowhammer Tolerance for DRAM.  TED, 2021.
  * [148] Ali Fakhrzadehgan, Yale N. Patt, Prashant J. Nair, and Moinuddin K. Qureshi.  SafeGuard: Reducing the Security Risk from Row-Hammer via Low-Cost Integrity Protection.  In HPCA, 2022.
  * [149] Stefan Saroiu, Alec Wolman, and Lucian Cojocar.  The Price of Secrecy: How Hiding Internal DRAM Topologies Hurts Rowhammer Defenses.  In IRPS, 2022.
  * [150] Stefan Saroiu and Alec Wolman.  How to Configure Row-Sampling-Based Rowhammer Defenses.  DRAMSec, 2022.
  * [151] Kevin Loughlin, Stefan Saroiu, Alec Wolman, Yatin A. Manerkar, and Baris Kasikci.  MOESI-Prime: Preventing Coherence-Induced Hammering in Commodity Workloads.  In ISCA, 2022.
  * [152] Ranyang Zhou, Sepehr Tabrizchi, Arman Roohi, and Shaahin Angizi.  LT-PIM: An LUT-Based Processing-in-DRAM Architecture With RowHammer Self-Tracking.  IEEE CAL, 2022.
  * [153] Seungki Hong, Dongha Kim, Jaehyung Lee, Reum Oh, Changsik Yoo, Sangjoon Hwang, and Jooyoung Lee.  DSAC: Low-Cost Rowhammer Mitigation Using In-DRAM Stochastic and Approximate Counting Algorithm.  arXiv:2302.03591, 2023.
  * [154] Andrea Di Dio, Koen Koning, Herbert Bos, and Cristiano Giuffrida.  Copy-on-Flip: Hardening ECC Memory Against Rowhammer Attacks.  In NDSS, 2023.
  * [155] Sonia Sharma, Debdeep Sanyal, Arpit Mukhopadhyay, and Ramij Hasan Shaik.  A Review on Study of Defects of DRAM-RowHammer and Its Mitigation.  Journal For Basic Sciences, 2022.
  * [156] Jeonghyun Woo, Gururaj Saileshwar, and Prashant J Nair.  Scalable and Secure Row-Swap: Efficient and Safe Row Hammer Mitigation in Memory Systems.  In HPCA, 2023.
  * [157] Jin Hyo Park, Su Yeon Kim, Dong Young Kim, Geon Kim, Je Won Park, Sunyong Yoo, Young-Woo Lee, and Myoung Jin Lee.  RowHammer Reduction Using a Buried Insulator in a Buried Channel Array Transistor.  IEEE Transactions on Electron Devices, 2022.
  * [158] Minbok Wi, Jaehyun Park, Seoyoung Ko, Michael Jaemin Kim, Nam Sung Kim, Eojin Lee, and Jung Ho Ahn.  SHADOW: Preventing Row Hammer in DRAM with Intra-Subarray Row Shuffling.  In HPCA, 2023.
  * [159] Woongrae Kim, Chulmoon Jung, Seongnyuh Yoo, Duckhwa Hong, Jeongjin Hwang, Jungmin Yoon, Ohyong Jung, Joonwoo Choi, Sanga Hyun, Mankeun Kang, et al.  A 1.1 V 16Gb DDR5 DRAM with Probabilistic-Aggressor Tracking, Refresh-Management Functionality, Per-Row Hammer Tracking, a Multi-Step Precharge, and Core-Bias Modulation for Security and Reliability Enhancement.  In ISSCC, 2023.
  * [160] C Gude Ramarao, K Tejesh Kumar, G Ujjinappa, and B Vasu Deva Naidu.  Defending SoCs with FPGAs from Rowhammer Attacks.  Material Science, 2023.
  * [161] Krishnendu Guha and Amlan Chakrabarti.  Criticality based Reliability from Rowhammer Attacks in Multi-User-Multi-FPGA Platform.  In VLSID, 2022.
  * [162] Loïc France, Florent Bruguier, Maria Mushtaq, David Novo, and Pascal Benoit.  Modeling Rowhammer in the gem5 Simulator.  In CHES 2022-Conference on Cryptographic Hardware and Embedded Systems, 2022.
  * [163] Loïc France, Florent Bruguier, David Novo, Maria Mushtaq, and Pascal Benoit.  Reducing the Silicon Area Overhead of Counter-Based Rowhammer Mitigations.  In 18th CryptArchi Workshop, 2022.
  * [164] Kerem Arıkan, Alessandro Palumbo, Luca Cassano, Pedro Reviriego, Salvatore Pontarelli, Giuseppe Bianchi, Oğuz Ergin, and Marco Ottavi.  Processor security: Detecting microarchitectural attacks via count-min sketches.  VLSI, 2022.
  * [165] Chihiro Tomita, Makoto Takita, Kazuhide Fukushima, Yuto Nakano, Yoshiaki Shiraishi, and Masakatu Morii.  Extracting the Secrets of OpenSSL with RAMBleed.  Sensors, 2022.
  * [166] Anish Saxena, Gururaj Saileshwar, Jonas Juffinger, Andreas Kogler, Daniel Gruss, and Moinuddin Qureshi.  PT-Guard: Integrity-Protected Page Tables to Defend Against Breakthrough Rowhammer Attacks.  In DSN, 2023.
  * [167] Ranyang Zhou, Sabbir Ahmed, Adnan Siraj Rakin, and Shaahin Angizi.  DNN-Defender: An in-DRAM Deep Neural Network Defense Mechanism for Adversarial Weight Attack.  arXiv:2305.08034, 2023.
  * [168] Seyed Mohammad Seyedzadeh, Alex K. Jones, and Rami Melhem.  Counter-Based Tree Structure for Row Hammering Mitigation in DRAM.  CAL, 2017.
  * [169] Jayadev Misra and David Gries.  Finding Repeated Elements.  Science of Computer Programming, 1982.
  * [170] Zhaogeng Li, Jun Bi, Sen Wang, and Xiaoke Jiang.  Compression of Pending Interest Table with Bloom Filter in Content Centric Network.  In CFI, 2012.
  * [171] Hiroyuki Usui, Lavanya Subramanian, Kevin Kai-Wei Chang, and Onur Mutlu.  DASH: Deadline-Aware High-Performance Memory Scheduler for Heterogeneous Systems with Hardware Accelerators.  TACO, 2016.
  * [172] Yoongu Kim, Michael Papamichael, Onur Mutlu, and Mor Harchol-Balter.  Thread Cluster Memory Scheduling: Exploiting Differences in Memory Access Behavior.  In MICRO, 2010.
  * [173] Lavanya Subramanian, Donghyuk Lee, Vivek Seshadri, Harsha Rastogi, and Onur Mutlu.  The Blacklisting Memory Scheduler: Achieving High Performance and Fairness at Low Cost.  In ICCD, 2014.
  * [174] Yoongu Kim, Dongsu Han, Onur Mutlu, and Mor Harchol-Balter.  ATLAS: A Scalable and High-Performance Scheduling Algorithm for Multiple Memory Controllers.  In HPCA, 2010.
  * [175] K. J. Nesbit, N. Aggarwal, J. Laudon, and J. E. Smith.  Fair Queuing Memory Systems.  In International Symposium on Microarchitecture (MICRO-39), 2006.
  * [176] Rachata Ausavarungnirun, Kevin Kai-Wei Chang, Lavanya Subramanian, Gabriel H Loh, and Onur Mutlu.  Staged Memory Scheduling: Achieving High Performance and Scalability in Heterogeneous Systems.  In ISCA, 2012.
  * [177] Intel Inc.  3rd Gen Intel Xeon Scalable Processors.  https://www.intel.com/content/dam/www/public/us/en/documents/a1171486-icelake-productbrief-updates-r1v2.pdf.
  * [178] SAFARI Research Group.  Ramulator V2.0.  https://github.com/CMU-SAFARI/ramulator2.
  * [179] Haocong Luo, Yahya Can Tuğrul, F. Nisa Bostancı, Ataberk Olgun, A. Giray Yağlıkçı, , and Onur Mutlu.  Ramulator 2.0: A Modern, Modular, and Extensible DRAM Simulator, 2023.
  * [180] Scott Rixner et al.  Memory Access Scheduling.  In ISCA, 2000.
  * [181] Scott Rixner, William J. Dally, Ujval J. Kapasi, Peter Mattson, and John D. Owens.  Memory Access Scheduling.  In ISCA, 2000.
  * [182] William K Zuravleff and Timothy Robinson.  Controller for a Synchronous DRAM That Maximizes Throughput by Allowing Memory Requests and Commands to Be Issued Out of Order, 1997.
  * [183] Dimitris Kaseridis, Jeffrey Stuecheli, and Lizy Kurian John.  Minimalist Open-Page: A DRAM Page-Mode Scheduling Policy for the Many-Core Era.  In MICRO, 2011.
  * [184] Woongrae Kim, Chulmoon Jung, Seongnyuh Yoo, Duckhwa Hong, Jeongjin Hwang, Jungmin Yoon, Ohyong Jung, Joonwoo Choi, Sanga Hyun, Mankeun Kang, et al.  A 1.1 v 16gb ddr5 dram with probabilistic-aggressor tracking, refresh-management functionality, per-row hammer tracking, a multi-step precharge, and core-bias modulation for security and reliability enhancement.  In 2023 IEEE International Solid-State Circuits Conference (ISSCC), pages 1–3. IEEE, 2023.
  * [185] Standard Performance Evaluation Corp.  SPEC CPU 2006.  http://www.spec.org/cpu2006/.
  * [186] Standard Performance Evaluation Corp.  SPEC CPU2017 Benchmarks.  http://www.spec.org/cpu2017/.
  * [187] Transaction Processing Performance Council.
  * [188] Jason E. Fritts, Frederick W. Steiling, Joseph A. Tucek, and Wayne Wolf.  MediaBench II Video: Expediting the next Generation of Video Systems Research.  Microprocess. Microsyst., 2009.
  * [189] Brian Cooper, Adam Silberstein, Erwin Tam, Raghu Ramakrishnan, and Russell Sears.  Benchmarking Cloud Serving Systems with YCSB.  In SoCC, 2010.
  * [190] Karthik Chandrasekar, Christian Weis, Yonghui Li, Sven Goossens, Matthias Jung, Omar Naji, Benny Akesson, Norbert Wehn, and Kees Goossens.  DRAMPower: Open-Source DRAM Power & Energy Estimation Tool.  http://www.drampower.info/.
  * [191] Yicheng Wang, Yang Liu, Peiyun Wu, and Zhao Zhang.  Discreet-PARA: Rowhammer Defense with Low Cost and High Efficiency.  In 2021 IEEE 39th International Conference on Computer Design (ICCD), 2021.
  * [192] Dae-Hyun Kim, Prashant J Nair, and Moinuddin K Qureshi.  Architectural Support for Mitigating Row Hammering in DRAM Memories.  CAL, 2015.
  * [193] Jeonghyun Woo, Gururaj Saileshwar, and Prashant J. Nair.  Scalable and Secure Row-Swap: Efficient and Safe Row Hammer Mitigation in Memory Systems.  2022\.
  * [194] Thomas Moscibroda and Onur Mutlu.  Memory Performance Attacks: Denial of Memory Service in Multi-Core Systems.  In USENIX Security, 2007.
  * [195] Onur Mutlu and Thomas Moscibroda.  Stall-Time Fair Memory Access Scheduling for Chip Multiprocessors.  In MICRO, 2007.
  * [196] Onur Mutlu and Thomas Moscibroda.  Parallelism-Aware Batch Scheduling: Enhancing Both Performance and Fairness of Shared DRAM Systems.  In ISCA, 2008.
  * [197] Kevin KaiWei Chang, Rachata Ausavarungnirun, Chris Fallin, and Onur Mutlu.  HAT: Heterogeneous Adaptive Throttling for On-Chip Networks.  In SBAC-PAD, 2012.
  * [198] Eiman Ebrahimi, Chang Joo Lee, Onur Mutlu, and Yale N Patt.  Fairness via Source Throttling: A Configurable and High-Performance Fairness Substrate for Multi-Core Memory Systems.  In ASPLOS, 2010.
  * [199] Eiman Ebrahimi, Chang Joo Lee, Onur Mutlu, and Yale N. Patt.  Prefetch-Aware Shared Resource Management for Multi-Core Systems.  In ISCA, 2011.
  * [200] Eiman Ebrahimi, Chang Joo Lee, Onur Mutlu, and Yale N. Patt.  Fairness via Source Throttling: A Configurable and High Performance Fairness Substrate for Multi Core Memory Systems.  In ASPLOS, 2010.
  * [201] Eiman Ebrahimi, Rustam Miftakhutdinov, Chris Fallin, Chang Joo Lee, José A Joao, Onur Mutlu, and Yale N Patt.  Parallel Application Memory Scheduling.  In MICRO, 2011.
  * [202] Zhi Zhang, Yueqiang Cheng, Dongxi Liu, Surya Nepal, and Zhi Wang.  TeleHammer: A Stealthy Cross-Boundary Rowhammer Technique.  arXiv:1912.03076 [cs.CR], 2019.
  * [203] Timothy J Dell.  A White Paper on the Benefits of Chipkill-Correct ECC for PC Server Main Memory.  IBM Microelectronics Division, 1997.
  * [204] Ruirui Huang and G. Edward Suh.  IVEC: Off-Chip Memory Integrity Protection for Both Security and Reliability.  In ISCA, 2010.
  * [205] Gururaj Saileshwar, Prashant J. Nair, Prakash Ramrakhyani, Wendy Elsasser, and Moinuddin K. Qureshi.  SYNERGY: Rethinking Secure-Memory Design for Error-Correcting Memories.  In HPCA, 2018.
  * [206] Long Chen and Zhao Zhang.  MemGuard: A low cost and energy efficient design to support and enhance memory system reliability.  In ISCA, 2014.
  * [207] Moinuddin Qureshi.  Rethinking ECC in the Era of Row-Hammer.  DRAMSec, 2021.