such as: How prevalent are aging-related failures? What types of usage
accelerate aging? How can we design architectural techniques that can slow
down the aging process?

Third, prior works show that the failure rate of DRAM modules in large data
centers is significant, largely affecting the cost and downtime in data
centers [197, 272, 196, 302]. Unfortunately, there is no study that analyzes
DRAM modules that have failed in the field to determine the common causes of
failure. Our SoftMC infrastructure can test faulty DRAM modules and help
answer various research questions: What are the dominant types of DRAM
failures at runtime? Are failures correlated to any location or specific
structure in DRAM? Do all chips from the same generation exhibit the same
failure characteristics?

Characterization of Non-Volatile Memory. The SoftMC infrastructure can test
any chip compatible with the DDR interface. Such a design makes the scope of
the chips that can be tested by SoftMC go well beyond just DRAM. With the
emergence of byte addressable non-volatile memories (e.g., PCM [303, 304, 305,
304], STT-RAM [306, 307], ReRAM [308, 309]), several vendors are working
towards manufacturing DDR-compatible non-volatile memory chips at a large
scale [310, 311]. When these chips become commercially available, it will be
critical to characterize and analyze them in order to understand, exploit,
and/or correct their behavior. We believe that SoftMC can be seamlessly used
to characterize these chips, and can help enable future mechanisms for NVM.

SoftMC will hopefully enable other works that build on it in various ways. For
example, future work can extend the infrastructure to enable researchers to
analyze memory scheduling (e.g., [173, 172, 312, 170, 171, 313, 314]) and
memory power management [292, 315] mechanisms, and allow them to develop new
mechanisms using a programmable memory controller and real workloads. We
conclude that characterization with SoftMC enables a wide range of research
directions in DDR-compatible memory chips (DRAM or NVM), leading to better
understanding of these technologies and helping to develop mechanisms that
improve the reliability and performance of future memory systems.

###  3.7 Other Related Work

Although no prior work provides an open-source DRAM testing infrastructure
similar to SoftMC, infrastructures for testing other types of memories have
been developed. Cai et al. [316] developed a platform for characterizing NAND
flash memory. They propose a flash controller, implemented on an FPGA, to
quickly characterize error patterns of existing flash memory chips. They
expose the functions of the flash translation layer (i.e., the flash chip
interface) to the software developer via the host machine connected to the
FPGA board, similar to how we expose the DDR interface to the user in SoftMC.
Many works [317, 318, 319, 320, 321, 322, 323, 324, 325, 326, 327] use this
flash memory testing infrastructure to study various aspects of flash chips.

Our prior works [10, 68, 67, 73, 12, 66, 65, 11] developed and used FPGA-based
infrastructures for a wide range of DRAM studies. Liu et al. [65] and Khan et
al. [66] analyzed the data retention behavior of modern DRAM chips and
proposed mechanisms for mitigating retention failures. Khan et al. [68, 67]
studied data-dependent failures in DRAM, and developed techniques for
efficiently detecting and handling them. Lee et al. [11, 12] analyzed latency
characteristics of modern DRAM chips and proposed mechanisms for latency
reduction. Kim et al. [73] discovered a new reliability issue in existing
DRAM, called _RowHammer_ , which can lead to security breaches [233, 234, 236,
235, 250, 249]. Chang et al. [10] used SoftMC to characterize latency
variation across DRAM cells for fundamental DRAM operations (e.g., activation,
precharge). SoftMC evolved out of these previous infrastructures, to address
the need to make the infrastructure flexible and easy to use.

###  3.8 Summary

This chapter introduces the first publicly-available FPGA-based DRAM testing
infrastructure, _SoftMC_ (Soft Memory Controller), which provides a
programmable memory controller with a flexible and easy-to-use software
interface. SoftMC enables the flexibility to test any standard DRAM operation
and any (existing or new) mechanism comprising of such operations. It provides
an intuitive high-level software interface for the user to invoke low-level
DRAM operations, in order to minimize programming effort and time. We provide
a prototype implementation of SoftMC, and we have released it publicly as a
freely-available open-source tool [98].

We demonstrate the capability, flexibility, and programming ease of SoftMC by
implementing two example use cases. Our experimental analyses demonstrate the
effectiveness of SoftMC as a new tool to _(i)_ perform detailed
characterization of various DRAM parameters (e.g., refresh interval and access
latency) as well as the relationships between them, and _(ii)_ test the
expected effects of existing or new mechanisms (e.g., whether or not highly-
charged cells can be accessed faster in existing DRAM chips). We believe and
hope that SoftMC, with its flexibility and ease of use, can enable many other
studies, ideas and methodologies in the design of future memory systems, by
making memory control and characterization easily accessible to a wide range
of software and hardware developers.

##  ?chaptername? 4 Uncovering In-DRAM RowHammer Protection Mechanisms: A New
Methodology, Custom RowHammer Patterns, and Implications

The RowHammer vulnerability in DRAM is a critical threat to system security.
To protect against RowHammer, vendors commit to security-through-obscurity:
modern DRAM chips rely on undocumented, proprietary, on-die mitigations,
commonly known as _Target Row Refresh_ (TRR). At a high level, TRR detects and
refreshes potential RowHammer-victim rows, but its exact implementations are
not openly disclosed. Security guarantees of TRR mechanisms cannot be easily
studied due to their proprietary nature.

To assess the security guarantees of recent DRAM chips, we present _Uncovering
TRR_ (U-TRR), an experimental methodology to analyze in-DRAM TRR
implementations. U-TRR is based on the new observation that data retention
failures in DRAM enable a side channel that leaks information on how TRR
refreshes potential victim rows. U-TRR allows us to (i) understand how logical
DRAM rows are laid out physically in silicon; (ii) study undocumented on-die
TRR mechanisms; and (iii) combine (i) and (ii) to evaluate the RowHammer
security guarantees of modern DRAM chips. We show how U-TRR allows us to craft
RowHammer access patterns that successfully circumvent the TRR mechanisms
employed in 45 DRAM modules of the three major DRAM vendors. We find that the
DRAM modules we analyze are vulnerable to RowHammer, having bit flips in up to
99.9% of all DRAM rows.

###  4.1 Motivation and Goal

DRAM technology scaling leads to increasingly important DRAM reliability
problems as DRAM cells get smaller and the distance between the cell reduce.
Kim et al. [73] report that most DRAM chips manufactured since 2010 are
susceptible to disturbance errors that are popularly referred to as RowHammer.
Recent works [328, 329, 73, 74, 330, 331, 332, 333, 334, 335] explain the
circuit-level charge leakage mechanisms that lead to the RowHammer
vulnerability. A security attack exploits the RowHammer vulnerability by
hammering (i.e., repeatedly activating and precharging) an _aggressor_ row
many times (e.g., $139K$ in DDR3 [73], $10K$ in DDR4 [70], and $4.8K$ in
LPDDR4 [70])111For DDR3 chips, [73] reports the minimum number of row
activations on a _single_ aggressor row (i.e., single-sided RowHammer) to
cause a RowHammer bit flip. For DDR4 and LPDDR4 chips, [70] reports the
minimum number of row activations to _each of the two_ immediately-adjacent
aggressor rows (i.e., double-sided RowHammer). to cause bit flips in the cells
of the _victim_ rows that are physically adjacent to the hammered row. Since
the discovery of RowHammer, researchers have proposed many techniques that
take advantage of the RowHammer vulnerability to compromise operating systems
[233, 83, 235, 236, 77, 237, 238, 239, 240, 241, 242, 134, 243, 244], web
browsers [245, 246, 100, 247, 248], cloud virtual machines [249, 250], remote
servers [251, 252], and deep neural networks [253, 254].222A review of many
RowHammer attacks and defenses is provided in [74]. Thus, RowHammer is a clear
major threat to system security.

To prevent RowHammer, DRAM vendors equip their DRAM chips with a _mitigation
mechanism_ known as Target Row Refresh (TRR) [100, 77, 70, 336]. The main idea
of TRR is to detect an aggressor row (i.e., a row that is being rapidly
activated) and refresh its victim rows (i.e., neighboring rows that are
physically adjacent to the aggressor row). TRR refreshes the victim rows
separately from the _regular_ refresh operations [43, 191, 65, 53, 52] that
must periodically (e.g., once every $64\text{\,}\mathrm{ms}$) refresh each
DRAM row in the entire DRAM chip. Some of the major DRAM vendors advertise
_RowHammer-free_ DDR4 DRAM chips [115, 116, 100]. However, none of the DRAM
vendors have so far disclosed the implementation details let alone proved the
protection guarantees of their TRR mechanisms. It is long understood that
security cannot be achieved only through obscurity [337, 338, 339]. Yet, such
is the current state of practice when it comes to DRAM.

The recent TRRespass work [100] shows that in certain DRAM chips, the TRR
mechanism keeps track of only a few aggressor rows. Hence, an access pattern
that hammers many aggressor rows can circumvent the TRR protection and induce
RowHammer bit flips. While TRRespass already demonstrates the flaws of certain
TRR implementations, it does _not_ propose a methodology for _discovering_
these flaws. According to [100], simply increasing the number of aggressor
rows is _not_ sufficient to induce bit flips on 29 out of 42 of the DDR4
modules that were tested by [100]. However, it is unclear whether such DDR4
chips are _fully_ secure due to the lack of insight into the detailed
operation of TRR in these chips. Thus, we need new methods for identifying
whether or not DRAM chips are fully secure against RowHammer.

To this end, our goal is to uncover the inner workings of TRR mechanisms in
modern DRAM chips and assess their security guarantees. To achieve this goal,
we develop U-TRR, a new and practical methodology for understanding the
operation of an in-DRAM TRR mechanism. In U-TRR, we formulate TRR as a
function that takes a number of DRAM accesses including aggressor rows as
input and refreshes a number of rows that are detected as victims. U-TRR is
based on the key observation that retention failures that occur on a DRAM row
can be used as a side channel to detect _when_ the row is refreshed, due to
either TRR or periodic refresh operations. We easily distinguish TRR-induced
refreshes from regular refreshes as the latter occur at fixed time intervals
independently of the access pattern.

We use U-TRR to analyze 45 DDR4 modules from the three major DRAM chip vendors
(i.e., Micron, Samsung, SK Hynix). Our methodology uncovers important details
of the in-DRAM TRR designs of all vendors. We demonstrate the usefulness of
these insights for developing effective RowHammer attacks on DRAM chips from
each vendor by crafting specialized DRAM access patterns that hammer a row
enough times to cause a RowHammer bit flip _without_ alerting the TRR
protection mechanism (i.e., by redirecting potential TRR refreshes _away from_
the victim rows).

###  4.2 Overview of U-TRR

U-TRR is a new methodology for gaining visibility into Target Row Refresh
(TRR) operations. It enables system designers and researchers to understand
how TRR detects an aggressor row, when it refreshes the victim rows of the
aggressor row, and how many potential victim rows it refreshes. U-TRR enables
users to easily conduct experiments that uncover the inner workings of the TRR
mechanism in an off-the-shelf DRAM module.

Figure 4.1 illustrates the two components of U-TRR: _Row Scout_ (_RS_) and
_TRR Analyzer_ (_TRR-A_). _RS_ finds a set of DRAM rows that meet certain
requirements as needed by _TRR-A_ and identifies the data retention times of
these rows. _TRR-A_ uses the _RS_ -provided rows to distinguish between TRR
refreshes and regular refreshes, and thus builds an understanding of the
underlying TRR mechanism.

?figurename? 4.1: Overview of U-TRR.

####  4.2.1 Overview of _Row Scout_ (_RS_)

The goal of _RS_ is to identify a list of useful DRAM rows and their retention
times, and provide this list to _TRR-A_. _RS_ profiles the retention time of a
DRAM row by writing a data pattern (e.g., all ones) [43, 65] to the entire row
and measuring the time interval for which the row can correctly retain its
data without being refreshed.

A useful DRAM row must satisfy two key requirements. First, the retention time
of the row should be consistent and _not_ vary over time based on effects such
as Variable Retention Time (VRT) [42, 66, 65, 217, 49, 212, 63]. A consistent
retention time is essential for _TRR-A_ to accurately infer whether or not a
row has been refreshed after a specific time interval, based on whether or not
the row contains retention failures. _RS_ validates the retention time of a
row one thousand times to ensure its consistency over time.

Second, to observe exactly which DRAM rows the TRR mechanism treats as victim
rows for each aggressor row it detects, _RS_ should provide _multiple_ DRAM
rows that have the _same_ retention times and that are located at certain
_configurable_ distances with respect to each other (we call this a _row
group_). It is crucial to find rows with the same retention times in order to
observe whether or not TRR can refresh _multiple_ rows at the same time.
Enforcing a particular distance between rows is useful when the user wants to
specify an aggressor row at a specific distance from the _RS_ -provided rows.
These two requirements enable reliable and precise analysis of TRR-induced
refreshes by _TRR-A_.

As shown in Figure 4.1, the number of row groups (i.e., row group count) and
the relative distances of the rows within the group (i.e., row group layout)
is specified in the _profiling configuration_. U-TRR user also specifies a
certain DRAM bank and row range within the bank for the _RS_ to search for the
desired row groups. We discuss the operation and capabilities of _RS_ in
greater detail in section 4.3.

####  4.2.2 Overview of _TRR Analyzer_ (_TRR-A_)

The goal of _TRR-A_ is to use _RS_ -provided rows to determine when a TRR
mechanism refreshes a victim row by exactly distinguishing between TRR
refreshes and regular refreshes, and thus build an understanding of the
underlying TRR operation. _TRR-A_ runs a RowHammer attack and monitors
retention failures in _RS_ -provided rows to determine _when_ TRR refreshes
any of these rows. As Figure 4.1 shows, _TRR-A_ operates based on an
_experiment configuration_ , which includes several parameters we discuss in
section 4.4.2. Figure 4.2 shows the three steps a _TRR-A_ experiment generally
follows:

  1. 1.

_TRR-A_ uses _RS_ -provided rows as victim rows and initializes 1 them by
writing into them the same data pattern that is used during retention
profiling with _RS_. Since the RowHammer vulnerability greatly depends on the
data values stored in an aggressor row [70, 73], _TRR-A_ also initializes
aggressor rows to the data values that the user specifies in the experiment
configuration. _TRR-A_ waits for half of the victim rows’ retention time
($\frac{T}{2}$) without performing any refreshes or accesses.

  2. 2.

_TRR-A_ hammers 2 the aggressor rows and issues REF 3 commands based on the
experiment configuration.

  3. 3.

After again waiting for the half of the victim rows’ retention time
($\frac{T}{2}$), excluding the time spent on hammering and refresh during step
(2), _TRR-A_ reads the victim rows and compares 4 the data stored in them
against the initial data value pattern written to them in step (1). A victim
row with no bit flips indicates that either a TRR-induced or a regular refresh
operation targeted the victim row while serving the REF commands in step (2).
_TRR-A_ easily distinguishes between a TRR-induced and a regular refresh as
the latter refreshes a row periodically (e.g., once in every $8K$ REF
commands). The user can then examine the TRR-induced refresh patterns to gain
insight into the underlying TRR implementation.

?figurename? 4.2: General approach for detecting a TRR-induced refresh using
_TRR-A_.

_TRR-A_ offers flexibility in experiments via parameters in the profiling and
experiment configurations, which enable analyzing different TRR
implementations with low effort. section 4.4 provides details.

####  4.2.3 Required Experimental Setup for U-TRR

Both the _RS_ and _TRR-A_ tools require a way to directly interface with a
DRAM module at a DDR-command level. This is because the tools need to
accurately control when an individual DDR command (e.g., ACT, REF) is issued
to the DRAM module. However, existing systems based on commodity CPUs can
access DRAM _only_ using load/store instructions. Therefore, we implement _RS_
and _TRR-A_ using SoftMC [1, 98], an FPGA-based DRAM testing infrastructure
that provides precise control on the DDR commands issued to a DRAM module. We
modify SoftMC to support testing DDR4 modules, as also done in [70, 105, 71,
100]. Figure 4.3 shows our experimental SoftMC setup. Table
LABEL:utrr_table:trr_summary provides a list of the 45 DDR4 DRAM modules we
analyze in this chapter.

?figurename? 4.3: DDR4 SO-DIMM SoftMC [1] experimental setup.

###  4.3 Row Scout (_RS_)

U-TRR uses data retention failures as a side channel to determine if and when
a row receives a (TRR-induced or regular) refresh. As such, to know how long a
row can retain its data correctly without being refreshed, U-TRR requires a
mechanism for profiling the retention time of a DRAM row. We define _DRAM row
retention time_ as the maximum time interval for which all cells in the row
can correctly retain their data without being refreshed.

Unlike existing DRAM retention-time profiling techniques [122, 65, 43, 49,
48], U-TRR does _not_ require a profiler that finds the retention time of
_all_ rows in a DRAM chip. Instead, U-TRR needs to search for a small set of
DRAM rows (i.e., tens of rows depending on the experiment) that match certain
criteria (section 4.3.1) as specified by the U-TRR user based on the desired
experiment.

####  4.3.1 Row Scout (_RS_) Requirements

Depending on the experiment that the U-TRR user conducts, _TRR-A_ needs the
data retention time of DRAM rows that match different criteria. We identify
the following general requirements for _RS_ to enable it to search for DRAM
rows suitable for _TRR-A_.

Rows with uniform retention time. A TRR mechanism may refresh multiple victim
rows. For instance, during a single-sided RowHammer attack, a TRR mechanism
may refresh the row on either side of the aggressor _or_ both at the same
time. To examine whether or not TRR can refresh multiple victim rows at the
same time (i.e., with a single REF), _RS_ must provide multiple rows (i.e., a
_row group_) that have the _same_ retention time.

Relative positions of profiled rows. The location of a victim row depends on
the location of the aggressor rows that the U-TRR user specifies for an
experiment. For example, for a double-sided RowHammer attack (see Figure
2.3b), _RS_ must provide three rows with the same retention time that are
exactly one row apart from each other. _TRR-A_ can then analyze which of the
three victim rows get refreshed by TRR when hammering the two aggressor rows
that are placed between the victim rows. We represent the relative positions
of rows in a row group (i.e., the _row group layout_) using a notation such as
R-R-R, where ‘R’ indicates a retention-profiled row and ‘-’ indicates a
distance of one DRAM row. _RS_ must find a row group based on the row group
layout that the user specifies.

Rows in specific DRAM regions. TRR may treat rows in different parts of a DRAM
chip differently by operating independently at different granularities. For
example, TRR may operate independently at the granularity of a DRAM bank or a
region of DRAM bank. To identify the granularity at which TRR operates, _RS_
must find DRAM rows within a _specific region_ of a DRAM chip.

Rows with consistent retention time. An _RS_ -provided row must have a
consistent retention time such that U-TRR can accurately infer the occurrence
of a TRR-induced refresh operation based on whether the row contains retention
failures after a time period equivalent to the row’s retention time. The main
difficulty is a phenomenon known as Variable Retention Time (VRT) [42, 66, 65,
217, 49, 212, 63], which causes the retention time of certain DRAM cells to
change over time. If an _RS_ -provided row has an inconsistent retention time
that was initially measured to be $T$, U-TRR will not be able to correctly
infer the occurrence of a TRR-induced refresh operation.333 U-TRR fails to
correctly infer a TRR-induced refresh when a row retains its data for
significantly longer or shorter than $T$. If the row retains its data for
longer than $T$, U-TRR will _always_ infer the occurrence of a TRR-induced
refresh operation. If the row fails too soon (i.e., before $\frac{T}{2}$ or
during Step 1 in section 4.2.2), U-TRR will always observe retention failures,
since even a TRR-induced refresh will not be able to prevent the bit flip (in
Step 2 in section 4.2.2). Consequently, U-TRR will _always_ infer that a TRR-
induced refresh operation was not issued to the row. To make it likely for
row’s retention time to remain consistent during the experiment, _RS_
validates the retention time of a row _one thousand times_ in order to rule
out rows with inconsistent retention times (that are due to VRT).

Rows with short retention times. The time it takes to finish a single U-TRR
experiment depends on the retention time of the rows _RS_ finds. This is
because even retention-weak DRAM rows typically retain their data correctly
for tens or hundreds of milliseconds [65, 43, 122], whereas other _TRR-A_
operations (e.g., reading from or writing to a row, hammering a row,
performing refresh) often take much less than a millisecond. Thus, as Figure
4.2 shows, the duration of a _TRR-A_ experiment is dominated by retention
times (T) of the profiled rows. To reduce the overall experiment time, it is
critical for _RS_ to identify rows with short data retention times.

####  4.3.2 Row Scout (_RS_) Operation

We design and implement _Row Scout_ (_RS_), a DRAM retention time profiler,
such that it satisfies the requirements listed in section 4.3.1. We implement
_RS_ using a modified version of SoftMC [1, 98] with DDR4 support (described
in section 4.2.3).

We illustrate the operation of _RS_ in Figure 4.4. 1 _RS_ scans a full range
of DRAM rows within a DRAM bank, as specified in the profiling configuration
(Figure 4.1), and collects the addresses of rows that experience retention
failures if not refreshed over the time interval $T$. _RS_ initially sets $T$
to a small value (e.g., $100\text{\,}\mathrm{ms}$) in order to identify rows
with small retention times as we discuss in the requirements of _RS_ (section
4.3.1). 2 _RS_ creates candidate row groups by combining the appropriate row
addresses (with retention time $T$) that match the row group layout specified
in the profiling configuration. If the number of candidate row groups is less
than the number of row groups to find according to the profiling
configuration, 3 _RS_ increases $T$ by a certain amount (e.g.,
$50\text{\,}\mathrm{ms}$) and starts over from 1. Otherwise, 4 _RS_ tests each
row in a candidate row group one thousand times to build confidence that all
rows in the candidate row group have a consistent retention time that is equal
to $T$. Repeating the test thousand times does _not_ fully ensure that the
retention time of the entire candidate row group will remain consistent during
the whole experiment. The retention time of the rows in the group may still
change due to effects such as VRT and result in noise (i.e., observing
retention success on a row after $T$ even though the row is not refreshed) in
the results. In our experiments, we observe that testing the retention time of
the candidate row group thousand times and using only row groups passing the
tests largely eliminate such noise. If the number of candidate row groups that
pass the retention time consistency test is less than the number of row groups
to find according to the profiling configuration, 5 _RS_ increases $T$ by a
certain amount (e.g., $50\text{\,}\mathrm{ms}$) and starts over from 1.
Otherwise, 6 _RS_ provides a list of retention time-profiled rows to be used
by _TRR-A_.

?figurename? 4.4: Detailed _RS_ operation.

###  4.4 Analyzing TRR-induced Refresh

_TRR-A_ is a configurable and extensible component in U-TRR for analyzing TRR-
induced as well as regular refresh operations. We use the _TRR-A_ to inspect
in-DRAM RowHammer mitigations in modules from the three major DRAM vendors. We
implement _TRR-A_ on top of a modified version of SoftMC [1, 98] with DDR4
support. In section 4.2, we discuss the general operation of _TRR-A_ using
Figure 4.2.

####  4.4.1 TRR Analyzer Requirements

We identify and discuss four key requirements needed to enable reverse
engineering a RowHammer mitigation mechanism. First, to analyze the capability
of TRR in detecting multiple aggressor rows, _TRR-A_ should allow the user to
specify one or more aggressor rows, their corresponding hammer counts, and the
order in which to hammer the aggressor rows.

###### Requirement 1

Ability to hammer multiple aggressor rows with individually configurable
hammer counts in a configurable order.

The user should be able to specify dummy rows444A dummy row operates similarly
to an aggressor row, but it can be implemented more efficiently in a SoftMC
program since a dummy row does not need to be initialized with specific data
unlike an aggressor row. that can be hammered to divert the TRR mechanism to
refresh the neighbors of a dummy row instead of victims of an aggressor row.

###### Requirement 2

Ability to specify dummy rows that are hammered in addition to the aggressor
rows.

To force the TRR mechanism to perform an additional refresh operation when
desired during the experiment, _TRR-A_ should allow flexibly issuing an any
number of REF commands at arbitrary times.

###### Requirement 3

Ability to flexibly issue REF commands.

The TRR mechanism under study may retain its state beyond a single experiment,
potentially causing the TRR mechanism to detect different rows as aggressors
depending on previous experiments. For example, in a _counter-based TRR_
(section 4.5.1.2), the TRR mechanism’s internal counter values updated due to
a previous experiment might affect the outcome of future experiments. To
isolate an experiment from the past experiments, _TRR-A_ should reset TRR’s
internal state to a consistent state after each experiment.

###### Requirement 4

Ability to reset TRR mechanism’s internal state.

####  4.4.2 TRR Analyzer Operation

We explain how _TRR Analyzer_ (_TRR-A_) satisfies all of the requirements
described in section 4.4.1 to enable detailed experiments that uncover the
implementation details of in-DRAM RowHammer mitigation mechanisms. Figure 4.5
illustrates a typical _TRR-A_ experiment and provides a list of the experiment
configuration parameters.

?figurename? 4.5: Detailed _TRR-A_ experiment.

Initializing rows’ data. _TRR-A_ initializes 1 the _RS_ -provided rows by
writing into them the same data pattern that that _RS_ used for profiling
these rows. _TRR-A_ also initializes the aggressor rows, whose addresses are
specified in the experiment configuration, as the RowHammer vulnerability
greatly depends on the data values stored in an aggressor row [70, 73].

Resetting internal TRR state. To reset the TRR mechanism’s internal state 2 so
as to satisfy Requirement 4, _TRR-A_ performs refresh for multiple refresh
periods while hammering a set of dummy rows. _TRR-A_ issues REF commands at
the default refresh rate (i.e., one REF every
$7.8\text{\,}\mathrm{\SIUnitSymbolMicro s}$) for several (e.g., $10$)
$64\text{\,}\mathrm{ms}$ refresh periods. During these refresh operations, the
_RS_ -provided rows do _not_ experience bit flips as they get refreshed by the
regular refresh operations. Between two refresh commands, _TRR-A_ hammers a
large number (e.g., $128$) of dummy rows as many times as the DRAM timing
parameters (i.e., tRAS and tRP [116, 340, 3, 2, 11]) permit. _TRR-A_
automatically selects dummy rows from the same bank as the _RS_ -provided and
aggressor rows, since a TRR mechanism may operate independently in each bank.
To select a dummy row that does _not_ cause RowHammer bit flips on the _RS_
-provided rows when the dummy row is hammered, _TRR-A_ enforces a minimum row
distance of $100$ between a selected dummy row and the _RS_ -provided rows.
Note that $100$ rows is an arbitrary distance that we have set in _TRR-A_ for
selecting a dummy row, and it does _not_ necessarily ensure that hammering the
dummy row will not cause RowHammer bit flip in the _RS_ -provided rows.
Regardless of how a dummy row is selected, _TRR-A_ performs a test, where it
hammers the selected dummy row to actually ensure that hammering the dummy row
does _not_ cause a bit flip in the _RS_ -provided rows. If the selected dummy
row fails to pass this test (i.e., it causes bit flips in a _RS_ -provided
row), _TRR-A_ selects a different dummy row. We find that the operations we
perform in 2 make the TRR mechanism clear any internal state that is relevant
to rows activated in past experiments or during 1. Resetting TRR’s internal
state is an optional step since the user may sometimes want to examine how TRR
operates across multiple experiments.

Hammering aggressor and dummy rows. The experiment configuration specifies the
addresses and individual hammer counts of aggressor rows that _TRR-A_
accordingly hammers 3. Optionally, the configuration specifies a number of
dummy rows that can be hammered to divert the TRR mechanism away from the
actual aggressor rows. _TRR-A_ automatically selects dummy rows based on the
criteria for selecting dummy rows explained above. The experiment
configuration specifies a single hammer count for all dummy rows; _TRR-A_
hammers each dummy row by that count.

Hammering modes. The order with which DRAM rows get hammered can affect both
the magnitude of the disturbance each hammer causes and how the TRR mechanism
detects an aggressor row. _TRR-A_ supports two _hammering modes_.
_Interleaved_ mode hammers each aggressor row one at a time until all
aggressors accumulate their corresponding hammer count. _Cascaded_ mode
repeatedly hammers one aggressor row until it accumulates its corresponding
hammer count and then does the same for the other aggressor rows. In our
experiments, we observe that interleaved hammering generally causes more bit
flips (up to four orders of magnitude) compared to cascaded hammering for a
given hammer count. In contrast, we find that cascaded hammering is more
effective at evading the TRR mechanism than interleaved hammering. Therefore,
it is critical to support both hammering modes.

Issuing REFs. To cause the TRR mechanism to perform TRR-induced refresh
operations on the victim rows, _TRR-A_ issues a number of REF commands 3
according to the experiment configuration. As shown in Figure 4.5, _TRR-A_
issues the REF commands _after_ hammering the aggressor/dummy rows and waiting
for half of the retention time $T$ of the _RS_ -provided rows. This is to 1)
allow TRR to potentially detect the aggressor rows hammered in 3 and 2) ensure
that a victim row refreshed in 4 does _not_ experience retention failures
until its data is read in 5.

Hammering rounds. To allow distributing hammers between multiple REF commands,
_TRR-A_ performs hammers in multiple _rounds_. A round consists of 1)
hammering the aggressor and dummy rows and 2) issuing REF commands as the last
operation of the round. The experiment configuration specifies the
aggressor/dummy row hammer counts and the number of REFs to issue per round.

####  4.4.3 Determining Physical Row Mapping

DRAM rows that have consecutive _logical_ row addresses (from the perspective
of the memory controller) may not be physically adjacent inside a DRAM chip
[3, 134, 163] due to two main reasons. First, post-manufacturing row repair
techniques (e.g., [42, 61, 156, 341, 342, 220, 343, 44]) may repair a faulty
row by remapping the logical row address that points to the faulty row to a
spare row at a different physical location inside a DRAM chip. Second, a row
address decoder in the DRAM chip may not necessarily map consecutive row
addresses to adjacent wordlines [3, 134, 163]. The row address decoder can
maintain the logical row address order in physical row space but it may
scramble the logical-to-physical row mapping as well depending on the circuit
implementation.

Since a TRR mechanism should refresh rows that are physically adjacent to an
aggressor row, we need to ensure that _TRR-A_ uses physically adjacent rows in
the experiments. For this purpose, we use two methods. First, before we run
_RS_ , we reverse engineer the logical-to-physical row address mapping of a
DRAM chip by disabling refresh and performing double-sided RowHammer.555Other
works [163, 126, 184, 239, 71] also propose various methods for reverse
engineering DRAM physical layout and their methods can also be used for our
purposes. We analyze the rows at which RowHammer bit flips appear, so as to
determine the physical adjacency of rows and hence reconstruct the physical
row mapping. If the logical row address order is preserved in the physical
space, we simply observe RowHammer bit flips on logical row addresses $R-1$
and $R+1$ as a result of hammering $R$. Otherwise, bit flips occur in other
logical rows depending on the logical-to-physical row address mapping of the
DRAM chip. Second, before an experiment, _TRR-A_ verifies that the given
aggressor row can actually successfully hammer the _RS_ -provided rows by
hammering the aggressor row a large number of times (i.e., $300K$) with
refresh disabled. Doing so ensures that the _RS_ -provided or aggressor rows
are _not_ remapped due to post-manufacturing repair and are still physically
adjacent to each other.

###  4.5 Reverse-Engineering TRR

We use U-TRR, the components of which we describe in section 4.3 and section
4.4, to gain insights about TRR implementations by analyzing DDR4 modules from
three major DRAM vendors. We follow a systematic approach in our reverse
engineering to gain these insights. First, we discover which refresh commands
perform TRR. Second, we observe how many rows are concurrently refreshed by
TRR. Third, we try to understand the strategy that the TRR mechanism employs
for detecting a DRAM row as an aggressor row so as to refresh its neighboring
victim rows. Unless stated otherwise, we conduct all experiments at
$85\text{\,}\mathrm{\SIUnitSymbolCelsius}$ DRAM temperature.

Our approach leads to a number of new insights specific to each DRAM vendor.
Table LABEL:utrr_table:trr_summary summarizes our key findings regarding the
TRR implementations of the 45 modules we test. We describe the experiments
that lead us to these insights in more detail.

####  4.5.1 Vendor A

Using U-TRR, we find that vendor A uses two slightly different TRR
implementations in their modules as we show in Table
LABEL:utrr_table:trr_summary. We explain how to use U-TRR to understand the
operation of the $A_{TRR1}$ mechanism but our methodology is also applicable
to $A_{TRR2}$.

#####  4.5.1.1 TRR-Capable REF Commands

We first run an experiment to determine whether all of the REF commands issued
to DRAM can perform TRR-induced refresh in addition to the regular refresh
operations or only certain REF commands are responsible for TRR-induced
refresh.

To uncover TRR-capable REF commands, we perform experiments that follow the
general template that we present in Figure 4.5. We use _RS_ to find $N$ row
groups that match the R-R layout. Among the profiled rows in each row group,
we designate an aggressor row, which we hammer $H$ times. We choose $H$ so
that it does not cause RowHammer bit flips on the profiled rows but at the
same time is large enough to potentially trigger the TRR mechanism to consider
the hammered row as a potential aggressor. To verify that $H$ hammers do not
cause RowHammer bit flips, we simply run a separate experiment where we 1)
initialize the profiled rows, 2) immediately after initialization, we hammer
the profiled rows $H$ times each, without performing any refresh, and 3) read
back the profiled rows and verify that there are no bit flips.

We issue only one REF command to individually analyze each refresh operation.
Without a TRR mechanism, we expect to see retention failures in _all_ of the
profiled rows in _almost every_ iteration of the experiment. This is because
each row is not refreshed for a long enough period of time (i.e., for $T$ as
in Figure 4.2) such that retention failures occur. Retention failures may not
be observed during the _very few_ iterations that a regular refresh operation
refreshes one or more of the profiled rows. Since regular refreshes happen
periodically (i.e., a row is refreshes by a regular refresh at a fixed REF
command interval (section 4.5.1.3)), U-TRR easily determines when a row is
refreshed by a regular refresh. When we observe a profiled row with no bit
flips when regular refresh is _not_ expected, we attribute that to a TRR-
induced refresh operation.

When we run the experiment in Figure 4.5 with $N\geq 16$ and $H=5K$, we find
an interesting pattern where we see a row group with no bit flips _only_ in
every $9^{th}$ iteration of the experiment, i.e., for every $9^{th}$ REF
command issued consecutively. This shows that, for this particular TRR design,
not all REF commands perform a TRR-induced refresh but only every $9^{th}$ of
them have this capability.

###### Vendor A | Observation 1

Every $9^{th}$ REF command performs a TRR-induced refresh.

We also find with this experiment that, when TRR detects an aggressor row, it
simultaneously refreshes _both_ victim rows on each side of the detected
aggressor row with a single REF. To check if the refreshes are limited to
these two rows, we repeat the experiment using three profiled rows on each
side of the row that we hammer (i.e., we use row group layout RRR-RRR). We
observe that the TRR mechanism refreshes _four_ of the victim rows closest to
the detected aggressor row, i.e., two victims on each side of the aggressor.
This is likely done to protect against the probability that RowHammer bit
flips can occur in victim rows that are two rows apart from the aggressor
rows, as demonstrated by prior works [78, 70, 73, 90].

###### Vendor A | Observation 2

TRR refreshes four rows that are physically closest to the detected aggressor
row. When row address $A$ is detected as an aggressor, TRR refreshes rows
$A\mp 1$ and $A\mp 2$.

We next perform a slightly different experiment to understand in what sequence
TRR detects the hammered rows as aggressor rows in consecutive TRR-capable REF
commands. We use two R-R row groups and hammer the aggressor rows $H_{0}$ and
$H_{1}$ times, where $H_{0}<<H_{1}$ (e.g., typical values we use are
$H_{0}=50$ and $H_{1}=5K$). This experiment uncovers that there are two
different types of TRR-induced refresh operations that alternate on every
$9^{th}$ REF. These two TRR-induced refresh operations differ in how they
detect an aggressor row to refresh its neighbors. The first type ($TREF_{a}$)
always detects the row that has accumulated the most hammers since the time
TRR previously detected the same row (e.g., the row that we hammer $H_{1}$
times in this experiment). This suggests that this particular TRR mechanism
might use a counter table to keep track of activation counts of the accessed
DRAM rows. The second type ($TREF_{b}$) detects the same row periodically
every $16^{th}$ instance of $TREF_{b}$. We anticipate that $TREF_{b}$ uses a
pointer that refers to an entry in the counter table that has $16$ entries.
$TREF_{b}$ refreshes the neighbor rows of the row address associated with the
table entry that the pointer refers to. After performing a TRR-induced
refresh, $TREF_{b}$ increments the pointer to refer to the next entry in the
table. This is our hypothesis as to why $TREF_{b}$ repeatedly detects the same
row once every 16 instances of $TREF_{b}$, and detects other activated rows
that are in the counter table during other instances of $TREF_{b}$. In section
4.5.1.2, we uncover the exact reason why we see the neighbors of the same row
refreshed every $16^{th}$ $TREF_{b}$ operation.

###### Vendor A | Observation 3

The TRR mechanism performs two types of TRR-induced refresh operations
($TREF_{a}$ and $TREF_{b}$) that both use a 16-entry counter table to detect
aggressor rows.
$TREF_{a}$: Detects the row that corresponds to the table entry with the
highest counter value.
$TREF_{b}$: Traverses the counter table by detecting a row that corresponds to
one table entry at each of its instances.

#####  4.5.1.2 Counter-Based TRR

Observation 3 indicates that the TRR mechanism is capable of determining which
single row is activated (i.e., hammered) more than the others. This suggests
that the TRR mechanism implements a set of counters it associates with the
accessed rows and increments the corresponding counter upon a DRAM row
activation. We perform a set of experiments using the U-TRR methodology to
understand more about this counter-based TRR implementation we hypothesize
about.

To find the maximum number of rows that the TRR mechanism can keep track of,
we perform an experiment where we use $N$ R-R row groups and hammer the rows
between the profiled rows $H$ times each in cascaded hammering mode (section
4.4.2). We use $H=1K$ and vary $N$ in the range $1\leq N\leq 32$. When we
repeatedly run the experiment, we observe that all profiled rows are
eventually refreshed by $TREF_{a}$ or $TREF_{b}$ when $1\leq N\leq 16$.
However, with $N\geq 16$, we start observing profiled rows that are never
refreshed (except when they are refreshed due to regular refresh operations as
we discuss in section 4.5.1.3). Thus, we infer that this particular TRR
mechanism has a counter table capacity for 16 different row addresses. We also
observe that the $TREF_{b}$ operations detect rows by repeatedly iterating
over the counter table entries, such that a $TREF_{b}$ detects a row
associated with one entry and the next $TREF_{b}$ detects the row associated
with the next entry. We find this to be the reason for why every $16^{th}$
$TREF_{b}$ detects the same aggressor row when the same set of aggressor rows
are repeatedly hammered. Using row groups from different banks, we uncover
that the TRR mechanism keeps track of $16$ different rows in _each_ bank,
suggesting that each bank implements a separate counter table.

###### Vendor A | Observation 4

The TRR mechanism counts how many times DRAM rows are activated using a per-
bank counter table, which can keep track of activation counts to $16$
different row addresses.

We next try to find how TRR decides which row to evict from the counter table
when a new row is to be inserted. We perform an experiment where we check if
the TRR mechanism evicts the entry with the smallest counter value from the
counter table. In the experiment, we use 17 R-R row groups and hammer the row
between the two retention-profiled rows in each group. We hammer the
aggressors in the following order. First, we hammer one of the aggressors
$H_{0}$ times. Next, we hammer the remaining 16 aggressors $H_{1}$ times,
where $H_{0}<H_{1}$ (e.g., $H_{0}=50$ and $H_{1}=100$). Even after running the
experiment for thousands of iterations, we observe that the TRR mechanism
never identifies the row that is hammered $H_{0}$ times as an aggressor row.
This indicates that the counter table entry with the smallest counter value is
evicted from the table upon inserting a new row address (i.e., the last row
that we hammer $H_{1}$ times in this case) into the table.

###### Vendor A | Observation 5

When inserting a new row into the counter table, TRR evicts the row with the
smallest counter value.

We have already observed that a DRAM row activation increments the
corresponding counter in the table. However, we do not yet know whether or not
a TRR-induced refresh operation updates the corresponding counter value of the
detected aggressor row (e.g., resets the counter to 0). To check if a TRR-
induced refresh updates the corresponding counter, we conduct another
experiment with two R-R row groups, where we hammer the two aggressors $H_{0}$
and $H_{1}$ times. When we run the experiment multiple times with
$H_{0}<H_{1}$, we notice that $TREF_{a}$ detects an aggressor row based on how
many hammers the aggressor row accumulated since the last time it is detected
by $TREF_{a}$ or $TREF_{b}$. For example, with $H_{0}=2K$ and $H_{1}=3K$, the
corresponding counters accumulate $36K$ and $54K$ hammers, respectively,
assuming the $18^{th}$ REF performs $TREF_{a}$.666Since $TREF_{a}$ and
$TREF_{b}$ happen every $9^{th}$ REF in an interleaved manner, $TREF_{a}$
happens every $18^{th}$ REF. Thus, $TREF_{a}$ detects the aggressor row that
is hammered $54K$ times and resets the corresponding counter. Until the
subsequent $TREF_{a}$ operation, the two counters reach $72K$ and $54K$
hammers, respectively, and $TREF_{a}$ detects the first aggressor row as its
counter value is higher than that of the second aggressor row since the latter
counter was reset earlier. This experiment shows that a TRR-induced refresh
operation resets the counter that corresponds to the aggressor row detected to
refresh the neighbors of.

###### Vendor A | Observation 6

When TRR detects an aggressor row, TRR resets the counter corresponding to the
detected row to zero.

We next question whether, once inserted, a row address remains indefinitely in
the counter table or TRR periodically clears out the counter table. To answer
this question, we run _only once_ an experiment with one R-R row group and
hammer the row between the profiled rows several times to insert the aggressor
rows into the counter table. Then, we repeat the experiment many times
_without_ hammering the aggressor row. After running these experiments, we
observe that the aggressor row is detected by a $TREF_{a}$ operation only
once. This is expected since we do not access the row except in the first
experiment, and once reset by the first $TREF_{a}$, the corresponding counter
value remains reset and never becomes a target for $TREF_{a}$ again. However,
we observe that every $16^{th}$ $TREF_{b}$ detects the same aggressor row and
refreshes its neighbors. We keep observing the same even after repeating the
experiment $32K$ times (i.e., issuing $32K$ REF commands that equal the number
of refreshes issued within four $64\text{\,}\mathrm{ms}$ nominal refresh
periods). This shows that the aggressor row remains in the counter table and
keeps getting periodically detected by $TREF_{b}$ operations. The TRR
mechanism does _not_ seem to periodically clear the counter table, for
example, based on time or the number of issued REF commands.

###### Vendor A | Observation 7

After an entry corresponding to a row is inserted into the counter table, the
entry remains in the table indefinitely until it is evicted due to insertion
of a different row.

#####  4.5.1.3 Analyzing Regular Refresh

To refresh every DRAM cell at the default $64\text{\,}\mathrm{ms}$ period, the
memory controller issues a REF command once every
$7.8\text{\,}\mathrm{\SIUnitSymbolMicro s}$ according to the DDR4
specification [343, 116, 340]. In total, the memory controller issues $\approx
8K$ ($64\text{\,}\mathrm{ms}$$/$$7.8\text{\,}\mathrm{\SIUnitSymbolMicro s}$)
REF commands every $64\text{\,}\mathrm{ms}$. Therefore, it is expected that
$\approx 8K$ REF commands refresh each row in the DRAM chip once to prevent a
row from leaking charge for more than $64\text{\,}\mathrm{ms}$. In our
experiments, we observe that the DRAM chips of vendor A internally refresh
more rows with each REF such that a row receives a regular refresh once every
$3758$ (instead of $\approx 8K$) REF commands. Thus, the DRAM chip internally
refreshes its rows with a period even smaller than $32\text{\,}\mathrm{ms}$
instead of the specified $64\text{\,}\mathrm{ms}$. We suspect this could be an
additional measure vendor A takes 1) to protect against RowHammer [73] or 2)
in response to the decreasing retention time as DRAM technology node size
becomes smaller [43, 41, 5, 6].

###### Vendor A | Observation 8

Periodic DRAM refresh leads to internally refreshing the DRAM chip with a
period smaller than half of the specified $64\text{\,}\mathrm{ms}$ refresh
period.

In section 4.6, we exploit the insights we present in this section to craft a
new DRAM access pattern that effectively circumvents the protection of the TRR
mechanism. This new custom access pattern induces a significantly higher
number of RowHammer bit flips than the state-of-the-art access patterns
presented in [100].

####  4.5.2 Vendor B

Using U-TRR, we find that vendor B uses three slightly different TRR
implementations in their modules, as Table LABEL:utrr_table:trr_summary shows.
We explain how to use U-TRR to understand the operation of the $B_{TRR1}$
mechanism. Our methodology is also applicable to $B_{TRR2}$ and $B_{TRR3}$.

#####  4.5.2.1 TRR-Capable REF Commands

Similar to vendor A, we again start with uncovering which REF commands can
perform TRR-induced refresh. When we repeatedly run the experiment with one or
more row groups (i.e., $N\geq 16$) while hammering each aggressor row $5K$
times in each iteration of the experiment, we observe that not all REF
commands perform TRR-induced refresh. Instead, we find that, in $B_{TRR1}$
only every $4^{th}$ REF command is used for TRR-induced refresh. Similar
experiments on modules that implement $B_{TRR2}$ and $B_{TRR3}$ uncover that
every $9^{th}$ and $2^{nd}$ REF command, respectively, is used for TRR-induced
refresh.

###### Vendor B | Observation 1

Every $4^{th}$, $9^{th}$, and $2^{nd}$ REF command performs a TRR-induced
refresh in the three TRR mechanisms of vendor B.

From the same experiment, we also observe that a TRR-induced refresh operation
refreshes only the two neighboring rows that are immediately adjacent to the
hammered row as opposed to vendor A’s TRR implementation, which refreshes the
four physically closest rows to the hammered row.

###### Vendor B | Observation 2

The TRR mechanism refreshes the two rows physically closest to the detected
aggressor row. When row address $A$ is detected as an aggressor, TRR refreshes
rows $A\mp 1$.

#####  4.5.2.2 Sampling-Based TRR

We perform experiments to show how the TRR mechanism detects the potential
aggressor rows. When we perform the experiments that we use for vendor A’s
modules (described in section 4.5.1.2), we do _not_ observe obvious patterns
in the rows detected by TRR so as to indicate a counter-based TRR
implementation. Instead, we observe that the aggressor row that is last
hammered before a REF command is more likely to be detected. In particular,
when we hammer two aggressor rows $H_{0}=5K$ and $H_{1}=3K$ times,
respectively, we find that the $4^{th}$ REF _always_ refreshes the neighbors
of the second aggressor row, which we hammer $2K$ times less than the first
aggressor row. We perform experiments with different $H_{0}$ and $H_{1}$
values and find that, when we hammer the second row at least $2K$ times and
issue a REF, the TRR mechanism consistently refreshes the neighbors of the
second row on every $4^{th}$ REF. However, as we reduce $H_{1}$, the first
aggressor row gets detected by TRR with an increasing probability.

With further analysis, we determine that $B_{TRR1}$ operates by sampling the
row addresses provided along with ACT commands. This sampling of ACT commands
happens with a certain probability such that $2K$ consecutive activations to a
particular row consistently causes the row to be detected for TRR-induced
refresh. We did not analyze this aspect of TRR further; we suspect (based on
some experiments) that the sampling does not happen truly randomly but is
likely based on pseudo-random sampling of an incoming ACT.

###### Vendor B | Observation 3

TRR probabilistically detects aggressor rows by sampling row addresses of ACT
commands.

To determine how many rows the TRR mechanism can sample and refresh at the
same time, we repeat the previous experiment with the same $H_{0}=5K$ and
$H_{1}=3K$ hammer counts but by issuing $M$ REF commands, instead of just one,
after performing the hammers. Even when we use a large $M$ (e.g., to 100) such
that it contains multiple TRR-capable REF commands (e.g., $25$), we _never_
see the neighbors of the first aggressor row to be refreshed but _always_ the
neighbors of the _second_ aggressor row. This suggests that, a newly-sampled
row overwrites the previously-sampled one. Therefore, we conclude that the TRR
mechanism has a capacity to sample _only_ one row address. Further, we find
that this sampling capacity is shared across _all banks_ in a DRAM chip that
implements $B_{TRR1}$ and $B_{TRR2}$. When TRR samples row $R_{1}$ from DRAM
bank $B_{1}$, it overwrites a previously-sampled row $R_{2}$ from bank $B_{0}$
even though $R_{2}$’s neighbors may not have been refreshed yet.

###### Vendor B | Observation 4

The TRR mechanism has a sampling capacity of only one row that is shared
across all banks in a DRAM chip (except for $B_{TRR3}$).

Our experiments also uncover that a previously-sampled row address is _not_
cleared when the TRR mechanism performs a TRR-induced refresh on the neighbors
of this aggressor row. Instead, when a new TRR-enabled REF is issued, TRR
refreshes (again) the neighbors of the same row.

###### Vendor B | Observation 5

A TRR-induced refresh does not clear the sampled row, and therefore the same
row keeps getting detected until TRR samples another aggressor row.

####  4.5.3 Vendor C

Using U-TRR, we find that vendor C uses three slightly different TRR
implementations in their modules, as Table LABEL:utrr_table:trr_summary shows.
For brevity, we omit the details of the experiments as they are largely
similar to the experiments for the modules of vendors A and B (section 4.5.1
and section 4.5.2). Instead, we only describe our key observations.

We start with running experiments to find which REF commands are TRR-capable.
Different from the modules of vendors A and B, we find that vendor C’s modules
implement a TRR mechanism that _can_ perform a TRR-induced refresh during the
execution of _any_ REF command. The TRR mechanism performs a TRR-induced
refresh once every $17$ consecutive REF commands during a likely RowHammer
attack. When likely not under an attack (i.e., when a small number of row
activations happen), TRR can defer a TRR-induced refresh to any of the
subsequent REF commands until it detects an aggressor row. We do not observe
TRR-induced refresh more frequently than once in every $17$ REF commands. For
$C_{TRR2}$ and $C_{TRR3}$, we find that every $9^{th}$ and $8^{th}$ REF
command, respectively, performs a TRR-induced refresh.

###### Vendor C | Observation 1

Every $17^{th}$, $9^{th}$, and $8^{th}$ REF command normally performs a TRR-
induced refresh in the three TRR mechanisms of vendor C. A TRR-induced refresh
can be deferred to a later REF if no potential aggressor row is detected.

To uncover the logic behind how a potential aggressor row is detected, we run
experiments similar to those we use for the modules from vendors A and B. We
find that vendor C’s TRR mechanism detects aggressor rows only from the set of
rows targeted by the first $2K$ ACT commands (per bank) following a TRR-
induced refresh operation. We also find that 1) TRR probabilistically detects
one of the rows activated within the first $2K$ ACT commands and 2) the rows
that are activated earlier have a higher chance to be targeted by the
subsequent TRR-induced refresh operation. Discovering that TRR detects
aggressor rows based on only the first $2K$ ACT commands helped us to craft an
effective access pattern (section 4.6.1); thus we did not further analyze
vendor C modules to uncover the maximum number of potential aggressor rows TRR
tracks.

###### Vendor C | Observation 2

TRR detects an aggressor row only among the first $2K$ ACT777Except for the
modules that implement $C_{TRR3}$ (Table LABEL:utrr_table:trr_summary).
$C_{TRR3}$ detects an aggressor row only among the first $1K$ activations to
each bank. (to each bank) following a TRR-induced refresh. Rows activated
earlier are more likely to be detected by TRR.

Our experiments uncover a unique DRAM row organization in modules $C0$-$8$. It
appears that two consecutively addressed rows (i.e., physical row addresses
$R$ and $R+1$ where $R$ is an even row address) are isolated in pairs such
that hammering one row (e.g., $R$) can induce RowHammer bit flips _only_ in
its _pair row_ (e.g., $R+1$), and not in any other row in the bank. As
expected, we also observe that TRR issues refresh operations _only_ to the
pair row of each aggressor row that it identifies.

###### Vendor C | Observation 3

Given any two rows, $R$ and $R+1$, where $R$ is an even number, TRR refreshes
_only_ one of the rows (e.g., $R$) upon detecting the other (e.g., $R+1$) as
an aggressor row.

###  4.6 Bypassing TRR Using U-TRR Observations

U-TRR uncovers critical characteristics of the TRR mechanisms different DRAM
vendors implement in their chips. We leverage those characteristics to craft
custom DRAM access patterns that hammer an aggressor row such that TRR cannot
refresh the aggressor row’s neighbors (i.e., victim rows) in a timely manner.
Our results show that these new custom access patterns greatly increase
RowHammer bit flips on the 45 DDR4 modules we test.

####  4.6.1 Custom RowHammer Access Patterns

Vendor A. Using U-TRR, we find that vendor A’s modules implement a counter-
based TRR ($A_{TRRx}$888We refer to all versions of TRR mechanisms that vendor
A’s modules implement (i.e., $A_{TRR1}$ and $A_{TRR2}$) as $A_{TRRx}$. We use
a similar terminology for other vendors.), the details of which are in section
4.5.1. Since $A_{TRRx}$ evicts the entry with the lowest counter value when
inserting a new entry to the table, a custom RowHammer access pattern that
takes advantage of our U-TRR analysis should first hammer two aggressor rows
in a double-sided manner and then evict the two aggressor rows from the table
by hammering other rows (i.e., _dummy rows_) within the same bank during the
remaining time until the memory controller issues a REF command.999The memory
controller issues a REF once every $7.8\text{\,}\mathrm{\SIUnitSymbolMicro s}$
when using the default $64\text{\,}\mathrm{ms}$ refresh period. This allows at
most 149 hammers to a single DRAM bank assuming typical activation
($35\text{\,}\mathrm{ns}$), precharge ($15\text{\,}\mathrm{ns}$), and refresh
($350\text{\,}\mathrm{ns}$) latencies [116, 65, 41].

We show how we can hammer two aggressor rows ($A_{0}$ and $A_{1}$) in a
double-sided manner without allowing $A_{TRRx}$ to refresh their victim rows.
First, the attacker should synchronize the memory accesses with the periodic
REF commands101010A recent work [247] shows how to detect when a memory
controller issues a periodic REF from an unprivileged process and from a web
browser using JavaScript. in order to hammer $A_{0}$ and $A_{1}$ _right after_
the memory controller issues a REF. After hammering the two aggressor rows,
the attacker should then use the remaining time until the next REF to hammer
dummy rows in order to steer $A_{TRRx}$ to identify one of the dummy rows (and
_not_ rows $A_{0}$ and $A_{1}$) as potential aggressors and refresh the dummy
rows’ neighboring victim rows. The particular access pattern that leads to the
largest number of bit flips is hammering $A_{0}$ and $A_{1}$ 24 times each,
followed by hammering 16 dummy rows 6 times each. We discover the access
pattern that maximizes the bit flip count by sweeping the number of hammers to
$A_{0}$ and $A_{1}$ and adjusting the number of hammers to the 16 dummy rows
based on the time that remains until the next REF after hammering the
aggressors.

Vendor B. $B_{TRRx}$ operates by probabilistically sampling a single row
address from all ACT (section 4.5.2) commands issued (across all banks for
$B_{TRR1}$ and $B_{TRR2}$) to DRAM. Rows neighboring the sampled row are
refreshed during a TRR-induced refresh operation that happens once in every
$4$, $9$, and $2$ REF commands for $B_{TRR1}$, $B_{TRR2}$, and $B_{TRR3}$,
respectively. To maximize the probability of $B_{TRRx}$ detecting a dummy row
instead of the aggressor row, our custom access pattern maximizes the number
of hammers to dummy rows after hammering the aggressor rows and before every
TRR-induced refresh operation. Our custom access pattern first hammers rows
$A_{0}$ and $A_{1}$ immediately following a TRR-induced refresh. Then, it
simultaneously hammers a single dummy row in each of four banks111111We do not
hammer a dummy row in more than four different banks due to the Four-
Activation-Window (tFAW [116, 343, 340]) DRAM timing constraint. to perform a
large number of dummy row activations within the limited time until the next
TRR-induced refresh.121212For $B_{TRR3}$, which separately samples ACT
commands to each bank, we hammer a dummy row from the aggressor row’s bank. We
find that $220$ hammers per aggressor row (leaving 156 hammers for each dummy
row in the four banks) within a window of four consecutive REF commands causes
RowHammer bit flips even in the least RowHammer-vulnerable module of the 15
vendor B modules that we use in our experiments.

Vendor C. $C_{TRR1}$, $C_{TRR2}$, and $C_{TRR3}$ have the ability to perform a
TRR-induced refresh once in every $17$, $9$, and $8$ REF commands,
respectively, and they can defer the TRR-induced refresh to a later REF until
a potential aggressor row is detected (section 4.5.3). $C_{TRRx}$ does not
keep track of more than $2K$ ACT commands that follow a TRR-induced refresh
operation and rows activated earlier in the set of $2K$ ACT commands are more
likely to be detected. Therefore, we craft a custom RowHammer access pattern
that follows a TRR-induced refresh operation with a large number (e.g., $2K$)
of dummy row activations and then hammers the aggressor rows $A_{0}$ and
$A_{1}$ until the next TRR-induced refresh operation. To properly execute this
access pattern, it is critical to synchronize the dummy and aggressor row
hammers with TRR-enabled REF commands.

####  4.6.2 Effect on RowHammer Bit Flip Count

We implement and evaluate the different custom DRAM access patterns that are
used to circumvent $A_{TRRx}$, $B_{TRRx}$, and $C_{TRRx}$ on our FPGA-based
SoftMC platform [1] (section 4.2.3). The SoftMC program executes each custom
access pattern for a fixed interval of time (determined by each chip’s TRR-
induced refresh frequency), while also issuing REF commands once every
$7.8\text{\,}\mathrm{\SIUnitSymbolMicro s}$ to comply with the vendor-
specified default refresh rate.

Figure 4.6 shows the distribution of number of bit flips per row as box-and-
whisker plots131313The lower and upper bounds of the box represent the first
quartile (i.e., the median of the first half of a sorted dataset) and the
second quartile (i.e., the median of the second half of a sorted dataset),
respectively. The median line is within the box. The size of the box
represents the inter-quartile range (IQR). The whiskers are placed at
$1.5*IQR$ on both sides of the box. The outliers are represented with dots. in
modules $A5$, $B8$, and $C7$141414We analyze $A5$, $B8$, and $C7$ as they are
the modules that experience the most RowHammer bit flips and implement
$A_{TRR1}$, $B_{TRR1}$, and $C_{TRR1}$, respectively. when sweeping the number
of hammers issued to aggressor rows in each custom access pattern. The x-axis
is normalized so that it shows the average number of hammers performed between
two REFs to a single aggressor row.151515The x-axis shows the number of
hammers per aggressor row per REF to enable easy comparison of the
effectiveness of different RowHammer patterns across different modules. Our
actual experiments perform the aggressor and dummy row hammers as required by
each custom RowHammer access pattern described in section 4.6.1. We show
different hammers per aggressor per REF for each module as the number of
hammers we can fit between two REFs depend on the custom RowHammer patterns we
craft (section 4.6.1). Each access pattern uses a fixed number of dummy rows
as described in section 4.6.1. We perform the maximum number of hammers that
fit between two REFs. Therefore, a lower number of aggressor row hammers
translates to a higher number of dummy row hammers.

?figurename? 4.6: Distribution of bit flips per DRAM row for different
aggressor hammer counts in three representative modules.

Vendor A. We observe the highest bit flip count (i.e., up to 62 bit flips in a
row) when using $26$ hammers per aggressor row, in which case each of the $16$
dummy rows are hammered $6$ times. The number of bit flips decreases as we
hammer the aggressors more than $26$ times. This is because the aggressors
become less likely to be evicted from the counter table as more activations to
them increment the corresponding counters to higher values. In contrast, the
aggressor rows become more likely to be evicted from the counter table when
they are hammered fewer than $26$ times each. However, we still observe a
smaller bit flip count with fewer than $26$ hammers per aggressor because
fewer hammers are insufficient for many victim rows to experience RowHammer
bit flips.

Vendor B. The number of bit flips gradually increases with the number of
hammers per aggressor row. This increases to a point where too many aggressor
row activations leave an insufficient time to perform enough dummy row
activations to ensure that a dummy row is sampled to replace an aggressor row
for the subsequent TRR-induced refresh. According to our experiments, at least
$12$ total dummy row activations simultaneously performed in four banks
(leaving enough time to perform $73$ hammers per aggressor) are needed to
induce RowHammer bit flips. We observe the maximum number of bit flips with
$68$ hammers per aggressor row.

Vendor C. We observe bit flips appear when a dummy row is initially hammered a
large number of times to make the subsequent aggressor row activations less
likely to be tracked by $C_{TRRx}$. The access pattern causes bit flips when
performing at least $252$ dummy hammers (right after a TRR-enabled REF) prior
to continuously hammering the aggressor rows until the next TRR-enabled REF.
This leaves time to perform $71$ hammers per aggressor row per REF on average.
We observe the maximum number of bit flips with $65$ hammers per aggressor
row.

####  4.6.3 Effect on Individual Rows

To mount a successful system-level RowHammer attack, it is critical to force
the operating system to place sensitive data in vulnerable rows. To make this
task easier, it is important to induce RowHammer bit flips in as many rows as
possible. Ideally, all rows should be vulnerable to RowHammer from an
attacker’s perspective.

Figure 4.7 shows the percentage of vulnerable DRAM rows, i.e., rows that
experience at least one RowHammer bit flip with our custom RowHammer access
patterns (section 4.6.1), as a fraction of all rows in a bank of the tested 45
modules. We report data for a single bank161616We test a single bank to reduce
the experiment time. To ensure that the results are similar across different
banks, we tested multiple banks from several modules. from each module. For
each DRAM module, we use a different number of hammers per aggressor that
results in the highest percentage of vulnerable rows in the corresponding
module (see section 4.6.2).171717When using the conventional single- and
double-sided RowHammer, we do _not_ observe RowHammer bit flips in any of the
45 DDR4 modules (as expected from our understanding of the TRR implementations
and from [100]).

?figurename? 4.7: Percentage of rows that experience at least one RowHammer
bit flip using our custom RowHammer access patterns.

In many (i.e., $8$, $7$, and $6$, respectively) modules from vendor A, B, and
C we see bit flips in more than 99.9% of the rows. This shows that the custom
access patterns we use are effective at circumventing the $A_{TRRx}$,
$B_{TRRx}$, and $C_{TRRx}$ implementations. The other modules from vendors A
and B have a smaller yet still a very significant (i.e., $>$23% in all cases)
fraction of vulnerable rows. We believe that modules $A0$, $A8$-$12$ are
slightly more resistant to our access pattern than the other modules of vendor
A due to having more banks (i.e., $16$ vs. $8$) and smaller banks (i.e., $32K$
vs. $64K$ rows per bank). $B1$-$4$ have stronger rows that can endure more
hammers than the other modules of vendor B (as shown in $HC_{first}$ column of
LABEL:utrr_table:trr_summary), and therefore they have a lower fraction of
vulnerable rows. $B9$-$12$ implement a different TRR version ($B_{TRR2}$), for
which our custom access patterns are not as effective.

Modules from vendor C that implement $C_{TRR1}$ (i.e., $C0$-$8$) are less
vulnerable to our access patterns than the other modules of the same vendor.
We believe this is due to two main reasons. First, these modules use a unique
row organization that pairs every two consecutive DRAM rows, as we explain in
section 4.5.3. We only observe bit flips when hammering two aggressor rows
that have odd-numbered addresses but not when the two aggressor have even-
numbered addresses. This essentially halves the number of victim rows where
our access patterns can cause bit flips. Second, $C0$-$6$ have stronger rows
that are less vulnerable to RowHammer than the other vendor C modules (as
LABEL:utrr_table:trr_summary shows), and therefore $C0$-$6$ have even lower
fraction of vulnerable rows than $C7$-$8$.

Overall, even though our custom RowHammer access patterns cause bit flips in
45 DRAM modules, we could not explore the entire space of both TRR
implementations and custom RowHammer patterns. Therefore, we believe future
work can lead to even better RowHammer patterns via more exhaustive analysis
and testing.

####  4.6.4 Bypassing System-Level ECC Using U-TRR

Although we clearly show that the custom access patterns we craft induce
RowHammer bit flips in a very large fraction of DRAM rows (section 4.6.3), a
system that uses Error Correction Codes (ECC) [344, 196, 197, 345, 42, 219,
157, 135, 346, 347, 199, 198] can potentially protect against RowHammer bit
flips if those bit flips are distributed such that no ECC codeword contains
more bit flips than ECC can correct.

Figure 4.8 shows the distribution of RowHammer bit flips that our custom
access patterns induce across 8-byte data chunks as box-and-whisker
plots1414footnotemark: 14 for _all_ 45 DRAM modules we test across three
vendors. We use 8-byte data chunks as DRAM ECC typically uses 8-byte or larger
datawords [219, 348, 349, 350, 351, 341, 220, 352].

The majority of the 8-byte data chunks are those that have only a single
RowHammer bit flip (i.e., up to $6.9$ million 8-byte data chunks with a single
bit flip in one bank of module $B13$), which can be corrected using typical
SECDED ECC [219, 348, 349, 350, 351, 341, 220, 352]. However, our RowHammer
access patterns can cause $3$ or more (up to $7$) bit flips in many single
datawords, which the SECDED ECC _cannot_ correct or detect, in all three
vendor’s modules.

?figurename? 4.8: Distribution of 8-byte data chunks (log scale) with
different RowHammer bit flip counts in a single DRAM bank from each of the 45
tested DDR4 modules.

Chipkill [344, 157, 353] is a symbol-based code conventionally designed to
correct errors in one symbol (i.e., one DRAM chip failure) and detect errors
in two symbols (i.e., two DRAM chip failures). Because our access patterns
cause more than two bit flips in _arbitrary_ locations (i.e., different DRAM
chips), and thus in arbitrary symbols within an 8-byte data chunk, Chipkill
does _not_ provide guaranteed protection.

Still, it is challenging for an attacker to compromise a system protected with
ECC due to two reasons. First, identifying a codeword that experiences
uncorrectable bit flips after a RowHammer attack is difficult without first
causing detectable bit flips, using which the system may recognize the
RowHammer attack. Second, to cause a bit flip in a specific bit location in a
dataword, the attacker must know the parity check matrix to determine which
bit locations to flip on the codeword stored in DRAM. However, we believe that
determined and powerful attackers can find ways to compromise the system with
some effort, and certainly it can be relatively easy to cause data corruption
even if the system is not easily compromised.

To provide guaranteed protection against our RowHammer patterns using ECC,
Reed-Solomon codes [354] can be designed to offer stronger
correction/detection capability at the cost of additional parity check symbols
[346, 355]. To detect (and correct half of) the maximum number of bit flips
(i.e., $7$) that our access patterns can cause in an 8-byte data chunk, a
Reed-Solomon code would incur a large overhead by requiring at least $7$
parity-check symbols [354].

We conclude that 1) conventional DRAM ECC does _not_ provide guaranteed
protection against our new custom RowHammer patterns and 2) an ECC scheme that
guarantees protection against our custom patterns requires a large number of
parity check symbols, i.e., large overheads.

###  4.7 Related Work

Kim et al. [73] are the first to introduce and analyze the RowHammer
phenomenon. Numerous later works develop RowHammer attacks to compromise
various systems in various ways [77, 245, 236, 252, 237, 249, 233, 251, 235,
250, 100, 244, 238, 72, 83, 70, 247, 74, 239, 246, 240, 241, 356, 248, 254,
134, 243, 242, 357, 253] and analyze RowHammer further [134, 77, 245, 70, 237,
251, 328, 329, 71, 358]. To our knowledge, this is the first work to 1)
propose an experimental methodology to understand the inner workings of
commonly-implemented in-DRAM RowHammer protection (i.e., TRR) mechanisms and
2) use this understanding to create custom access patterns that circumvent the
TRR mechanisms of modern DDR4 DRAM chips.

In-DRAM TRR. We already provided extensive descriptions of TRR and TRRespass
in section 2.5.1, section 4.1, and section 4.5. TRRespass [100] is the most
relevant prior work to ours in understanding and circumventing TRR mechanisms,
yet it is not effective enough. While TRRespass can incur RowHammer bit flips
in 13 of 42 DDR4 modules (and 5 of 13 LPDDR4 modules), TRRespass does not
uncover many implementation details of the TRR mechanisms, which are important
to circumvent TRR mechanisms. For example, in 29 out of 42 DDR4 modules (and 8
out of 13 LPDDR4 modules), TRRespass fails to find an access pattern that can
circumvent TRR. In contrast, our new U-TRR methodology can be used to
understand different aspects of a TRR mechanism in great detail and use this
understanding to generate specific RowHammer access patterns that effectively
incur a large number of bit flips (as we show on 45 real DRAM modules).

System-level RowHammer Mitigation Techniques. A number of studies propose
system-level RowHammer mitigation techniques [78, 73, 79, 80, 81, 82, 83, 84,
85, 86, 87, 88, 89, 90, 91, 92, 93, 95, 158]. Recent works [248, 245, 78, 70]
show that some of these mechanisms are insecure, inefficient, or do not scale
well in chips with higher vulnerability to RowHammer. We believe the
fundamental principles of U-TRR can be useful for improving the security of
these works as well as potentially combining them with in-DRAM TRR. We leave
examining such directions to future work.

###  4.8 Summary

We propose U-TRR, a novel experimental methodology for reverse-engineering the
main RowHammer mitigation mechanism, Target Row Refresh (TRR), implemented in
modern DRAM chips. Using U-TRR, we 1) provide insights into the inner workings
of existing proprietary and undocumented TRR mechanisms and 2) develop custom
DRAM access patterns to efficiently circumvent TRR in 45 DDR4 DRAM modules
from three major vendors. We conclude that TRR does _not_ provide security
against RowHammer and can be easily circumvented using the new understanding
provided by U-TRR. We believe and hope that U-TRR will facilitate future
research by enabling rigorous and open analysis of RowHammer mitigation
mechanisms, leading to the development of both new RowHammer attacks and more
secure RowHammer protection mechanisms. We open source our U-TRR methodology
and make it freely available for further research and development [117].

##  ?chaptername? 5 A Case for Self-Managing DRAM Chips: Enabling Efficient
and Autonomous in-DRAM Maintenance Operations

The memory controller is in charge of managing DRAM maintenance operations
(e.g., refresh, RowHammer protection, memory scrubbing) in current DRAM chips.
Implementing new maintenance operations often necessitate modifications in the
DRAM interface, memory controller, and potentially other system components.
Such modifications are only possible with a new DRAM standard, which takes a
long time to develop, leading to slow progress in DRAM systems.

In this chapter, our goal is to 1) ease the process of enabling new DRAM
maintenance operations and 2) enable more efficient in-DRAM maintenance
operations. Our idea is to set the memory controller free from managing DRAM
maintenance. To this end, we propose (), a new low-cost DRAM architecture that
enables implementing new in-DRAM maintenance mechanisms (or modifying old
ones) with no further changes in the DRAM interface, memory controller, or
other system components. We use to implement new in-DRAM maintenance
mechanisms for three use cases: 1) periodic refresh, 2) RowHammer protection,
and 3) memory scrubbing. Our evaluations show that, -based maintenance
operations significantly improve the system performance and energy efficiency
while providing higher reliability compared to conventional DDR4 DRAM. A
combination of -based maintenance mechanisms that perform refresh, RowHammer
protection, and memory scrubbing achieve 7.6% speedup and 5.2% lower DRAM
energy on average for four-core workloads. We open source our Self-Managing
DRAM framework [120].

###  5.1 Motivation and Goal

Ensuring reliable and efficient DRAM operation becomes an even more critical
challenge as a DRAM cell becomes smaller and the distance between adjacent
cells shrink [359, 220, 360, 42, 70, 73, 361, 61, 5, 74, 156, 362, 49]. A
modern DRAM chip typically requires three types of maintenance operations for
reliable and secure operation: 1) periodic refresh, 2) RowHammer protection,
and 3) memory scrubbing.111Memory scrubbing is not always required in consumer
systems but often used by cloud service providers [146, 363, 197, 196, 364,
365, 366, 148].

DRAM Refresh. Due to the short retention time of DRAM cells, all DRAM cells
need to be periodically refreshed to ensure reliable operation. In existing
DRAM chips, a cell is typically refreshed every 64 or $32\text{\,}\mathrm{ms}$
below $85\text{\,}\mathrm{\SIUnitSymbolCelsius}$ [116, 8, 177] and every
$16\text{\,}\mathrm{ms}$ above $85\text{\,}\mathrm{\SIUnitSymbolCelsius}$
[118, 118]. A DRAM chip consists of billions of cells, and therefore
refreshing such a large number of cells incurs large performance and energy
overheads [43, 65, 49]. These overheads are expected to increase as DRAM chips
become denser [41, 42, 43]. Many ideas have been proposed to mitigate the DRAM
refresh overhead [41, 43, 49, 46, 50, 51, 53, 54, 55, 189, 162, 367, 302, 190,
57, 45, 58, 193, 59, 66, 68, 69, 191, 122, 192, 124, 56, 181, 368].

RowHammer Protection. Small and densely-packed DRAM cells suffer from the
RowHammer vulnerability [73], which leads to disturbance failures that stem
from electro-magnetic interference created by repeatedly activating (i.e.,
hammering) a DRAM row (i.e., aggressor row) many times [328, 334, 335, 331,
369, 330, 329, 332]. Such rapid row activations lead to bit flips in DRAM rows
that are physically nearby an aggressor row. Many works propose mechanisms to
protect DRAM chips against RowHammer [80, 73, 84, 85, 79, 86, 87, 92, 90, 88,
78, 89, 124, 158, 82, 81, 83, 258, 91, 96, 95, 94].

Memory Scrubbing. System designers typically use Error Correcting Codes (ECC)
[347, 344] to improve system reliability. DRAM vendors recently started to
equip DRAM chips with on-die ECC [44, 135, 141, 209, 157]. Detection and
correction capability of an ECC scheme is limited. For example, _Single-Error-
Correction Double-Error-Detection (SECDED)_ ECC detects up to two bit errors
and corrects one bit error in a codeword. To prevent independent single-bit
errors from accumulating multi-bit errors, memory scrubbing [146, 363, 197,
196, 364, 365, 366, 148] is commonly employed: the entire memory is scanned to
correct single-bit errors.

We consider periodic refresh, RowHammer protection, and memory scrubbing as
_DRAM maintenance operations_ needed for reliable and secure operation of
modern and future DRAM chips. An ideal maintenance operation should
efficiently improve DRAM reliability and security with minimal system
performance and energy consumption overheads.

As DRAM technology node scales to smaller sizes, the reliability and security
of DRAM chips worsen. As a result, new DRAM chip generations necessitate
making existing maintenance operations more intensive (e.g., lowering the
refresh period [44, 118, 80]) and introducing new types of maintenance
operations (e.g., targeted refresh [103, 100, 119] and DDR5 RFM [44] as
RowHammer defenses). As the intensity and number of different maintenance
operations increase, it becomes increasingly more challenging to keep the
overhead of the maintenance operations low.

Unfortunately, modifying the DRAM maintenance operations is difficult due to
the current rigid DRAM interface that places the Memory Controller (MC)
completely in charge of DRAM control. Implementing new maintenance operations
(or changing existing ones) often necessitate modifications in the DRAM
interface, MC, and potentially other system components. Such modifications are
only possible with a new DRAM standard, which takes a long time to develop,
leading to slow progress in DRAM systems. For example, there was a five-year
gap between the DDR3 [7] and DDR4 [8] standards, and eight-year gap between
the DDR4 [8] and DDR5 [44] standards. In addition to waiting for a new
standard to come out, DRAM vendors also need to push their proposal regarding
the maintenance operations through the JEDEC committee so the new standard
includes the desired changes to enable new maintenance operations. Thus, we
believe a flexible DRAM interface that allows DRAM vendors to quickly
implement custom in-DRAM maintenance mechanisms would help to develop more
reliable and secure DRAM chips.

Our goal is to 1) ease the process of implementing new DRAM maintenance
operations and 2) enable more efficient in-DRAM maintenance operations. We
believe that enabling autonomous in-DRAM maintenance operations would
encourage innovation, reduce time-to-market, and ease adoption of novel
mechanisms that improve DRAM efficiency, reliability, and security. DRAM
architects will quickly deploy their new in-DRAM solutions to tackle
reliability and security problems of DRAM without demanding further changes in
the DRAM interface, MC, or other system components.

###  5.2 Motivation

In current DRAM chips, the Memory Controller (MC) is in charge of managing
DRAM maintenance operations such as periodic refresh, RowHammer protection,
and memory scrubbing. When DRAM vendors make modifications in a DRAM
maintenance mechanism, the changes often need to be reflected to the MC design
as well as the DRAM interface, which makes such modifications very difficult.
As a result, implementing new or modifying existing maintenance operations
requires multi-year effort by multiple parties that are part of the JEDEC
committee. A prime example to support our argument is the most recent DDR5
standard [44], which took almost a decade to develop after the initial release
of DDR4. DDR5 introduces changes to key issues we study in this paper: DRAM
refresh, RowHammer protection, and memory scrubbing. We discuss these changes
as motivating examples to show the shortcomings of the status quo in DRAM.

####  5.2.1 DRAM Refresh

DDR5 introduces _Same Bank Refresh (SBR)_ , which refreshes one bank in each
bank group at a time instead of simultaneously refreshing all banks as in DDR4
[343, 116]. _SBR_ improves bank availability as the MC can access the non-
refreshing banks while certain banks are being refreshed. DDR5 implements
_SBR_ by introducing a new REFsb command [44]. Implementing REFsb necessitates
changes in the DRAM interface _and_ MC.

####  5.2.2 RowHammer Protection

In DDR4, DRAM vendors implement in-DRAM RowHammer protection mechanisms by
performing Targeted Row Refresh (TRR) operations within the slack time
available when performing regular refresh. However, prior works have shown
that in-DRAM TRR is vulnerable to certain memory access patterns [103, 100,
119]. DDR5 specifies a _Refresh Management (RFM)_ mechanism that an MC
implements to aid the RowHammer protection implemented in DRAM chips. As part
of RFM, the MC uses a set of counters to keep track of row activations to each
DRAM bank. When a counter reaches a specified threshold value, the MC issues
the new RFM command to DRAM chips. A DRAM chip then internally performs an
undocumented operation with the time allowed for RFM to mitigate the RowHammer
effect. Since the first RowHammer work [73] in 2014, it took about 7 years to
introduce DDR5 RFM, which requires significant changes in the DRAM interface
and the MC design. Still, RFM is likely not a definitive solution for
RowHammer as it does not outline a specific RowHammer defense with security
proof. Rather, RFM provides additional time to a DRAM chip for internally
mitigating the RowHammer effect.

####  5.2.3 Memory Scrubbing

DDR5 adds support for on-die ECC and in-DRAM scrubbing. A DDR5 chip internally
performs ECC encoding and decoding when the chip is accessed. To perform DRAM
scrubbing, the MC must periodically issue the new _scrub command_ (for manual
scrubbing) or _all-bank refresh command_ (for automatic scrubbing). Similar to
_Same Bank Refresh_ and _RFM_ , enabling in-DRAM scrubbing necessitated
changes in the DRAM interface and in the MC design.

###  5.3 Self-Managing DRAM

We introduce the _Self-Managing DRAM_ () architecture.

####  5.3.1 Overview of

has a flexible interface that enables efficient implementation of multiple
DRAM maintenance operations within the DRAM chip. Our key insight is to
prevent the MC from accessing a DRAM row that is under maintenance by
prohibiting the MC from activating the row until the maintenance is complete.
The key idea of is to provide a DRAM chip with the ability to reject an ACT
command via a single-bit _negative-acknowledgment_ () signal. An informs the
MC that the DRAM row it tried to activate is under maintenance, and thus
temporarily unavailable. Leveraging the ability to reject an ACT, a
maintenance operation can be implemented _completely within_ a DRAM chip.

As Fig. 5.1 shows, preserves the general DRAM interface222We consider the
widely-available DDR4 as a baseline DRAM and explain the changes required to
implement on top of DDR4. However, other DRAM interfaces (e.g., DDR5, LPDDR5,
GDDR6, HBM2) can also be modified in a similar way to support . and only adds
a single uni-directional pin to the physical interface of a DRAM chip. The
extra pin is used for transmitting the signal from the DRAM chip to the MC.
Upon receiving an , the MC notices that the previous row activation is
rejected, and thus it need to be re-issued at later time. While introducing
changes in the MC to handle , also simplifies MC design and operation as the
MC no longer implements control logic to periodically issue DRAM maintenance
commands. For example, the MC does _not_ 1) prepare a bank for refresh by
precharging it, 2) implement timing parameters relevant to refresh, and 3)
issue REF commands. The MC still maintains the bank state information (e.g.,
whether and which row is open in a bank) and respects the DRAM timing
parameters associated with commands for performing access (e.g., ACT, PRE, RD,
WR).

?figurename? 5.1: A DRAM channel with four chips.

Fig. 5.2 shows the organization of a bank in an chip. divides the rows in a
DRAM bank into multiple _lock regions_. provides the number and the size of
the lock regions to the MC via DRAM _mode registers_ [343]. For each lock
region, stores an entry in a _Lock Region Table (LRT)_ to indicate whether or
not a lock region is reserved for performing a maintenance operation.

?figurename? 5.2:  bank organization in DRAM chip.

A maintenance operation and an ACT can be performed concurrently in the same
bank on different lock regions. To enable this, implements a _row address
latch_ in order to drive two local row decoders with two independent row
addresses.333Having a row address latch per lock region enables two or more
maintenance operations to concurrently happen on different lock regions within
a bank. However, to keep our design simple, we restrict a maintenance
operation to happen on one lock region while the MC can access another lock
region. Our design can be easily extended to increase concurrency of
maintenance operations across multiple lock regions. When a maintenance
operation and an ACT arrive at the same lock region at the same time, the
multiplexer shown in Fig. 5.2 prioritizes the maintenance operation and the
chip rejects the ACT.

For a maintenance operation to take place, the _Lock Controller_ first sets
the _lock bit_ in the LRT entry that corresponds to the lock region on which
the maintenance operation is to be performed. When the MC attempts to open a
row in a locked region, the Lock Controller generates an .

####  5.3.2 Handling an ACT_NACK Signal

Fig. 5.3 depicts a timeline that shows how the MC handles an signal. Upon
receiving an , the MC waits for _ACT Retry Interval_ () time to re-issue the
same ACT. It keeps re-issuing the ACT command once every until the DRAM chip
accepts the ACT. While waiting for , the MC can attempt activating a row from
a different lock region or bank, to overlap the latency with a useful
operation.

?figurename? 5.3: Handling in MC.

#####  5.3.2.1 Setting the _ACT Retry Interval_ ()

Setting to a very low or high value relative to the expected duration of the
maintenance operations can have a negative impact on system performance and
energy efficiency. When too low, the MC frequently re-issues an ACT, and the
DRAM chip rejects many of these ACT commands. The rejected ACT commands waste
energy and potentially delay other row activations that the MC could have
issued to serve other memory requests. When is too high, the MC may delay re-
issuing a rejected ACT for too long, and the ACT gets delayed significantly
even after the completion of the maintenance. We empirically find that
$\ARI=$62.5\text{\,}\mathrm{ns}$$ is a favorable configuration for the six
maintenance mechanisms that we evaluate in this work (section 5.4).

#####  5.3.2.2  Latency

An chip sends an (in case an ACT command is to be rejected) DRAM command bus
cycles after receiving the ACT. Thus, the MC knows that an ACT is successful
when it does _not_ receive an in cycles after issuing the ACT. It is desirable
for to be as low as possible so that the MC can be quickly notified when an
ACT fails, and it can attempt to activate a different row in the same bank
while waiting for to retry the rejected ACT. Further, if is larger than tRCD,
the latency of RD and WR commands increases (by
$\tnackplain{}-\texttt{{tRCD}}{}$) as the MC should not issue a RD or WR
without ensuring that the row is successfully opened.

The latency has three components: 1) the propagation delay (from the MC to the
DRAM chip) of the ACT, 2) the latency of determining whether or not the row to
be activated belongs to a locked region, and 3) the propagation delay (from
the DRAM chip to the MC) of the signal.

We estimate the overall latency based on the latency of an RD in a
conventional DRAM. An RD has a latency breakdown that resembles the latency
breakdown of a . An RD command 1) propagates from the MC to the DRAM chip, 2)
accesses data in a portion of the row buffer in the corresponding bank, and 3)
sends the data back to the MC. In the DDR4 standard [343], the latency between
issuing an RD and the first data beat appearing on the data bus is defined as
tCL (typically 22 cycles for DDR4-3200). The latency components 1) and 3) of
RD are similar to those of . Thus, the main difference between and tCL arises
from the second component. According to our evaluation, the latency of
accessing the Lock Region Table (LRT) is $0.053\text{\,}\mathrm{ns}$ (section
5.6.5). Given the relatively low complexity of the LRT compared to the
datapath that is involved during an RD, we believe the second component of the
latency breakdown and thus the overall latency can be designed to be much
smaller than tCL. We assume $=5$ cycles unless stated otherwise. In our
evaluations, we find that small latencies (e.g., $\leq\texttt{{tCL}}{}$) have
negligible effect on system performance mainly because the number of rejected
ACTs constitute a small portion of all ACTs.

#####  5.3.2.3  Divergence Across DRAM Chips

maintenance operations take place independently in each DRAM chip. Therefore,
when a DRAM rank, which can be composed of multiple DRAM chips operating in
lock step444DDRx systems typically consist of DRAM ranks built with multiple
chips (e.g., eight chips with 8-bit data bus in each chip), whereas LPDDRx
systems typically consist of DRAM ranks built with a single DRAM chip.,
receives an ACT command, some of the chips may send an while others do not.
Normally, divergence would not happen for maintenance mechanisms that perform
the exact same operation at the exact same time in all DRAM chips. However, a
mechanism can also operate differently in each DRAM chip, e.g., the Variable
Refresh () mechanism (section 5.4.1.2). As a result of this divergence, the
row becomes partially open in chips that do _not_ send .

As a solution, the MC can take one of the following two approaches. First, it
can issue a PRE command to close the partially open row. Upon receiving the
PRE, chips that sent an and do not have an open row can simply ignore the PRE.
The advantage of this approach is that, after the PRE, the MC can attempt to
open another row from the same bank. However, as a downside, precharging the
partially activated row would waste energy. As a second approach, the MC can
wait for and re-issue the same ACT command to attempt activating the row in
the chips that previously sent an signal. This approach does not waste row
activation energy but it prevents the MC from attempting to activate another
row in the same bank while waiting for . We empirically find that the second
approach performs slightly better (by 0.04% on average) mainly because the
benefits of the first approach are limited as a partially activated row cannot
be immediately precharged due to tRAS, which constitutes a large part of 555By
default, we set $\ARI=$62.5\text{\,}\mathrm{ns}$$ while tRAS is about
$35\text{\,}\mathrm{ns}$ [116].). Our analysis shows that under the worse-case
divergence (i.e., when each of the 16 chips in a rank perform refresh on a
different region at different time), performs 15.4% worse than with no
divergence, which still provides 7.8% average speedup over conventional DDR4
refresh for memory-intensive four-core workloads.

####  5.3.3 Region Locking Mechanism

locks rows at a _lock region_ granularity.

#####  5.3.3.1 Lock Region Size

A _lock region_ consists of a fixed number of consecutively-addressed DRAM
rows. To simplify the design, we set the lock region size such that a lock
region spans one or multiple subarrays. This is because a maintenance
operation uses the local row buffers in a subarray, and thus having a subarray
shared by multiple lock regions will cause a conflict when accessing a row in
a different lock region that maps to the subarray under maintenance. We design
and evaluate assuming a default lock region size of $16$ 512-row subarrays.
However, a lock region can be designed to span fewer than $16$ subarrays or it
can span the entire bank.

Modern DRAM chips typically use the density-optimized _open-bitline_
architecture [144, 146], which places sense amplifiers both on top and bottom
sides of a subarray and adjacent subarrays share sense amplifiers. With the
open-bitline architecture, the MC should not be allowed to access a row in a
subarray that is adjacent to one under maintenance. To achieve this, the Lock
Controller simply sends an when the MC attempts to activate a row in a
subarray adjacent to a subarray in a locked region. Consequently, when SMD
locks a region that spans $16$ 512-row subarrays, it prevents the MC from
accessing $18$ subarrays in a bank with $128K$ rows ($256$ subarrays). In the
_folded-bitline_ architecture [144, 146], adjacent subarrays do not share
sense amplifiers with each other. Therefore, SMD prevents access only to the
subarrays in a locked region. We evaluate SMD using the density-optimized
open-bitline architecture.

#####  5.3.3.2 Locking a Region

A maintenance operation can be performed only on DRAM rows in a locked region.
Therefore, a maintenance mechanism must lock the region that includes the rows
that should undergo a maintenance. A maintenance mechanism can _only_ lock a
region that is _not_ already locked. This is to prevent different maintenance
mechanisms from interfering with each other. Once having locked a region, the
region remains locked until the completion of the maintenance. Afterward, the
maintenance mechanism releases the lock to allow 1) the MC to access the
region and 2) other maintenance mechanisms to lock the same region.

#####  5.3.3.3 Ensuring Timely Maintenance Operations

A maintenance mechanism _cannot_ lock a region that has an active DRAM row. To
lock the region, the maintenance mechanism must wait for the MC to precharge
the row. The MC may keep a DRAM row active for too long, which may delay a
maintenance operation to a point that affects DRAM reliability (e.g., delaying
a refresh operation too long as such a retention failure occurs). To prevent
this, we rely on the existing time limit for a row to remain open, i.e., tRAS
has an upper limit of 9x tREFI [343, 116, 340]).

####  5.3.4 Impact to Request Scheduling

partitions DRAM into small regions to perform maintenance operations. This
allows to pause accesses to small DRAM regions while the rest of the DRAM
remains available to access. In contrast, existing DRAM chips perform
maintenance operations at a larger granularity. For example, with existing
DRAM chips, MCs perform refresh at bank or rank granularity, pausing accesses
to an entire bank/rank. Although the MC can postpone a refresh operation for a
small time interval (e.g., 8x tREFI), it does so just based on information
(e.g., queue occupancy) available to the MC, but without the knowledge of
future requests. As a result, processing units are stalled with existing DRAM
chips when requests enter the MC after a maintenance operation starts.
significantly improves the overall availability of DRAM by pausing accesses to
small regions and improves performance as we show in section 5.6.1 and section
5.6.2 (e.g., for memory intensive four-core workloads, a system with -based
refresh achieves 8.7% average speedup compared to a system with conventional
DDR4). Therefore, improves the overall availability of DRAM, and thus reduces
the performance overhead of DRAM maintenance operations.

###  5.4 SMD Maintenance Mechanisms

We propose -based maintenance mechanisms for three use cases. However, is not
limited to these three use cases and it can be used to support more operations
in DRAM.

####  5.4.1 Use Case 1: DRAM Refresh

In conventional DRAM, the MC periodically issues REF commands to initiate a
DRAM refresh operation. This approach is inefficient due to three main
reasons. First, transmitting $8192$ REF commands over the DRAM command bus
within the refresh period (e.g., 64, 32, or even $16\text{\,}\mathrm{ms}$
depending on the refresh rate) consumes energy and increases the command bus
utilization. Due to transmitting a REF over the command bus, the MC may delay
a command to another rank in the same channel, which increases DRAM access
latency [41]. Second, an entire bank becomes inaccessible while being
refreshed although a REF command refreshes only a few rows in the bank. This
incurs up to 50% loss in memory throughput [43]. Third, new mechanisms that
reduce refresh overhead (e.g., by skipping refreshes on retention-strong rows)
are difficult to implement. Even a simple optimization of enabling per-bank
refresh in DDR4 requires changes to the DRAM interface and the MC.

Leveraging , we design two maintenance mechanisms for DRAM refresh: _Fixed-
Rate Refresh_ and _Variable Refresh_.

#####  5.4.1.1 Fixed-Rate Refresh ()

refreshes DRAM rows in a fixed time interval (i.e., tREFI), similar to
conventional DRAM refresh. It enables refresh-access parallelization without
any burden on the MC beyond the changes required for implementing the
interface. As with any maintenance operation in , the MC can activate a row
(in any bank) in regions that are not locked while refreshes rows in a locked
region. refreshes $RG$ (Refresh Granularity) number of rows from a lock region
and switches to refreshing another region to 1) limit the time for which a
single lock region remains under maintenance and 2) prevent memory requests
from waiting too long for the region to become available for access.

operates independently in each DRAM bank and uses three counters for managing
the refresh operations in a bank: _pending refresh counter_ , _lock region
counter_ , and _row address counter_. Fig. 5.4 illustrates operation. The
_pending refresh counter_ is used to slightly delay refresh operations within
the slack666DDR4 [343, 116, 340] allows the MC to postpone issuing up to $8$
REF commands in order to serve pending memory requests first. given in the
DRAM standard until the region to be refreshed can be locked. The _pending
refresh counter_ is initially zero and increments it by one at the end of a
tREFI interval 1. allows up to $8$ refresh operations to be accumulated in the
_pending refresh counter_. As we explain in section 5.3.3.3, because the MC
can keep a row open for a limited time, the _pending refresh counter_ never
exceeds the value $8$, and this is how ensures that the refresh operations do
_not_ lag behind more than the window of $8$ refresh operations.

?figurename? 5.4: Fixed-Rate Refresh () Operation.

The _lock region_ and _row address_ counters indicate the next row to refresh.
When _pending refresh counter_ is greater than zero, attempts to lock the
region indicated by the _lock region counter_ every clock cycle until it
successfully locks the region 2. In some cycles, may fail to lock the region
either because the lock region contains an active row or the region is locked
by another maintenance mechanism. When successfully locks the region, it
initiates a refresh operation that refreshes $RG$ number of sequentially-
addressed rows in the lock region starting from the row indicated by the _row
address counter_ 3. The refresh operation is carried out similarly as in
conventional DRAM, essentially by activating and precharging a row to restore
the charge in its DRAM cells. Making $RG$ larger increases the latency of a
single refresh operation, which prolongs the time that a lock region remains
unavailable for access. In contrast, small $RG$ causes switching from one lock
region to another very often, increasing interference with accesses. We
empirically find $RG=16$ to be a favorable design point.

After the refresh operation completes, releases the locked region 4 and
increments _only_ the _lock region counter_. When the _lock region counter_
rolls back to zero, also increments by one the _row address counter_ 5.
Finally, decrements the _target refresh counter_ 6.

#####  5.4.1.2 Variable Refresh ()

In conventional DRAM, all DRAM rows are uniformly refreshed with the same
refresh period. However, the actual data retention times of different rows in
the same DRAM chip greatly vary mainly due to manufacturing process variation
and design-induced variation [43, 49, 65, 122, 126, 46]. In fact, only
hundreds of “weak” rows across an entire $32\text{\,}\mathrm{Gbit}$ DRAM chip
require to be refreshed at the default refresh rate, and a vast majority of
the rows can correctly operate when the refresh period is doubled or
quadrupled [43]. Eliminating unnecessary refreshes to DRAM rows that do not
contain weak cells can significantly mitigate the performance and energy
consumption overhead of DRAM refresh [43].

We develop _Variable Refresh_ (), a mechanism that refreshes different rows at
different refresh rates depending on the retention time characteristics of the
weakest cell in each row. enables implementing with no further changes in the
DRAM interface and the MC. Our design demonstrates the versatility of in
supporting different DRAM refresh mechanisms.

The high-level idea of is to group DRAM rows into multiple retention time bins
and refresh a DRAM row based on the retention time bin that it belongs to. To
achieve low design complexity, uses only two bins: 1) _retention-weak_ rows
that have retention time less than $RT_{weak\\_row}$ and 2) rows that have
retention time more than $RT_{weak\\_row}$. Inspired by RAIDR [43], stores the
addresses of retention-weak rows using a per-bank Bloom Filter [370], which is
a space-efficient probabilistic data structure for representing set
membership. We assume retention-weak rows are already inserted into the Bloom
Filters by the DRAM vendors during post-manufacturing tests.777Alternatively,
can be used to develop a maintenance mechanism that performs retention
profiling. We believe enables such profiling in a seamless way. Due to limited
space, we leave the development and analysis of it to future work.

The operation of resembles the operation of with the key difference that
sometimes skips refreshes to a row that is not in the Bloom Filter, i.e., a
row with high retention time. Fig. 5.5 illustrates how operates. uses the same
three counters as . also uses a _refresh cycle counter_ , which is used to
indicate the refresh period when all rows (including retention-strong rows)
must be refreshed. The _refresh cycle counter_ is initially zero and gets
incremented at the end of every refresh period, i.e., when the entire DRAM is
refreshed.

?figurename? 5.5: Variable Refresh () Operation.

increments the _pending refresh counter_ by one at the end of a tREFI interval
1. When the _pending refresh counter_ is greater than zero, determines whether
or not the $RG$ number of rows, starting from the address indicated by the
_lock region_ and _row address_ counters, are retention-weak rows by testing
their row addresses using the bank’s Bloom Filter 2a. refreshes the rows that
are present in the Bloom Filter every time when it is their turn to be
refreshed, as indicated by the _lock region_ and _row address_ counters. In
contrast, refreshes the rows that are _not_ present in the Bloom Filter _only_
when the _refresh cycle counter_ has a value that is multiple of $VR\\_factor$
2b, which is specified by Equation 5.1.

$VR\\_factor=\frac{RT_{weak\\_row}}{RefreshPeriod}$ (5.1)

Unless stated otherwise, we assume $RT_{weak\\_row}=$128\text{\,}\mathrm{ms}$$
and $RefreshPeriod=$32\text{\,}\mathrm{ms}$$. Therefore, refreshes the DRAM
rows that are not in the Bloom Filter once every four consecutive refresh
periods as these rows can retain their data correctly for at least four
refresh periods.

After determining which DRAM rows need refresh, operates in a way similar to .

####  5.4.2 Use Case 2: RowHammer Protection

RowHammer is a DRAM reliability issue mainly caused due to the small DRAM cell
size and the short cell-to-cell distance in modern DRAM chips. Repeatedly
activating and precharging (i.e., hammering) a (aggressor) DRAM row creates a
disturbance effect, which accelerates charge leakage and causes bit errors in
the cells of a nearby (victim) DRAM row [328, 334, 335, 331, 369, 330, 329,
332].

The three major DRAM manufacturers equip their existing DRAM chips with in-
DRAM RowHammer protection mechanisms, generally referred to as Target Row
Refresh (TRR) [103, 100, 119]. At a high level, TRR protects against RowHammer
by detecting an aggressor row and refreshing its victim rows. Because a
conventional DRAM chip _cannot_ initiate a refresh operation by itself, TRR
refreshes victim rows by taking advantage of the slack time available in the
refresh latency (i.e., tRFC), originally used to perform _only_ periodic DRAM
refresh [103, 100, 119]. This approach has two major shortcomings that limit
the protection capability of TRR [103]. First, the limited slack time in tRFC
puts a hard constraint on the number of TRR-induced refreshes. This
restriction results in insufficient protection to victim rows, especially when
DRAM becomes more RowHammer vulnerable with DRAM technology scaling. Second,
TRR-induced refresh takes place only at a certain rate (i.e., at most on every
REF ). Recent works [103, 100, 119, 247] demonstrate a variety of new
RowHammer access patterns that circumvent the TRR protection in chips of all
three major DRAM vendors, proving that the existing DRAM interface is not well
suited to enable strong RowHammer protection especially as RowHammer becomes a
bigger problem with DRAM technology scaling.

We use to develop two maintenance mechanisms that overcome the limitations of
the existing TRR mechanisms by initiating victim row refresh within the DRAM
chip.

#####  5.4.2.1 Probabilistic RowHammer Protection

Inspired by PARA [73], we implement an in-DRAM maintenance mechanism called
Probabilistic RowHammer Protection (). The high level idea is to refresh the
nearby rows of an activated row with a small probability. PARA is proposed as
a mechanisms in the MC, which makes it difficult to adopt since victim rows
are not always known to the MC. enables us to overcome this issue by
implementing the PARA-inspired mechanism completely within the DRAM chip. In
addition, avoids explicit ACT and PRE commands to be sent over the DRAM bus.
Fig. 5.6 illustrates the operation of .

?figurename? 5.6: Probabilistic RowHammer Protection () Operation.

On a DRAM row activation, marks the activated row as an aggressor with a small
probability of $P_{mark}$ 1. It marks an aggressor row using a per-bank
_Marked Rows Table (MRT)_ , that contains an entry for each lock region in the
bank. An entry consists of the marked row address and a _valid_ bit. The bit
length of the address depend on the size of a lock region. For example, an MRT
entry has a 13-bit address field when the lock region size is $8192$ rows.
When MRT contains a marked row, locks the corresponding region 2 and refreshes
the neighbor rows of the marked row 3. This step can easily accommodate blast
radius [78] and any address scrambling. Once the neighbor rows are refreshed,
unlocks the region and unmarks the row in MRT 4.

#####  5.4.2.2  with Aggressor Row Detection

refreshes victim rows with a small probability on every row activation, even
does so for a row that has been activated only a few times. This results in
unnecessary victim refreshes, especially for high $P_{mark}$ values that
strengthen the RowHammer protection as DRAM cells become more vulnerable to
RowHammer with technology scaling.

We propose , which detects potential aggressor rows and probabilistically
refreshes only their victim rows. The key idea of is to track frequently-
activated rows in a DRAM bank and refresh the neighbor rows of these rows
using the region locking mechanism of .

tracks frequently-activated rows, within a rolling time window of length
$L_{RTW}$, using two Counting Bloom Filters (CBF) [371] that operate in time-
interleaved manner. CBF is a Bloom Filter variant that represents the
upperbound for the number of times an element is inserted into the CBF. We
refer the reader to prior work for background on CBFs [78, 372].

Depicted in Fig. 5.7, operation is based on 1) detecting a row that has been
activated more than $ACT_{max}$ times within the most recent $L_{RTW}$
interval and 2) refreshing the neighbor rows of this row. $ACT_{max}$ must be
set according to the minimum hammer count needed to cause a RowHammer bit flip
in a given DRAM chip. A recent work shows that $4.8K$ activations can cause
bit flips in LPDDR4 chips [70]. We conservatively set $ACT_{max}$ to $1K$.
$L_{RTW}$ must be equal to or larger than the refresh period in order to track
all activations that happen until rows get refreshed by regular refresh
operations. We set $L_{RTW}$ equal to the refresh period.

?figurename? 5.7:  Operation.

Initially, one of the CBFs is in _active_ mode while the other is in _passive_
mode. When activating a row, inserts the address of the activated row to both
CBFs 1. Then, tests the active CBF to check if the accumulated insertion count
exceeds the $ACT_{max}$ threshold 2. If so, marks the row in the _Marked Rows
Table_ to refresh its neighbor rows with the probability of $P_{mark}$ 3. does
not always mark the row because it is impossible to reset _only_ the counters
that correspond to the marked row address in the CBFs. If always marked, a
subsequent activation of the same row would again cause the row to be marked,
leading to unnecessary neighbor row refresh until all CBF counters are reset,
which happens at the end of the $\frac{L_{RTW}}{2}$ interval. After a row is
marked, steps 4\- 6 are same as steps 2\- 4 in . Finally, at the end of an
$\frac{L_{RTW}}{2}$ interval, clears the active CBF and swaps the two CBFs to
continuously track row activations within the most recent $L_{RTW}$ window 7.

#####  5.4.2.3 Deterministic RowHammer Protection

and are probabilistic mechanisms that provide statistical security against
RowHammer attacks with $P_{mark}$ being the security parameter. On an
extremely security-critical system, a deterministic RowHammer protection
mechanisms can guarantees mitigation of RowHammer bit flips at all times.

We use to implement , a deterministic RowHammer protection mechanism based on
the Graphene [79] mechanism, which uses the Misra-Gries algorithm [373] for
detecting frequent elements in a data stream to keep track of frequently
activated DRAM rows. Graphene is provably secure RowHammer protection
mechanism with zero chance to miss an aggressor row activated more than a
predetermined threshold. Different from Graphene, we implement completely
within a DRAM chip by taking advantage of , whereas Graphene requires the
memory controller to issue neighbor row refresh operations when necessary.

The key idea of is to maintain a per-bank _Counter Table (CT)_ to track the
$N$ most-frequently activated DRAM rows within a certain time interval (e.g.,
refresh period of tREFW). Fig. 5.8 illustrates the operation of .

?figurename? 5.8:  Operation.

When receives an ACT, it check if the activated row address ($Id_{row}$) is
already in CT 1. If so, increments the corresponding counter in CT by one 2.
If $Id_{row}$ is not in CT, finds the smallest counter value ($min_{counter}$)
in CT and compares it to the value of the _spillover counter (SP)_ 3, which is
initially zero. If SP is equal to $min_{counter}$, replaces the row address
corresponding to $min_{counter}$ in CT with $Id_{row}$ 4 and increments the
corresponding CT counter by one 2. If SP is smaller than $min_{counter}$,
increments SP by one 5. When a CT counter is incremented in step 2, checks if
the counter value is a multiple of $ACT_{max}$ 6, which is the maximum number
of times a row can be activated without refreshing its neighbors. If so,
refreshes the neighbors of $Id_{row}$ 7. To prevent the counters from
overflowing, resets the CT counters and SP on every tREFW interval.

To ensure that no row is activated more than $ACT_{max}$ without refreshing
its neighbor rows, the number of CT counters ($N$) must be configured
according to the following formula:

$N>\frac{ACT_{\texttt{{tREFW}}}}{ACT_{max}}-1$ (5.2)

where $ACT_{\texttt{{tREFW}}}$ is the maximum number of activations that the
memory controller can perform within a tREFW interval in a single bank.

We refer the reader to [79] for more details on the Graphene mechanism and its
security proof. The operation of is similar to the operation of Graphene with
the difference of being implemented completely within a DRAM chip, which does
not affect the underlying operation, and thus the security proof of Graphene
applies to .

####  5.4.3 Use Case 3: Memory Scrubbing

To mitigate the increasing bit error rates that are mainly caused by the
continued DRAM technology scaling, DRAM vendors equip their DRAM chips with
on-die Error Correction Codes (ECC) [135, 141, 157, 42]. On-die ECC is
designed to correct a single bit error assuming that a failure mechanism is
unlikely to incur more than one bit error in a codeword [141]. However, even
when the assumption always holds, a failure mechanism can gradually incur two
or more bit errors over time. A widely-used technique for preventing the
accumulation of an uncorrectable number of bit errors is _memory scrubbing_.
Memory scrubbing describes the process of periodically scanning the memory for
bit errors in order to correct them before more errors occur.

We propose -based Memory Scrubbing (), which is an in-DRAM maintenance
mechanism that periodically performs scrubbing on DRAM chips with on-die ECC.
Using , we implement without any further changes to the DRAM interface and the
MC. Compared to conventional MC-based scrubbing, eliminates moving data to the
MC by scrubbing within the DRAM chip, and thus reduces the performance and
energy overheads of memory scrubbing.

operation resembles the operation of . Similar to , maintains _pending scrub
counter_ , _lock region counter_ , and _row address counter_. increments the
pending scrub counter at fixed intervals of $tScrub$. When the pending scrub
counter is greater than zero, attempts to lock the region indicated by the
_lock region counter_. After locking the region, performs scrubbing operation
on the row indicated by the _row address counter_. The scrubbing operation
takes more time than a refresh operation as performing scrubbing on a row
consists of three time consuming steps for each codeword in the row: 1)
reading the codeword, 2) performing ECC decoding and checking for bit errors,
and 3) encoding and writing back the new codeword into the row only when the
decoded codeword contains a bit error. Refreshing a row takes $tRAS+tRP\approx
50ns$, whereas scrubbing a row takes
$tRCD+128*tBL+tRP\approx$350\text{\,}\mathrm{ns}$$ when no bit errors are
detected.888We assume ECC decoding/encoding hardware is fully pipelined. In
case of a bit error, writing a corrected codeword incurs
$4*tBL=$2.5\text{\,}\mathrm{ns}$$ additional latency. Therefore, keeps a
region locked for much longer than . When the scrubbing operation is complete,
releases the lock region and increments the _lock region_ and _row address_
counters, and decrements the _pending scrub counter_ as in .

###  5.5 Experimental Methodology

We extend Ramulator [138, 300] to implement and evaluate the six maintenance
mechanisms (, , , , , and ) that we describe in section 5.4. We use DRAMPower
[374, 375] to evaluate DRAM energy consumption. We use Ramulator in CPU-trace
driven mode executing traces of representative sections of our workloads
collected with a custom Pintool [376]. We warm-up the caches by fast-
forwarding 100 million instructions. We simulate each representative trace for
500 million instructions (for multi-core simulations, we simulate until each
core executes at least 500 million instructions).

We use the system configuration provided in Table 5.1 in our evaluations.
Although our evaluation is based on DDR4 DRAM, the modifications required to
enable can be adopted in other DRAM standards, as we explain in section 5.6.5.

?tablename? 5.1: Simulated system configuration.

Processor |  $4\text{\,}\mathrm{GHz}$ & 4-wide issue CPU core, 1-4 cores, 8 MSHRs/core, 128-entry instruction window
---|---
Last-Level Cache |  $64\text{\,}\mathrm{B}$ cache-line, 8-way associative, $4\text{\,}\mathrm{MiB}$/core
Memory Controller |  64-entry read/write request queue, FR-FCFS-Cap [172]
DRAM |  DDR4-3200 [343], $32\text{\,}\mathrm{ms}$ refresh period, 4 channels, 2 ranks, 4/4 bank groups/banks, 128K-row bank, 512-row subarray, $8\text{\,}\mathrm{KiB}$ row size

Workloads. We evaluate 44 single-core applications from four benchmark suites:
SPEC CPU2006 [377], TPC [378], STREAM [379], and MediaBench [380]. We classify
the workloads in three groups based on their memory intensity, which we
measure using misses-per-kilo-instructions (MPKI) in the last-level cache
(LLC). The low, medium, and high memory intensity groups consist of workloads
with $MPKI<1$, $1\leq MPKI\leq 10$, and $MPKI\geq 10$. We randomly combine
single-core workloads to create multi-programmed workloads. Each multi-
programmed workload group, 4c-low, 4c-medium, and 4c-high, contains $20$ four-
core workloads with low, medium, and high memory intensity.

Metrics. We use Instructions Per Cycle (IPC) to evaluate the performance of
single-core workloads. For multi-core workloads, we evaluate the system
throughput using the weighted speedup metric [381, 382, 383].

###  5.6 Evaluation

We evaluate the performance and energy efficiency of -based maintenance
mechanisms.

####  5.6.1 Single-core Performance

Fig. LABEL:fig:single_core_perf shows the speedup of single-core workloads
when using the following maintenance mechanisms: 1) , 2) , 3) , 4) , 5) , 6) ,
and 7) the combination of , , and (-Combined).999We individually evaluate , ,
, and using as a refresh mechanism since is very simple and easy to implement.
In -Combined, we prefer SMD-PRP over SMD-PRP+ and SMD-DRP to keep the DRAM
chip area overhead minimal. Based on [43], for , we conservatively assume 0.1%
of rows in each bank need to be refreshed every $32\text{\,}\mathrm{ms}$ while
the rest retain their data correctly for $128\text{\,}\mathrm{ms}$ and more.
uses a $8K$-bit Bloom Filter with $6$ hash functions. and refresh the victims
of an activated row with a high probability, i.e., $P_{mark}=1\%$. operates
with an aggressive 5-minute scrubbing period.101010We analyze , , , and at
various configurations and find that their overheads are relatively low even
at more aggressive settings. We calculate the speedup compared to DDR4 DRAM
with a nominal $32\text{\,}\mathrm{ms}$ refresh period. To demonstrate the
maximum speedup achievable by eliminating the entire DRAM refresh overhead,
Fig. LABEL:fig:single_core_perf also includes the performance of hypothetical
DRAM that does not require refresh (_NoRefresh_). The figure shows $22$
workloads that have at least 10 Last-Level Cache _Misses per Kilo Instruction
(MPKI)_. _GMEAN-22_ provides the geometric mean of the $22$ workloads and
_GMEAN-ALL_ of all $44$ single-core workloads that we evaluate.

We make five key observations. First, provides 5.7% average speedup (up to
23.2%) over conventional DDR4 refresh (84.1% of the speedup that _NoRefresh_
provides). Although and DDR4 have similar average latency to refresh a single
DRAM row, outperforms DDR4 refresh due to two main reasons: 1) enabling
concurrent access and refresh of two different _lock regions_ within a DRAM
bank and 2) completely eliminating the REF commands on the DRAM commands bus
to reduce the command bus utilization. requires very low area overhead and no
information with respect to DRAM cell characteristics, yet provides
significant speedup.

Second, provides 6.1% average speedup (up to 24.5%), achieving 89.9% of the
speedup that _NoRefresh_ provides. provides higher speedup due to eliminating
unnecessary refresh operations to retention-strong rows. Compared to , ’s
performance benefits are limited because significantly mitigates the refresh
overhead by overlapping refresh operations with accesses to other lock
regions, leaving small opportunity for further improvement by skipping
refreshes to retention-strong rows.

Third, both and perform close to the hypothetical “NoRefresh” DRAM. On
average, / provide 83.8%/86.8% of the speedup that “NoRefresh” provides
compared to the DDR4 baseline.

Fourth, although the overheads of the , , and mechanisms partially negate the
performance benefits of , they still achieve average (maximum) speedup of
4.7%/5.7%/5.4% (9.4%/23.2%/12.9) over the DDR4 baseline, when integrated on
top of .

Fifth, -Combined improves performance by 6.3% (up to 24.5%), showing that
enables robust RowHammer protection and frequent (5-minute) memory scrubbing
while still improving system performance.

####  5.6.2 Multi-core Performance

Fig. 5.9 shows weighted speedup (normalized to the weighted speedup of the
DDR4 baseline) for 60 four-core workloads (20 per memory intensity level). The
bars (error lines) represent the average (minimum and maximum) weighted
speedup across the 20 workloads in the corresponding group. We make three
major observations.

?figurename? 5.9: Four-core weighted speedup

First, we observe the largest average speedup in memory-intensive four-core
workloads, i.e., 4c-high. / improve average speedup by 8.7%/9.2% (9.9%/10.2
maximum), which corresponds to 86.8%/91.2% of the speedup that hypothetical
“NoRefresh” achieves over DDR4.

Second, combining ++ provides 9.1% average (10.1% maximum) improvement in
weighted speedup, which indicates that and incur only small performance
overhead on top of .

Third, the performance benefits become smaller as the memory intensity of the
workloads decrease. Specifically, 4c-medium achieves lower speedup than
4c-high, and 4c-low achieves lower speedup than 4c-medium.

Performance Summary. The new DRAM refresh mechanisms and significantly improve
system performance, achieving speedup close to that provided by the
hypothetical “NoRefresh” DRAM. enables efficient and robust RowHammer
protection (,, and ) and memory scrubbing () that still provide significant
speedup when integrated with . Overall, enables DRAM that is both faster and
more robust than DDR4.

####  5.6.3 Energy Consumption

Fig. 5.10 shows the average DRAM energy consumption normalized to the DDR4
baseline for single- and four-core workloads. We make three major
observations.

?figurename? 5.10: DRAM energy consumption

First, reduces DRAM energy for both single- and four-core workloads (by 5.9%