# SpyHammer: Using RowHammer to
Remotely Spy on Temperature

Lois Orosa1,2 Ulrich Rührmair3,4 A. Giray Yağlıkçı1 Haocong Luo1 Ataberk
Olgun1
Patrick Jattke1 Minesh Patel1 Jeremie Kim1 Kaveh Razavi1 Onur Mutlu1
1 _ETH Zürich_ 2 _Galicia Supercomputing Center (CESGA)_ 3 _LMU München_ 4
_University of Connecticut_

###### Abstract

RowHammer is a DRAM vulnerability that can cause bit errors in a victim DRAM
row by just accessing its neighboring DRAM rows at a high-enough rate. Recent
studies demonstrate that new DRAM devices are becoming increasingly more
vulnerable to RowHammer, and many works demonstrate system-level attacks for
privilege escalation or information leakage. In this work, we leverage two key
observations about RowHammer characteristics to spy on DRAM temperature: 1)
RowHammer-induced bit error rate consistently increases (or decreases) as the
temperature increases, and 2) some DRAM cells that are vulnerable to RowHammer
cause bit errors only at a particular temperature. Based on these
observations, we propose a new RowHammer attack, called SpyHammer, that spies
on the temperature of critical systems such as industrial production lines,
vehicles, and medical systems. SpyHammer is the first practical attack that
can spy on DRAM temperature. SpyHammer can spy on absolute temperature with an
error of less than $\pm$$2.5\text{\,}\mathrm{\SIUnitSymbolCelsius}$ at the
$90^{\mathrm{th}}$ percentile of tested temperature points, for 12 real DRAM
modules from 4 main manufacturers.

##  I Introduction

RowHammer is a DRAM vulnerability where a DRAM cell experiences a bit-flip
when the cells nearby it are rapidly and frequently accessed [1]. Recent works
[2, 3] demonstrate that modern DDR4 DRAM devices are more vulnerable to
RowHammer than their predecessor DDR3 devices, suggesting that RowHammer is an
important DRAM vulnerability issue that is becoming increasingly severe as
DRAM manufacturing technology nodes scale down. Using RowHammer, many works
demonstrate attacks that 1) escalate privileges at system-level, 2) leak
secret information, and 3) manipulate critical application outputs [4, 5, 6,
7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 3,
26, 27, 28, 29, 30].

In this work, we propose SpyHammer, a new attack that uses RowHammer to spy on
DRAM temperature with high accuracy. Our attack can be performed with minimal
knowledge of the target computing system. SpyHammer can be used to compromise
the security and confidentiality of several critical systems that use DRAM.
SpyHammer can compromise a victim computing system to achieve two goals.
First, it can identify the utilization of a computer system, as the compute
and memory intensity of a workload can change the temperature of the system.
For example, an attacker could infer if a server is at its peak hour by
identifying the temperature using SpyHammer. Second, it can measure the
ambient temperature, which may convey information about the state of a larger
system that contains the target computing system (e.g., a car, a drone, or an
industrial manufacturing machinery). For example, the temperature of a car’s
engine may rise if the engine is operating at high revs. SpyHammer can also
compromise privacy. For example, by spying the temperature of a house (or
different instances of a house), an attacker can infer the habits of the
person(s) living in that house. Tracking the temperature could give
information about at which times the person(s) leaves or enter the house, in
which instance of the house the person is, etc.

To this end, we leverage two key observations about RowHammer to spy on DRAM
temperature: 1) RowHammer-induced bit error rate consistently increases (or
decreases) when the temperature increases, and 2) some DRAM cells that are
vulnerable to RowHammer experiment bit errors only at a specific temperature.
Using these observations, we build an attack, called SpyHammer, that infers
the temperature of DRAM chips by just characterizing DRAM cells that exhibit
RowHammer-induced bit errors in the address space of the attacker, without
requiring any hardware or system software modifications. We propose two
variants of the SpyHammer attack, each with a different threat model.

First, a variant of SpyHammer spies on _relative temperature changes_ that
requires no prior physical access to or knowledge of the victim DRAM module.
Although two DRAM modules of the same model and manufacturing date may have
different Bit Errors per Row ($BER$) for a given temperature (i.e., we can not
infer absolute temperature changes), we observe that the correlation between
$BER$ and temperature is very similar for the two DRAM modules. We use this
observation to spy on relative temperature changes. Since the attacker has no
prior information about the victim DRAM module, the attacker must reverse
engineer the victim DRAM module using remote RowHammer-based techniques [18,
31]. To estimate the temperature of the victim DRAM module, we propose to
build a polynomial regression model using a DRAM module (to which the attacker
has physical access and can control the operating temperature) that is exactly
the same model as the victim DRAM module.

Second, a variant of SpyHammer to spy on _absolute temperatures_ that requires
to characterize the victim DRAM module before the attack. The key idea is to
build an accurate polynomial regression model using the victim DRAM module
that will be used to infer the temperature of the victim DRAM module with high
accuracy.

Monitoring the $BER$ of a DRAM module reliably requires the attacker to hammer
a large region of memory. To reduce the cost of the attack, we propose a
SpyHammer optimization that spies on temperature by monitoring the DRAM cells
that manifest bit flips only at one specific temperature point, called _canary
cells_. We identify canary cells in the enrollment process, where cells that
flip at more than one temperature point are removed from the canary cells.
After the enrollment phase, an attacker can estimate the temperature of the
victim DRAM by monitoring only a few selected canary cells, thus reducing the
number of memory accesses required to perform the attack.

To evaluate SpyHammer, we perform an extensive and thorough DRAM RowHammer
characterization on 12 real DRAM modules (120 DRAM chips) using temperature
steps of $1\text{\,}\mathrm{\SIUnitSymbolCelsius}$ in a controlled
environment. Our results show that an attacker can spy on 1) absolute
temperature (with prior characterization of the victim DRAM module) with an
error of $\pm$$1\text{\,}\mathrm{\SIUnitSymbolCelsius}$, and 2) relative
temperature changes (without prior characterization of the victim DRAM module)
with an error of $\pm$$5\text{\,}\mathrm{\SIUnitSymbolCelsius}$, for most DRAM
modules we test.

We make the following main contributions:

  * •

We propose SpyHammer, the first attack that can spy on DRAM temperature
without any modification to the victim system.

  * •

We propose a two variants of SpyHammer: 1) a variant that can spy on relative
temperature changes using RowHammer without having any prior information about
the DRAM module and without any changes to the victim DRAM module, and 2) a
variant that can spy on absolute temperature changes using RowHammer when the
attacker can characterize the DRAM module before deploying the victim DRAM
module.

  * •

We perform a thorough characterization and analysis of the correlation between
RowHammer and temperature, using 12 real DDR4 DRAM modules (120 DRAM chips).

  * •

We perform a detailed study on the accuracy of the two variants of SpyHammer,
which shows that we can spy with a maximum error (at the $90^{\mathrm{th}}$
percentile of tested temperature points) of 1)
$\pm$$2.5\text{\,}\mathrm{\SIUnitSymbolCelsius}$ on absolute temperature
values, and 2) $\pm$$3.5\text{\,}\mathrm{\SIUnitSymbolCelsius}$ on relative
temperature changes, in all 12 DRAM modules (120 DRAM chips) from the four
manufacturers we test.

##  II Background

We provide a brief background on DRAM organization and RowHammer
vulnerability. For more detailed background, we refer the reader to prior
works [32, 33, 34, 35, 36, 37, 38, 39, 40, 1, 41, 42, 43, 44, 45, 46, 47, 2,
48, 3, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66,
67, 68, 69, 70, 71].

###  II-A DRAM Organization

The memory controller in the processor communicates with DRAM modules over one
or multiple DRAM channels. Each module contains a set of DRAM chips that
operate in lockstep. The DRAM cells within a DRAM chip are organized
hierarchically. A DRAM chip comprises multiple DRAM banks that can operate
independently. DRAM cells in a DRAM bank are laid out in a two-dimensional
structure of rows and columns. Each DRAM cell on a DRAM row is connected to a
common wordline via access transistors. A bitline connects a column of DRAM
cells to a DRAM sense amplifier to access data.

Accesses to DRAM devices are typically performed in cache block granularity
(64-bytes) in contemporary systems. An access to a DRAM cache block works in
three steps. First, the memory controller sends an ACT command to activate a
specific row within a DRAM bank, which prepares the row for a columns access
(i.e., copies the row to the sense amplifiers). Second, the memory controller
sends a READ (WRITE) command to read (write) a column in the row. Third, once
all operations to the active row are completed, the memory controller sends a
PRE command that closes the row and prepares the DRAM bank to open a new DRAM
row (i.e., it precharges the bank).

###  II-B RowHammer

Modern DRAM devices are subject to disturbance failures caused by high
frequency accesses (i.e., hammer) to DRAM rows (i.e., aggressor rows) that
result in unintentional bit flips in physically nearby rows that are not being
accessed (i.e., victim rows). This phenomenon is referred to as RowHammer [1,
2, 72]. RowHammer-induced bit flips are exacerbated as DRAM technology nodes
shrink and DRAM cells come closer to each other. This results in newer, high-
density DRAM chips to become more vulnerable to RowHammer [2]. These bit-flips
manifest after a row’s activation count reaches a certain threshold value
within a refresh window (usually denoted as MAC [73] or $HC_{first}$ [2]).

Prior works devise attacks that can escalate the privilege level [17, 18, 6,
22, 7, 4, 5, 9, 74], leak confidential data [25], or perform denial of service
[24, 30]. A subset of RowHammer attacks require no physical access to a victim
computing system; for example, attacks leveraging RDMA [31] or attacks in
JavaScript programs [6].

###  II-C PUFs and Physical Cryptography

Our work also relates to the recent areas of physical unclonable functions
(PUFs) and physical cryptography. In these established fields, the intrinsic,
physical characteristics of hardware are employed to either enable new
cryptographic and security schemes, or to launch new classes of attacks.
Optical PUFs and digital silicon PUFs have been pioneered early on by Pappu et
al. and Gassend et al. [75, 76], and have been advanced in a large number of
follow-up works [77, 78, 79, 80, 78, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90,
91, 92, 93, 94, 95, 96, 97, 98, 99, 100]. Also DRAM PUFs and Rowhammer PUFs
have been suggested recently, creating yet another link between the PUF-field
and the studies of this paper [47, 101, 102, 103, 104].

##  III Threat Models

We assume two different threat models for 1) spying on relative temperature
changes and 2) spying on absolute temperature changes.

###  III-A Spying on Relative Temperature Changes.

We assume an attacker with no prior knowledge or physical access to the victim
DRAM module. Thus, the victim’s software and hardware can not be characterized
or modified by the attacker prior to the attack.

With the goal of building models that correlate $BER$ with temperature, the
attacker can purchase many DRAM modules from different manufacturers, and has
the infrastructure to control the DRAM temperature of those modules in a fine-
grained manner.

###  III-B Spying on Absolute Temperature Changes.

We assume an attacker that has access to the victim DRAM module before
performing the attack, and they can characterize the bit errors caused by
RowHammer in a controlled environment at different temperatures.

##  IV Methodology

We perform a thorough analysis of the potential of the SpyHammer attack using
an FPGA-based infrastructure. To perform a SpyHammer attack on a real DDR4
system (i.e., with RowHammer defense mechanisms enabled), we can use the
methodology proposed in previous work [3, 74, 105] to induce a significant
amount of bit flips in real systems (not shown in this paper).

###  IV-A Testing Infrastructure

We experimentally study DDR4 DRAM chips across a wide range of temperatures.
We use a custom version of the SoftMC framework [52] that supports DDR4
modules, and a highly accurate temperature controller infrastructure.

####  IV-A1 SoftMC

Figure 1 shows the SoftMC setup for testing DDR4 DRAM modules. We use the
Xilinx Alveo U200 [106] FPGA board in all of our tests.

Figure 1: SoftMC Infrastructure: (a) temperature controller, (b) DRAM module
clamped with heater pads, and (c) FPGA board programmed with a custom SoftMC
[52] version that supports DDR4 modules.

We use an FPGA board with SoftMC (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 a fine-
grained control over the timing between DRAM commands. We enforce all timing
parameters defined by Jedec [73] to enforce reliable operation.

####  IV-A2 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 reflective 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
a custom software that enables us to automatize the management of the
temperature, and integrate it in our testing infrastructure. In our tests
using this infrastructure, we measure temperature with an accuracy of
$\pm$$0.1\text{\,}\mathrm{\SIUnitSymbolCelsius}$.

###  IV-B Testing Methodology

Disabling Sources of Interference. We disable all DRAM self-regulation events
except the calibration signals like ZQ for signal integrity, so that we ensure
that the observed errors are solely caused by RowHammer. We also make sure
that our tests finish before retention errors manifest.

To the best of our knowledge, we also disable all DRAM-level (e.g., TRR [73])
and system-level RowHammer mitigation mechanisms (e.g., pTRR [107]) along with
all forms of rank-level error-correction codes (ECC), which could obscure
RowHammer bit-flips. Based on the prior work’s observations [3, 2], 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 as the worst case test pattern, in which 1) we hammer the two rows that
are adjacent to the victim row (i.e., aggressor rows), and 2) we access the
aggressor rows as fast as possible.

Data Pattern. We conduct our experiments on a DRAM module by using the
module’s worst-case data pattern ($WCDP$). We identify the $WCDP$ as the
pattern that experiences the largest number of bit-flips among seven different
data patterns that prior research on DRAM characterization uses [55, 33, 46,
2, 43, 45, 44], presented in Table I: colstripe, checkered, rowstripe, and
random (we also test the complements of the first three). For each RowHammer
test, we write the corresponding data pattern to the victim row ($V$ in Table
I), and to the 8 previous ($V-[1...8]$) and next ($V+[1...8]$) physically-
adjacent rows.

TABLE I: Data patterns used in our RowHammer analyses.

Row Address | Colstripe† | Checkered† | Rowstripe† | Random
---|---|---|---|---
$V^{*}\pm[0,2,4,6,8]$ | `0x55` | `0x55` | `0x00` | `random`
$V^{*}\pm[1,3,5,7]$ | `0x55` | `0xaa` | `0xff` | `random`

$\quad{}^{*}V$ is the physical address of the victim row

$\quad{}^{\dagger}{}$We also test the complements of these patterns

Memory Access Pattern. In all of our tests we perform a double-sided RowHammer
attack [1, 2].

Metrics. We compare the $BER$ across all our tests at a constant hammer count
of 150K per aggressor row. We also identify the DRAM cells that flip only at a
particular temperature point (i.e., canary cells).

Iterations. To collect reliable results and estimate temperatures with
SpyHammer, we repeat every single experiment for a particular DRAM module and
temperature 20 times. We use the 20 repetitions of the experiments in
different ways, depending on the particular evaluation (e.g., for estimating
the accuracy on absolute temperature values in Section VII-A, we use the first
10 repetitions to build the estimation model and the other 10 repetitions to
estimate the model’s accuracy).

###  IV-C Tested DRAM Modules

Table II summarizes the 12 DDR4 modules (120 DRAM chips) we test from four
major manufacturers. With the goal of testing our hypotheses (i.e., we can spy
on the temperature if we know the model of the victim DRAM, or we can reverse
engineer it), we test 3 modules from each manufacturer that are exactly the
same model, and have exactly the same manufacturing date.

TABLE II: Summary of DDR4 DRAM chips tested.

Mfr. | Model† | Module Id. | #Chips | Density | Die | Org. | Date
---|---|---|---|---|---|---|---
|  |  |  |  |  |  | (year/week)
A (Micron) | 9TBJ | 1 | 16 | 16GB | B |  $\times$4 | 19/11
9TBJ | 2 | 16 | 16GB | B |  $\times$4 | 19/11
9TBJ | 3 | 16 | 16GB | B |  $\times$4 | 19/11
B (Samsung) | 8GNT | 4 | 8 | 8GB | F |  $\times$8 | 21/02
8GNT | 5 | 8 | 8GB | F |  $\times$8 | 21/02
8GNT | 6 | 8 | 8GB | F |  $\times$8 | 21/02
C (Hynix) | S8/4 | 7 | 8 | 4GB | D |  $\times$8 | 19/46
S8/4 | 8 | 8 | 4GB | D |  $\times$8 | 19/46
S8/4 | 9 | 8 | 4GB | D |  $\times$8 | 19/46
D (Nanya) | PGRK | 10 | 8 | 8GB | C |  $\times$8 | 21/12
PGRK | 11 | 8 | 8GB | C |  $\times$8 | 21/12
PGRK | 12 | 8 | 8GB | C |  $\times$8 | 21/12

† Last 4 digits of the model reference.

##  V SpyHammer Attack

In this section, we describe how to perform a SpyHammer attack that spies on
_relative temperature changes_ of the victim DRAM chip. In Section VI, we
describe how to perform a SpyHammer variant that spies on the _absolute
temperature_ of the victim DRAM module.

Overview. The basic SpyHammer attack is based on two key observations. First,
the RowHammer-induced $BER$ consistently increases (decreases) when the
temperature increases [72]. We use this observation to infer if the
temperature increases or decreases compared to a reference temperature point
by just monitoring the $BER$ in a DRAM region. Second, the form of the curve
that relates $BER$ and temperature is usually very similar across modules from
the same manufacturer and manufacturing date.

Based on these observations, SpyHammer can detect relative changes on DRAM
chip temperature by 1) continuously monitoring the $BER$ of the victim DRAM
module at different points in time, and 2) correlating the $BER$ changes with
temperature changes using a temperature-error model obtained from a module
that is from the same manufacturer and has the same manufacturing date as the
victim DRAM module.

Obtaining consistent and reliable $BER$ numbers might require to hammer a
large region of the DRAM module, which can make the SpyHammer attack
intrusive. To solve this problem, we propose an optimization to reduce the
number of hammers needed to spy on temperature. This optimization is based on
the observation that some DRAM cells are vulnerable to RowHammer only at a
very narrow temperature range [72]. We use this observation to make SpyHammer
faster and less intrusive by identifying the cells that flip only at one
temperature point, which we call canary cells. By using canary cells instead
of $BER$ to spy on temperature, we can reduce the number of DRAM accesses to
perform the SpyHammer attack.

The canary cell optimization is performed in two steps. First, the attacker
enrolls canary cells for different temperatures. The enrollment stage is
performed in parallel with $BER$ monitoring, and it associates particular
canary cells to particular $BER$ values. For an accurate enrollment phase, the
victim DRAM needs to go through different temperatures that change the $BER$.
The duration of the enrollment phase varies depending on the variability of
the temperature in the victim DRAM module. Second, once the attacker
identifies the canary cells for different temperatures, the attacker monitors
canary cells to spy the temperature of the victim DRAM module.

SpyHammer neither requires previous information about the victim DRAM module,
nor the characterization of the victim DRAM module (see Section III-A) to spy
on _relative temperature changes_ (see Section VI for a SpyHammer attack on
_absolute temperatures_). However, to build an accurate model for temperature
estimation, the attacker needs to characterize a DRAM module that is as
similar as possible to the victim (e.g., same manufacturer and model). This
means that the attacker needs to reverse engineer the manufacturer and model
of the victim DRAM module remotely.

We perform the SpyHammer attack in five steps:  1) identify the victim DRAM
model,  2) build a polynomial regression model from a DRAM module that is the
same model as the victim,  3) allocate a contiguous DRAM memory region in the
victim system,  4) monitor the $BER$ of the victim DRAM module continuously,
5) enroll and monitor canary cells in the victim DRAM module.

###  V-A Step 1: Identify the Victim DRAM Module

SpyHammer requires to reverse engineer the manufacturer and model of the
victim DRAM module. Our methodology identifies the DRAM manufacturer first,
and then identifies the technology node of the model. There are many
techniques that enable us to reverse engineer the victim DRAM manufacturer and
model remotely, without physical access or modification to the victim system.
Next, we explain some of these techniques an attacker can use, based on new
observations, and observations from previous works.

We classify our methodologies into two categories: 1) methodologies that are
very simple and quick to implement, but that can lead two some inaccuracies in
some cases (Section V-A1), and 2) methodologies that are more complex but that
usually can provide more accurate results (Section V-A2). The best methodology
for each particular case might depend on the required accuracy, or the time
the attacker has to do the attack.

####  V-A1 Quickly Identifying the DRAM Manufacturer and Model

We can quickly infer some characteristics of the DRAM manufacturer of the
victim DRAM module remotely by using two simple techniques based on RowHammer.
These techniques can not accurately distinguish between Mfr. A and Mfr. D
modules, so they might have to be complemented with more sophisticated
techniques (Section V-A2) when required.

Mfr. B: Unique Logical-to-Physical Row Mapping. DRAM manufacturers use DRAM
internal mapping schemes to translate memory-controller-visible row addresses
to physical row addresses in DRAM [1, 108, 109, 34, 110, 33, 56, 53, 111, 44,
16, 112, 26, 61, 113]. We use the logical-to-physical row mapping to uniquely
identify Mfr. B modules. We observe that Mfr. A, Mfr. C, and Mfr. D modules
use a sequential logical-to-physical row mapping, whereas Mfr. B uses a unique
logical-to-physical row mapping in which two adjacent row addresses sent from
the memory controller might map to non-adjacent physical locations in the DRAM
chip.

To discover the logical-to-physical row mapping of a DRAM module, we use the
observation that, when performing a single-sided RowHammer attack, the rows
with more RowHammer-induced bit flips are the rows that are physically
adjacent to the attacker row. Using this observation, we perform a simple
iterative algorithm that infers the logical-to-physical mapping. Table III
shows the logical-to-physical row mapping from all four major DRAM
manufacturers we test. In the table, each element in the address, physical
($phy$) or logical ($log$), represents a bit, where bit 0 is the least
significant bit of the address.

Logical-to-Physical Row Mapping | Mfr.
---|---
$phy[x]=log[x]{{}^{\dagger}{}}$ |  A, C, and D
$phy[0]=log[0]$ | B
$phy[1]=log[3]\oplus log[1]$
$phy[2]=log[2]\oplus log[3]$
$phy[y]=log[y]{{}^{\ddagger}{}}$

† where x ranges from 0 to N.

‡ where y ranges from 3 to N.

TABLE III: Logical-to-physical mapping of DRAM row addresses.

We make two observations. First, Mfr. B is the only manufacturer that uses a
non-sequential logical-to-physical row mapping. Second, all Mfr. B modules
have the same logical-to-physical row mapping in all modules we test. We
verify that Mfr. B uses this mapping also for other modules other than the
ones we use for performing our thorough characterization (Table II). We
conclude that an attacker can identify Mfr. B modules by just reverse
engineering their unique logical-to-physical row mapping.

Mfr. A and Mfr. D: Single-sided RowHammer Tests. We make the new observation
that performing single-sided RowHammer usually only affects to one neighboring
row in Mfr. A and Mfr. D modules. For example, we observe that hammering row
$X$ causes bit flips only in $X+1$, and hammering row $X+1$ causes bit flips
only in row $X$. In Mfr. B and Mfr. C modules, when performing a single-sided
RowHammer attack, the two victim rows are susceptible to bit flips. We
speculate that this observation is caused by architectural design
decisions.111DRAM manufacturers do not reveal any detail about the internal
DRAM architecture implementation. We conclude that we can use a single-sided
RowHammer attack to identify DRAM modules from Mfr. A and D.

Identifying the DRAM Model. Modules from the same manufacturer might have
different characteristics, depending on the manufacturing process,
manufacturing date, etc. To identify the particular DRAM model of a DRAM
module, we use the observation that the $BER$ of modules from the same
manufacturer but different technology nodes differ significantly. This
observation could also be used to infer the DRAM manufacturer, as the absolute
$BER$ values from different manufacturers also differ very significantly in
the modules we test (see Section VII-A).

####  V-A2 Accurately Identifying the DRAM Manufacturer and Module

U-TRR [105] assesses the security guarantees of recent DRAM chips by reverse
engineering proprietary on-die RowHammer mitigation mechanisms, commonly known
as Target Row Refresh (TRR). TRR detects and refreshes potential RowHammer-
victim rows, but its exact implementations are not openly disclosed. 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. The authors show in their evaluation that it is possible to reverse
engineer the TRR mechanism for many different DRAM models from 3 major
manufacturers. Our observation is that each manufacturer implements TRR in a
different way, and, for modules from the same manufacturer, there are also a
wide variety of TRR implementations. We conclude that we can use the
techniques proposed by [105] to uniquely identify a particular DRAM model.

###  V-B Step 2: Build the Polynomial Regression Model

Although the absolute $BER$ of two different modules from the same
manufacturer and technology node can differ significantly, the correlation
between $BER$ and temperature have a very similar relation (i.e., the shape of
the polynomial regression curve is very similar in most cases). Thus, using
the data obtained from the $BER$ characterization, an attacker can 1) make a
polynomial regression model from a DRAM module with the same characteristics
as the victim DRAM module, and 2) use the model to estimate the relative
temperature changes of the victim DRAM module.

Using a polynomial regression model, we can estimate the temperature change
$\delta$ [in $\text{\,}\mathrm{\SIUnitSymbolCelsius}$]. In our evaluation, we
demonstrate that a polynomial regression model of order 3 is enough to
estimate temperature with $\pm$$5\text{\,}\mathrm{\SIUnitSymbolCelsius}$
accuracy when estimating relative temperatures changes, and
$\pm$$1\text{\,}\mathrm{\SIUnitSymbolCelsius}$ accuracy when estimating
absolute temperatures, for most DRAM modules we test.

###  V-C Step 3: Allocate a Contiguous Memory Region

Unlike other RowHammer attacks [7], SpyHammer does not require sophisticated
techniques to place the victim memory row (not controlled by the attacker)
into a particular physical row that is adjacent to the aggressor row
controlled by the attacker. Instead, in SpyHammer, both the victim and the
aggressor row are in the attacker’s own memory space.

The attacker only has two requirements when allocating memory from the victim
system. First, the memory region should be as contiguous as possible (i.e.,
the memory space is not very fragmented), so when performing hammers the
aggressor and victim row are neighbors with high probability. This is
important not only for maximising the $BER$, but also for not corrupting the
memory of other processes that use memory in adjacent memory regions. Second,
for using the canary cell optimization, the memory region should not migrate
to different physical locations during the attack, as the canary cells change
from region to region. When using $BER$ to spy on temperature, this is not
required, as different regions within the same DRAM module have similar $BER$
(see Section VII-A).

To identify if the physical memory region changes at different points in time,
the attacker can use memory deduplication to reverse-map any physical page
into a virtual page [7].

###  V-D Step 4: Monitor the $BER$ of the Victim DRAM Module

SpyHammer is carried out in a memory region entirely in the attacker’s address
space. To characterize the $BER$ of the memory region, the attacker simply
needs to perform a RowHammer attack to every row within their address space
with a double-sided RowHammer attack (as described in Section IV), and count
the total number of RowHammer-induced bit flips in the memory region. More
sophisticated attacks can be used to trigger the attack (e.g., Blacksmith
[74]), but we evaluate a double sided attack to simplify the comparison and to
extract more clear conclusions.

The attacker initially establishes an estimated reference temperature by
correlating the measured $BER$ to the estimated temperature using the
polynomial regression model (Step 3). In subsequent $BER$ measurements and
temperature estimations, the attacker can estimate the relative temperature
changes using the model.

###  V-E Step 5: Enroll and Monitor Canary Cells

To improve performance and reduce the probability of the SpyHammer attack to
be detected, we identify and monitor canary cells, i.e., cells that only flip
at a particular temperature point. By using canary cells, an attacker only
needs to characterize (i.e., hammer) a few cells in the memory region instead
the entire memory region. Before using canary cells to estimate temperature,
the attacker needs to identify those canary cells in a variety of different
temperatures (i.e., enrollment). Enrollment requires characterizing the victim
system during a large-enough time period to the system work in a wide variety
of temperatures.

Enrolling Canary Cells. The canary enrollment process registers the cells that
will be used as canaries for detecting temperature changes. This process
requires to monitor DRAM cells while characterizing the $BER$ (Step 4). To
this end, the attacker 1) associates every different $BER$ value (with a
specified error tolerance) with the DRAM cells that experience bit flips at
only at the associated $BER$ (i.e., canary cells), and 2) eliminates
duplicated canary cells from the previously generated $BER$-canary cells
pairs. By using this methodology iteratively, the attacker can identify which
cells are vulnerable to RowHammer at a specific $BER$ value.

Monitoring Canary Cells to Estimate Temperature. After enrolling the canary
cells, the attacker monitors canary cells (i.e., check if the enrolled canary
cells are vulnerable to RowHammer) to detect temperature changes, instead of
accessing large regions of DRAM to calculate the $BER$. By comparing the $BER$
associated with different canary cells, the attacker can infer relative
temperature changes using the same methodology as used in Step 4.

To minimize the number of DRAM accesses, the attacker can use a limited amount
of canary cells per temperature, or access DRAM rows that have a large number
of canary cells.

##  VI Spying on Absolute Temperature Values with SpyHammer

This variant of the SpyHammer attack aims to spy on absolute values of
temperature. For doing so, the attacker must characterize the victim DRAM
module prior to the attack (see Section III-B) under different temperature
conditions. Thus, the attacker does not need to reverse engineer the model of
the victim DRAM module, as in Section V-A. Because the attacker uses the
victim DRAM module to build the polynomial regression model, the temperature
estimations are absolute and more accurate, as we demonstrate in Section
VII-A. The rest of the attack remains the same as in Section V.

We discuss the limitations of this attack model in Section VIII-B.

##  VII Evaluation

We evaluate the SpyHammer accuracy and sensitivities when using both $BER$
(Section VII-A) and canary cells (Section VII-B) to spy on relative
temperature changes and absolute temperature.

###  VII-A $BER$ Characterization and Analysis

We characterize and analyze the correlation between $BER$ and temperature for
four different manufacturers. Figure 2 shows the RowHammer-induced $BER$ for
temperatures from $50^{\circ}$C to $95^{\circ}$C. We analyze 12 DRAM modules,
3 identical modules (i.e., manufacturing data, technology node, chip
identifier, etc.) for each DRAM manufacturer. We use a memory region of 192MB
(i.e., 24K DRAM rows) for each DRAM module, and we repeat each experiment 20
times for each temperature point. We plot a line for each module (in the same
color as the points in the plot) that represents the polynomial regression
model we use for each module.

Figure 2: Correlation between RowHammer-induced bit flips per row ($BER$) and
temperature.

We make five observations. First, the absolute $BER$ values of 2 identical
modules from the same manufacturer can differ significantly. For example,
Module Id. 3 from Mfr. A shows in the order of 2.5$\times$ more bit flips than
Module Id. 2. Second, the form of the curve for a particular DRAM module is
similar to the curve from other modules from the same manufacturer. For
example, although thee absolute $BER$ values differ slightly, all curves from
Mfr. D modules have approximately the same shape. Third, the $BER$ can
increase (e.g., Mfr. A) or decrease (e.g., Mfr. B) depending on the DRAM
manufacturer. Fourth, most modules (i.e., Mfrs. A, B and D) show a linear
relation between $BER$ and temperature. In Mfr. C, we observe that the
relation is not linear if the temperature is higher than
$70\text{\,}\mathrm{\SIUnitSymbolCelsius}$. Fifth, the $BER$ across the 20
repetitions of the experiment is very similar, as there is little variation
within the y-axis for each temperature point.

We conclude that the similar correlation between $BER$ and temperature within
the same manufacturer can be used to estimate the victim temperature.222For a
particular model of a Mfr. D module (not shown in our evaluation results), we
can not observe enough RowHammer-induced bit flips for making conclusive
observations about the relation RowHammer/Temperature. To do so, we find that
a polynomial regression model of order 3 is good enough to accurately model
the correlation beetween $BER$ an temperature for all modules we test. Table
IV shows the polynomial regression equations inferred for each DRAM module.

Id. | Polynomial Regression
---|---
1 | $y=-(1.9*10^{-6})*x^{3}+(4.8*10^{-4})*x^{2}-(2.2*10^{-2})*x+2.1$
2 | $y=+(6.8*10^{-7})*x^{3}-(6.4*10^{-5})*x^{2}+(1.2*10^{-2})*x+0.8$
3 | $y=+(4.0*10^{-7})*x^{3}+(3.0*10^{-5})*x^{2}+(2.0*10^{-2})*x+2.3$
4 | $y=-(1.9*10^{-4})*x^{3}+(4.0*10^{-2})*x^{2}-3.5*x+260$
5 | $y=+(9.5*10^{-5})*x^{3}-(2.1*10^{-2})*x^{2}+0.8*x+157.7$
6 | $y=+(2.4*10^{-4})*x^{3}-(4.9*10^{-2})*x^{2}+(2.5)*x+121.8$
7 | $y=+(1.4*10^{-3})*x^{3}-0.2*x^{2}+15.6*x-152.2$
8 | $y=+(5.1*10^{-3})*x^{3}-1.0*x^{2}+64.1*x-1201.8$
9 | $y=+(8.1*10^{-5})*x^{3}-(9.9*10^{-3})*x^{2}+(0.9)*x+167.6$
10 | $y=+(4.5*10^{-7})*x^{3}-(6.3*10^{-5})*x^{2}+(7.4*10^{-3})*x+0.1$
11 | $y=+(3.4*10^{-7})*x^{3}-(4.3*10^{-5})*x^{2}+(5.7*10^{-3})*x+0.1$
12 | $y=-(1.2*10^{-7})*x^{3}+(6.4*10^{-5})*x^{2}+(2.5*10^{-3})*x+0.3)$
TABLE IV: Polynomial regression that models the correlation between $BER$ and
temperature.

We observe that the the regression curve is reasonably similar between modules
from the same manufacturers. We conclude that we can spy on temperature by
using a polynomial regression model from a DRAM module that is the same model
as the victim DRAM module. However, we assume that the accuracy of the model
can significantly change depending on the DRAM module and the threat model.

Methodology for Measuring Accuracy. To evaluate the accuracy of the polynomial
regression model to estimate temperature, we select a sequence of 720 random
temperature points in the tested range (i.e., from
$50\text{\,}\mathrm{\SIUnitSymbolCelsius}$ to
$95\text{\,}\mathrm{\SIUnitSymbolCelsius}$), and we measure the accuracy of
the estimation for all temperatures in the sequence. For spying on relative
temperature changes, we use the change between consecutive temperature points
in the sequence, and for spying on absolute temperature, we use each
temperature point in the sequence. We make sure that the sequence of random
temperatures include extreme temperature changes (e.g., from
$95\text{\,}\mathrm{\SIUnitSymbolCelsius}$ to
$50\text{\,}\mathrm{\SIUnitSymbolCelsius}$), and small temperature changes
(e.g., from $50\text{\,}\mathrm{\SIUnitSymbolCelsius}$ to
$51\text{\,}\mathrm{\SIUnitSymbolCelsius}$).

Accuracy when Spying on Relative Temperature Changes. We study the accuracy of
spying the relative temperature changes of the victim DRAM module using a
polynomial regression model obtained from a DRAM module that is the same model
as the victim DRAM module. Figure 3 shows the probability distribution of the
temperature error when we use the polynomial regression model. For each victim
DRAM module of each manufacturer, we use a polynomial regression model
obtained from one of the other two modules we test from the same manufacturer.
Table V shows the maximum error in the estimation of the relative temperature
changes (in $\text{\,}\mathrm{\SIUnitSymbolCelsius}$), for $90^{\mathrm{th}}$
percentile of the error distribution. We show values for temperature changes
up to $45\text{\,}\mathrm{\SIUnitSymbolCelsius}$ (L), and for temperature
changes up to $5\text{\,}\mathrm{\SIUnitSymbolCelsius}$ (S), which should be
the common case if the $BER$ monitoring frequency is large enough.

Figure 3: Error of the relative temperature change estimation obtained using a
polynomial regression model from a DRAM module that is the same model as the
victim DRAM module.

Module Id. | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
---|---|---|---|---|---|---|---|---|---|---|---|---
Error (L)† ($\text{\,}\mathrm{\SIUnitSymbolCelsius}$) | 7.8 | 12.6 | 5.6 | 3.9 | 4.6 | 3.9 | 14.5 | 6.6 | 23.1 | 2.0 | 1.9 | 1.0
Error (S)‡ ($\text{\,}\mathrm{\SIUnitSymbolCelsius}$) | 3.1 | 3.1 | 3.3 | 3.4 | 2.4 | 3.2 | 2.6 | 3.3 | 2.6 | 2.0 | 1.9 | 1.0

† for relative temperature changes up to
$45\text{\,}\mathrm{\SIUnitSymbolCelsius}$.

‡ for relative temperature changes up to
$5\text{\,}\mathrm{\SIUnitSymbolCelsius}$

TABLE V: Maximum temperature error (in
$\text{\,}\mathrm{\SIUnitSymbolCelsius}$) for $90^{\mathrm{th}}$ percentile of
the error distribution, when estimating relative temperature changes.

We make two observations. First, the error of the temperature estimated by the
regression model reasonably low for modules from Mfr. B (Module Id. 4, 5, 6)
and Mfr. D (Module Id. 10, 11, 12), because the correlation between $BER$ and
temperature is very similar across all modules from the same manufacturer. We
find that the error is larger for Mfr. A (Module Id. 1, 2, 3) and Mfr. C
(Module Id. 7, 8, 9) because in each of these manufacturers there is one
module that has a slightly different curve than the other two modules. Second,
in many cases, the estimation error is zero (i.e., error =
$0\text{\,}\mathrm{\SIUnitSymbolCelsius}$). We observe that when the
temperature change is small (e.g.,
$<$$5\text{\,}\mathrm{\SIUnitSymbolCelsius}$), the estimation error is small
for all modules ($<$$3.5\text{\,}\mathrm{\SIUnitSymbolCelsius}$), whereas when
the temperature change is large (e.g., up to
$45\text{\,}\mathrm{\SIUnitSymbolCelsius}$) the estimation error is much
larger (only 3 modules have less than
$3.5\text{\,}\mathrm{\SIUnitSymbolCelsius}$ error).

We make two conclusions. First, for all possible temperature changes (i.e.,
from very small to very large temperature changes), a polynomial regression
model works well if the modules show very similar correlations between $BER$
and temperature. Second, for small temperature changes, we can get accurate
temperature estimations from all modules we test. By sampling with enough
frequency, this should be always the case in regular conditions.

Accuracy when Spying on Absolute Temperature Values. We study the accuracy of
spying the absolute temperature of the victim DRAM module using a polynomial
regression model obtained from the victim DRAM module itself. Figure 4 shows
the probability distribution of the error when estimating the absolute
temperature. Table VI shows the maximum error in the estimation of the
absolute temperatures (in $\text{\,}\mathrm{\SIUnitSymbolCelsius}$), for
$90^{\mathrm{th}}$ percentile of the error distribution.

Figure 4: Absolute temperature error estimated for the victim DRAM module with a polynomial regression model obtained from the victim DRAM module. Module Id. | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
---|---|---|---|---|---|---|---|---|---|---|---|---
Error ($\text{\,}\mathrm{\SIUnitSymbolCelsius}$) | 0.5 | 1.2 | 0.5 | 1.4 | 2.3 | 2.3 | 0.9 | 1.7 | 1.9 | 0.5 | 0.6 | 0.5
TABLE VI: Maximum temperature error (in
$\text{\,}\mathrm{\SIUnitSymbolCelsius}$) for $90^{\mathrm{th}}$ percentile of
the error distribution, when estimating absolute temperatures.

We make the main observation that the absolute temperature estimations are
very accurate for most of the DRAM modules. All modules we tested show an
error lower than $2.5\text{\,}\mathrm{\SIUnitSymbolCelsius}$ for
$90^{\mathrm{th}}$ percentile. We conclude that 1) using a regression model
from the same victim DRAM module provides accurate results, and 2) a
polynomial regression model is enough to accurately estimate absolute
temperatures in most modules.

$BER$ Variations in Different DRAM Regions. To make the attack less intrusive
and simple (i.e., reduce the probability of being detected), an attacker can
monitor the $BER$ in a smaller DRAM region to reduce the number of RowHammer
accesses. We study if different DRAM regions within a DRAM module have a
similar $BER$ behavior. Figure 5 shows the correlation between the $BER$ and
the temperature, for 48 different DRAM regions of 4MB, for all DRAM modules we
test.

Figure 5: Boxplot of RowHammer-induced $BER$ in 48 different 4MB memory
regions from the same DRAM module.

We make two observations. First, the correlation of $BER$ with temperature
follows the same trend for all regions we test (i.e., the curves for different
regions within the same module are similar). Second, the variation on absolute
$BER$ values across different regions is reasonably small for all DRAM
modules.

We conclude that the attacker can use any region in memory to perform the
attack, which simplifies the requirements of the attack (i.e., no need for
reverse engineering the physical location of the memory region to find an
appropriate region).

Sensitivity to Different Region Sizes. To improve performance and reduce the
probability of the attack to be detected, the attacker can reduce the size of
the DRAM region used for performing the attack. Figure 6 shows the mean error
of the temperature change estimated by the polynomial regression model, for
different region sizes from 512 rows (4MB) to 24k rows (192MB). The the color
of the bars represents the two threat models we evaluate: 1) spying on
relative temperature changes, and 2) spying on absolute temperatures.

Figure 6: Mean error of the temperature estimated by the polynomial regression
model for different region sizes.

We make three observations. First, we can reduce the region size from 24k to
2k with minor or none increase in the mean error for all cases we test.
Second, for region sizes lower than 2k, the mean error increases significantly
in many cases. For example, modules from Mfr. B (Module Id. 4, 5 6) show a
very significant error increase in the absolute temperature estimation. Third,
the mean error values show similar trends for both relative temperature
changes and absolute temperature, for most modules we test. However, the error
increases more quickly when reducing the region size when estimating absolute
temperatures.

We conclude that the attacker can use regions of size as small as 2k rows
(i.e., 16MB) for spying on temperature, while maintaining reasonable levels of
accuracy.

###  VII-B Canary Cell Analysis

Canary cells can be used to reduce to optimize the SpyHammer attack by
reducing the number of hammers required to perform the attack (see Section V).
We analyze the number of canary cells we observe for each temperature point
that can be used to estimate the temperature of the victim DRAM module. Figure
7 shows the number of canary cells (in logarithmic scale) per temperature
point, and the minimum number of canary cells across all temperature points.
In the enrollment process, we repeat each experiment 10 times for each
temperature point, and we select those cells that experience bit flips at
least once.

Figure 7: Number of canary DRAM cells (i.e., DRAM cells that flip only at one
temperature) that flip at each temperature point.

We make two observations. First, all temperature points we test have at least
18 canary cells (Module Id. 11, and 12) in the worst case, in all modules we
test. The minimum number of canary cells is large enough, as it only requires
one single canary cell to estimate the temperature at a particular temperature
point. Second, there are more canary cells on the extremes of the temperature
range. This phenomenon is caused by the limited temperature range, so some
canary cells at the lower limit ($50\text{\,}\mathrm{\SIUnitSymbolCelsius}$)
might not be canary cells anymore if they result to flip also at
$49\text{\,}\mathrm{\SIUnitSymbolCelsius}$.

We conclude that all modules we test have a large enough number of canary
cells (i.e., more than one) for each temperature point, so they can be used to
reliably infer the DRAM temperature.

Canary Cell Accuracy. We measure the accuracy of SpyHammer when using canary
cells. Figure 8 shows the probability distribution of the temperature errors
when spying on absolute temperature using canary cells.333Similarly, canary
cells can be also used to estimate relative temperature changes. We use 10
iterations of our experiments to perform the enrollment process (i.e.,
identify the canary cells), and another 10 different iterations of our
experiments to monitor the canary cells and spy on temperature.

Figure 8: Probability distribution of the temperature estimation errors using
canary cells.

We make two main observations. First, canary cells can estimate the
temperature accurately (i.e., no errors) with more than 25% probability, with
some cases close to 50% (e.g., Module Id. 4, 8). Second, canary cells can be
used to estimate temperature with less than
$\pm$$5\text{\,}\mathrm{\SIUnitSymbolCelsius}$ error with very high
probability.

We conclude that canary cells can be used to estimate temperature with
significant accuracy, while reducing the number of hammers significantly. For
example, if an attacker wants to know if the temperature is
$60\text{\,}\mathrm{\SIUnitSymbolCelsius}$, it only has to monitor a canary
cell that flips only at that temperature point, instead of hammering a large
region of memory (see Section VII-A).

##  VIII Discussion and Limitations

###  VIII-A Discussion

SpyHammer is the first practical attack that spies on DRAM temperature without
any software or hardware modification to the victim system. As many prior
works demonstrate, DRAM devices are becoming increasing vulnerable to
RowHammer [2, 72], and they can be remotely induced at system level [6, 31],
without physical access, which makes SpyHammer challenging to mitigate.

Unlike other RowHammer attacks [6, 31, 7, 5], SpyHammer is much simpler to
perform because of two main reasons. First, SpyHammer happens entirely in the
attacker address space, not requiring to trigger bit flips in other processes.
This makes the attack more difficult to detect. Second, the attacker does not
require to perform complex memory templates, and it does not depend on the
memory allocator of the system [7]. As we demonstrate in Section VII-A, the
correlation between $BER$ and temperature is very similar across different
regions of the same DRAM module, thus SpyHammer also does not need to
understand the exact physical location of the allocated memory.

For these reasons, we believe that SpyHammer is a simple practical attack that
can compromise the security and privacy of any system that uses modern DRAM
modules.

###  VIII-B Limitations

SpyHammer has one main limitation. To spy on absolute temperature changes, the
attacker requires to characterize the victim DRAM module previously to
performing the attack, in an environment controlled by the attacker with
precise temperature control. Without previous access to the victim DRAM
device, we can only infer relative temperature changes over time. This is also
the case for any mechanism proposed by previous work [114]. The reason of this
limitation is that each DRAM chip, even if they are from the same manufacturer
and technology node, presents unpredictable variation caused by process
variation. For example, we find that the $BER$ of two modules from the same
manufacturer and technology node can differ up to a factor of 2.5$\times$ (see
Figure 2).

##  IX Countermeasures

SpyHammer can spy on DRAM temperature without any modification to the victim
system. The correlation between RowHammer-induded errors and temperature is
inherent to the DRAM device. There are two types of countermeasures against
SpyHammer.

First, general RowHammer defense mechanisms that prevent agains RowHammer bit
flips, independently of the temperature. A good RowHammer defense mechanism
that can mitigate most RowHammer bit flips would be also effective to prevent
SpyHammer. There is an emerging body of work that provides efficient RowHammer
defense mechanisms [115, 1, 116, 107, 117, 118, 119, 120, 121, 122, 123, 124,
125, 19, 48, 126, 127, 128, 113, 129, 130, 131, 73, 132, 133, 134, 135] that
can be also used to mitigate SpyHammer. For example, BlockHammer [113]
selectively throttles memory accesses that could otherwise potentially cause
RowHammer bit-flips. The key idea of BlockHammer is to 1) track row activation
rates using area-efficient Bloom filters, and 2) use the tracking data to
ensure that no row is ever activated rapidly enough to induce RowHammer bit-
flips.

Second, specific RowHammer defense mechanisms that obfuscate the relation
between $BER$ and temperature by introducing a temperature-dependent
parameters in the mechanism. These types of mechanisms are impractical, as
they only target our SpyHammer attack, whereas general RowHammer defenses can
protect against all types of RowHammer attacks.

Thus, we conclude that SpyHammer should be mitigated with general and
effective RowHammer mitigation mechanisms. To date, existing DRAM modules
still do not employ such effective techniques [105, 72, 2, 74].

##  X Related Work

This is the first attack that can remotely spy on temperature without
compromising the victim system (i.e., no software or hardware modification to
the victim system).

Attacks that Spy on Temperature. Xiong et al. [114] proposes an attack that
spies on DRAM temperature by using the observation that when the temperature
increases [33], the leakage of the DRAM cells also increases, thus retention
errors are manifested earlier. The main limitation of this attack is that, to
observe bit errors caused by retention failures, the cell needs to be
discharged for many seconds. This work has two main limitations. First, the
technique requires disabling DRAM refreshes in the victim system, which can
corrupt the data in critical data structures of the operating system, which
would break the system. Second, disabling refreshes requires modifications to
the victim system, which in turn requires the attacker to have physical access
to the device before conducting the attack. Compared to Xiong et al. [114],
SpyHammer can spy on temperature without any hardware or software
modifications to the victim system. Also, SpyHammer does not require to
disable refreshes, which enables to remotely spy on temperature without
corrupting the data of other processes running on the same system.

Other RowHammer Attacks. Many prior works exploit RowHammer to perform system-
level attacks [17, 6, 24, 22, 25, 18, 7, 4, 5, 9, 30, 74]. These attacks can
perform denial of service [17, 18], privilege escalation [17, 18, 6, 22, 7, 4,
5, 9, 74], confidential data leakage [25], or manipulation of the application
correctness [24, 30]. Compared to these existing works, SpyHammer is a much
easier and less intrusive attack to do, as it does not involve manipulating
data from any other process other than the attacker process.

Characterization of Real DRAM Chips. Three major works extensively
characterize RowHammer using real DRAM chips [1, 2, 72]. The first RowHammer
work [1] that that investigates the vulnerability in detail for the first time
1) analyzes 129 commodity DDR3 DRAM modules, 2) characterizes the sensitivity
of RowHammer to refresh rate, activation rate, and the physical distance
between aggressor and victim rows, and 3) analyzes several potential
solutions. The second extensive RowHammer characterization [2], conducted in
2020, analyzes RowHammer scalability by performing experiments on 1580 DDR3,
DDR4, and LPDDR4 commodity DRAM chips from different DRAM generations and
technology nodes, demonstrating that RowHammer has become more problematic
over time. The third work [72], conducted in 2021, studies the sensitivity of
RowHammer to DRAM chip temperature, aggressor row active time, and victim DRAM
cell’s physical location, by performing experiments on 248 DDR4 and 24 DDR3
modern DRAM chips from four major manufacturers.

Even though these works rigorously characterize various RowHammer aspects,
they do not analyze the effects of temperature in great detail: 1) they do not
perform fine-grained analyses (e.g., $1\text{\,}\mathrm{\SIUnitSymbolCelsius}$
steps), 2) they do not empirically analyze their observations from the
attacker perspective in great detail, and 3) they do not build and
experimentally demonstrate new RowHammer attacks based on the correlation
between RowHammer vulnerability and temperature.

##  XI Conclusion

Recent studies demonstrate that new DRAM devices are becoming increasingly
more vulnerable to RowHammer, and many works demonstrate system-level attacks
for privilege escalation or information leakage. In this work, we leverage two
key observations about RowHammer characteristics to spy on DRAM temperature:
1) RowHammer-induced bit error rate consistently increases (or decreases) when
the temperature increases, and 2) some DRAM cells that are vulnerable to
RowHammer cause bit errors only at particular temperature. Based on these
observations, we build a new RowHammer attack, called SpyHammer, that spies on
temperature of critical systems such as industrial production lines, unmanned
or semi-automated vehicles, and medical systems, without any modification to
the victim system. We propose two variants of SpyHammer for two different
threat models. First, if the attacker cannot characterize the victim DRAM
module before the attack, they can use SpyHammer to spy on _relative
temperature changes_ on the victim system. Second, if the attacker can
characterize the victim DRAM module before the attack, they can use SpyHammer
to spy on _absolute temperature_. Our evaluation shows that SpyHammer can 1)
spy on relative temperature changes with an error of
$\pm$$3.5\text{\,}\mathrm{\SIUnitSymbolCelsius}$, and 2) spy on absolute
temperature changes with an error of
$\pm$$2.5\text{\,}\mathrm{\SIUnitSymbolCelsius}$, for all 12 DRAM modules from
4 manufacturers, at the $90^{\mathrm{th}}$ percentile of tested temperature
points.

We conclude that SpyHammer is a simple and effective attack that can spy on
temperature of critical systems with no modifications or prior knowledge about
the victim system. We believe that SpyHammer will be a threat to security and
privacy of systems until a definitive RowHammer defense mechanism is adopted,
which is a big challenge given the tendency of RowHammer vulnerability to
worsen with technology scaling.

## Acknowledgments

We thank the SAFARI Research Group members for useful feedback and the
stimulating intellectual environment they provide. We acknowledge the generous
gifts provided by our industrial partners, including Google, Huawei, Intel,
Microsoft, and VMware, and support from the Microsoft Swiss Joint Research
Center. Ulrich Rühmair acknowledges support by the Air Force Office of
Scientific Research (AFOSR) via grant FA9550-21-1-0039.

## References

  * [1] Y. Kim, R. Daly, J. Kim, C. Fallin, J. H. Lee, D. Lee, C. Wilkerson, K. Lai, and O. Mutlu, “Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors,” in _ISCA_ , 2014.
  * [2] J. S. Kim, M. Patel, A. G. Yağlıkçı, H. Hassan, R. Azizi, L. Orosa, and O. Mutlu, “Revisiting RowHammer: An Experimental Analysis of Modern Devices and Mitigation Techniques,” in _ISCA_ , 2020.
  * [3] P. Frigo, E. Vannacci, H. Hassan, V. van der Veen, O. Mutlu, C. Giuffrida, H. Bos, and K. Razavi, “TRRespass: Exploiting the Many Sides of Target Row Refresh,” in _S &P_, 2020.
  * [4] M. Seaborn and T. Dullien, “Exploiting the DRAM Rowhammer Bug to Gain Kernel Privileges,” _Black Hat_ , 2015.
  * [5] V. van der Veen, Y. Fratantonio, M. Lindorfer, D. Gruss, C. Maurice, G. Vigna, H. Bos, K. Razavi, and C. Giuffrida, “Drammer: Deterministic Rowhammer Attacks on Mobile Platforms,” in _CCS_ , 2016.
  * [6] D. Gruss, C. Maurice, and S. Mangard, “Rowhammer.js: A Remote Software-Induced Fault Attack in Javascript,” arXiv:1507.06955 [cs.CR], 2016\.
  * [7] K. Razavi, B. Gras, E. Bosman, B. Preneel, C. Giuffrida, and H. Bos, “Flip Feng Shui: Hammering a Needle in the Software Stack,” in _USENIX Security_ , 2016.
  * [8] P. Pessl, D. Gruss, C. Maurice, M. Schwarz, and S. Mangard, “DRAMA: Exploiting DRAM Addressing for Cross-CPU Attacks,” in _USENIX Security_ , 2016.
  * [9] Y. Xiao, X. Zhang, Y. Zhang, and R. Teodorescu, “One Bit Flips, One Cloud Flops: Cross-VM Row Hammer Attacks and Privilege Escalation,” in _USENIX Security_ , 2016.
  * [10] E. Bosman, K. Razavi, H. Bos, and C. Giuffrida, “Dedup Est Machina: Memory Deduplication as An Advanced Exploitation Vector,” in _S &P_, 2016.
  * [11] S. Bhattacharya and D. Mukhopadhyay, “Curious Case of Rowhammer: Flipping Secret Exponent Bits Using Timing Analysis,” in _CHES_ , 2016.
  * [12] R. Qiao and M. Seaborn, “A New Approach for RowHammer Attacks,” in _HOST_ , 2016.
  * [13] Y. Jang, J. Lee, S. Lee, and T. Kim, “SGX-Bomb: Locking Down the Processor via Rowhammer Attack,” in _SOSP_ , 2017.
  * [14] M. T. Aga, Z. B. Aweke, and T. Austin, “When Good Protections Go Bad: Exploiting Anti-DoS Measures to Accelerate Rowhammer Attacks,” in _HOST_ , 2017.
  * [15] O. Mutlu, “The RowHammer Problem and Other Issues We May Face as Memory Becomes Denser,” in _DATE_ , 2017.
  * [16] A. Tatar, C. Giuffrida, H. Bos, and K. Razavi, “Defeating Software Mitigations Against Rowhammer: A Surgical Precision Hammer,” in _RAID_ , 2018.
  * [17] D. Gruss, M. Lipp, M. Schwarz, D. Genkin, J. Juffinger, S. O’Connell, W. Schoechl, and Y. Yarom, “Another Flip in the Wall of Rowhammer Defenses,” in _S &P_, 2018.
  * [18] M. Lipp, M. T. Aga, M. Schwarz, D. Gruss, C. Maurice, L. Raab, and L. Lamster, “Nethammer: Inducing Rowhammer Faults Through Network Requests,” arXiv:1805.04956 [cs.CR], 2018.
  * [19] V. van der Veen, M. Lindorfer, Y. Fratantonio, H. P. Pillai, G. Vigna, C. Kruegel, H. Bos, and K. Razavi, “GuardION: Practical Mitigation of DMA-Based Rowhammer Attacks on ARM,” in _DIMVA_ , 2018.
  * [20] P. Frigo, C. Giuffrida, H. Bos, and K. Razavi, “Grand Pwning Unit: Accelerating Microarchitectural Attacks with the GPU,” in _S &P_, 2018\.
  * [21] L. Cojocar, K. Razavi, C. Giuffrida, and H. Bos, “Exploiting Correcting Codes: On the Effectiveness of ECC Memory Against Rowhammer Attacks,” in _S &P_, 2019.
  * [22] S. Ji, Y. Ko, S. Oh, and J. Kim, “Pinpoint Rowhammer: Suppressing Unwanted Bit Flips on Rowhammer Attacks,” in _ASIACCS_ , 2019.
  * [23] O. Mutlu and J. S. Kim, “RowHammer: A Retrospective,” _TCAD_ , 2019.
  * [24] S. Hong, P. Frigo, Y. Kaya, C. Giuffrida, and T. Dumitraş, “Terminal Brain Damage: Exposing the Graceless Degradation in Deep Neural Networks Under Hardware Fault Attacks,” in _USENIX Security_ , 2019.
  * [25] A. Kwong, D. Genkin, D. Gruss, and Y. Yarom, “RAMBleed: Reading Bits in Memory Without Accessing Them,” in _S &P_, 2020.
  * [26] L. Cojocar, J. Kim, M. Patel, L. Tsai, S. Saroiu, A. Wolman, and O. Mutlu, “Are We Susceptible to Rowhammer? An End-to-End Methodology for Cloud Providers,” in _S &P_, 2020.
  * [27] Z. Weissman, T. Tiemann, D. Moghimi, E. Custodio, T. Eisenbarth, and B. Sunar, “JackHammer: Efficient Rowhammer on Heterogeneous FPGA–CPU Platforms,” arXiv:1912.11523 [cs.CR], 2020.
  * [28] Z. Zhang, Y. Cheng, D. Liu, S. Nepal, Z. Wang, and Y. Yarom, “PThammer: Cross-User-Kernel-Boundary Rowhammer through Implicit Accesses,” in _MICRO_ , 2020.
  * [29] SAFARI Research Group, “RowHammer — GitHub Repository,” https://github.com/CMU-SAFARI/rowhammer.
  * [30] F. Yao, A. S. Rakin, and D. Fan, “Deephammer: Depleting the Intelligence of Deep Neural Networks Through Targeted Chain of Bit Flips,” in _USENIX Security_ , 2020.
  * [31] A. Tatar, R. K. Konoth, E. Athanasopoulos, C. Giuffrida, H. Bos, and K. Razavi, “Throwhammer: Rowhammer Attacks Over the Network and Defenses,” in _USENIX ATC_ , 2018.
  * [32] J. Liu, B. Jaiyen, R. Veras, and O. Mutlu, “RAIDR: Retention-Aware Intelligent DRAM Refresh,” in _ISCA_ , 2012.
  * [33] J. Liu, B. Jaiyen, Y. Kim, C. Wilkerson, O. Mutlu, J. Liu, B. Jaiyen, Y. Kim, C. Wilkerson, and O. Mutlu, “An Experimental Study of Data Retention Behavior in Modern DRAM Devices,” in _ISCA_ , 2013.
  * [34] B. Keeth and R. Baker, _DRAM Circuit Design: A Tutorial_. Wiley, 2001.
  * [35] O. Mutlu and T. Moscibroda, “Stall-Time Fair Memory Access Scheduling for Chip Multiprocessors,” in _MICRO_ , 2007.
  * [36] T. Moscibroda and O. Mutlu, “Memory Performance Attacks: Denial of Memory Service in Multi-Core Systems,” in _USENIX Security_ , 2007.
  * [37] O. Mutlu and T. Moscibroda, “Parallelism-Aware Batch Scheduling: Enhancing Both Performance and Fairness of Shared DRAM Systems,” in _ISCA_ , 2008\.
  * [38] Y. Kim, D. Han, O. Mutlu, and M. Harchol-Balter, “ATLAS: A Scalable and High-Performance Scheduling Algorithm for Multiple Memory Controllers,” in _HPCA_ , 2010.
  * [39] L. Subramanian, D. Lee, V. Seshadri, H. Rastogi, and O. Mutlu, “The Blacklisting Memory Scheduler: Achieving High Performance and Fairness at Low Cost,” in _ICCD_ , 2014.
  * [40] Y. Kim, V. Seshadri, D. Lee, J. Liu, O. Mutlu, Y. Kim, V. Seshadri, D. Lee, J. Liu, and O. Mutlu, “A Case for Exploiting Subarray-Level Parallelism (SALP) in DRAM,” in _ISCA_ , 2012.
  * [41] M. Qureshi, D.-H. Kim, S. Khan, P. Nair, and O. Mutlu, “AVATAR: A Variable-Retention-Time (VRT) Aware Refresh for DRAM Systems,” in _DSN_ , 2015.
  * [42] H. Hassan, G. Pekhimenko, N. Vijaykumar, V. Seshadri, D. Lee, O. Ergin, and O. Mutlu, “ChargeCache: Reducing DRAM Latency by Exploiting Row Access Locality,” in _HPCA_ , 2016.
  * [43] K. K. Chang, A. Kashyap, H. Hassan, S. Ghose, K. Hsieh, D. Lee, T. Li, G. Pekhimenko, S. Khan, and O. Mutlu, “Understanding Latency Variation in Modern DRAM Chips: Experimental Characterization, Analysis, and Optimization,” in _SIGMETRICS_ , 2016.
  * [44] D. Lee, S. Khan, L. Subramanian, S. Ghose, R. Ausavarungnirun, G. Pekhimenko, V. Seshadri, and O. Mutlu, “Design-Induced Latency Variation in Modern DRAM Chips: Characterization, Analysis, and Latency Reduction Mechanisms,” in _SIGMETRICS_ , 2017.
  * [45] K. K. Chang, A. G. Yağlıkçı, S. Ghose, A. Agrawal, N. Chatterjee, A. Kashyap, D. Lee, M. O’Connor, H. Hassan, and O. Mutlu, “Understanding Reduced-Voltage Operation in Modern DRAM Devices: Experimental Characterization, Analysis, and Mechanisms,” in _SIGMETRICS_ , 2017.
  * [46] M. Patel, J. S. Kim, and O. Mutlu, “The Reach Profiler (REAPER): Enabling the Mitigation of DRAM Retention Failures via Profiling at Aggressive Conditions,” in _ISCA_ , 2017.
  * [47] J. S. Kim, M. Patel, H. Hassan, and O. Mutlu, “The dram latency puf: Quickly evaluating physical unclonable functions by exploiting the latency-reliability tradeoff in modern commodity dram devices,” in _2018 IEEE International Symposium on High Performance Computer Architecture (HPCA)_. IEEE, 2018, pp. 194–207.
  * [48] H. Hassan, M. Patel, J. S. Kim, A. G. Yağlıkçı, N. Vijaykumar, N. Mansouri Ghiasi, S. Ghose, and O. Mutlu, “CROW: A Low-Cost Substrate for Improving DRAM Performance, Energy Efficiency, and Reliability,” in _ISCA_ , 2019.
  * [49] K. K. Chang, D. Lee, Z. Chishti, A. R. Alameldeen, C. Wilkerson, Y. Kim, and O. Mutlu, “Improving DRAM Performance by Parallelizing Refreshes with Accesses,” in _HPCA_ , 2014.
  * [50] K. K. Chang, P. J. Nair, D. Lee, S. Ghose, M. K. Qureshi, and O. Mutlu, “Low-Cost Inter-Linked Subarrays (LISA): Enabling Fast Inter-Subarray Data Movement in DRAM,” in _HPCA_ , 2016.
  * [51] S. Ghose, A. G. Yaglikci, R. Gupta, D. Lee, K. Kudrolli, W. Liu, H. Hassan, K. Chang, N. Chatterjee, A. Agrawal, M. O’Connor, and O. Mutlu, “What Your DRAM Power Models Are Not Telling You: Lessons from a Detailed Experimental Study,” in _SIGMETRICS_ , 2018.
  * [52] H. Hassan, N. Vijaykumar, S. Khan, S. Ghose, K. Chang, G. Pekhimenko, D. Lee, O. Ergin, and O. Mutlu, “SoftMC: A Flexible and Practical Open-Source Infrastructure for Enabling Experimental DRAM Studies,” in _HPCA_ , 2017\.
  * [53] S. Khan, D. Lee, and O. Mutlu, “PARBOR: An Efficient System-Level Technique to Detect Data-Dependent Failures in DRAM,” in _DSN_ , 2016.
  * [54] S. Khan, C. Wilkerson, D. Lee, A. R. Alameldeen, and O. Mutlu, “A Case for Memory Content-Based Detection and Mitigation of Data-Dependent Failures in DRAM,” _CAL_ , 2016.
  * [55] S. Khan, D. Lee, Y. Kim, A. R. Alameldeen, C. Wilkerson, and O. Mutlu, “The Efficacy of Error Mitigation Techniques for DRAM Retention Failures: A Comparative Experimental Study,” in _SIGMETRICS_ , 2014.
  * [56] V. Seshadri, T. Mullins, A. Boroumand, O. Mutlu, P. B. Gibbons, M. A. Kozuch, and T. C. Mowry, “Gather-Scatter DRAM: In-DRAM Address Translation to Improve the Spatial Locality of Non-Unit Strided Accesses,” in _MICRO_ , 2015.
  * [57] V. Seshadri, D. Lee, T. Mullins, H. Hassan, A. Boroumand, J. Kim, M. A. Kozuch, O. Mutlu, P. B. Gibbons, and T. C. Mowry, “Ambit: In-Memory Accelerator for Bulk Bitwise Operations Using Commodity DRAM Technology,” in _MICRO_ , 2017\.
  * [58] J. S. Kim, M. Patel, H. Hassan, and O. Mutlu, “Solar-DRAM: Reducing DRAM Access Latency by Exploiting the Variation in Local Bitlines,” in _ICCD_ , 2018.
  * [59] J. S. Kim, M. Patel, H. Hassan, L. Orosa, and O. Mutlu, “D-RaNGe: Using Commodity DRAM Devices to Generate True Random Numbers with Low Latency and High Throughput,” in _HPCA_ , 2019.
  * [60] M. Patel, J. S. Kim, H. Hassan, and O. Mutlu, “Understanding and Modeling On-Die Error Correction in Modern DRAM: An Experimental Study Using Real Devices,” in _DSN_ , 2019.
  * [61] M. Patel, J. Kim, T. Shahroodi, H. Hassan, and O. Mutlu, “Bit-Exact ECC Recovery (BEER): Determining DRAM On-Die ECC Functions by Exploiting DRAM Data Retention Characteristics (Best Paper),” in _MICRO_ , 2020.
  * [62] D. Lee, Y. Kim, V. Seshadri, J. Liu, L. Subramanian, and O. Mutlu, “Tiered-Latency DRAM: A Low Latency and Low Cost DRAM Architecture,” in _HPCA_ , 2013.
  * [63] D. Lee, L. Subramanian, R. Ausavarungnirun, J. Choi, and O. Mutlu, “Decoupled Direct Memory Access: Isolating CPU and IO Traffic by Leveraging a Dual-Data-Port DRAM,” in _PACT_ , 2015.
  * [64] V. Seshadri, Y. Kim, C. Fallin, D. Lee, R. Ausavarungnirun, G. Pekhimenko, Y. Luo, O. Mutlu, P. B. Gibbons, M. A. Kozuch, and T. Mowry, “RowClone: Fast and Energy-Efficient In-DRAM Bulk Data Copy and Initialization,” in _MICRO_ , 2013.
  * [65] H. Luo, T. Shahroodi, H. Hassan, M. Patel, A. G. Yaglikci, L. Orosa, J. Park, and O. Mutlu, “CLR-DRAM: A Low-Cost DRAM Architecture Enabling Dynamic Capacity-Latency Trade-Off,” in _ISCA_ , 2020.
  * [66] V. Seshadri and O. Mutlu, “In-DRAM Bulk Bitwise Execution Engine,” _arXiv:1905.09822_ , 2019.
  * [67] Y. Wang, L. Orosa, X. Peng, Y. Guo, S. Ghose, M. Patel, J. S. Kim, J. G. Luna, M. Sadrosadati, N. M. Ghiasi _et al._ , “FIGARO: Improving System Performance via Fine-Grained In-DRAM Data Relocation and Caching,” in _MICRO_ , 2020.
  * [68] L. Orosa, Y. Wang, M. Sadrosadati, J. S. Kim, M. Patel, I. Puddu, H. Luo, K. Razavi, J. Gómez-Luna, H. Hassan, N. Mansouri-Ghiasi, S. Ghose, and O. Mutlu, “CODIC: A Low-Cost Substrate for Enabling Custom In-DRAM Functionalities and Optimizations,” in _ISCA_ , 2021.
  * [69] Y. Wang, A. Tavakkol, L. Orosa, S. Ghose, N. M. Ghiasi, M. Patel, J. S. Kim, H. Hassan, M. Sadrosadati, and O. Mutlu, “Reducing DRAM Latency via Charge-Level-Aware Look-Ahead Partial Restoration,” in _MICRO_ , 2018.
  * [70] E. Ipek, O. Mutlu, J. F. Martínez, and R. Caruana, “Self-Optimizing Memory Controllers: A Reinforcement Learning Approach,” in _ISCA_ , 2008\.
  * [71] T. Zhang, K. Chen, C. Xu, G. Sun, T. Wang, and Y. Xie, “Half-DRAM: A High-Bandwidth and Low-Power DRAM Architecture from the Rethinking of Fine-Grained Activation,” in _ISCA_ , 2014.
  * [72] L. Orosa, A. G. Yaglikci, H. Luo, A. Olgun, J. Park, H. Hassan, M. Patel, J. S. Kim, and O. Mutlu, “A deeper look into rowhammer’s sensitivities: Experimental analysis of real dram chips and implications on future attacks and defenses,” in _MICRO_ , 2021.
  * [73] JEDEC, _JESD79-4C: DDR4 SDRAM Standard_ , 2020.
  * [74] P. Jattke, V. van der Veen, P. Frigo, S. Gunter, and K. Razavi, “Blacksmith: Scalable Rowhammering in the Frequency Domain,” in _S &P_, May 2022.
  * [75] R. Pappu, B. Recht, J. Taylor, and N. Gershenfeld, “Physical one-way functions,” _Science_ , vol. 297, no. 5589, pp. 2026–2030, 2002.
  * [76] B. Gassend, D. Clarke, M. Van Dijk, and S. Devadas, “Silicon physical random functions,” in _Proceedings of the 9th ACM Conference on Computer and Communications Security_ , 2002, pp. 148–160.
  * [77] G. E. Suh and S. Devadas, “Physical unclonable functions for device authentication and secret key generation,” in _2007 44th ACM/IEEE Design Automation Conference_. IEEE, 2007, pp. 9–14.
  * [78] P. Lugli, A. Mahmoud, G. Csaba, M. Algasinger, M. Stutzmann, and U. Rührmair, “Physical unclonable functions based on crossbar arrays for cryptographic applications,” _International journal of circuit theory and applications_ , vol. 41, no. 6, pp. 619–633, 2013.
  * [79] D. Merli, D. Schuster, F. Stumpf, and G. Sigl, “Side-channel analysis of pufs and fuzzy extractors,” in _International Conference on Trust and Trustworthy Computing_. Springer, 2011, pp. 33–47.
  * [80] U. Rührmair, X. Xu, J. Sölter, A. Mahmoud, F. Koushanfar, and W. Burleson, “Power and timing side channels for pufs and their efficient exploitation,” _Cryptology ePrint Archive_ , 2013.
  * [81] G. Csaba, X. Ju, Z. Ma, Q. Chen, W. Porod, J. Schmidhuber, U. Schlichtmann, P. Lugli, and U. Rührmair, “Application of mismatched cellular nonlinear networks for physical cryptography,” in _2010 12th International Workshop on Cellular Nanoscale Networks and their Applications (CNNA 2010)_. IEEE, 2010, pp. 1–6.
  * [82] Q. Chen, G. Csaba, X. Ju, S. B. Natarajan, P. Lugli, M. Stutzmann, U. Schlichtmann, and U. Rührmair, “Analog circuits for physical cryptography,” in _Proceedings of the 2009 12th International symposium on integrated circuits_. IEEE, 2009, pp. 121–124.
  * [83] U. Rührmair, “Simpl systems as a keyless cryptographic and security primitive,” in _Cryptography and Security: From Theory to Applications_. Springer, 2012, pp. 329–354.
  * [84] M. van Dijk and U. Rührmair, “Protocol attacks on advanced puf protocols and countermeasures,” in _2014 Design, Automation & Test in Europe Conference & Exhibition (DATE)_. IEEE, 2014, pp. 1–6.
  * [85] U. Rührmair, “Physical turing machines and the formalization of physical cryptography,” _Cryptology ePrint Archive_ , 2011.
  * [86] M. Sauer, P. Raiola, L. Feiten, B. Becker, U. Rührmair, and I. Polian, “Sensitized path puf: A lightweight embedded physical unclonable function,” in _Design, Automation & Test in Europe Conference & Exhibition (DATE), 2017_. IEEE, 2017, pp. 680–685.
  * [87] Q. Chen, G. Csaba, P. Lugli, U. Schlichtmann, M. Stutzmann, and U. Ruehrmair, “Circuit-based approaches to simpl systems,” _Journal of Circuits, Systems, and Computers_ , vol. 20, no. 01, pp. 107–123, 2011.
  * [88] Y. Gao, C. Jin, J. Kim, H. Nili, X. Xu, W. Burleson, O. Kavehei, M. van Dijk, D. C. Ranasinghe, and U. Rührmair, “Efficient erasable pufs from programmable logic and memristors,” _Cryptology ePrint Archive_ , 2018.
  * [89] R. Horstmeyer, S. Assawaworrarit, U. Ruhrmair, and C. Yang, “Physically secure and fully reconfigurable data storage using optical scattering,” in _2015 IEEE International Symposium on Hardware Oriented Security and Trust (HOST)_. IEEE, 2015, pp. 157–162.
  * [90] J. Guajardo, S. S. Kumar, G.-J. Schrijen, and P. Tuyls, “Fpga intrinsic pufs and their use for ip protection,” in _International workshop on cryptographic hardware and embedded systems_. Springer, 2007, pp. 63–80.
  * [91] M. Majzoobi, F. Koushanfar, and M. Potkonjak, “Techniques for design and implementation of secure reconfigurable pufs,” _ACM Transactions on Reconfigurable Technology and Systems (TRETS)_ , vol. 2, no. 1, pp. 1–33, 2009\.
  * [92] M. Majzoobi, F. Koushanfar, and S. Devadas, “Fpga puf using programmable delay lines,” in _2010 IEEE international workshop on information forensics and security_. IEEE, 2010, pp. 1–6.
  * [93] S. S. Kumar, J. Guajardo, R. Maes, G.-J. Schrijen, and P. Tuyls, “The butterfly puf protecting ip on every fpga,” in _2008 IEEE International Workshop on Hardware-Oriented Security and Trust_. IEEE, 2008, pp. 67–70.
  * [94] U. Rührmair, “Secret-free security: A survey and tutorial,” _Journal of Cryptographic Engineering_ , pp. 1–26, 2022.
  * [95] G. Csaba, X. Ju, Q. Chen, W. Porod, J. Schmidhuber, U. Schlichtmann, P. Lugli, and U. Rührmair, “On-chip electric waves: An analog circuit approach to physical uncloneable functions,” _Cryptology ePrint Archive_ , 2009.
  * [96] C. Jaeger, M. Algasinger, U. Rührmair, G. Csaba, and M. Stutzmann, “Random pn-junctions for physical cryptography,” _Applied Physics Letters_ , vol. 96, no. 17, p. 172103, 2010.
  * [97] U. Rührmair, Q. Chen, M. Stutzmann, P. Lugli, U. Schlichtmann, and G. Csaba, “Towards electrical, integrated implementations of simpl systems,” in _IFIP International Workshop on Information Security Theory and Practices_ , 2010.
  * [98] U. Ruehrmair, M. Stutzmann, J. Finley, C. Jirauschek, G. Csaba, P. Lugli, E. Biebl, R. Dietmueller, K. Mueller, and H. Langhuth, “Method for security purposes,” 2012, uS Patent App. 13/250,534.
  * [99] U. Rührmair and M. van Dijk, “On the practical use of physical unclonable functions in oblivious transfer and bit commitment protocols,” _Journal of Cryptographic Engineering_ , 2013.
  * [100] U. Rührmair and M. v. Dijk, “Practical security analysis of puf-based two-player protocols,” in _International Workshop on Cryptographic Hardware and Embedded Systems_ , 2012.
  * [101] F. Tehranipoor, N. Karimian, K. Xiao, and J. Chandy, “Dram based intrinsic physical unclonable functions for system level security,” in _Proceedings of the 25th edition on Great Lakes Symposium on VLSI_ , 2015, pp. 15–20.
  * [102] S. Sutar, A. Raha, and V. Raghunathan, “D-puf: An intrinsically reconfigurable dram puf for device authentication in embedded systems,” in _2016 International Conference on Compliers, Architectures, and Sythesis of Embedded Systems (CASES)_. IEEE, 2016, pp. 1–10.
  * [103] A. Schaller, W. Xiong, N. A. Anagnostopoulos, M. U. Saleem, S. Gabmeyer, S. Katzenbeisser, and J. Szefer, “Intrinsic rowhammer pufs: Leveraging the rowhammer effect for improved security,” in _2017 IEEE International Symposium on Hardware Oriented Security and Trust (HOST)_. IEEE, 2017, pp. 1–7.
  * [104] N. A. Anagnostopoulos, T. Arul, Y. Fan, C. Hatzfeld, A. Schaller, W. Xiong, M. Jain, M. U. Saleem, J. Lotichius, S. Gabmeyer _et al._ , “Intrinsic run-time row hammer pufs: Leveraging the row hammer effect for run-time cryptography and improved security,” _Cryptography_ , vol. 2, no. 3, p. 13, 2018.
  * [105] H. Hassan, Y. C. Tugrul, J. S. Kim, V. Van der Veen, K. Razavi, and O. Mutlu, “Uncovering In-DRAM RowHammer Protection Mechanisms: A New Methodology, Custom RowHammer Patterns, and Implications,” in _MICRO_ , 2021.
  * [106] “Xilinx Alveo U200 FPGA Board,” https://www.xilinx.com/products/boards-and-kits/alveo/u200.html.
  * [107] B. Aichinger, “DDR Memory Errors Caused by Row Hammer,” in _HPEC_ , 2015\.
  * [108] R. T. Smith, J. D. Chlipala, J. F. Bindels, R. G. Nelson, F. H. Fischer, and T. F. Mantz, “Laser Programmable Redundancy and Yield Improvement in a 64K DRAM,” _JSSC_ , 1981.
  * [109] M. Horiguchi, “Redundancy Techniques for High-Density DRAMs,” in _ISIS_ , 1997.
  * [110] K. Itoh, _VLSI Memory Chip Design_. Springer, 2001.
  * [111] S. Khan, C. Wilkerson, Z. Wang, A. R. Alameldeen, D. Lee, and O. Mutlu, “Detecting and Mitigating Data-Dependent DRAM Failures by Exploiting Current Memory Content,” in _MICRO_ , 2017.
  * [112] A. Barenghi, L. Breveglieri, N. Izzo, and G. Pelosi, “Software-Only Reverse Engineering of Physical DRAM Mappings for Rowhammer Attacks,” in _IVSW_ , 2018.
  * [113] A. G. Yağlıkçı, M. Patel, J. S. Kim, R. Azizibarzoki, A. Olgun, L. Orosa, H. Hassan, J. Park, K. Kanellopoullos, T. Shahroodi, S. Ghose, and O. Mutlu, “BlockHammer: Preventing RowHammer at Low Cost by Blacklisting Rapidly-Accessed DRAM Rows,” in _HPCA_ , 2021.
  * [114] W. Xiong, N. A. Anagnostopoulos, A. Schaller, S. Katzenbeisser, and J. Szefer, “Spying on Temperature using DRAM,” in _DATE_ , 2019.
  * [115] Apple Inc., “About the Security Content of Mac EFI Security Update 2015-001,” https://support.apple.com/en-us/HT204934, June 2015.
  * [116] D.-H. Kim, P. J. Nair, and M. K. Qureshi, “Architectural Support for Mitigating Row Hammering in DRAM Memories,” _CAL_ , 2014.
  * [117] K. Bains, J. Halbert, C. Mozak, T. Schoenborn, and Z. Greenfield, “Row Hammer Refresh Command,” 2015, U.S. Patent 9,117,544.
  * [118] Z. B. Aweke, S. F. Yitbarek, R. Qiao, R. Das, M. Hicks, Y. Oren, and T. Austin, “ANVIL: Software-Based Protection Against Next-Generation Rowhammer Attacks,” in _ASPLOS_ , 2016.
  * [119] K. S. Bains and J. B. Halbert, “Distributed Row Hammer Tracking,” 2016, U.S. Patent 9,299,400.
  * [120] ——, “Row Hammer Monitoring Based on Stored Row Hammer Threshold Value,” 2016, U.S. Patent 9,384,821.
  * [121] H. Gomez, A. Amaya, and E. Roa, “DRAM Row-Hammer Attack Reduction Using Dummy Cells,” in _NORCAS_ , 2016.
  * [122] F. Brasser, L. Davi, D. Gens, C. Liebchen, and A.-R. Sadeghi, “Can’t Touch This: Software-Only Mitigation Against Rowhammer Attacks Targeting Kernel Memory,” in _USENIX Security_ , 2017.
  * [123] M. Son, H. Park, J. Ahn, and S. Yoo, “Making DRAM Stronger Against Row Hammering,” in _DAC_ , 2017.
  * [124] R. K. Konoth, M. Oliverio, A. Tatar, D. Andriesse, H. Bos, C. Giuffrida, and K. Razavi, “ZebRAM: Comprehensive and Compatible Software Protection Against Rowhammer Attacks,” in _OSDI_ , 2018.
  * [125] S. M. Seyedzadeh, A. K. Jones, and R. Melhem, “Mitigating Wordline Crosstalk Using Adaptive Trees of Counters,” in _ISCA_ , 2018.
  * [126] E. Lee, I. Kang, S. Lee, G. Edward Suh, and J. Ho Ahn, “TWiCe: Preventing Row-Hammering by Exploiting Time Window Counters,” in _ISCA_ , 2019.
  * [127] I. Kang, E. Lee, and J. H. Ahn, “CAT-TWO: Counter-Based Adaptive Tree, Time Window Optimized for DRAM Row-Hammer Prevention,” _IEEE Access_ , 2020\.
  * [128] Y. Park, W. Kwon, E. Lee, T. J. Ham, J. H. Ahn, and J. W. Lee, “Graphene: Strong yet Lightweight Row Hammer Protection,” in _MICRO_ , 2020.
  * [129] A. G. Yağlıkçı, J. S. Kim, F. Devaux, and O. Mutlu, “Security Analysis of the Silver Bullet Technique for RowHammer Prevention,” 2021.
  * [130] F. Devaux and R. Ayrignac, “Method and Circuit for Protecting a DRAM Memory Device from the Row Hammer Effect,” 2021, 10,885,966.
  * [131] J. M. You and J.-S. Yang, “MRLoc: Mitigating Row-Hammering Based on Memory Locality,” in _DAC_ , 2019.
  * [132] JEDEC, _JESD235C: High Bandwidth Memory (HBM) DRAM_ , 2020.
  * [133] ——, _JESD79-5: DDR5 SDRAM Standard_ , 2020.
  * [134] ——, _JESD209-5A: LPDDR5 SDRAM Standard_ , 2020.
  * [135] Z. Greenfield and T. Levy, “Throttling Support for Row-Hammer Counters,” 2016, U.S. Patent 9,251,885.


# Complexity of Tetris variant

Oscar Temprano
<EMAIL_ADDRESS>
##  1 Introduction

The game complexity of Tetris was first studied by Erik demaine, Susan
Hohenberger and David Liben-Nowell in “Tetris is hard" [1].
Their proof was later simplified in “Tetris is hard, made easy” [2].
The authors of the last two papers published a joint paper [3],
In “Tetris is hard” they left open the question of the complexity of a variant
of the game.
In this variant, we can move and rotate a piece all the time we want in the
first row, and the piece will not fall unless we move it down.
Once we move the piece down we will not be able to move or rotate the piece
anymore.
This way to play tetris was introduced by John Brzustowsky [4].
In this paper we are going to prove that the problem of clearing the board in
this variant of the game is NP-complete, solving a problem that has been open
during thirteen years.
To accomplish this task we are going to reduce the 3-partition problem to the
problem of clearing a particular board on that variant of tetris.

##  2 Rules of Tetris

The game tetris consists of a game board and a set of pieces (tetriminos) that
fall down to the game board.
Every tetrimino is composed of four blocks.
When a piece falls, it will fall on top of another piece or in the bottom of
the game board. The objective of the player is to survive as much time as
possible by clearing the maximum amount of lines in the process.
A line is completed when is completely filled by blocks, when that happens,
that line disappears. The game ends when blocks reach the top of the board.
There are seven different tetriminos:
Left gun (LG), right gun (RG), I(I), square (Sq), left snake (LS) , right
snake (RS) and T (T).
To see a better description of the rules of Tetris and the pieces we use,
check [1].

##  3 Reduction

Now, we are going to show the details of the reduction.

We are going to describe the 3-PARTITION problem and we are going to see how
is the initial board, and how to clear the board, if the instance of three
partition is satisfiable

###  3.1 The 3-PARTITION problem

The 3-Partition problem can be defined as follows:

Given a multiset $A$ of positive numbers $a_{1}$,…,$a_{3}s$ and a positive
value $B$ such that $B/4$ < $a_{1}$ < $B/2$ for all 1 $\leq i\leq 3s$ such
that $\sum_{i=1}^{3s}a_{i}=sB$. Can $A$ be divided into $s$ disjoint subsets
$A_{1}$,…,$A_{s}$ such that $\sum_{a_{i}\in A_{j}}=B$ for all 1 $\leq j\leq s$

######  Theorem 1.

(Garey and johnson [5] ) 3-PARTITION is np-complete in the strong sense.

###  3.2 The initial board

The width of the board is $4\times s+3$ (where "s" is the number of subsets in
which we have to place the numbers). The height of the board equals
$16+T\times 4+5$, (where T is the number that each subset should add to), we
add the number five at the end so that the player has five extra lines to
decide the movements of the pieces.

Now, we are going to see a picture of the board at the start of the game, this
board corresponds to the multiset ($\\{4,3,2,1,1,1,2,2,2\\}$).

Figure 1: Example of an initial board

The board consists of three "buckets". Each "bucket" represents a subset in
which we have to place the numbers.
As there are nine numbers, we have three buckets, one for each respective
subset. Each bucket has a separator at the left, and has a width of three, for
a total width of four blocks per bucket. Each bucket has an height of
$16+T\times 4$

In each bucket there are two planted pieces, a right gun, and a left snake on
top of it, as can be seen in th figure.
Finally, at the right of the buckets, there is a fill space with a width of
one block, and two separators ,one at the left and other at the right, with a
width of one or more each.

To see how to construct the board check [6]

Now, we are going to show how to clear the board.

First we receive a "left gun" piece. With this piece we have to choose in
which bucket we are going to put the pieces that belong to the first number.

To do that we must put the piece in top of the bucket to "open" it, as seen in
the following figure:

Figure 2: How to open a bucket

Next, we receive the pieces for every number that belongs to the multiset.
Each digit of these pieces is formed by two "T" pieces and a right gun.

We place the pieces of a particular digit like this:

Figure 3: First digit

In our example, the first digit is four, so we have to place four digits:

Figure 4: First number

Finally, the only remaining thing to do is to close the bucket, to do that, we
receive a right gun and a left snake, we must put these pieces on top of the
opened bucket:

Figure 5: Bucket closed

We repeat this sequence of movements for every number that belongs to the
multiset.

So, for each number we reecive:

\- A left gun to open a bucket.

\- For every digit of a number: two "T" pieces and a right gun.

\- A right gun and a left snake to close the bucket.

At the end of the sequence of numbers, we will have gaps in top of the
buckets:

To clear them we receive $s$ left guns to clear the gaps

And finally to clear the board we receive $4+T$ pieces of type "I" to clear
the fill region and the board ("T" is the quantity that the numbers of each
subset should add to).

To clear the fill region, we simply put the "I" pieces in vertical position,
each one on top of another.

##  4 Correctness of the reduction

In the previous section, we have seen how to reduce a positive instance of
3-PARTITION to an instance of Tetris where the board can be cleared.

Now we are going to show that every negative instance of 3-PARTITION reduces
to a game of Tetris where the board cannot be cleared. We will do this through
a series of lemmas.

######  Lemma 1.

If we try to clear pieces of the fill space with other piece other than the
"I" piece we will not be able to clear the board

###### Proof.

Any other piece different than the I piece cannot go into the fill space
without blocking it, because the I piece is the only piece that has a width of
one block. If we try to put another piece into it we will block the fill space
and we will have to clear a line extra to "unlock" it.
As we have just enough pieces to clear the board, we will not be able to clear
the board ∎

######  Lemma 2.

If we try to use a "I" piece to cover gaps of a bucket we will not we able to
clear the board

###### Proof.

Notice that we receive just enough "I" pieces to clear the fill part, if we
try to use a "I" piece to cover gaps in other bucket, we will lack pieces to
cover the fill space. By lemma one we showed that if we try to cover the fill
space with other pieces different than the "I" piece we will not be able to
clear the board ∎

######  Lemma 3.

If there is ever placed a piece above the $16+4\times T$ bottom lines we will
not be able to clear the board

###### Proof.

Notice that we have just enough pieces to clear the board, this is independent
of the 3-PARTITION instance being positive or negative.

Notice too, that in Tetris once a piece has been fixed into a stable place, it
will only fall down if the pieces behind it are cleared, it will not fall
otherwise, even if there are gaps that are not filled under it

So, if we have a piece above of the height of the buckets, we will not be able
to clear the board, because we will have to clear more lines than $16+4\times
T$ and as we have just enough pieces to clear the buckets, we will not be able
to clear the board ∎

######  Lemma 4.

If some gaps that cannot be covered by other piece different than the "I"
piece are created, we will not be able to clear the board

###### Proof.

As seen in lemma two, if we try to use an "I" piece to clear gaps of the
buckets, we will not be able to clear the board.

As we have just enough pieces to fill the buckets, if we create gaps that
cannot be filled, some buckets will have pieces above the top of the buckets.
And by lemma three, we will not be able to clear the board ∎

######  Lemma 5.

If we put a "right gun" piece inside a closed bucket we will not be able to
clear the board

###### Proof.

We will show this with a figure:

This figure shows the six different ways a right gun can be placed inside a
closed bucket

As can be seen in the figure, if we put a right gun in top of a closed bucket
we will create gaps that cannot be filled. And as it was shown in lemma four,
we will not be able to clear a board with gaps that cannot be filled

∎

######  Lemma 6.

If we put a "T" piece inside a closed bucket we will not be able to clear the
board

###### Proof.

We will show this with a figure:

This figure shows the six different ways a T can be placed inside a closed
bucket

If we look at the four way to put the T inside the bucket (the fourth one
starting from the left), we see that the piece doesnt create gaps that cannot
be filled, but it creates gaps on the left. The only way to clear that space
without creating gaps that cannot be filled later on, is with a "I" piece. But
as we showed in lemma two, if we try to cover gaps with the I piece, we will
not be able to clear the board

In the rest, we will create gaps that cannot be filled. And as it was shown in
lemma four, we will not be able to clear a board with gaps that cannot be
filled

∎

######  Lemma 7.

If we put a "left snake" piece inside a closed bucket we will not be able to
clear the board

###### Proof.

We will show this with a figure:

This figure shows the three different ways a left snake can be placed inside a
closed bucket

If we look at the second way to put the snake inside the bucket, we see that
the piece doesnt create gaps that cannot be filled, but it creates gaps on the
left. The only way to clear that space without creating gaps that cannot be
filled later on, is with a "I" piece. But as we showed in lemma two, if we try
to cover gaps with the I piece, we will not be able to clear the board

In the rest of ways to put the piece, we will create gaps that cannot be
filled. And as it was shown in lemma four, we will not be able to clear a
board with gaps that cannot be filled

∎

######  Lemma 8.

If we try to put the pieces of a digit in a way that is different that the one
we specified in the previous section, we will create gaps that cannot be
filled

###### Proof.

We will show this through a series of figures, each depicting all the ways to
put a piece of the digit:

This figure shows the six different ways in which the first piece can be
placed, as can be seen in the figure, only the first one doesnt create gaps.
And as was shown in lemma six, we cannot put this piece in a closed bucket,
without creating gaps.

Now, we are going to see the different ways of placing the second piece of the
digit, we will do this with another figure:

This figure shows the six different ways in which the second T that belongs to
the digit can be placed in the bucket, as is shown in the figure, only the
third from the left and the sixth from the left doesnt create gaps. But as we
will see later, only in the third way, can the right snake by placed without
creating gaps. And as was shown in lemma six, we cannot put this piece in a
closed bucket, without creating gaps.

Finally we are going to show that the right gun can only be put inside the
opened bucket only if we have placed the second piece in the correct way.

We will do this with two figures, one for every way to put the second piece:

This figure shows the first six different ways in which the third piece in the
digit can be placed in the bucket. As is shown in the figure,we always create
gaps And as was shown in lemma five, we cannot put this piece in a closed
bucket, without creating gaps.

This figure shows the last six different ways in which the third piece in the
digit can be placed in the bucket. As is shown in the figure, the only way to
put the piece in the bucket without creating gaps is the sixth one from the
left. An as can be seen, it coincides with the way to place the pieces of a
digit that we showed in the third section And as was shown in lemma five, we
cannot put this piece in a closed bucket without creating gaps.

∎

######  Lemma 9.

If we try to close the bucket in a way that is different that the one we
specified in the previous section, we will create gaps that cannot be filled

###### Proof.

We will show this through a series of figures, each depicting all the ways to
put a piece of the closing sequence:

As shown in the figure, the fourth, fifth and sixth way to put the first piece
are valid. And as was shown in lemma five, we cannot put this piece in a
closed bucket, without creating gaps.

Now, we are going to show that if we put the left snake in top of the fourth
and fifth "right guns" we will create gaps that cannot be filled.

We will do this through a series of figures.

As can be seen on the figures above, only the last way to place the right gun
and the left snake are the only way to close the bucket without creating
gaps.The same that we shown in section three

And as was shown in lemma seven, we cannot put the left snake in a closed
bucket, without creating gaps.

∎

######  Lemma 10.

There is only one way to open a bucket without creating gaps

###### Proof.

In the following figure we show the six different ways of placing a left gun
in a closed bucket. Only one opens the bucket, the one that doesnt create gaps
(the sixth one from the left)

∎

######  Theorem 2.

Clearing the board in this Tetris variant is NP-hard

##  5 Acknowledgements

We wish to thank Michael Wehar and the community of computer science stack
exchange (cs.stackexchange.com) for helpful criticism and commentary

## References

  * [1] Erik D. Demaine, Susan Hohenberger, and David Liben-Nowell “Tetris is Hard, Even to Approximate”. Proc. 9th Annual International Conference on Computing and Combinatorics.
  * [2] Ron Breukelaar, Hendrik Jan Hoogeboom,and Walter A. Kosters,. “Tetris is Hard, Made easy”. Technical Report 2003-9, Leiden Institute of Advanced Computer Science, Universiteit Leiden, 2003.
  * [3] Ron Breukelaar, Erik D. Demaine, Susan Hohenberger, Hendrik Jan Hoogeboom, Walter A. Kosters, and David Liben-Nowell. “Tetris is Hard, Even to Approximate”. International Journal of Computational Geometry and Applications, volume 14, number 1–2, 2004, pages 41–68.
  * [4] John Brzustowski. “Can you win at Tetris?”. Master’s thesis, University of British Columbia, 1992.
  * [5] Garey, Michael R.; Johnson, David S. “Computers and Intractability: A Guide to the Theory of NP-Completeness”. W. H. Freeman, ISBN 0-7167-1045-5.
  * [6] Hendrik Jan Hoogeboom and Walter A. Kosters. “How to construct Tetris configurations.”. Technical Report 2003-8, Leiden Institute of Advanced Computer Science, Universiteit Leiden, 2003