
activation count reaches a certain threshold value within a
refresh window (usually denoted as MAC [82] or
HCf irst
[2]).
Prior works devise many dierent RowHammer-based at-
tacks, such as denial of service [17, 18], privilege escala-
tion [4
–
7, 9, 17, 18, 22, 31, 83, 84], secret data leakage [25, 32, 33],
manipulation of the application correctness [24, 30] or private
key recovery [85,86]. A subset of these attacks require no phys-
ical access to a victim computing system; for example, attacks
leveraging RDMA [34] or attacks in JavaScript programs [6].
3. Methodology
In order to thoroughly characterize the correlation between
RowHammer and temperature and analyze the potential of the
SpyHammer attack, we use an FPGA-based infrastructure that
allows us to avoid uncontrolled interference in the system that
might skew the results and lead to wrong insights and conclu-
sions. To perform a SpyHammer attack on a real commodity
computer system, we can use the methodology proposed in
previous works [3,31, 87] (not demonstrated in this paper).
3.1. Testing Infrastructure
We experimentally study DDR4 DRAM chips across a wide
range of temperatures. We use the DRAM Bender frame-
work [88, 89], which supports DDR4 modules, and a highly
accurate temperature controller infrastructure.
3.1.1. DRAM Bender. Figure 1 shows the DRAM Bender setup
for testing DDR4 DRAM modules. We use the Xilinx Alveo
U200 [90] FPGA board in all of our tests.
(a)$Temperature$
Controller
(b)$DRAM$+$Heater
(c)$FPGA
Figure 1: DRAM Bender Infrastructure: (a) temperature con-
troller, (b) DRAM module clamped with heater pads, and
(c) FPGA board programmed with DRAM Bender
[88].
We use an FPGA board with DRAM Bender (Figure 1c) to
perform all our RowHammer tests. We monitor and adjust the
temperature of DRAM chips under test with a temperature
controller (Figure 1a). This infrastructure provides us with ne-
grained control over the timing between DRAM commands.
We enforce all timing parameters dened by JEDEC [82] to
ensure reliable operation.
3.1.2. Temperature Controller. To regulate the temperature
in DRAM modules, we use silicone rubber heaters pressed to
both sides of the DDR4 module (Figure 1c). To reduce the
heat leakage, we apply two layers of insulation around the
DRAM module under test and the heater pads: 1) a layer of
reective aluminum sheets covering the DRAM and the heater
pads and 2) a layer of insulation sheets made of PTFE, a heat-
resistant material. To measure the actual temperature of DRAM
chips, we use a thermocouple, which we place between the
rubber heaters and the DDR4 chips. We connect the heater
pads and the thermocouple to a Maxwell FT200 temperature
controller (Figure 1a), which keeps the temperature stable by
implementing a closed-loop PID controller. Our host machine
communicates with the temperature controller via an RS485
channel. Using this feature, we build custom software that
enables us to automate the management of the temperature
and integrate it into our testing infrastructure. In our tests
using this infrastructure, we measure temperature with an
accuracy of ±0.1◦C.
3.2. Testing Methodology
Disabling Sources of Interference. We disable all DRAM
self-regulation events except the calibration signals, such as
ZQ, for signal integrity so that we ensure that the observed
errors are solely caused by RowHammer. We also make sure
that our tests nish before retention errors manifest.
To the best of our knowledge, we also disable all DRAM-
level (e.g., TRR [82]) and system-level RowHammer mitigation
mechanisms (e.g., pTRR [91]) along with all forms of rank-level
error-correction codes (ECC), which could obscure RowHam-
mer bitips. Based on the prior work’s observations [2, 3],
on-DRAM-die RowHammer mitigation mechanisms (i.e., TRR)
take action when the DRAM services a refresh (REF) command.
The DRAM modules we test do not implement error correction
internally.
RowHammer Access Sequence. We use a common access
sequence used in previous works [1, 2, 78] as the worst-case
access pattern, in which we 1) hammer the two rows that are
adjacent to the victim row (i.e., aggressor rows), and 2) access
the aggressor rows as frequently as possible. In our tests, we
perform a double-sided RowHammer attack [1, 2].
Data Pattern. We conduct our experiments on a DRAM mod-
ule by using the module’s worst-case data pattern (
W CDP
).
We identify the
W CDP
as the pattern that experiences the
largest number of bitips among seven dierent data patterns
that prior research on DRAM characterization uses [2,36, 46
–
49, 58], presented in Table 1: colstripe, checkered, rowstripe,
and random (we also test the complements of the rst three).
For each RowHammer test, we write the corresponding data
pattern to the victim row (
V
in Table 1), and to the 8 previous
(V−[1...8]) and next (V+ [1...8]) physically-adjacent rows.
Table 1: Data patterns used in our RowHammer analyses.
Row Address Colstripe†Checkered†Rowstripe†Random
V∗±[0,2,4,6,8] 0x55 0x55 0x00 random
V∗±[1,3,5,7] 0x55 0xaa 0xff random
∗Vis the physical address of the victim row
†We also test the complements of these patterns
Metrics. We compare the
BER
across all our tests at a con-
stant hammer count of 150K per aggressor row. We also iden-
tify the DRAM cells that ip only at a particular temperature
point (i.e., canary cells).
3