on a subset of chips over a 30-day period to show that the repeatability
property holds for longer periods of time (i.e., a memory segment generates a
PUF response similar to its previously-enrolled golden key irrespective of the
time since its enrollment). We examine a total of more than a million 8KiB
memory segments _across_ many chips from each of the three manufacturers as
shown in Table 4.2. The right column indicates the number of memory segments
across $n$ devices, where $n$ is indicated in the left column, and the rows
indicate the different manufacturers of the chips containing the memory
segments.

| #Chips | #Total Memory Segments
---|---|---
A | 19 | 589,824
B | 12 | 442,879
C | 14 | 437,990
Table 4.2: Number of PUF memory segments tested for 30 days.

In order to demonstrate the repeatability of evaluating a DRAM latency PUF
over long periods of time, we continuously evaluate our DRAM latency PUF
across a 30-day period using each of our chosen memory segments. For each
memory segment, we calculate the Intra-Jaccard index between the first PUF
response and each subsequent PUF response. We find the _Intra-Jaccard index
range_ , or the range of values ($max\\_value\leavevmode\nobreak\
-\leavevmode\nobreak\ min\\_value$) found across the Jaccard indices
calculated for every pair of PUF responses from a memory segment. If a memory
segment exhibits a low Intra-Jaccard index range, the memory segment generates
highly-similar PUF responses during each evaluation over our testing period.
Thus, memory segments that exhibit low Intra-Jaccard index ranges demonstrate
high repeatability.

Figure 4.4 shows the distribution of _Intra-Jaccard index ranges_ across our
memory segments with box-and-whisker plots222The box is bounded by the first
quartile (i.e., the median of the first half of the ordered set of Intra-
Jaccard index ranges) and third quartile (i.e., the median of the second half
of the ordered set of Intra-Jaccard index ranges). The median is marked by a
red line within the bounding box. The _inter-quartile range_ (IQR) is defined
as the difference between the third and first quartiles. The whiskers are
drawn out to extend an additional $1.5\times IQR$ above the third quartile and
$1.5\times IQR$ below the first quartile. Outliers are shown as orange crosses
indicating data points outside of the range of whiskers. for each of the three
manufacturers. We observe that the Intra-Jaccard index ranges are quite low,
i.e., less than 0.1 on average for all manufacturers. Thus, we conclude that
the vast majority of memory segments across all manufacturers exhibit very
high repeatability over long periods of time.

Figure 4.4: Distribution of the Intra-Jaccard index range values calculated
between many PUF responses that a PUF memory segment generates over a 30-day
period.

In order to show that every chip has a significant proportion of memory
segments that exhibit high reliability over time, we analyze per-chip Intra-
Jaccard index range properties. Table 4.3 shows the _median [minimum,
maximum]_ of the fraction of memory segments per chip that are observed to
have Intra-Jaccard index ranges below 0.1 and 0.2. Over 90% of all segments
_in each chip_ are suitable for PUF evaluation for Intra-Jaccard index ranges
below 0.1, and over 97% for Intra-Jaccard index ranges below 0.2. This means
that each chip has a significant number of memory segments that are viable for
DRAM latency PUF evaluation. Furthermore, the distributions are very narrow,
which indicates that different chips show similar behavior. We conclude that
every chip has a significant number of PUF memory segments that exhibit high
repeatability across time. We show in Section 4.7.5 how we can use a simple
characterization step to identify these viable memory segments quickly and
reliably.

| %Memory Segments per Chip
---|---
| Intra-Jaccard index range <0.1 | Intra-Jaccard index range <0.2
A | 100.00 [99.08, 100.00] | 100.00 [100.00, 100.00]
B | 90.39 [82.13, 99.96] | 96.34 [95.37, 100.00]
C | 95.74 [89.20, 100.00] | 96.65 [95.48, 100.00]
Table 4.3: Percentage of PUF memory segments per chip with Intra-Jaccard index
ranges <0.1 or 0.2 over a 30-day period. Median [minimum, maximum] values are
shown.

Temperature Effects. To demonstrate how changes in temperature affect PUF
evaluation, we evaluate the DRAM latency PUF 10 times for each of the memory
segments in Table 4.2 at each 5∘C increment throughout our testable
temperature range (55∘C-70∘C). Figure 4.5 shows the distributions of Intra-
Jaccard indices calculated between every possible pair of PUF responses
generated by the _same_ memory segment. The deltas between the operating
temperatures at the time of PUF evaluation are denoted in the x-axis
(_temperature delta_). Since we test at four evenly-spaced temperatures, we
have four distinct temperature deltas. The y-axis marks the Jaccard indices
calculated between the PUF responses. The distribution of Intra-Jaccard
indices found for a given temperature delta is shown using a box-and-whisker
plot.

Figure 4.5 subdivides the distributions for each of the three manufacturers as
indicated by A, B, and C. Two observations are in order. 1) Across all three
manufacturers, the distribution of Intra-Jaccard indices strictly shifts
towards zero as the temperature delta increases. 2) The Intra-Jaccard
distribution of PUF responses from chips of manufacturer C are the most
sensitive to changes in temperature as reflected in the large distribution
shift in Figure 4.5(C). Both observations show that evaluating a PUF at a
temperature different from the temperature during enrollment affects the
quality of the PUF response and reduces repeatability. However, 1) for small
temperature deltas (e.g., 5∘), PUF repeatability is not significantly
affected, and 2) we discuss in Section 4.7.5 how we can ameliorate this effect
during device enrollment.

Figure 4.5: DRAM latency PUF repeatability vs. temperature.

####  4.6.2 Runtime-Accessible PUF Metrics Evaluation

Throughout the remainder of this section, we show 1) how the DRAM latency PUF
satisfies the characteristics of a _runtime-accessible_ PUF (i.e., low latency
and low system interference) discussed in Section 4.3.2, and 2) that the DRAM
latency PUF significantly outperforms the DRAM retention PUF in terms of both
evaluation time and system interference.

##### Low Latency

The DRAM latency PUF consists of two key phases: 1) inducing latency failures,
and 2) filtering the PUF segment, which improves PUF repeatability (to be
discussed in Section 4.7.1). During Phase 1, we induce latency failures
multiple times (i.e., for multiple _iterations_) over the PUF memory segment
and count the failures in a separate buffer for additional bookkeeping (we
discuss this in further detail in Section 4.7.2). The execution time of this
phase depends directly on three factors:

  1. 1.

The value of the $t_{RCD}$ timing parameter. A smaller $t_{RCD}$ value causes
each read to have a shorter latency.

  2. 2.

The size of the PUF memory segment. A larger memory segment requires more DRAM
read requests per iteration. In our devices, we observe that latency failures
are induced at a granularity of 32 bytes with each read request, so we can
find the total number of required DRAM reads by dividing the size of the
memory segment by 32 bytes.

  3. 3.

The number of iterations used to induce latency failures. More iterations lead
to a longer evaluation time.

Increasing any one of these factors independently of the others directly
results in an increase in PUF evaluation time. We experimentally find that a
single low-$t_{RCD}$ access to DRAM, along with its associated bookkeeping and
memory barrier, takes 3.4$\mu$s. Because the value of $t_{RCD}$ is on the
scale of tens of nanoseconds [141], changing its value negligibly affects the
time for each low-$t_{RCD}$ access. Thus, we use a constant 3.4$\mu$s for each
read regardless of the $t_{RCD}$ value to find a good estimate of the PUF
evaluation time in Equation 4.1. We experimentally show that Phase 2 has
negligible runtime ($<0.1\%$ of total DRAM latency PUF evaluation time)
compared with Phase 1, so we omit Phase 2 in our PUF evaluation time
estimation.We express PUF evaluation time estimation as:

$T_{PUF\\_eval}=(N_{iters})\times[(size_{mem\\_seg})/(32\leavevmode\nobreak\
\mathrm{bytes})]\times 3.4\mu s\vspace{-5pt}$ (4.1)

where $N_{iters}$ is the number of times we induce latency failures on each 32
byte block of the memory segment, and $size_{mem\\_seg}$ is the size of the
memory segment used to evaluate the PUF. For our final chosen configuration
(discussed in detail in Section 4.7), we use the parameters
$size_{mem\\_seg}=8$KiB (Section 4.7.3), $t_{RCD}=9.8$ns (Section 4.7.4), and
$N_{iters}=100$ (Section 4.7.1). Using Equation 4.1, we expect this
configuration to result in an evaluation time of approximately 87ms.

In order to experimentally verify Equation 4.1, we measure the evaluation time
of the DRAM latency PUF for 10000 evaluations across chips from all three
manufacturers at 55∘C. We find that evaluation times are normally distributed
per-manufacturer according to
$\mathcal{N}_{A}(\mu=89.1\mathrm{ms},\leavevmode\nobreak\
\sigma=0.0132\mathrm{ms})$,
$\mathcal{N}_{B}(\mu=88.2\mathrm{ms},\leavevmode\nobreak\
\sigma=0.0135\mathrm{ms})$, and
$\mathcal{N}_{C}(\mu=87.2\mathrm{ms},\leavevmode\nobreak\
\sigma=0.0102\mathrm{ms})$. These distribution parameters show that evaluation
times have very similar means and are extremely tightly distributed (i.e.,
$<0.0002$ relative standard deviation). This is expected because, for any
particular configuration, DRAM latency PUF evaluation essentially requires a
_constant_ number of DRAM accesses. Therefore, any variation in PUF evaluation
time comes from variations in code execution (e.g., multitasking, interrupts,
DRAM refresh, etc.) rather than any characteristics of the PUF itself. In
order to compare these runtime distributions with the result of Equation 4.1,
we take take the mean of the mixture distribution of the three per-
manufacturer distributions (i.e.,
$\mathcal{N}_{ABC}(\mu=88.2\mathrm{ms},\leavevmode\nobreak\
\sigma=0.716\mathrm{ms})$) and find that the 87ms estimate from Equation 4.1
results in only 1.4% error.

Figure 4.1 provides a comparison of DRAM latency PUF evaluation time with
retention PUF evaluation time across our testable temperature range (i.e.,
55∘C-70∘C). We find that the DRAM latency PUF significantly outperforms the
DRAM retention PUF for an equivalent DRAM capacity overhead of 64KiB (i.e.,
8KiB latency PUF memory segment + 56KiB counter buffer), providing an average
(minimum, maximum) speedup of 152x (109x, 181x) at 70∘C and 1426x (868x,
1783x) at 55∘C. By increasing the memory segment size from 64KiB to 64MiB, we
can evaluate a DRAM retention PUF in 1.05s (1.01s, 1.09s) at 70∘C (Section
4.5.3). However, the DRAM latency PUF still outperforms this configuration
_without_ an increase in DRAM capacity overhead (i.e., still with an 8KiB
memory segment), providing a speedup of 12.1x (11.6x, 12.5x).

Similarly to prior work on DRAM latency reduction [55, 191], we experimentally
find that inducing latency failures is minimally affected by changes in
temperature. Importantly, since our method of inducing latency failures does
_not_ change with temperature (Section 4.7.2), DRAM latency PUF evaluation
time remains reliably short across _all_ operating temperatures. We conclude
that the DRAM latency PUF 1) can be evaluated at speeds that are orders of
magnitude faster than the DRAM retention PUF, and 2) overcomes the temperature
dependence of the DRAM retention PUF and maintains a low evaluation time
across all temperatures.

##### Low System Interference

The DRAM latency PUF exhibits two major sources of system interference: 1)
requiring exclusive DRAM rank/bank access throughout PUF evaluation, and 2)
using a region in a separate DRAM rank to count latency failures (Section
4.7.2).

First, because DRAM timing parameters can only be manipulated for the coarse
granularity of a DRAM rank, any other access to the same rank containing the
PUF memory segment must be blocked during PUF evaluation. Such blocking
prevents other accesses from obeying the same reduced timing parameters and
corrupting the data. For this reason, DRAM latency PUF evaluation requires
exclusive access to a full DRAM rank for the entire duration of PUF
evaluation. Fortunately, the DRAM latency PUF’s quick evaluation time (i.e.,
88.2ms on average) guarantees that the DRAM rank will be unavailable only for
a short period of time. This is in stark contrast with the DRAM retention PUF,
which 1) blocks rank/bank access for much longer periods of time (e.g., on the
order of _minutes_ or seconds), and 2) requires the memory controller to issue
a large number of refresh operations to rows in the rank/bank outside of the
PUF memory segment for the same period of time [364].

Second, the DRAM latency PUF algorithm (described in detail in Section 4.7.2)
requires a small _counter buffer_ (e.g., a 56KiB buffer for an 8KiB PUF memory
segment) which stores counters for each bit of the PUF memory segment. This
comes at the cost of both DRAM capacity overhead and additional memory traffic
penalty. However, given that the DRAM capacity overhead is small (e.g.,
<0.003% for a 2GB DRAM using an 8KiB memory segment) and the additional
bandwidth consumed is extremely low (e.g., on the order of 100MB/s using an
8KiB memory segment) in the context of total DRAM bandwidth (e.g., 8GB/s), we
conclude that the additional system interference induced by the counter buffer
is insignificant. In practice, we expect system caches to (fully) hold the
counter buffer, further reducing the required DRAM bandwidth.

###  4.7 Design Considerations

As we experimentally showed in Section 4.6, utilizing DRAM latency failures is
a viable method for evaluating runtime-accessible PUFs in commodity,
unmodified DRAM chips. However, due to variation across DRAM cells and chips,
there are various important design considerations that must be made in the
implementation of the DRAM latency PUF. In this section, we discuss these
considerations for implementing the DRAM latency PUF.

####  4.7.1 Repeatability of Cell Latency Failures

Due to many underlying factors (e.g., process variation, temperature), each
DRAM cell fails with a different probability when read with a timing parameter
reduced beyond the manufacturer specification [190, 191, 55, 188, 54]. We
define a _latency-weak cell_ as a cell that has a significant probability of
failure when read with a reduced timing parameter. Our DRAM latency PUFs are
comprised of the locations of latency-weak cells because such cells can be
repeatably found. In order to repeatably find the set of latency-weak cells,
we employ _many_ iterations (e.g., on the order of 100) of inducing latency
failures at the PUF memory segment. This improves the chances of a PUF
evaluation to find a significant proportion of the latency-weak cells. Because
we assume that any given cell has a static probability ($p$) to fail when
accessed with reduced latency, we can model the number of times that a cell
must be accessed before observing a latency failure as a _geometric random
variable_ with a success probability of $p$. The geometric distribution with
parameter $p$ has a mean value of $\frac{1}{p}$. By sampling cells over $x$
iterations during DRAM latency PUF evaluation, we expect to find all cells
that fail with a probability greater than or equal to $\frac{1}{x}$. There is
a chance that a cell with a failure probability below the threshold fails
during an instance of the PUF evaluation, reducing the similarity of the PUF
responses across evaluations and thus the repeatability of the PUF. To
mitigate this issue, we apply a _filter_ (see Section 4.7.2) that removes
cells that we observe to fail in only a small proportion of the $x$
iterations. We empirically find that removing cells that fail in less than 10%
of the iterations results in the highest Intra-Jaccard indices across PUF
responses.

In order to determine how many iterations to induce latency failures for
during latency PUF evaluation, we generate PUF responses across our devices
using a varying number of iterations between 1 and 1024. For each set of PUF
responses generated with a given number of iterations, we calculate the box-
and-whisker plots for both Inter- and Intra-Jaccard distributions (not shown).
We find that for PUF responses from chips across all manufacturers, the Inter-
Jaccard _and_ Intra-Jaccard distributions have strictly the same or increasing
medians, first and third quartiles, and whiskers, for an increasing number of
iterations.

Higher Intra-Jaccard index distribution values represent a more repeatable PUF
since the distribution directly reflects the similarities of PUF responses
from the same memory segment. We find that the Intra-Jaccard index
distribution’s median and bottom whiskers increase by 0.0025 and 0.0054,
respectively, for every doubling of the number of iterations. On the other
hand, higher Inter-Jaccard index distribution values represent higher
similarity across distinct memory segments. Such higher values would limit the
PUF’s ability to identify many unique devices. We find that the Inter-Jaccard
index distribution’s median and top whiskers increase by 0.0012 and 0.0011,
respectively, for every doubling of the number of iterations. Based on our
experimental analyses of these tradeoffs, we choose to induce latency failures
for 100 iterations during each DRAM latency PUF evaluation. We next discuss in
detail our algorithm for evaluating DRAM latency PUFs with high repeatability.

####  4.7.2 DRAM Latency PUF Evaluation Algorithm

We provide an implementable algorithm for evaluating a repeatable DRAM latency
PUF at a given memory segment. While we focus on evaluating DRAM latency PUFs
with $t_{RCD}$-induced failures, Algorithm 3 works with any other timing
parameter capable of inducing failures. We first initialize the PUF memory
segment indicated by $Segment[seg\\_id]$ by setting every bit in the memory
segment to “1” (line 2). We then attempt to find the reliable set of failures
as fast as possible in the memory segment (lines 4-11). Because DRAM RD
commands require a $t_{RCD}$ delay only after the activation of a previously
closed DRAM row, $t_{RCD}$ failures can only be observed when issuing a read
request to a _closed_ DRAM row. The key idea is to iterate over each row
sequentially such that each read request goes to a different row (i.e.,
perform column order accesses through the memory segment of interest) as shown
in lines 7-9. Before inducing failures across the PUF memory segment, we must
first obtain exclusive access to the rank containing the PUF memory segment
(line 4), due to the rank-level granularity of changing DRAM timing parameters
(Section 2.6). We then reduce the value of $t_{RCD}$ for the entire rank
containing the PUF memory segment (line 5). During the iterations of inducing
$t{RCD}$ failures (lines 6-11), we issue a memory barrier (line 10) after each
read. This ensures that 1) _only one_ memory instruction is in flight at a
given time and, thus, improves repeatability by simplifying the logic required
by the memory controller when issuing memory accesses, and 2) read requests do
_not_ get reordered by the memory controller to exploit row buffer locality
[274, 273, 242, 171, 243, 311, 337, 172]. Instead, each access activates a new
row, while obeying the $t_{RCD}$ timing parameter. We find that the
instruction order indicated by lines 6-11 is the fastest method for finding a
reliable set of latency failures in a memory segment. For every read, the
$t_{RCD}$ failure locations are determined and their failures are counted in a
separate rank for bookkeeping (line 11). After all iterations of inducing
$t_{RCD}$ failures, we must reset the $t_{RCD}$ value to the default (line
12), filter the PUF segment (line 13; see _Filtering Mechanism_), release
exclusive access to the rank containing the PUF memory segment (line 14), and
finally return the PUF response, i.e., the resulting _error pattern_ from the
PUF evaluation at the PUF memory segment (line 15).

1

2evaluate_DRAM_latency_PUF($seg\\_id$):

3 write known data (all 1’s) to Segment[$seg\\_id$]

4 $rank\\_id$ $\leftarrow$ DRAM rank containing $seg\\_id$

5 obtain exclusive access to Rank[$rank\\_id$]

6 set low $t_{RCD}$ for Rank[$rank\\_id$]

7 for $i\leavevmode\nobreak\ =\leavevmode\nobreak\ 1\leavevmode\nobreak\
to\leavevmode\nobreak\ num\\_iterations:$

8 for all $col$ in Segment[$seg\\_id$]

9 for all $row$ in Segment[$seg\\_id$]:  // column-order reads

10 $read()$ // induce read failures

11 $memory\\_barrier()$ // one access at a time

12 $count\\_failures()$ // record in another rank

13 set default $t_{RCD}$ for Rank[$rank\\_id$]

14 filter the PUF memory segment  // See _Filtering Mechanism_

15 release exclusive access to Rank[$rank\\_id$]

return error pattern at Segment[$seg\\_id$]

Algorithm 3 Evaluate DRAM latency PUF

Filtering Mechanism. In order to improve the repeatability of the DRAM latency
PUF, we employ a _filtering mechanism_ which removes the cells with low
failure probability from the PUF response (as shown on line 13 in Algorithm
3). The key idea is to count, for each bit location in the PUF memory segment,
the number of iterations in which the location fails and then use that count
to determine whether the bit location should be _set_ (“1”) or _cleared_ (“0”)
in the final PUF response. Every bit in the DRAM PUF memory segment has a
corresponding counter that we store in the _counter buffer_ , a data structure
we allocate in a DRAM rank separate from the one containing the PUF memory
segment. This is to ensure that read/write requests to the counter buffer
follow manufacturer-specified timing parameters and do not induce latency
failures.

After each reduced-latency read request in the PUF memory segment, we find all
bit locations in the read data that resulted in a latency failure, and
increment their corresponding counters in the counter buffer. After all
iterations of inducing latency failures are completed, we compare every
counter of each bit location in the PUF memory segment against a threshold. If
a counter holds a value greater than the threshold (i.e., the counter’s
corresponding bit location failed more than $n$ times, where $n$ is the
threshold), we set the corresponding bit location. Otherwise, we clear it.

Memory Footprint. Equation 4.2 provides the memory footprint required by PUF
evaluation:

$mem_{total}\leavevmode\nobreak\ =\leavevmode\nobreak\
(size_{mem\\_seg})\leavevmode\nobreak\ +\leavevmode\nobreak\
(size_{counter\\_buffer})\vspace{-5pt}$ (4.2)

where $size_{mem\\_seg}$ is the size of the PUF memory segment and
$size_{counter\\_buffer}$ is the size of the counter buffer. The size of the
counter buffer can be calculated using Equation 4.3:

$size_{counter\\_buffer}\leavevmode\nobreak\ =\leavevmode\nobreak\
(size_{mem\\_seg})\times\lceil\log_{2}N_{iters}\rceil\vspace{-5pt}$ (4.3)

where $size_{mem\\_seg}$ is the size of the PUF memory segment and $N_{iters}$
is the number of iterations that we want to induce latency failures for. Since
we require one counter per bit in the memory segment, we must multiply this
quantity by the size of each counter. Since the counter must be able to store
up to the value of $N_{iters}$ (e.g., in the case of a cell that fails every
iteration), each counter must be $\lceil\log_{2}N_{iters}\rceil$ bits wide.
For a memory segment size of 8KiB, we find that the DRAM latency PUF’s total
memory footprint is 64KiB. From this, we conclude that DRAM latency PUFs have
insignificant DRAM capacity overhead.

####  4.7.3 Variation Among PUF Memory Segments

We observe a variation in latency failure rates across different memory
segments, which make some DRAM memory segments more desirable to evaluate DRAM
latency PUFs with than others. Because we want to find 512 bits that fail per
PUF memory segment (Section 4.5.2), we consider only those memory segments
that have at least 512 failing bits as _good_ memory segments. In order to
determine the best size of the memory segment to evaluate the DRAM latency PUF
on, we study the effect of varying memory segment size on 1) DRAM capacity
overhead, 2) PUF evaluation time, and 3) fraction of good memory segments per
device. As the memory segment size increases, both the DRAM capacity overhead
and the PUF evaluation time increase linearly. The number of possible PUF
memory segments for a DRAM device with a DRAM latency PUF is obtained by
counting the number of contiguous PUF memory segments across all of DRAM
(i.e., dividing the DRAM size by the PUF memory segment size). Thus, larger
PUF memory segments result in fewer possible PUF memory segments for a DRAM
device. From an experimental analysis of the associated tradeoffs of varying
the PUF memory segment size (not shown), we choose a PUF memory segment size
of 8KiB.333We will provide details in a technical report/extended version for
all other results that we cannot provide detail for in the submission.

In Table 4.4, we represent the distribution of the percentage of good memory
segments per chip with a _median [minimum, maximum]_ across each of the three
manufacturers. The left column shows the number of chips tested, the right
column shows the representation of the distribution, and the rows indicate the
different manufacturers of the chips. We see that an overwhelming majority of
memory segments from manufacturers A and B are good for PUF evaluation. Memory
segments from chips of manufacturer C were observed to exhibit less latency
failures, but across each of our chips we could find at least 19.4% of the
memory segments to be good for PUF evaluation. Of the total number of PUF
memory segments tested (shown in Table 4.2), we experimentally find that 100%,
64.06%, and 19.37% of memory segments are _good_ (i.e., contain enough
failures to be considered for PUF evaluation) in the worst-case chips from
manufacturers A, B, and C. We conclude that there are plenty of PUF memory
segments that are good enough for DRAM latency PUF evaluation.

| #Chips | Good Memory Segments per Chip (%)
---|---|---
A | 19 | 100.00 [100.00, 100.00]
B | 12 | 100.00 [64.06, 100.00]
C | 14 | 30.86 [19.37, 95.31]
Table 4.4: Percentage of _good_ memory segments per chip across manufacturers.
Median [min, max] values are shown.

####  4.7.4 Support for Changing Timing Parameters

In order to induce latency failures, the manufacturer-specified DRAM timing
parameters must be changed. Some existing processors [191, 1, 12] enable
software to directly manipulate DRAM timing parameters. These processors can
trivially implement and evaluate a DRAM latency PUF with _minimal_ changes to
the software and no changes to hardware. However, for other processors that
cannot directly manipulate DRAM timing parameters, we would need to simply
enable software to programmatically modify memory controller registers which
indicate the DRAM timing parameters that a memory access must observe.

We find that we can reliably induce latency failures when we reduce the value
of $t_{RCD}$ from a default value of 18ns to between 6ns and 13ns. Given this
wide range of failure-inducing $t_{RCD}$ values, most memory controllers
should be able to issue read requests with a $t_{RCD}$ value within this
range.

####  4.7.5 Device Enrollment

Device enrollment is a one-time process consisting of evaluating all possible
PUFs from across the entire challenge-response space and securely storing the
evaluated PUFs in a trusted database such that they can be later queried for
authentication [153, 318, 364]. Since the goal of PUF authentication is to
ensure that a challenge-response is difficult to replicate without access to
the original device, enrollment must be done securely so that the full set of
all possible challenge-response pairs is known only to the trusted database
and can be created _only_ by the device owner.

Similar to prior works’ approach to DRAM PUFs [364, 328, 318], we assume that
a trusted third party (e.g., the DRAM manufacturer) performs device enrollment
prior to making the system available to the end consumer. This ensures that
the complete set of all possible challenge responses are known only by the
trusted third party. After the device is in the field, even the trusted third
party _cannot_ regenerate the enrollment data. Thus, allowing the trusted
third party to both characterize and enroll the responses makes it extremely
difficult for a malicious attacker to obtain the full set of possible response
pairs without first compromising the trusted third party.

Because DRAM latency PUF responses vary depending on the temperature of DRAM
during evaluation time (see Section 4.6.1), we must enroll multiple golden
keys at varying temperature intervals. This enables a PUF response to match at
least one golden key during authentication regardless of the temperature
during evaluation time. We find that some chips generate PUF responses with
less variation across a range of temperatures than other chips. Chips with
less variation can enroll golden keys for temperatures at larger intervals
than chips with more variation.

####  4.7.6 In-DRAM Error Correcting Codes

Some new DRAM chips utilize in-DRAM _error-correcting codes_ (ECC), which
perform single-bit error correction per _word_ (i.e., typically 64 data bits)
invisibly to the system [246, 151, 248], to overcome the reliability
challenges of DRAM technology scaling [238, 239, 170, 207, 244, 230, 284].
When such chips are used for DRAM latency PUFs, ECC words with only one error
appear to be error-free to the memory controller, leaving fewer total errors
available for PUF response. We note that error correction _deterministically_
transforms DRAM error patterns. Thus, a DRAM PUF (on a chip with in-DRAM ECC)
that repeatably induces the same error pattern prior to ECC correction, would
repeatably result in a different but _consistent error pattern_ after ECC
correction.

In order to support PUF evaluation in a system using DRAM chips with in-DRAM
ECC, we would need to evaluate PUFs with a higher _raw bit error rate_ (i.e.,
the error rate before ECC is performed) relative to non-ECC DRAMs. A higher
raw bit error rate would produce enough observable failures (after ECC is
performed) for a PUF. The DRAM latency PUF can achieve this higher raw bit
error rate by simply reducing the latency parameter value further. Such
reduction would also ideally reduce PUF evaluation time and system
interference. Therefore, we expect the DRAM latency PUF to be evaluated even
faster in chips with built-in ECC.444In contrast, DRAM retention PUF _must_ be
evaluated with a longer refresh interval to increase the raw bit error rate in
a DRAM chip with in-DRAM ECC. This leads to a significantly longer DRAM
retention PUF evaluation time when in-DRAM ECC is used. As stronger ECC
mechanisms are used, i.e., ECC can correct DRAM words containing more than 1
error, we expect even lower evaluation latencies and lower system interference
with the DRAM latency PUF.

####  4.7.7 Effect of High-Temperature

Our evaluation of the DRAM latency and retention PUFs is limited to the 70∘C
maximum DRAM temperature. We clearly show in Section 4.5.2 that DRAM latency
PUFs are much faster than DRAM retention PUFs at 70∘C and lower (Figure 4.1).
However, at higher temperatures (e.g., $>85^{\circ}$C), DRAM retention PUFs
could become faster than DRAM latency PUFs.555Note that the DDR protocol
specifies that every cell must be refreshed at least every 32ms for LPDDR3/4
or 64ms for DDR3/4 below $85^{\circ}$C and at even higher rates at higher
temperatures.

If a DRAM retention PUF is faster than the DRAM latency PUF at a very high
temperature, it is easy to envision a mechanism that dynamically switches
between DRAM latency PUFs and DRAM retention PUFs based on the device
operating temperature at the time of evaluation. This mechanism could exploit
the strengths of each type of DRAM PUF in order to allow the fastest possible
PUF evaluation time. By exploiting in-DRAM temperature sensors that already
exist in modern DRAM chips [141, 140, 191, 139], this mechanism could
potentially be implemented with no additional hardware overhead beyond what is
already required for DRAM retention PUFs and DRAM latency PUFs individually.

Such a mechanism would require challenge-response pairs from both the DRAM
retention PUF and DRAM latency PUF to be enrolled. Furthermore, since
retention failure rates vary significantly across different chips [206, 155,
260], each chip will have a different temperature at which the mechanism
switches between the two DRAM PUFs. This could considerably impact enrollment
time and complicate the device authentication process. Ultimately, it is up to
the system architect to decide whether such a mechanism is worth the
evaluation runtime benefits at very high temperatures (which is likely to be
on the order of tens of milliseconds). We leave a full exploration of this
hybrid DRAM latency-retention PUF mechanism to future work.

###  4.8 Related Work

To our knowledge, this is the first work to: 1) introduce the idea of
violating DRAM read latency parameters to create a fast, runtime-accessible
DRAM PUF without modifying commodity DRAM devices, 2) introduce an effective
DRAM PUF that is runtime-accessible at all operating temperatures, 3)
demonstrate a wide variety of tradeoffs in DRAM PUFs, based on extensive new
experimental data from 223 state-of-the-art LPDDR4 DRAM chips, 4) demonstrate
the prohibitively slow evaluation times of the DRAM retention PUF, the
previously fastest DRAM PUF suitable for commodity devices.

In this section, we discuss prior works that propose DRAM PUFs and PUFs based
on other substrates. The proliferation of recent works on DRAM PUFs reflects
the growing importance of DRAM PUFs given DRAM’s near ubiquity in modern
systems and large address space.

DRAM Retention PUFs. We have already described the basics of DRAM retention
PUFs in Section 4.5 and extensively evaluated them in Section 4.5. We briefly
explain the differences between prior proposals. Keller et al. [154] is the
first to propose using DRAM retention failures as unique identifiers, shortly
followed by Xiong et al. [364] and D-PUF [318], both of which enable runtime-
accessible DRAM retention PUFs. Other works propose further optimizations for
improving the quality of DRAM retention PUFs [268, 322, 329]. As our
experimental evaluations across 223 LPDDR4 DRAM chips show, DRAM retention
PUFs take very long to evaluate at common-case operating temperatures; they
are orders of magnitude slower than our proposal (see Section 4.5). A work
[235] published after the DRAM Latency PUF, demonstrates highly reliable
debiasing techniques for PUFs generated with retention failures.

Other DRAM PUFs. Hashemian et al. [117] propose adding a delay generator to
the DRAM write-circuitry to induce failures. However, this requires additional
hardware and cannot be applied to existing DRAM designs. Tehranipoor et al.
[328, 152] suggest using DRAM start-up values for PUFs, but this precludes
runtime evaluation by requiring a DRAM power cycle for every authentication.
In a work published after this work, Talukder et al., [321] propose evaluating
a PUF by inducing precharge latency failures and show that they can provide
PUFs orders of magnitude faster, since precharge latency failures occur at
larger granularities than activation latency failures.

PUFs Based on Other Substrates. Many PUFs have been proposed for various other
substrates, including other memory technologies and customized hardware
designs. We categorize them into delay-based and memory-based PUFs.

Delay-based PUFs include 1) arbiter PUFs [195, 200, 226, 278, 251, 252, 116,
370], which rely on process variation to extract the unique behavior of two
identical competing circuit paths, 2) ring oscillator PUFs [92, 91, 314, 205],
which rely on frequencies of oscillating signals from chained inverters, and
3) Current Mirror Array (CMA) PUFs [355], which rely on the manufacturing
process variation in a customized circuit typically used for machine learning
tasks. These works rely on customized hardware _not_ present in commodity
systems. FPGA-based PUFs [179, 108, 224, 223, 107, 106, 331, 93] overcome the
need for hardware changes. However, they are not as common as DRAM in computer
systems.

Memory-based PUFs include SRAM PUFs, which rely on SRAM start up values [107,
126, 127, 67, 32, 382, 359, 319] and voltage reduction induced failures [19];
butterfly PUFs, which mimic the behavior of SRAM cells with cross-coupled data
latches [179]; latch PUFs, which cross-couple two NOR-gates [309]; flip-flop
PUFs, which exploit the power up behavior of regular flip-flops [221, 338];
and PUFs for emerging memory technologies [136, 177, 277, 342, 59, 60, 208,
71, 374, 375, 343, 31, 254, 149]. These prior works either require additional
customized hardware or usage of SRAM, which has a small address space compared
to DRAM, and thus cannot accommodate a large number of challenge-response
pairs.

###  4.9 Limitations

Although the DRAM Latency PUF can be used immediately in certain systems, the
DRAM Latency PUF has a few limitations that prevent its immediate deployment
in all real systems at its full potential.

First, the DRAM Latency PUF has a linear challenge-response space which
results in its categorization as a weak PUF. While weak PUFs have many use
cases in the field, a strong PUF (i.e., a PUF with an exponential challenge-
response space) is more practical and provides added value to a system. We
believe that studying the interactions between many DRAM timing parameters may
help to identify effects of parameters that can be combined to build a strong
PUF with an exponential challenge-response space.

Second, the DRAM Latency PUF requires a flexible memory controller that can
interleave DRAM accesses with varying timing parameters in order to minimize
the overhead that evaluating this PUF would cause on a standard system that
likely has higher overhead in changing timing parameters.

Third, as the DRAM bus is considered an insecure communication channel, the
current interface for evaluating the PUF over the DRAM bus is prone to
interference and eavesdropping. As the DRAM Latency PUF can be evaluated
purely on the DRAM chip itself, we believe that developing simple logic nearby
memory to facilitate the evaluation of the DRAM latency PUF on DRAM without
relying on an insecure channel may help to further improve the security of the
PUF.

Fourth, our aging studies are limited to a 30-day period. While we demonstrate
that PUF responses do not change significantly over 30 days, long-term aging
may have stronger effects. If long-term effects change PUF responses such that
they are incomparable to the golden PUF responses, occasional re-profiling may
be required to reliably employ the DRAM Latency PUF.

###  4.10 Summary

We introduce and analyze the DRAM latency PUF, a new DRAM PUF suitable for
runtime authentication. The DRAM latency PUF intentionally violates
manufacturer-specified DRAM timing parameters in order to provide many highly
repeatable, unique, and unclonable PUF responses with low latency. Through
experimental evaluation using 223 state-of-the-art LPDDR4 DRAM devices, we
show that the DRAM latency PUF reliably generates PUF responses at runtime-
accessible speeds (i.e., 88.2ms on average) at all operating temperatures. We
show that the DRAM latency PUF achieves an average speedup of 152x/1426x at
70∘C/55∘C when compared with a DRAM retention PUF of the same DRAM capacity
overhead, and it achieves even greater speedups at lower temperatures. We
conclude that the DRAM latency PUF enables a fast and effective substrate for
runtime device authentication across all operating temperatures, and we hope
that the advent of runtime-accessible PUFs like the DRAM latency PUF and the
detailed experimental characterization data we provide on modern DRAM devices
will enable security architects to develop even more secure systems for future
devices.

##  Chapter 5 D-RaNGe: Using Commodity DRAM Devices to Generate True Random
Numbers with Low Latency and High Throughput

We propose a new DRAM-based true random number generator (TRNG) that leverages
DRAM cells as an entropy source. The key idea is to intentionally violate the
DRAM access timing parameters and use the resulting errors as the source of
randomness. Our technique specifically decreases the DRAM row activation
latency (timing parameter $t_{RCD}$) below manufacturer-recommended
specifications, to induce read errors, or activation failures, that exhibit
true random behavior. We then aggregate the resulting data from multiple cells
to obtain a TRNG capable of providing a high throughput of random numbers at
low latency.

To demonstrate that our TRNG design is viable using commodity DRAM chips, we
rigorously characterize the behavior of activation failures in 282 state-of-
the-art LPDDR4 devices from three major DRAM manufacturers. We verify our
observations using four additional DDR3 DRAM devices from the same
manufacturers. Our results show that many cells in each device produce random
data that remains robust over both time and temperature variation. We use our
observations to develop D-RaNGe, a methodology for extracting true random
numbers from commodity DRAM devices with high throughput and low latency by
deliberately violating the read access timing parameters. We evaluate the
quality of our TRNG using the commonly-used NIST statistical test suite for
randomness and find that D-RaNGe: 1) successfully passes each test, and 2)
generates true random numbers with over two orders of magnitude higher
throughput than the previous highest-throughput DRAM-based TRNG.

###  5.1 True Random Number Generators (TRNGs)

A _true random number generator (TRNG)_ requires physical processes (e.g.,
radioactive decay, thermal noise, Poisson noise) to construct a bitstream of
random data. Unlike pseudo-random number generators, the random numbers
generated by a TRNG do _not_ depend on the previously-generated numbers and
_only_ depend on the random noise obtained from physical processes. TRNGs are
usually validated using statistical tests such as NIST [279] or DIEHARD [227].
A TRNG typically consists of 1) an _entropy source_ , 2) a _randomness
extraction technique_ , and sometimes 3) a _post-processor_ , which improves
the randomness of the extracted data often at the expense of throughput. These
three components are typically used to reliably generate true random numbers
[308, 315].

Entropy Source. The entropy source is a critical component of a random number
generator, as its amount of entropy affects the unpredictability and the
throughput of the generated random data. Various physical phenomena can be
used as entropy sources. In the domain of electrical circuits, thermal and
Poisson noise, jitter, and circuit metastability have been proposed as
processes that have high entropy [353, 269, 126, 127, 339, 229, 42, 332, 33].
To ensure robustness, the entropy source should not be visible or modifiable
by an adversary. Failing to satisfy that requirement would result in
generating predictable data, and thus put the system into a state susceptible
to security attacks.

Randomness Extraction Technique. The randomness extraction technique harvests
random data from an entropy source. A good randomness extraction technique
should have two key properties. First, it should have high throughput, i.e.,
extract as much as randomness possible in a short amount of time [176, 308],
especially important for applications that require high-throughput random
number generation (e.g., security applications [109, 346, 160, 75, 181, 61,
377, 185, 22, 276, 220, 308, 30, 323, 40, 229, 368], scientific simulation
[220, 40]). Second, it should not disturb the physical process [176, 308].
Affecting the entropy source during the randomness extraction process would
make the harvested data predictable, lowering the reliability of the TRNG.

Post-processing. Harvesting randomness from a physical phenomenon _may_
produce bits that are biased or correlated [176, 267]. In such a case, a post-
processing step, which is also known as _de-biasing_ , is applied to eliminate
the bias and correlation. The post-processing step also provides protection
against environmental changes and adversary tampering [176, 267, 308]. Well-
known post-processing techniques are the von Neumann corrector [146] and
cryptographic hash functions such as SHA-1 [76] or MD5 [272]. These post-
processing steps work well, but generally result in decreased throughput
(e.g., up to 80% [182]).

###  5.2 Motivation and Goal

True random numbers sampled from physical phenomena have a number of real-
world applications from system security [22, 276, 308] to recreational
entertainment [308]. As user data privacy becomes a _highly-sought_ commodity
in Internet-of-Things (IoT) and mobile devices, enabling primitives that
provide security on such systems becomes critically important [203, 263, 377].
Cryptography is one typical method for securing systems against various
attacks by encrypting the system’s data with keys generated with true random
values. Many cryptographic algorithms require random values to generate keys
in many standard protocols (e.g., TLS/SSL/RSA/VPN keys) to either 1) encrypt
network packets, file systems, and data, 2) select internet protocol sequence
numbers (TCP), or 3) generate data padding values [109, 346, 160, 75, 181, 61,
377, 185]. TRNGs are also commonly used in authentication protocols and in
countermeasures against hardware attacks [61], in which psuedo-random number
generators (PRNGs) are shown to be insecure [346, 61]. To keep up with the
_ever-increasing_ rate of secure data creation, especially with the growing
number of commodity data-harvesting devices (e.g., IoT and mobile devices),
the ability to generate true random numbers with _high throughput and low
latency_ becomes ever more relevant to maintain user data privacy. In
addition, _high-throughput_ TRNGs are already _essential_ components of
various important applications such as scientific simulation [220, 40],
industrial testing, statistical sampling, randomized algorithms, and
recreational entertainment [22, 276, 220, 308, 30, 323, 40, 377, 229, 368].

A _widely-available, high-throughput, low-latency_ TRNG will enable all
previously mentioned applications that rely on TRNGs, including improved
security and privacy in most systems that are known to be vulnerable to
attacks [203, 263, 377], as well as enable research that we may not anticipate
at the moment. One such direction is using a one-time pad (i.e., a private key
used to encode and decode only a single message) with quantum key
distribution, which requires at least _4Gb/s_ of true random number generation
throughput [354, 64, 214]. Many _high-throughput_ TRNGs have been recently
proposed [181, 334, 378, 61, 30, 377, 247, 185, 354, 229, 368, 20, 85, 110],
and the availability of these high-throughput TRNGs can enable a wide range of
new applications with improved security and privacy.

DRAM offers a promising substrate for developing an effective and widely-
available TRNG due to the prevalence of DRAM throughout all modern computing
systems ranging from microcontrollers to supercomputers. A high-throughput
DRAM-based TRNG would help enable widespread adoption of applications that are
today limited to only select architectures equipped with dedicated high-
performance TRNG engines. Examples of such applications include high-
performance scientific simulations and cryptographic applications for securing
devices and communication protocols, both of which would run much more
efficiently on mobile devices, embedded devices, or microcontrollers with the
availability of higher-throughput TRNGs in the system.

In terms of the CPU architecture itself, a high-throughput DRAM-based TRNG
could help the memory controller to improve scheduling decisions [337, 243,
15, 311, 310, 172, 242, 313, 312] and enable the implementation a truly-
randomized version of PARA [170] (i.e., a protection mechanism against the
RowHammer vulnerability [170, 239]). Furthermore, a DRAM-based TRNG would
likely have additional hardware and software applications as system designs
become more capable and increasingly security-critical.

In addition to traditional computing paradigms, DRAM-based TRNGs can benefit
processing-in-memory (PIM) architectures [96, 240, 296], which co-locate logic
within or near memory to overcome the large bandwidth and energy bottleneck
caused by the memory bus and leverage the _significant_ data parallelism
available within the DRAM chip itself. Many prior works provide primitives for
PIM or exploit PIM-enabled systems for workload acceleration [7, 8, 189, 291,
292, 295, 294, 211, 296, 261, 18, 81, 88, 89, 121, 130, 232, 316, 373, 131,
38, 39, 57, 161, 96, 240, 37, 289]. A low-latency, high-throughput DRAM-based
TRNG can enable PIM applications to source random values _directly within the
memory itself_ , thereby enhancing the overall potential, security, and
privacy, of PIM-enabled architectures. For example, in applications that
require true random numbers, a DRAM-based TRNG can enable large contiguous
code segments to execute in memory, which would reduce communication with the
CPU, and thus improve system efficiency. A DRAM-based TRNG can also enable
security tasks to run completely in memory. This would remove the dependence
of PIM-based security tasks on an I/O channel and would increase overall
system security.

We posit, based on analysis done in prior works [176, 146, 283], that an
_effective_ TRNG must satisfy _six_ key properties: it must 1) have low
implementation cost, 2) be fully non-deterministic such that it is impossible
to predict the next output given complete information about how the mechanism
operates, 3) provide a continuous stream of true random numbers with high
throughput, 4) provide true random numbers with low latency, 5) exhibit low
system interference, i.e., not significantly slow down concurrently-running
applications, and 6) generate random values with low energy overhead.

To this end, our goal in this work, is to provide a widely-available TRNG for
DRAM devices that satisfies all six key properties of an effective TRNG.

###  5.3 Testing Environment

In order to test our hypothesis that DRAM cells are an effective source of
entropy when accessed with reduced DRAM timing parameters, we developed an
infrastructure to characterize modern LPDDR4 DRAM chips. We also use an
infrastructure for DDR3 DRAM chips, SoftMC [120, 302], to demonstrate
empirically that our proposal is applicable beyond the LPDDR4 technology. Both
testing environments give us precise control over DRAM commands and DRAM
timing parameters as verified with a logic analyzer probing the command bus.

We perform all tests, unless otherwise specified, using a total of 282 2y-nm
LPDDR4 DRAM chips from three major manufacturers in a thermally-controlled
chamber held at 45∘C. For consistency across results, we precisely stabilize
the ambient temperature using heaters and fans controlled via a
microcontroller-based proportional-integral-derivative (PID) loop to within an
accuracy of 0.25∘C and a reliable range of 40∘C to 55∘C. We maintain DRAM
temperature at 15∘C above ambient temperature using a separate local heating
source. We use temperature sensors to smooth out temperature variations caused
by self-induced heating.

We also use a separate infrastructure, based on open-source SoftMC [120, 302],
to validate our mechanism on 4 DDR3 DRAM chips from a single manufacturer.
SoftMC enables precise control over timing parameters, and we house the DRAM
chips inside another temperature chamber to maintain a stable ambient testing
temperature (with the same temperature range as the temperature chamber used
for the LPDDR4 devices).

To explore the various effects of temperature, short-term aging, and circuit-
level interference (in Section 5.4) on activation failures, we reduce the
$t_{RCD}$ parameter from the default $18ns$ to $10ns$ for all experiments,
unless otherwise stated. Algorithm 4 explains the general testing methodology
we use to induce activation failures. First, we write a data pattern to the

1

2DRAM_ACT_failure_testing($data\\_pattern$, $DRAM\\_region$):

3 write $data\\_pattern$ (e.g., solid 1s) into all cells in $DRAM\\_region$

4 set low $t_{RCD}$ for ranks containing $DRAM\\_region$

5 foreach $col$ in $DRAM\\_region$:

6 foreach $row$ in $DRAM\\_region$:

7 $activate(row)$ // fully refresh cells

8 $precharge(row)$ // ensure next access activates the row

9 $activate(row)$

10 $read(col)$ // induce activation failure on col

11 $precharge(row)$

12 record activation failures to storage

13 set default $t_{RCD}$ for DRAM ranks containing $DRAM\\_region$

Algorithm 4 DRAM Activation Failure Testing

region of DRAM under test (Line 2). Next, we reduce the $t_{RCD}$ parameter to
begin inducing activation failures (Line 3). We then access the DRAM region in
column order (Lines 4-5) in order to ensure that each DRAM access is to a
closed DRAM row and thus requires an activation. This enables each access to
induce activation failures in DRAM. Prior to each reduced-latency read, we
first refresh the target row such that each cell has the same amount of charge
each time it is accessed with a reduced-latency read. We effectively refresh a
row by issuing an activate (Line 6) followed by a precharge (Line 7) to that
row. We then induce the activation failures by issuing consecutive activate
(Line 8), read (Line 9), and precharge (Line 10) commands. Afterwards, we
record any activation failures that we observe (Line 11). We find that this
methodology enables us to quickly induce activation failures across _all_ of
DRAM, and minimizes testing time.

###  5.4 Activation Failure Characterization

To demonstrate the viability of using DRAM cells as an entropy source for
random data, we explore and characterize DRAM failures when employing a
reduced DRAM activation latency ($t_{RCD}$) across 282 LPDDR4 DRAM chips. We
also compare our findings against those of prior works that study an older
generation of DDR3 DRAM chips [55, 190, 191, 163] to cross-validate our
infrastructure. To understand the effects of changing environmental conditions
on a DRAM cell that is used as a source of entropy, we rigorously characterize
DRAM cell behavior as we vary four environmental conditions. First, we study
the effects of DRAM array design-induced variation (i.e., the spatial
distribution of activation failures in DRAM). Second, we study data pattern
dependence (DPD) effects on DRAM cells. Third, we study the effects of
temperature variation on DRAM cells. Fourth, we study a DRAM cell’s activation
failure probability over time. We present several key observations that
support the viability of a mechanism that generates random numbers by
accessing DRAM cells with a reduced $t_{RCD}$. In Section 5.5, we discuss a
mechanism to effectively sample DRAM cells to extract true random numbers
while minimizing the effects of environmental condition variation (presented
in this section) on the DRAM cells.

####  5.4.1 Spatial Distribution of Activation Failures

To study which regions of DRAM are better suited to generating random data, we
first visually inspect the spatial distributions of activation failures both
across DRAM chips and within each chip individually. Figure 5.1 plots the
spatial distribution of activation failures in a _representative_ $1024\times
1024$ array of DRAM cells taken from a single DRAM chip. Every observed
activation failure is marked in black. We make two observations. First, we
observe that each contiguous region of 512 DRAM rows111We note that subarrays
have either 512 or 1024 (not shown) rows depending on the manufacturer of the
DRAM device. consists of repeating rows with the same set (or subset) of
column bits that are prone to activation failures. As shown in the figure,
rows 0 to 511 have the same 8 (or a subset of the 8) column bits failing in
the row, and rows 512 to 1023 have the same 4 (or a subset of the 4) column
bits failing in the row. We hypothesize that these contiguous regions reveal
the DRAM subarray architecture as a result of variation across the local sense
amplifiers in the subarray. We indicate the two subarrays in Figure 5.1 as
Subarray A and Subarray B. A “weaker” local sense amplifier results in cells
that share its respective _local bitline_ in the subarray having an increased
probability of failure. For this reason, we observe that activation failures
are localized to a few columns within a DRAM subarray as shown in Figure 5.1.
Second, we observe that within a subarray, the activation failure probability
increases across rows (i.e., activation failures are _more_ likely to occur in
higher-numbered rows in the subarray and are _less_ likely in lower-numbered
rows in the subarray). This can be seen from the fact that more cells fail in
higher-numbered rows in the subarray (i.e., there are more black marks higher
in each subarray). We hypothesize that the failure probability of a cell
attached to a local bitline correlates with the distance between the row and
the local sense amplifiers, and further rows have less time to amplify their
data due to the signal propagation delay in a bitline. These observations are
similar to those made in prior studies [190, 55, 191, 163] on DDR3 devices.

Figure 5.1: Activation failure bitmap in $1024\times 1024$ cell array.

We next study the granularity at which we can induce activation failures when
accessing a row. We observe (not shown) that activation failures occur _only_
within the first cache line that is accessed immediately following an
activation. No subsequent access to an already _open_ row results in
activation failures. This is because cells within the _same_ row have a longer
time to restore their cell charge (Figure 2.3) when they are accessed after
the row has already been opened. We draw two key conclusions: 1) the region
_and_ bitline of DRAM being accessed affect the number of observable
activation failures, and 2) different DRAM subarrays _and_ different local
bitlines exhibit varying levels of entropy.

####  5.4.2 Data Pattern Dependence

To understand the data pattern dependence of activation failures and DRAM cell
entropy, we study how effectively we can discover failures using different
data patterns across multiple rounds of testing. Our _goal_ in this experiment
is to determine which data pattern results in the highest entropy such that we
can generate random values with high throughput. Similar to prior works [260,
206] that extensively describe the data patterns, we analyze a total of 40
unique data patterns: solid 1s, checkered, row stripe, column stripe, 16
walking 1s, _and_ the inverses of all 20 aforementioned data patterns.

Figure 5.2 plots the ratio of activation failures discovered by a particular
data pattern after 100 iterations of Algorithm 4 relative to the _total_
number of failures discovered by _all_ patterns for a representative chip from
each manufacturer. We call this metric _coverage_ because it indicates the
effectiveness of a single data pattern to identify all possible DRAM cells
that are prone to activation failure. We show results for each pattern
individually except for the WALK1 and WALK0 patterns, for which we show the
mean (bar) and minimum/maximum (error bars) coverage across all 16 iterations
of each walking pattern.

Figure 5.2: Data pattern dependence of DRAM cells prone to activation failure
over 100 iterations

We make three key observations from this experiment. First, we find that
testing with different data patterns identifies different subsets of the total
set of possible activation failures. This indicates that 1) different data
patterns cause different DRAM cells to fail and 2) specific data patterns
induce more activation failures than others. Thus, certain data patterns may
extract more entropy from a DRAM cell array than other data patterns. Second,
we find that, of _all_ 40 tested data patterns, each of the 16 _walking 1s_ ,
for a given device, provides a similarly high coverage, regardless of the
manufacturer. This high coverage is similarly provided by only one other data
pattern per manufacturer: solid 0s for manufacturers A and B, and walking 0s
for manufacturer C. Third, if we repeat this experiment (i.e., Figure 5.2)
while varying the number of iterations of Algorithm 4, the _total failure
count_ across all data patterns _increases_ as we increase the number of
iterations of Algorithm 4. This indicates that not all DRAM cells fail
deterministically when accessed with a reduced $t_{RCD}$, providing a
potential source of entropy for random number generation.

We next analyze each cell’s probability of failing when accessed with a
reduced $t_{RCD}$ (i.e., its _activation failure probability_) to determine
which data pattern most effectively identifies cells that provide high
entropy. We note that DRAM cells with an activation failure probability
$F_{prob}$ of 50% provide high entropy when accessed many times. With the same
data used to produce Figure 5.2, we study the different data patterns with
regard to the number of cells they cause to fail 50% of the time.
Interestingly, we find that the data pattern that induces the most failures
overall does not necessarily find the most number of cells that fail 50% of
the time. In fact, when searching for cells with an $F_{prob}$ between 40% and
60%, we observe that the data patterns that find the highest number of cells
are solid 0s, checkered 0s, and solid 0s for manufacturers A, B, and C,
respectively. We conclude that: 1) due to manufacturing and design variation
across DRAM devices from different manufacturers, different data patterns
result in different failure probabilities in our DRAM devices, and 2) to
provide high entropy when accessing DRAM cells with a reduced $t_{RCD}$, we
should use the respective data pattern that finds the most number of cells
with an $F_{prob}$ of 50% for DRAM devices from a given manufacturer.

Unless otherwise stated, in the rest of this chapter, we use the solid 0s,
checkered 0s, and solid 0s data patterns for manufacturers A, B, and C,
respectively, to analyze $F_{prob}$ at the granularity of a single cell and to
study the effects of temperature and time on our sources of entropy.

####  5.4.3 Temperature Effects

In this section, we study whether temperature fluctuations affect a DRAM
cell’s activation failure probability and thus the entropy that can be
extracted from the DRAM cell. To analyze temperature effects, we record the
$F_{prob}$ of cells throughout our DRAM devices across 100 iterations of
Algorithm 4 at 5∘C increments between 55∘C and 70∘). Figure 5.3 aggregates
results across 30 DRAM modules from each DRAM manufacturer. Each point in the
figure represents how the $F_{prob}$ of a DRAM cell changes as the temperature
changes (i.e., ${\Delta}F_{prob}$). The x-axis shows the $F_{prob}$ of a
single cell at temperature $T$ (i.e., the baseline temperature), and the
y-axis shows the $F_{prob}$ of the same cell at temperature $T+5$ (i.e., 5∘C
above the baseline temperature). Because we test each cell at each temperature
across 100 iterations, the granularity of $F_{prob}$ on both the x- and y-axes
is 1%. For a given $F_{prob}$ at temperature $T$ (x% on the x-axis), we
aggregate _all_ respective $F_{prob}$ points at temperature $T+5$ (y% on the
y-axis) with box-and-whiskers plots222A box-and-whiskers plot emphasizes the
important metrics of a dataset’s distribution. The box is lower-bounded by the
first quartile (i.e., the median of the first half of the ordered set of data
points) and upper-bounded by the third quartile (i.e., the median of the
second half of the ordered set of data points). The median falls within the
box. The _inter-quartile range_ (IQR) is the distance between the first and
third quartiles (i.e., box size). Whiskers extend an additional $1.5\times
IQR$ on either sides of the box. We indicate outliers, or data points outside
of the range of the whiskers, with pluses. to show how the given $F_{prob}$ is
affected by the increased DRAM temperature. The _box_ is drawn in blue and
contains the _median_ drawn in red. The _whiskers_ are drawn in gray, and the
_outliers_ are indicated with orange pluses.

Figure 5.3: Effect of temperature variation on failure probability

We observe that $F_{prob}$ at temperature $T+5$ tends to be higher than
$F_{prob}$ at temperature $T$, as shown by the blue region of the figure
(i.e., the boxes of the box-and-whiskers plots) lying above the
$x\leavevmode\nobreak\ =\leavevmode\nobreak\ y$ line. However, fewer than 25%
of all data points fall below the $x\leavevmode\nobreak\ =\leavevmode\nobreak\
y$ line, indicating that a portion of cells have a lower $F_{prob}$ as
temperature is increased.

We observe that DRAM devices from different manufacturers are affected by
temperature differently. DRAM cells of manufacturer A have the _least_
variation of ${\Delta}F_{prob}$ when temperature is increased since the boxes
of the box-and-whiskers plots are strongly correlated with the
$x\leavevmode\nobreak\ =\leavevmode\nobreak\ y$ line. How a DRAM cell’s
activation failure probability changes in DRAM devices from _other_
manufacturers is unfortunately _less_ predictable under temperature change
(i.e., a DRAM cell from manufacturers B or C has higher variation in
$F_{prob}$ change), but the data still shows a strong positive correlation
between temperature and $F_{prob}$. We conclude that temperature affects cell
failure probability ($F_{prob}$) to different degrees depending on the
manufacturer of the DRAM device, but increasing temperature generally
increases the activation failure probability.

####  5.4.4 Entropy Variation over Time

To determine whether the failure probability of a DRAM cell changes over time,
we complete 250 _rounds_ of recording the activation failure probability of
DRAM cells over the span of 15 days. Each round consists of accessing every
cell in DRAM 100 times with a reduced $t_{RCD}$ value and recording the
failure probability for each individual cell (out of 100 iterations). We find
that a DRAM cell’s activation failure probability does _not_ change
significantly over time. This means that, once we identify a DRAM cell that
exhibits high entropy, we can rely on the cell to maintain its high entropy
over time. We hypothesize that this is because a DRAM cell fails with high
entropy when process manufacturing variation in peripheral and DRAM cell
circuit elements combine such that, when we read the cell using a reduced
$t_{RCD}$ value, we induce a metastable state resulting from the cell voltage
falling between the reliable sensing margins (i.e., falling close to
$\frac{V_{dd}}{2}$) [55]. Since manufacturing variation is fully determined at
manufacturing time, a DRAM cell’s activation failure probability is stable
over time given the same experimental conditions. In Section 5.5.1, we discuss
our methodology for selecting DRAM cells for extracting stable entropy, such
that we can preemptively avoid longer-term aging effects that we do not study
in this chapter.

###  5.5 D-RaNGe: A DRAM-based TRNG

Based on our rigorous analysis of DRAM activation failures (presented in
Section 5.4), we propose D-RaNGe, a flexible mechanism that provides high-
throughput DRAM-based true random number generation (TRNG) by sourcing entropy
from a subset of DRAM cells and is built fully within the memory controller.
D-RaNGe is based on the key observation that DRAM cells fail probabilistically
when accessed with reduced DRAM timing parameters, and this probabilistic
failure mechanism can be used as a source of true random numbers. While there
are many other timing parameters that we could reduce to induce failures in
DRAM [55, 190, 191, 163, 188, 54], we focus specifically on reducing $t_{RCD}$
below manufacturer-recommended values to study the resulting activation
failures.333We believe that reducing other timing parameters could be used to
generate true random values, but we leave their exploration to future work.

Activation failures occur as a result of reading the value from a DRAM cell
_too soon_ after sense amplification. This results in reading the value at the
sense amplifiers before the bitline voltage is amplified to an I/O-readable
voltage level. The probability of reading incorrect data from the DRAM cell
therefore depends largely on the bitline’s voltage at the time of reading the
sense amplifiers. Because there is significant process variation across the
DRAM cells and I/O circuitry [55, 190, 191, 163], we observe a wide variety of
failure probabilities for different DRAM cells (as discussed in Section 5.4)
for a given $t_{RCD}$ value, ranging from 0% probability to 100% probability.

We discover that in each DRAM chip, a subset of cells fail at
${\color[rgb]{0,0,0}\sim}$50% probability, and a subset of these cells fail
randomly with high entropy (shown in Section 5.6.2). In this section, we first
discuss our method of identifying such cells, which we refer to as _RNG cells_
(in Section 5.5.1). Second, we describe the mechanism with which D-RaNGe
_samples_ RNG cells to extract random data (Section 5.5.2). Finally, we
discuss a potential design for integrating D-RaNGe in a full system (Section
5.5.3).

####  5.5.1 RNG Cell Identification

Prior to generating random data, we must first identify cells that are capable
of producing truly random output (i.e., RNG cells). Our process of identifying
RNG cells involves reading every cell in the DRAM array 1000 times with a
_reduced_ $t_{RCD}$ and approximating each cell’s Shannon entropy [298] by
counting the occurrences of 3-bit symbols across its 1000-bit stream. We
identify cells that generate an approximately equal number of every possible
3-bit symbol ($\pm 10\%$ of the number of expected symbols) as RNG cells.

We find that RNG cells provide unbiased output, meaning that a post-processing
step (described in Section 5.1) is _not_ necessary to provide sufficiently
high entropy for random number generation. We also find that RNG cells
_maintain high entropy across system reboots_. In order to account for our
observation that entropy from an RNG cell changes depending on the DRAM
temperature (Section 5.4.3), we identify reliable RNG cells at each
temperature and store their locations in the memory controller. Depending on
the DRAM temperature at the time an application requests random values,
D-RaNGe samples the appropriate RNG cells. To ensure that DRAM aging does not
negatively impact the reliability of RNG cells, we require re-identifying the
set of RNG cells at regular intervals. From our observation that entropy does
not change significantly over a tested 15 day period of sampling RNG cells
(Section 5.4.4), we expect the interval of re-identifying RNG cells to be at
least 15 days long. Our RNG cell identification process is effective at
identifying cells that are reliable entropy sources for random number
generation, and we quantify their randomness using the NIST test suite for
randomness [279] in Section 5.6.1.

####  5.5.2 Sampling RNG Cells for Random Data

Given the availability of these RNG cells, we use our observations in Section
5.4 to design a high-throughput TRNG that quickly and repeatedly samples RNG
cells with reduced DRAM timing parameters. Algorithm 5 demonstrates the key
components of D-RaNGe that enable us to generate random numbers with high
throughput.

1

2D-RaNGe($num\\_bits$): // _num_bits_ : number of random bits requested

3 $DP$: a known data pattern that results in high entropy

4 select 2 DRAM words with RNG cells in distinct rows in each bank

5 write $DP$ to chosen DRAM words and their neighboring cells

6 get exclusive access to rows of chosen DRAM words and nearby cells

7 set low $t_{RCD}$ for DRAM ranks containing chosen DRAM words

8 for each bank:

9 read data in $DW_{1}$ // induce activation failure

10 write the read value of $DW_{1}$’s RNG cells to $bitstream$

11 write original data value back into $DW_{1}$

12 memory barrier  // ensure completion of write to $DW_{1}$

13 read data in $DW_{2}$ // induce activation failure

14 write the read value of $DW_{2}$’s RNG cells to $bitstream$

15 write original data value back into $DW_{2}$

16 memory barrier  // ensure completion of write to $DW_{2}$

17 if $bitstream_{size}$$\leavevmode\nobreak\ \geq\leavevmode\nobreak\
num\\_bits$:

18 break

19 set default $t_{RCD}$ for DRAM ranks of the chosen DRAM words

20 release exclusive access to rows of chosen words and nearby cells

Algorithm 5 D-RaNGe: A DRAM-based TRNG

D-RaNGe takes in $num\\_bits$ as an argument, which is defined as the number
of random bits desired (Line 1). D-RaNGe then prepares to generate random
numbers in Lines 2-6 by first selecting DRAM words (i.e., the granularity at
which a DRAM module is accessed) containing known RNG cells for generating
random data (Line 3). To maximize the throughput of random number generation,
D-RaNGe chooses DRAM words with the highest density of RNG cells in each bank
(to exploit DRAM parallelism). Since each DRAM access can induce activation
failures _only_ in the accessed DRAM word, the density of RNG cells per DRAM
word determines the number of random bits D-RaNGe can generate per access. For
each available DRAM bank, D-RaNGe selects two DRAM words (in distinct DRAM
rows) containing RNG cells. The purpose of selecting two DRAM words in
_different_ rows is to _repeatedly_ cause _bank conflicts_ , or issue requests
to _closed_ DRAM rows so that every read request will _immediately_ follow an
activation. This is done by alternating accesses to the chosen DRAM words in
different DRAM rows. After selecting DRAM words for generating random values,
D-RaNGe writes a known data pattern that results in high entropy to each
chosen DRAM word and its neighboring cells (Line 4) and gains exclusive access
to rows containing the two chosen DRAM words as well as their neighboring
cells (Line 5).444Ensuring exclusive access to DRAM rows can be done by
remapping rows to 1) redundant DRAM rows or 2) buffers in the memory
controller so that these rows are hidden from the system software and only
accessible by the memory controller for generating random numbers.  This
ensures that the data pattern surrounding the RNG cell and the original value
of the RNG cell stay constant prior to each access such that the failure
probability of each RNG cell remains reliable (as observed to be necessary in
Section 5.4.2). To begin generating random data (i.e., sampling RNG cells),
D-RaNGe reduces the value of $t_{RCD}$ (Line 6). From every available bank
(Line 7), D-RaNGe generates random values in parallel (Lines 8-15). Lines 8
and 12 indicate the commands to alternate accesses to two DRAM words in
distinct rows of a bank to both 1) induce activation failures and 2) precharge
the recently-accessed row. After inducing activation failures in a DRAM word,
D-RaNGe extracts the value of the RNG cells within the DRAM word (Lines 9 and
13) to use as random data and restores the DRAM word to its original data
value (Lines 10 and 14) to maintain the original data pattern. Line 15 ensures
that writing the original data value is complete before attempting to sample
the DRAM words again. Lines 16 and 17 simply end the loop if enough random
bits of data have been harvested. Line 18 sets the $t_{RCD}$ timing parameter
back to its default value, so other applications can access DRAM without
corrupting data. Line 19 releases exclusive access to the rows containing the
chosen DRAM words and their neighboring rows.

We find that this methodology maximizes the opportunity for activation
failures in DRAM, thereby maximizing the rate of generating random data from
RNG cells.

####  5.5.3 Full System Integration

In this work, we focus on developing a flexible substrate for sampling RNG
cells fully from within the memory controller. D-RaNGe generates random
numbers using a simple firmware routine running entirely within the memory
controller. The firmware executes the sampling algorithm (Algorithm 5)
whenever an application requests random samples and there is available DRAM
bandwidth (i.e., DRAM is not servicing other requests or maintenance
commands). In order to minimize latency between requests for samples and their
corresponding responses, a small queue of already-harvested random data may be
maintained in the memory controller for use by the system. Overall performance
overhead can be minimized by tuning both 1) the queue size and 2) how the
memory controller prioritizes requests for random numbers relative to normal
memory requests.

In order to integrate D-RaNGe with the rest of the system, the system designer
needs to decide how to best expose an interface by which an application can
leverage D-RaNGe to generate true random numbers on their system. There are
many ways to achieve this, including, but not limited to:

  * •

Providing a simple REQUEST and RECEIVE interface for applications to request
and receive the random numbers using memory-mapped configuration status
registers (CSRs) [357] or other existing I/O datapaths (e.g., x86 IN and OUT
opcodes, Local Advanced Programmable Interrupt Controller (LAPIC configuration
[133]).

  * •

Adding a new ISA instruction (e.g., Intel RDRAND [114]) that retrieves random
numbers from the memory controller and stores them into processor registers.

The operating system may then expose one or more of these interfaces to user
applications through standard kernel-user interfaces (e.g., system calls, file
I/O, operating system APIs). The system designer has complete freedom to
choose between these (and other) mechanisms that expose an interface for user
applications to interact with D-RaNGe. We expect that the best option will be
system specific, depending both on the desired D-RaNGe use cases and the ease
with which the design can be implemented.

###  5.6 D-RaNGe Evaluation

We evaluate three key aspects of D-RaNGe. First, we show that the random data
obtained from RNG cells identified by D-RaNGe passes all of the tests in the
NIST test suite for randomness (Section 5.6.1). Second, we analyze the
existence of RNG cells across 59 LPDDR4 and 4 DDR3 DRAM chips (due to long
testing time) randomly sampled from the overall population of DRAM chips
across all three major DRAM manufacturers (Section 5.6.2). Third, we evaluate
D-RaNGe in terms of the six key properties of an ideal TRNG as explained in
Section 5.2 (Section 5.6.3).

####  5.6.1 NIST Tests

First, we identify RNG cells using our RNG cell identification process
(Section 5.5.1). Second, we sample _each_ identified RNG cell one million
times to generate large amounts of random data (i.e., 1 Mb _bitstreams_).
Third, we evaluate the entropy of the bitstreams from the identified RNG cells
with the NIST test suite for randomness [279]. Table 5.1 shows the average
results of 236 1 Mb bitstreams555We test data obtained from 4 RNG cells from
each of 59 DRAM chips, to maintain a reasonable NIST testing time and thus
show that RNG cells across all tested DRAM chips reliably generate random
values. across the 15 tests of the full NIST

NIST Test Name | P-value | Status
---|---|---
monobit | 0.675 | PASS
frequency_within_block | 0.096 | PASS
runs | 0.501 | PASS
longest_run_ones_in_a_block | 0.256 | PASS
binary_matrix_rank | 0.914 | PASS
dft | 0.424 | PASS
non_overlapping_template_matching | >0.999 | PASS
overlapping_template_matching | 0.624 | PASS
maurers_universal | 0.999 | PASS
linear_complexity | 0.663 | PASS
serial | 0.405 | PASS
approximate_entropy | 0.735 | PASS
cumulative_sums | 0.588 | PASS
random_excursion | 0.200 | PASS
random_excursion_variant | 0.066 | PASS
Table 5.1: D-RaNGe results with NIST randomness test suite.

test suite for randomness. P-values are calculated for each test,666A p-value
close to 1 indicates that we must accept the null hypothesis, while a p-value
close to 0 and below a small threshold, e.g., $\alpha=0.0001$ (recommended by
the NIST Statistical Test Suite documentation [279]), indicates that we must
reject the null hypothesis. where the null hypothesis for each test is that a
perfect random number generator would _not_ have produced random data with
_better_ characteristics for the given test than the tested sequence [228].
Since the resulting P-values for each test in the suite are greater than our
chosen level of significance, $\alpha=0.0001$, we accept our null hypothesis
for each test. We note that all 236 bitstreams pass all 15 tests with similar
P-values. Given our $\alpha=0.0001$, our proportion of passing sequences (1.0)
falls within the range of acceptable proportions of sequences that pass each
test ([0.998,1] calculated by the NIST statistical test suite using
$(1-\alpha)\pm 3\sqrt{\frac{\alpha(1-\alpha)}{k}}$, where $k$ is the number of
tested sequences). This _strongly_ indicates that D-RaNGe can generate
unpredictable, truly random values. Using the proportion of 1s and 0s
generated from each RNG cell, we calculate Shannon entropy [298] and find the
_minimum_ entropy across all RNG cells to be 0.9507.

####  5.6.2 RNG Cell Distribution

The throughput at which D-RaNGe generates random numbers is a function of the
1) density of RNG cells per DRAM word and 2) bandwidth with which we can
access DRAM words when using our methodology for inducing activation failures.
Since each DRAM access can induce activation failures _only_ in the accessed
DRAM word, the density of RNG cells per DRAM word indicates the number of
random bits D-RaNGe can sample per access. We first study the density of RNG
cells per word across DRAM chips. Figure 5.4 plots the distribution of the
number of words containing x RNG cells (indicated by the value on the x-axis)
per _bank_ across 472 banks from 59 DRAM devices from all manufacturers. The
distribution is presented as a box-and-whiskers plot where the y-axis has a
logarithmic scale with a 0 point. The three plots respectively show the
distributions for DRAM devices from the three manufacturers (indicated at the
bottom left corner of each plot).

Figure 5.4: Density of RNG cells in DRAM words per bank.

We make three key observations. First, RNG cells are _widely available in
every bank_ across many chips. This means that we can use the available DRAM
access parallelism that multiple banks offer and sample RNG cells from each
DRAM bank in parallel to improve random number generation throughput. Second,
_every_ bank that we analyze has _multiple DRAM words_ containing at least one
RNG cell. The DRAM bank with the smallest occurrence of RNG cells has 100 DRAM
words containing only 1 RNG cell (manufacturer B). Discounting this point, the
distribution of the number of DRAM words containing only 1 RNG cell is tight
with a high number of RNG cells (e.g., tens of thousands) in each bank,
regardless of the manufacturer. Given our random sample of DRAM chips, we
expect that the existence of RNG cells in DRAM banks will hold true for all
DRAM chips. Third, we observe that a single DRAM word can contain as many as 4
RNG cells. Because the throughput of accesses to DRAM is fixed, the number of
RNG cells in the accessed words essentially acts as a multiplier for the
throughput of random numbers generated (e.g., accessing DRAM words containing
4 RNG cells results in _4x_ the throughput of random numbers compared to
accessing DRAM words containing 1 RNG cell).

####  5.6.3 TRNG Key Characteristics Evaluation

We now evaluate D-RaNGe in terms of the six key properties of an effective
TRNG as explained in Section 5.2.

Low Implementation Cost. To induce activation failures, we must be able to
reduce the DRAM timing parameters below manufacturer-specified values. Because
memory controllers issue memory accesses according to the timing parameters
specified in a set of internal registers, D-RaNGe requires simple software
support to be able to programmatically modify the memory controller’s
registers. Fortunately, there exist some processors [191, 11, 12, 80] that
_already_ enable software to directly change memory controller register
values, i.e., the DRAM timing parameters. These processors can easily generate
random numbers with D-RaNGe.

All other processors that do _not_ currently support direct changes to memory
controller registers require _minimal_ software changes to expose an interface
for changing the memory controller registers [14, 281, 120, 302]. To enable a
more efficient implementation, the memory controller could be programmed such
that it issues DRAM accesses with distinct timing parameters on a per-access
granularity to reduce the overhead in 1) changing the DRAM timing parameters
and 2) allow concurrent DRAM accesses by other applications. In the rare case
where these registers are unmodifiable by even the hardware, the hardware
changes necessary to enable register modification are minimal and are simple
to implement [191, 120, 302].

We experimentally find that we can induce activation failures with $t_{RCD}$
between $6ns$ and $13ns$ (reduced from the default of $18ns$). Given this wide
range of failure-inducing $t_{RCD}$ values, most memory controllers should be
able to adjust their timing parameter registers to a value within this range.

Fully Non-deterministic. As we have shown in Section 5.6.1, the bitstreams
extracted from the D-RaNGe-identified RNG cells pass _all_ 15 NIST tests. We
have full reason to believe that we are inducing a metastable state of the
sense amplifiers (as hypothesized by [55]) such that we are effectively
sampling random physical phenomena to extract unpredictable random values.

High Throughput of Random Data. Due to the various use cases of random number
generation discussed in Section 5.2, different applications have different
throughput requirements for random number generation, and applications may
tolerate a reduction in performance so that D-RaNGe can quickly generate true
random numbers. Fortunately, D-RaNGe provides flexibility to tradeoff between
the system interference it causes, i.e., the slowdown experienced by
concurrently running applications, and the random number generation throughput
it provides. To demonstrate this flexibility, Figure 5.5 plots the TRNG
throughput of D-RaNGe when using varying numbers of banks (_x_ banks on the
x-axis) across the three DRAM manufacturers (indicated at the top left corner
of each plot). For each number of banks used, we plot the distribution of TRNG
throughput that we observe _real_ DRAM devices to provide. The available
density of RNG cells in a DRAM device (provided in Figure 5.4) dictates the
TRNG throughput that the DRAM device can provide. We plot each distribution as
a box-and-whiskers plot. For each number of banks used, we select x banks with
the greatest sum of RNG cells across each banks’ two DRAM words with the
highest density of RNG cells (that are _not_ in the same DRAM row). We select
two DRAM words per bank because we must alternate accesses between two DRAM
rows (as shown in Lines 8 and 12 of Algorithm 5). The sum of the RNG cells
available across the two selected DRAM words for each bank is considered each
bank’s _TRNG data rate_ , and we use this value to obtain D-RaNGe’s
throughput. We use Ramulator [3, 174] to obtain the rate at which we can
execute the core loop of Algorithm 5 with varying numbers of banks. We obtain
the random number generation throughput for x banks with the following
equation:

$TRNG\\_Throughput_{x\\_Banks}=\sum_{n=1}^{x}\frac{TRNG\\_data\\_rate_{Bank\\_n}}{Alg2\\_Runtime_{x\\_banks}}$
(5.1)

where $TRNG\\_data\\_rate_{Bank\\_n}$ is the TRNG data rate for the selected
bank, and $Alg2\\_Runtime_{x\\_banks}$ is the runtime of the core loop of
Algorithm 5 when using $x$ Banks. We note that because we observe small
variation in the density of RNG cells per word (between 0 and 4), we see that
TRNG throughput across different chips is generally very similar. For this
reason, we see that the box and whiskers are condensed into a single point for
distributions of manufacturers B and C. We find that when _fully_ using _all_
8 banks in a single DRAM channel, every device can produce _at least_ 40 Mb/s
of random data regardless of manufacturer. The highest throughput we observe
from devices of manufacturers A/B/C respectively are 179.4/134.5/179.4 Mb/s.
On average, across all manufacturers, we find that D-RaNGe can provide a
throughput of 108.9 Mb/s.

Figure 5.5: Distribution of TRNG throughput across chips.

We draw two key conclusions. First, due to the _parallelism_ of multiple
banks, the throughput of random number generation increases linearly as we use
more banks. Second, there is variation of TRNG throughput across different
DRAM devices, but the medians across manufacturers are very similar.

We note that any throughput sample point on this figure can be multiplied by
the number of available channels in a memory hierarchy for a better TRNG
throughput estimate for a system with multiple DRAM channels. For an example
memory hierarchy comprised of 4 DRAM channels, D-RaNGe results in a maximum
(average) throughput of 717.4 Mb/s (435.7 Mb/s).

Low Latency. Since D-RaNGe’s sampling mechanism consists of a single DRAM
access, the latency of generating random values is directly related to the
DRAM access latency. Using the timing parameters specified in the JEDEC LPDDR4
specification [141], we calculate D-RaNGe’s latency to generate a 64-bit
random value. To calculate the _maximum latency_ for D-RaNGe, we assume that
1) each DRAM access provides only 1 bit of random data (i.e., each DRAM word
contains _only_ 1 RNG cell) and 2) we can use only a single bank within a
single channel to generate random data. We find that D-RaNGe can generate 64
bits of random data with a _maximum_ latency of $960ns$. If D-RaNGe takes full
advantage of DRAM’s channel- and bank-level parallelism in a system with 4
DRAM channels and 8 banks per channel, D-RaNGe can generate 64 bits of random
data by issuing 16 DRAM accesses per channel in parallel. This results in a
latency of $220ns$. To calculate the _empirical minimum latency_ for D-RaNGe,
we fully parallelize D-RaNGe across banks in all 4 channels while also
assuming that each DRAM access provides 4 bits of random data, since we find a
maximum density of 4 RNG cells per DRAM word in the LPDDR4 DRAM devices that
we characterize (Figure 5.4). We find the empirical minimum latency to be
_only_ $100ns$ in our tested devices.

Low System Interference. The flexibility of using a different number of banks
across the available channels in a system’s memory hierarchy allows D-RaNGe to
cause varying levels of system interference at the expense of TRNG throughput.
This enables application developers to generate random values with D-RaNGe at
varying tradeoff points depending on the running applications’ memory access
requirements. We analyze D-RaNGe’s system interference with respect to DRAM
storage overhead and DRAM latency.

In terms of storage overhead, D-RaNGe simply requires exclusive access rights
to six DRAM rows per bank, consisting of the two rows containing the RNG cells
and each row’s two physically-adjacent DRAM rows containing the chosen data
pattern.777As in prior work [170, 27, 239], we argue that manufacturers can
disclose which rows are physically adjacent to each other. This results in an
insignificant 0.018% DRAM storage overhead cost.

To evaluate D-RaNGe’s effect on the DRAM access latency of regular memory
requests, we present one implementation of D-RaNGe. For a single DRAM channel,
which is the granularity at which DRAM timing parameters are applied, D-RaNGe
can alternate between using a reduced $t_{RCD}$ and the default $t_{RCD}$.
When using a reduced $t_{RCD}$, D-RaNGe generates random numbers across every
bank in the channel. On the other hand, when using the default $t_{RCD}$,
memory requests from running applications are serviced to ensure application
progress. The length of these time intervals (with default/reduced $t_{RCD}$)
can both be adjusted according to the applications’ random number generation
requirements. Overall, D-RaNGe provides significant flexibility in trading off
its system overhead with its TRNG throughput. However, it is up to the system
designer to use and exploit the flexibility for their requirements. To show
the potential throughput of D-RaNGe without impacting concurrently-running
applications, we run simulations with the SPEC CPU2006 [5] workloads, and
calculate the idle DRAM bandwidth available that we can use to issue D-RaNGe
commands. We find that, across all workloads, we can obtain an average
(maximum, minimum) random-value throughput of 83.1 (98.3, 49.1) Mb/s with _no_
significant impact on overall system performance.

Low Energy Consumption. To evaluate the energy consumption of D-RaNGe, we use
DRAMPower [2] to analyze the output traces of Ramulator [3, 174] when DRAM is
(1) generating random numbers (Algorithm 5), and (2) idling and not servicing
memory requests. We subtract quantity (2) from (1) to obtain the estimated
energy consumption of D-RaNGe. We then divide the value by the total number of
random bits found during execution and find that, on average, D-RaNGe finds
random bits at the cost of 4.4 nJ/bit.

###  5.7 Comparison with Prior DRAM TRNGs

To our knowledge, D-RaNGe is the highest-throughput TRNG _for commodity DRAM
devices_ that works by exploiting activation failures as a sampling mechanism
for observing entropy in DRAM cells. There are a number of proposals to
construct TRNGs using commodity DRAM devices, which we summarize in Table 5.2
based on their entropy sources. In this section, we compare each of these
works with D-RaNGe. We show how D-RaNGe fulfills the six key properties of an
ideal TRNG (Section 5.2) better than any prior DRAM-based TRNG proposal. We
group our comparisons by the entropy source of each prior DRAM-based TRNG
proposal.

Proposal | Year |  | Entropy
---
Source
| True
---
Random
| Streaming
---
Capable
| 64-bit TRNG
---
Latency
| Energy
---
Consumption
| Peak
---
Throughput
Pyo+ [264] | 2009 | Command Schedule | ✗ | ✓ | $18{\mu}s$ | N/A | $3.40Mb/s$
Keller+ [154] | 2014 | Data Retention | ✓ | ✓ | $40s$ | $6.8mJ/bit$ | $0.05Mb/s$
Tehranipoor+ [330] | 2016 | Startup Values | ✓ | ✗ |  $>60ns$ (optimistic) |  $>245.9pJ/bit$ (optimistic) | N/A
Sutar+ [317] | 2018 | Data Retention | ✓ | ✓ | $40s$ | $6.8mJ/bit$ | $0.05Mb/s$
D-RaNGe | 2018 | Activation Failures | ✓ | ✓ | $100ns<x<960ns$ | $4.4nJ/bit$ | $717.4Mb/s$
Table 5.2: Comparison to previous DRAM-based TRNG proposals.

####  5.7.1 DRAM Command Scheduling

Prior work [264] proposes using non-determinism in DRAM command scheduling for
true random number generation. In particular, since pending access commands
contend with regular refresh operations, the latency of a DRAM access is hard
to predict and is useful for random number generation.

Unfortunately, this method fails to satisfy two important properties of an
ideal TRNG. First, it harvests random numbers from the instruction and DRAM
command scheduling decisions made by the processor and memory controller,
which does _not_ constitute a fully non-deterministic entropy source. Since
the quality of the harvested random numbers depends directly on the quality of
the processor and memory controller implementations, the entropy source is
visible to and potentially modifiable by an adversary (e.g., by simultaneously
running a memory-intensive workload on another processor core [234]).
Therefore, this method does not meet our design goals as it does not securely
generate random numbers.

Second, although this technique has a higher throughput than those based on
DRAM data retention (Table 5.2), D-RaNGe still outperforms this method in
terms of throughput by 211x (maximum) and 128x (average) because a single byte
of random data requires a _significant_ amount of time to generate. Even if we
scale the throughput results provided by [264] to a modern day system (e.g.,
$5GHz$ processor, 4 DRAM channels888The authors do not provide their DRAM
configuration, so we optimistically assume that they evaluate their proposal
using one DRAM channel. We also assume that by utilizing 4 DRAM channels, the
authors can harvest four times the entropy, which gives the benefit of the
doubt to [264].), the theoretical maximum throughput of Pyo et al.’s
approach999We base our estimations on [264]’s claim that they can harvest one
byte of random data every 45000 cycles. However, using these numbers along
with the authors’ stated processor configuration (i.e., $2.8GHz$) leads to a
discrepancy between our calculated maximum throughput ($\approx 0.5Mb/s$) and
that reported in [264] ($\approx 5Mb/s$). We believe our estimation
methodology and calculations are sound. In our work, we compare D-RaNGe’s peak
throughput against that of [264] using a more modern system configuration
(i.e., $5GHz$ processor, 4 DRAM channels) than used in the original work,
which gives the benefit of the doubt to [264]. is _only_ $3.40Mb/s$ as
compared with the maximum (average) throughput of $717.4Mb/s$ ($435.7Mb/s$)
for D-RaNGe. To calculate the latency of generating random values, we assume
the same system configuration with [264]’s claimed number of cycles 45000 to
generate random bits. To provide 64 bits of random data, [264] takes 18$\mu$s,
which is significantly higher than D-RaNGe’s minimum/maximum latency of
$100ns/960ns$. Energy consumption for [264] depends heavily on the entire
system that it is running on, so we do not compare against this metric.

####  5.7.2 DRAM Data Retention

Prior works [154, 317] propose using DRAM data retention failures to generate
random numbers. Unfortunately, this approach is _inherently too slow_ for
high-throughput operation due to the long wait times required to induce data
retention failures in DRAM. While the failure rate can be increased by
increasing the operating temperature, a wait time on the order of seconds is
required to induce enough failures [206, 155, 266, 260, 164] to achieve high-
throughput random number generation, which is orders of magnitude slower than
D-RaNGe.

Sutar et al. [317] report that they are able to generate 256-bit random
numbers using a hashing algorithm (e.g., SHA-256) on a $4\leavevmode\nobreak\
MiB$ DRAM block that contains data retention errors resulting from having
disabled DRAM refresh for 40 seconds. Optimistically assuming a large DRAM
capacity of $32\leavevmode\nobreak\ GiB$ and ignoring the time required to
read out and hash the erroneous data, a waiting time of 40 seconds to induce
data retention errors allows for an estimated maximum random number throughput
of $0.05\leavevmode\nobreak\ Mb/s$. This throughput is already far smaller
than D-RaNGe’s measured maximum throughput of $717.4Mb/s$, and it would
decrease linearly with DRAM capacity. Even if we were able to induce a large
number of data retention errors by waiting only 1 second, the maximum random
number generation throughput would be $2\leavevmode\nobreak\ Mb/s$, i.e.,
orders of magnitude smaller than that of D-RaNGe.

Because [317] requires a wait time of 40 seconds before producing any random
values, its latency for random number generation is extremely high (40s). In
contrast, D-RaNGe can produce random values very quickly since it generates
random values potentially with each DRAM access (10s of nanoseconds). D-RaNGe
therefore has a latency many orders of magnitude lower than Sutar et al.’s
mechanism [317].

We estimate the energy consumption of retention-time based TRNG mechanisms
with Ramulator [174, 3] and DRAMPower [2, 52]. We model first writing data to
a 4MiB DRAM region (to constrain the energy consumption estimate to the region
of interest), waiting for 40 seconds, and then reading from that region. We
then divide the energy consumption of these operations by the number of bits
found (256 bits). We find that the energy consumption is around $6.8mJ$ per
bit, which is orders of magnitude more costly than that of D-RaNGe, which
provides random numbers at $4.4nJ$ per bit.

####  5.7.3 DRAM Startup Values

Prior work [330, 77] proposes using DRAM startup values as random numbers.
Unfortunately, this method is unsuitable for continuous high-throughput
operation since it requires a DRAM power cycle in order to obtain random data.
We are unable to accurately model the latency of this mechanism since it
relies on the startup time of DRAM (i.e., bus frequency calibration,
temperature calibration, timing register initialization [132]). This heavily
depends on the implementation of the system and the DRAM device in use.
Ignoring these components, we estimate the throughput of generating random
numbers using startup values by taking into account only the latency of a
single DRAM read (_after_ all initialization is complete), which is $60ns$. We
model energy consumption ignoring the initialization phase as well, by
modeling the energy to read a MiB of DRAM and dividing that quantity by
[330]’s claimed number of random bits found in that region (420Kbit). Based on
this calculation, we estimate energy consumption as $245.9pJ$ per bit. While
the energy consumption of [330] is smaller than the energy cost of D-RaNGe, we
note that our energy estimation for [330] does _not_ account for the energy
consumption required for initializing DRAM to be able to read out the random
values. Additionally, [330] requires a full system reboot which is often
impractical for applications and for effectively providing a _steady stream of
random values_. [77] suffers from the same issues since it uses the same
mechanism as [330] to generate random numbers and is strictly worse since [77]
results in $31.8x$ less entropy.

####  5.7.4 Combining DRAM-based TRNGs

We note that D-RaNGe’s method for sampling random values from DRAM is entirely
distinct from prior DRAM-based TRNGs that we have discussed in this section.
This makes it possible to combine D-RaNGe with prior work to produce random
values at an even higher throughput.

###  5.8 Other Related Works

In this work, we focus on the design of a DRAM-based hardware mechanism to
implement a TRNG, which makes the focus of our work orthogonal to those that
design PRNGs. In contrast to prior DRAM-based TRNGs discussed in Section 5.7,
we propose using _activation failures_ as an entropy source. Prior works
characterize activation failures in order to exploit the resulting error
patterns for overall DRAM latency reduction [55, 163, 190, 191] and to
implement physical unclonable functions (PUFs) [164]. However, none of these
works measure the randomness inherent in activation failures or propose using
them to generate random numbers.

Many TRNG designs have been proposed that exploit sources of entropy that are
_not_ based on DRAM. Unfortunately, these proposals either 1) require custom
hardware modifications that preclude their application to commodity devices,
or 2) do not sustain continuous (i.e., constant-rate) high-throughput
operation. We briefly discuss different entropy sources with examples.

Flash Memory Read Noise. Prior proposals use random telegraph noise in flash
memory devices as an entropy source (up to 1 Mbit/s) [353, 269].
Unfortunately, flash memory is orders of magnitude slower than DRAM, making
flash unsuitable for high-throughput and low-latency operation. A more recent
work [50] demonstrates that random numbers can be extracted from the
variability of write and erase latency in flash memory devices. However this
technique suffers from low throughput (i.e., up to 0.25 Kb/s) as it depends on
long flash memory latencies.

SRAM-based Designs. SRAM-based TRNG designs exploit randomness in startup
values [126, 127, 339]. Unfortunately, these proposals are unsuitable for
continuous, high-throughput operation since they require a power cycle.

GPU- and FPGA-Based Designs. Several works harvest random numbers from GPU-
based (up to 447.83 Mbit/s) [51, 336, 327] and FPGA-based (up to 12.5 Mbit/s)
[225, 356, 63, 122, 84] entropy sources. These proposals do not require
modifications to commodity GPUs or FPGAs. Yet, GPUs and FPGAs are not as
prevalent as DRAM in commodity devices today.

Custom Hardware. Various works propose TRNGs based in part or fully on non-
determinism provided by custom hardware designs (with TRNG throughput up to
2.4 Gbit/s) [10, 367, 44, 33, 262, 229, 42, 332, 175, 128, 127, 255, 307].
Unfortunately, the need for custom hardware limits the widespread use of such
proposals in commodity hardware devices (today).

###  5.9 Limitations

While D-RaNGe cam be immediately deployed in certain available systems today,
D-RaNGe has limitations in implementation that limits its full potential even
in these systems.

First, D-RaNGe requires a flexible memory controller that has the ability to
issue DRAM commands with varying timing parameters on the fly. Without such a
memory controller, D-RaNGe is limited to existing systems with tunable timing
parameters and may have high overhead in switching latencies for D-RaNGe
accesses and regular memory accesses. We believe that a flexible memory
controller has many use cases for the system, including Solar-DRAM, the DRAM
Latency PUF, and D-RaNGe, and we expect future work to develop such a memory
controller.

Second, D-RaNGe requires an intelligent memory access scheduler that can
interleave D-RaNGe accesses with regular accesses. The scheduler may have to
predict and account for many parameters including 1) future memory idle time,
2) priority levels for D-RaNGe accesses and concurrently running applications,
3) anticipated random number throughput and latency requirements, and 4)
amount of random numbers saved in the buffer. Developing such a memory
controller would enable systems to satisfy random number requirements of
running applications with minimal interference from D-RaNGe.

###  5.10 Summary

We propose D-RaNGe, a mechanism for extracting true random numbers with high
throughput from unmodified commodity DRAM devices on any system that allows
manipulation of DRAM timing parameters in the memory controller. D-RaNGe
harvests fully non-deterministic random numbers from DRAM row activation
failures, which are bit errors induced by intentionally accessing DRAM with
lower latency than required for correct row activation. Our TRNG is based on
two key observations: 1) activation failures can be induced quickly and 2)
repeatedly accessing certain DRAM cells with reduced activation latency
results in reading true random data. We validate the quality of our TRNG with
the commonly-used NIST statistical test suite for randomness. Our evaluations
show that D-RaNGe significantly outperforms the previous highest-throughput
DRAM-based TRNG by up to 211x (128x on average). We conclude that DRAM row
activation failures can be effectively exploited to efficiently generate true
random numbers with high throughput on a wide range of devices that use
commodity DRAM chips.

##  Chapter 6 Revisiting RowHammer: An Experimental Analysis of Modern Devices
and Mitigation Techniques

RowHammer is a circuit-level DRAM vulnerability, first rigorously analyzed and
introduced in 2014, where repeatedly accessing data in a DRAM row can cause
bit flips in nearby rows. The RowHammer vulnerability has since garnered
significant interest in both computer architecture and computer security
research communities because it stems from physical circuit-level interference
effects that worsen with continued DRAM density scaling. As DRAM manufacturers
primarily depend on density scaling to increase DRAM capacity, future DRAM
chips will likely be more vulnerable to RowHammer than those of the past. Many
RowHammer mitigation mechanisms have been proposed by both industry and
academia, but it is unclear whether these mechanisms will remain viable
solutions for future devices, as their overheads increase with DRAM’s
vulnerability to RowHammer.

In order to shed more light on how RowHammer affects modern and future devices
at the circuit-level, we first present an experimental characterization of
RowHammer on 1580 DRAM chips (408$\times$ DDR3, 652$\times$ DDR4, and
520$\times$ LPDDR4) from 300 DRAM modules (60$\times$ DDR3, 110$\times$ DDR4,
and 130$\times$ LPDDR4) with RowHammer protection mechanisms disabled,
spanning multiple different technology nodes from across each of the three
major DRAM manufacturers. Our studies definitively show that newer DRAM chips
are more vulnerable to RowHammer: as device feature size reduces, the number
of activations needed to induce a RowHammer bit flip also reduces, to as few
as $9.6k$ (4.8k to two rows each) in the most vulnerable chip we tested.

We evaluate five state-of-the-art RowHammer mitigation mechanisms using cycle-
accurate simulation in the context of real data taken from our chips to study
how the mitigation mechanisms scale with chip vulnerability. We find that
existing mechanisms either are not scalable or suffer from prohibitively large
performance overheads in projected future devices given our observed trends of
RowHammer vulnerability. Thus, it is critical to research more effective
solutions to RowHammer.

###  6.1 RowHammer: DRAM Disturbance Errors

Modern DRAM devices suffer from _disturbance errors_ that occur when a high
rate of accesses to a single DRAM row unintentionally flip the values of cells
in nearby rows. This phenomenon is known as _RowHammer_ [170]. It inherently
stems from electromagnetic interference between nearby cells. RowHammer is
exacerbated by reduction in process technology node size because adjacent DRAM
cells become both smaller and closer to each other. Therefore, as DRAM
manufacturers continue to increase DRAM storage density, a chip’s
vulnerability to RowHammer bit flips increases [170, 239, 241].

RowHammer exposes a system-level security vulnerability that has been studied
by many prior works both from the attack and defense perspectives. Prior works
demonstrate that RowHammer can be used to mount system-level attacks for
privilege escalation (e.g., [66, 104, 105, 204, 265, 270, 285, 324, 340, 360,
87, 145]), leaking confidential data (e.g., [184]), and denial of service
(e.g., [104, 204]). These works effectively demonstrate that a system must
provide protection against RowHammer to ensure robust (i.e., reliable and
secure) execution.

Prior works propose defenses against RowHammer attacks both at the hardware
(e.g., [170, 194, 280, 303, 94, 372, 297, 150, 159, 99, 23, 25, 28, 103, 26,
24, 118, 83]) and software (e.g., [13, 16, 41, 170, 178, 198, 341, 197, 124,
135, 43, 86, 358, 36, 169, 351, 49, 350]) levels. DRAM manufacturers
themselves employ in-DRAM RowHammer prevention mechanisms such as _Target Row
Refresh (TRR)_ [139], which internally performs proprietary operations to
reduce the vulnerability of a DRAM chip against potential RowHammer attacks,
although these solutions have been recently shown to be vulnerable [87].
Memory controller and system manufacturers have also included defenses such as
increasing the refresh rate [13, 16, 197] and Hardware RHP [134, 249, 333,
345]. For a detailed survey of the RowHammer problem, its underlying causes,
characteristics, exploits building on it, and mitigation techniques, we refer
the reader to [241].

###  6.2 Motivation and Goal

Despite the considerable research effort expended towards understanding and
mitigating RowHammer, scientific literature still lacks rigorous experimental
data on how the RowHammer vulnerability is changing with the advancement of
DRAM designs and process technologies. In general, important practical
concerns are difficult to address with existing data in literature. For
example:

  * •

How vulnerable to RowHammer are future DRAM chips expected to be at the
circuit level?

  * •

How well would RowHammer mitigation mechanisms prevent or mitigate RowHammer
in future devices?

  * •

What types of RowHammer solutions would cope best with increased circuit-level
vulnerability due to continued technology node scaling?

While existing experimental characterization studies [170, 257, 256] take
important steps towards building an overall understanding of the RowHammer
vulnerability, they are too scarce and collectively do not provide a holistic
view of RowHammer evolution into the modern day. To help overcome this lack of
understanding, we need a unifying study of the RowHammer vulnerability of a
broad range of DRAM chips spanning the time since the original RowHammer paper
was published in 2014 [170].

To this end, our goal in this chapter is to evaluate and understand how the
RowHammer vulnerability of real DRAM chips at the circuit level changes across
different chip types, manufacturers, and process technology node generations.
Doing so enables us to predict how the RowHammer vulnerability in DRAM chips
will scale as the industry continues to increase storage density and reduce
technology node size for future chip designs. To achieve this goal, we perform
a rigorous experimental characterization study of DRAM chips from three
different DRAM types (i.e., DDR3, DDR4, and LPDDR4), three major DRAM
manufacturers, and at least two different process technology nodes from each
DRAM type. We show how different chips from different DRAM types and
technology nodes (abbreviated as “type-node” configurations) have varying
levels of vulnerability to RowHammer. We compare the chips’ vulnerabilities
against each other and project how they will likely scale when reducing the
technology node size even further (Section 6.4). Finally, we study how
effective existing RowHammer mitigation mechanisms will be, based on our
observed and projected experimental data on the RowHammer vulnerability
(Section 6.5).

###  6.3 Experimental Methodology

We describe our methodology for characterizing DRAM chips for RowHammer.

####  6.3.1 Testing Infrastructure

In order to characterize the effects of RowHammer across a broad range of
modern DRAM chips, we experimentally study DDR3, DDR4, and LPDDR4 DRAM chips
across a wide range of testing conditions. To achieve this, we use two
different testing infrastructures: (1) the SoftMC framework [302, 120] capable
of testing DDR3 and DDR4 DRAM modules in a temperature-controlled chamber and
(2) an in-house temperature-controlled testing chamber capable of testing
LPDDR4 DRAM chips.

SoftMC. Figure 6.1 shows our SoftMC setup for testing DDR4 chips. In this
setup, we use an FPGA board with a Xilinx Virtex UltraScale 95 FPGA [362], two
DDR4 SODIMM slots, and a PCIe interface. To open up space around the DDR4
chips for temperature control, we use a vertical DDR4 SODIMM riser board to
plug a DDR4 module into the FPGA board. We heat the DDR4 chips to a target
temperature using silicone rubber heaters pressed to both sides of the DDR4
module. We control the temperature using a thermocouple, which we place
between the rubber heaters and the DDR4 chips, and a temperature controller.
To enable fast data transfer between the FPGA and a host machine, we connect
the FPGA to the host machine using PCIe via a 30 cm PCIe extender. We use the
host machine to program the SoftMC hardware and collect the test results. Our
SoftMC setup for testing DDR3 chips is similar but uses a Xilinx ML605 FPGA
board [361]. Both infrastructures provide fine-grained control over the types
and timings of DRAM commands sent to the chips under test and provide precise
temperature control at typical operating conditions.

Figure 6.1: Our SoftMC infrastructure [302, 120] for testing DDR4 DRAM chips.

LPDDR4 Infrastructure. Our LPDDR4 DRAM testing infrastructure uses industry-
developed in-house testing hardware for package-on-package LPDDR4 chips. The
LPDDR4 testing infrastructure is further equipped with cooling and heating
capabilities that also provide us with precise temperature control at typical
operating conditions.

####  6.3.2 Characterized DRAM Chips

Table 6.1 summarizes the DRAM chips that we test using both infrastructures.
We have chips from all of the three major DRAM manufacturers spanning DDR3,
DDR4, and two known technology nodes of LPDDR4. We refer to the DRAM type
(e.g., LPDDR4) and technology node of a DRAM chip as a _DRAM type-node
configuration_ (e.g., LPDDR4-1x). For DRAM chips whose technology node we do
not exactly know, we identify their node as _old_ or _new_.

Table 6.1: Summary of DRAM chips tested. DRAM | Number of Chips (Modules) Tested
---|---
type-node | Mfr. A | Mfr. B | Mfr. C | Total
DDR3-old | 56 (10) | 88 (11) | 28 (7) | 172 (28)
DDR3-new | 80 (10) | 52 (9) | 104 (13) | 236 (32)
DDR4-old | 112 (16) | 24 (3) | 128 (18) | 264 (37)
DDR4-new | 264 (43) | 16 (2) | 108 (28) | 388 (73)
LPDDR4-1x | 12 (3) | 180 (45) | N/A | 192 (48)
LPDDR4-1y | 184 (46) | N/A | 144 (36) | 328 (82)

DDR3 and DDR4. Among our tested DDR3 modules, we identify two distinct batches
of chips based on their manufacturing date, datasheet publication date,
purchase date, and RowHammer characteristics. We categorize DDR3 devices with
a manufacturing date earlier than 2014 as DDR3-old chips, and devices with a
manufacturing date including and after 2014 as DDR3-new chips. Using the same
set of properties, we identify two distinct batches of devices among the DDR4
devices. We categorize DDR4 devices with a manufacturing date before 2018 or a
datasheet publication date of 2015 as DDR4-old chips and devices with a
manufacturing date including and after 2018 or a datasheet publication date of
2016 or 2017 as DDR4-new chips. Based on our observations on RowHammer
characteristics from these chips, we expect that DDR3-old/DDR4-old chips are
manufactured at an older date with an older process technology compared to
DDR3-new/DDR4-new chips, respectively. This enables us to directly study the
effects of shrinking process technology node sizes in DDR3 and DDR4 DRAM
chips.

LPDDR4. For our LPDDR4 chips, we have two known distinct generations
manufactured with different technology node sizes, 1x-nm and 1y-nm, where
1y-nm is smaller than 1x-nm. Unfortunately, we are missing data from some
generations of DRAM from specific manufacturers (i.e., LPDDR4-1x from
manufacturer C and LPDDR4-1y from manufacturer B) since we did not have access
to chips of these manufacturer-technology node combinations due to
confidentiality issues. Note that while we know the external technology node
values for the chips we characterize (e.g., 1x-nm, 1y-nm), these values are
_not_ standardized across different DRAM manufacturers and the actual values
are confidential. This means that a 1x chip from one manufacturer is not
necessarily manufactured with the same process technology node as a 1x chip
from another manufacturer. However, since we do know relative process node
sizes of chips from the _same_ manufacturer, we can directly observe how
technology node size affects RowHammer on LPDDR4 DRAM chips.

####  6.3.3 Effectively Characterizing RowHammer

In order to characterize RowHammer effects on our DRAM chips at the circuit-
level, we want to test our chips at the worst-case RowHammer conditions. We
identify two conditions that our tests must satisfy to effectively
characterize RowHammer at the circuit level: our testing routines must both:
1) run without interference (e.g., without DRAM refresh or RowHammer
mitigation mechanisms) and 2) systematically test each DRAM row’s
vulnerability to RowHammer by issuing the _worst-case sequence of DRAM
accesses_ for that particular row.

Disabling Sources of Interference. To directly observe RowHammer effects at
the circuit level, we want to minimize the external factors that may limit 1)
the effectiveness of our tests or 2) our ability to effectively
characterize/observe circuit-level effects of RowHammer on our DRAM chips.
First, we want to ensure that we have control over how our RowHammer tests
behave without disturbing the desired access pattern in any way. Therefore,
during the core loop of each RowHammer test (i.e., when activations are issued
at a high rate to induce RowHammer bit flips), we disable all DRAM self-
regulation events such as refresh and calibration, using control registers in
the memory controller. This guarantees consistent testing without confounding
factors due to intermittent events (e.g., to avoid the possibility that a
victim row is refreshed during a RowHammer test routine such that we observe
fewer RowHammer bit flips). Second, we want to directly observe the circuit-
level bit flips such that we can make conclusions about DRAM’s vulnerability
to RowHammer at the circuit technology level rather than the system level. To
this end, to the best of our knowledge, we disable all DRAM-level (e.g., TRR
[141, 139, 87]) and system-level RowHammer mitigation mechanisms (e.g., pTRR
[9]) along with all forms of rank-level error-correction codes (ECC), which
could obscure RowHammer bit flips. Unfortunately, all of our LPDDR4-1x and
LPDDR4-1y chips use on-die ECC [6, 180, 151, 259, 183] (i.e., an error
correcting mechanism that corrects single-bit failures entirely within the
DRAM chip [259]), which we cannot disable. Third, we ensure that the core loop
of our RowHammer test runs for less than 32 ms (i.e., the lowest refresh
interval specified by manufacturers to prevent DRAM data retention failures
across our tested chips [260, 206, 155, 138, 139, 141]) so that we do not
conflate retention failures with RowHammer bit flips.

Worst-case RowHammer Access Sequence. We leverage _three_ key observations
from prior work [170, 16, 104, 360, 65] in order to craft a worst-case
RowHammer test pattern. First, a repeatedly accessed row (i.e., _aggressor
row_) has the greatest impact on its immediate physically-adjacent rows (i.e.,
repeatedly accessing physical row $N$ will cause the highest number of
RowHammer bit flips in physical rows $N+1$ and $N-1$). Second, a _double-sided
hammer_ targeting physical victim row $N$ (i.e., repeatedly accessing physical
rows $N-1$ and $N+1$) causes the _highest_ number of RowHammer bit flips in
row $N$ compared to any other access pattern. Third, increasing the rate of
DRAM activations (i.e., issuing the same number of activations within shorter
time periods) results in an increasing number of RowHammer bit flips. This
rate of activations is limited by the DRAM timing parameter $t_{RC}$ (i.e.,
the time between two successive activations) which depends on the DRAM clock
frequency and the DRAM type: DDR3 (52.5ns) [138], DDR4 (50ns) [139], LPDDR4
(60ns) [141]. Using these observations, we test each row’s worst-case
vulnerability to RowHammer by repeatedly accessing the two directly
physically-adjacent rows as fast as possible.

To enable the quick identification of physical rows $N-1$ and $N+1$ for a
given row $N$, we reverse-engineer the _undocumented_ and _confidential_
logical-to-physical DRAM-internal row address remapping. To do this, we
exploit RowHammer’s key observation that repeatedly accessing an arbitrary row
causes the two directly physically-adjacent rows to contain the _highest_
number of RowHammer bit flips [170]. By repeating this analysis across rows
throughout the DRAM chip, we can deduce the address mappings for each type of
chip that we test. We can then use this mapping information to quickly test
RowHammer effects at worst-case conditions. We note that for our LPDDR4-1x
chips from Manufacturer B, when we repeatedly access a single row within two
consecutive rows such that the first row is an even row (e.g., rows 2 and 3)
in the logical row address space as seen by the memory controller, we observe
1) no RowHammer bit flips in either of the two consecutive rows and 2) a near
equivalent number of RowHammer bit flips in each of the four immediately
adjacent rows: the two previous consecutive rows (e.g., rows 0 and 1) and the
two subsequent consecutive rows (e.g., rows 4 and 5). This indicates a row
address remapping that is internal to the DRAM chip such that every pair of
consecutive rows share the same internal wordline. To account for this DRAM-
internal row address remapping, we test each row $N$ in LPDDR4-1x chips from
manufacturer B by repeatedly accessing physical rows $N-2$ and $N+2$.

Additional Testing Parameters. To investigate RowHammer characteristics, we
explore two testing parameters at a stable ambient temperature of
$50^{\circ}C$:

  1. 1.

Hammer count ($HC$). We test the effects of changing the number of times we
access (i.e., activate) a victim row’s physically-adjacent rows (i.e.,
aggressor rows). We count each pair of activations to the two neighboring rows
as one _hammer_ (e.g., one activation each to rows $N-1$ and $N+1$ counts as
one hammer). We sweep the hammer count from 2k to 150k (i.e., 4k to 300k
activations) across our chips so that the hammer test runs for less than 32ms.

  2. 2.

Data pattern ($DP$). We test several commonly-used DRAM data patterns where
every byte is written with the same data: Solid0 (SO0: 0x00), Solid1 (SO1:
0xFF), Colstripe0 (CO0: 0x55), Colstripe1 (CO1: 0xAA) [206, 260, 155]. In
addition, we test data patterns where each byte in every other row, including
the row being hammered, is written with the same data, Checkered0 (CH0: 0x55)
or Rowstripe0 (RS0: 0x00), and all other rows are written with the inverse
data, Checkered1 (CH1: 0xAA) or Rowstripe1 (RS1: 0xFF), respectively.

RowHammer Testing Routine. Algorithm 6 presents the general testing
methodology we use to characterize RowHammer on DRAM chips. For different data
patterns ($DP$) (line 2) and hammer counts ($HC$) (line 8), the test
individually targets each row in DRAM (line 4) as a victim row (line 5). For
each victim row, we identify the two physically-adjacent rows
($aggressor\\_row1$ and $aggressor\\_row2$) as aggressor rows (lines 6 and 7).
Before beginning the core loop of our RowHammer test (Lines 11-13), two things
happen: 1) the memory controller disables DRAM refresh (line 9) to ensure no
interruptions in the core loop of our test due to refresh operations, and 2)
we refresh the victim row (line 10) so that we begin inducing RowHammer bit
flips on a fully-charged row, which ensures that bit flips we observe are not
due to retention time violations. The core loop of our RowHammer test (Lines
11-13) induces RowHammer bit flips in the victim row

1 DRAM_RowHammer_Characterization():

2 foreach $DP$ in [Data Patterns]:

3 write $DP$ into all cells in $DRAM$

4 foreach $row$ in $DRAM$:

5 set $victim\\_row$ to $row$

6 set $aggressor\\_row1$ to $victim\\_row-1$

7 set $aggressor\\_row2$ to $victim\\_row+1$

8 foreach $HC$ in [$HC$ sweep]:

9 Disable DRAM refresh

10 Refresh $victim\\_row$

11 for $n=1\rightarrow HC$: // core test loop

12 activate $aggressor\\_row1$

13 activate $aggressor\\_row2$

14 Enable DRAM refresh

15 Record RowHammer bit flips to storage

16 Restore bit flips to original values

Algorithm 6 DRAM RowHammer Characterization

by first activating $aggressor\\_row1$ then $aggressor\\_row2$, $HC$ times.
After the core loop of our RowHammer test, we re-enable DRAM refresh (line 14)
to prevent retention failures and record the observed bit flips to secondary
storage (line 15) for analysis (presented in Section 6.4). Finally, we prepare