Spoiler: Speculative Load Hazards Boost

Rowhammer and Cache Attacks

Saad Islam and Ahmad Moghimi, Worcester Polytechnic Institute; Ida Bruhns and
Moritz Krebbel, University of Luebeck; Berk Gulmezoglu, Worcester Polytechnic Institute;
Thomas Eisenbarth, Worcester Polytechnic Institute and University of Luebeck; Berk Sunar,
Worcester Polytechnic Institute
[Link]

This paper is included in the Proceedings of the

28th USENIX Security Symposium.
August 14–16, 2019 • Santa Clara, CA, USA
978-1-939133-06-9

Open access to the Proceedings of the

28th USENIX Security Symposium
is sponsored by USENIX.
 S POILER: Speculative Load Hazards Boost Rowhammer and Cache Attacks

Saad Islam1 , Ahmad Moghimi1 , Ida Bruhns2 , Moritz Krebbel2 , Berk Gulmezoglu1 , Thomas Eisenbarth1, 2 ,
and Berk Sunar1
1 Worcester Polytechnic Institute, Worcester, MA, USA
2 University of Lübeck, Lübeck, Germany

Abstract defense mechanisms such as Kernel Address Space Layout

Randomization (KASLR) [11, 17]. Rowhammer attacks can
Modern microarchitectures incorporate optimization tech-
further break the data and code integrity by tampering with
niques such as speculative loads and store forwarding to
memory contents [29,47]. While most of these attacks require
improve the memory bottleneck. The processor executes the
local access and native code execution, various efforts have
load speculatively before the stores, and forwards the data
been successful in conducting them remotely [50] or from
of a preceding store to the load if there is a potential depen-
within a remotely accessible sandbox such as JavaScript [42].
dency. This enhances performance since the load does not
have to wait for preceding stores to complete. However, the Memory components such as DRAM [29] and cache [43]
dependency prediction relies on partial address information, are not the only microarchitectural attack surfaces. Spectre
which may lead to false dependencies and stall hazards. attacks on the branch prediction unit [30, 38] imply that side
channels such as caches can be used as a primitive for more
In this work, we are the first to show that the dependency
advanced attacks on speculative engines. Speculative engines
resolution logic that serves the speculative load can be ex-
predict the outcome of an operation before its completion,
ploited to gain information about the physical page mappings.
and they enable execution of the following dependent instruc-
Microarchitectural side-channel attacks such as Rowhammer
tions ahead of time based on the prediction. As a result, the
and cache attacks like Prime+Probe rely on the reverse engi-
pipeline can maximize the instruction level parallelism and re-
neering of the virtual-to-physical address mapping. We pro-
source usage. In rare cases where the prediction is wrong, the
pose the S POILER attack which exploits this leakage to speed
pipeline needs to be flushed resulting in performance penal-
up this reverse engineering by a factor of 256. Then, we show
ties. However, this approach suffers from a security weakness,
how this can improve the Prime+Probe attack by a 4096
in which an adversary can fool the predictor and introduce ar-
factor speed up of the eviction set search, even from sand-
bitrary mispredictions that leave microarchitectural footprints
boxed environments like JavaScript. Finally, we improve the
in the cache. These footprints can be collected through the
Rowhammer attack by showing how S POILER helps to con-
cache side channel to steal secrets.
duct DRAM row conflicts deterministically with up to 100%
chance, and by demonstrating a double-sided Rowhammer Modern processors feature further speculative behavior
attack with normal user’s privilege. The later is due to the such as memory disambiguation and speculative loads [10]. A
possibility of detecting contiguous memory pages using the load operation can be executed speculatively before preced-
S POILER leakage. ing store operations. During the speculative execution of the
load, false dependencies may occur due to the unavailability
of physical address information. These false dependencies
1 Introduction need to be resolved to avoid computation on invalid data. The
occurrence of false dependencies and their resolution depend
Microarchitectural attacks have evolved over the past decade on the actual implementation of the memory subsystem. Intel
from attacks on weak cryptographic implementations [5] to uses a proprietary memory disambiguation and dependency
devastating attacks breaking through layers of defenses pro- resolution logic in the processors to predict and resolve false
vided by the hardware and the Operating System (OS) [52]. dependencies that are related to the speculative load. In this
These attacks can steal secrets such as cryptographic keys [4, work, we discover that the dependency resolution logic suffers
44] or keystrokes [33]. More advanced attacks can entirely from an unknown false dependency independent of the 4K
subvert the OS memory isolation to read the memory content aliasing [40, 49]. The discovered false dependency happens
from more privileged security domains [35], and to bypass during the 1 MB aliasing of speculative memory accesses

USENIX Association 28th USENIX Security Symposium 621

which is exploited to leak information about physical page 5. explores how S POILER can track nearby load operations
mappings. from a more privileged security domain right after a
The state-of-the-art microarchitectural attacks [25, 45] ei- context switch.
ther rely on knowledge of physical addresses or are signifi-
cantly eased by that knowledge. Yet, knowledge of the physi-
cal address space is only granted with root privileges. Cache
1.2 Related Work
attacks such as Prime+Probe on the Last-Level Cache (LLC) Kosher et al. [30] and Maisuradze et al. [38] have exploited
are challenging due to the unknown mapping of virtual ad- vulnerabilities in the speculative branch prediction unit. Tran-
dresses to cache sets and slices. Knowledge about the physical sient execution of instructions after a fault, as exploited by
page mappings enables more attack opportunities using the Lipp et al. [35] and Bulck et al. [52], can leak memory con-
Prime+Probe technique. Rowhammer [29] attacks require tent of protected environments. Similarly, transient behavior
efficient access to rows within the same bank to induce fast due to the lazy store/restore of the FPU and SIMD registers
row conflicts. To achieve this, an adversary needs to reverse can leak register contents from other contexts [48]. New vari-
engineer layers of abstraction from the virtual address space ants of both Meltdown and Spectre have been systematically
to DRAM cells. Availability of physical address information analyzed [7]. The Speculative Store Bypass (SSB) vulnera-
facilitates this reverse engineering process. In sandboxed en- bility [21] is a variant of the Spectre attack and relies on the
vironments, attacks are more limited, since in addition to the stale sensitive data in registers to be used as an address for
limited access to the address space, low-level instructions speculative loads which may then allow the attacker to read
are also inaccessible [18]. Previous attacks assume special this sensitive data. In contrast to previous attacks on specu-
access privileges only granted through weak software config- lative and transient behaviors, we discover a new leakage on
urations [25, 34, 55] to overcome some of these challenges. In the undocumented memory disambiguation and dependency
contrast, S POILER only relies on simple operations, load and resolution logic. S POILER is not a Spectre attack. The root
store, to recover crucial physical address information, which cause for S POILER is a weakness in the address speculation of
in turn enables Rowhammer and cache attacks, by leaking Intel’s proprietary implementation of the memory subsystem
information about physical pages without assuming any weak which directly leaks timing behavior due to physical address
configuration or special privileges. conflicts. Existing spectre mitigations would therefore not
interfere with S POILER.
The timing behavior of the 4K aliasing false dependency
1.1 Our Contribution on Intel processors have been studied [12, 61]. MemJam [40]
We have discovered a novel microarchitectural leakage which uses this behavior to perform a side-channel attack, and Sul-
reveals critical information about physical page mappings livan et al. [49] demonstrate a covert channel. These works
to user space processes. The leakage can be exploited by a only mention the 4K aliasing as documented by Intel [24],
limited set of instructions, which is visible in all Intel genera- and the authors conclude that the address aliasing check is a
tions starting from the 1st generation of Intel Core processors, two stage approach: Firstly, it uses page offset for the initial
independent of the OS and also works from within virtual ma- guess. Secondly, it performs the final resolution based on the
chines and sandboxed environments. In summary, this work: exact physical address. On the contrary, we discover that the
undocumented address resolution logic performs additional
1. exposes a previously unknown microarchitectural leak- partial address checks that lead to an unknown, but observable
age stemming from the false dependency hazards during aliasing behavior based on the physical address.
speculative load operations. Several microarchitectural attacks have been discovered to
recover virtual address information and break KASLR by ex-
2. proposes an attack, S POILER, to efficiently exploit this ploiting the Translation Lookaside Buffer (TLB) [22], Branch
leakage to speed up the reverse engineering of virtual-to- Target Buffer (BTB) [11] and Transactional Synchronization
physical mappings by a factor of 256 from both native Extensions (TSX) [27]. Additionally, Gruss et al. [17] ex-
and JavaScript environments. ploit the timing information obtained from the prefetch
instruction to leak the physical address information. The main
3. demonstrates a novel eviction set search technique from obstacle to this approach is that the prefetch instruction is
JavaScript and compares its reliability and efficiency to not accessible in JavaScript, and it can be disabled in native
existing approaches. sandboxed environments [62], whereas S POILER is applicable
to sandboxed environments including JavaScript.
4. achieves efficient DRAM row conflicts and the first Knowledge of the physical address enables adversaries to
double-sided Rowhammer attack with normal user-level bypass OS protections [28] and ease other microarchitectural
privilege using the contiguous memory detection capa- attacks [34]. For instance, the procfs filesystem exposes
bility of S POILER. physical addresses [34], and Huge pages allocate contiguous

622 28th USENIX Security Symposium USENIX Association

physical memory [25, 36]. Drammer [55] exploits the An- processor accesses a memory address, a cache hit or miss
droid ION memory allocator to access contiguous memory. occurs. If a miss occurs in all cache levels, the memory line
However, access to the aforementioned primitives is restricted has to be fetched from DRAM. Accesses to the same memory
on most environments by default. We do not have any assump- address would be served from the cache unless other memory
tion about the OS and software configuration, and we exploit accesses evict that cache line. In addition, we can use the
a hardware leakage with minimum access rights to find virtual clflush instruction, which follows the same memory access
pages that have the same least significant 20 physical address check as other memory operations, to evict our own cache
bits. GLitch [13] detects contiguous physical pages by ex- lines from the entire cache hierarchy.
ploiting row conflicts through the GPU interface. In contrast,
our attack does not rely on a specific integrated GPU configu-
ration, and it is widely applicable to any system running on
2.3 Prime+Probe Attack
an Intel CPU. We use S POILER to find contiguous physical In the Prime+Probe attack, the attacker first fills an entire
pages with a high probability and verify it by producing row cache set by accessing memory addresses that are mapped
conflicts. S POILER is particularly helpful for attacks in sand- to the same set, an eviction set. Later, the attacker checks
boxed low-privilege environments such as JavaScript, where whether the victim program has displaced any entry in the
previous methods require a time-consuming brute forcing of cache set by accessing the eviction set again and measuring
the memory addresses [18, 42, 47]. the execution time. If this is the case, the attacker can de-
tect congruent addresses, since the displaced entries cause an
2 Background increased access time. However, finding the eviction sets is
difficult due to the unknown translation of virtual addresses
to physical addresses. Since an unprivileged attacker has no
2.1 Memory Management
access to hugepages [23] or the virtual-to-physical page map-
The virtual memory manager shares the DRAM across all ping such as the pagemap file [34], knowledge about the phys-
running tasks by assigning isolated virtual address spaces to ical address bits greatly speeds up the eviction set search.
each task. The assigned memory is allocated in pages, which
are typically 4 kB each, and each virtual page will be stored as
2.4 Rowhammer Attack
a physical page in DRAM through a virtual-to-physical page
mapping. Memory instructions operate on virtual addresses, DRAM consists of multiple memory banks, and each bank is
which are translated within the processor to the correspond- subdivided into rows. When the processor accesses a memory
ing physical addresses. The page offset comprising the least location, the corresponding row needs to be activated and
significant 12 bits of the virtual address is not translated. The loaded into the row buffer. If the processor accesses the same
processor only translates the bits in the rest of the virtual row again, it is called a row hit, and the request will be served
address, the virtual page number. The OS is the reference for from the row buffer. Otherwise, it is called a row conflict, and
this translation, and the processor stores the translation results the previous row will be deactivated and copied back to the
inside the TLB. As a result, repeated translations of the same original row location, after which the new row is activated.
address are performed more efficiently. DRAM cells leak charge over time and need to be refreshed
periodically to maintain the data. A Rowhammer [29] at-
2.2 Cache Hierarchy tack causes cells of a victim row to leak faster by activating
the neighboring rows repeatedly. If the refresh cycle fails
Modern processors incorporate multiple levels of caches to to refresh the victim row fast enough, that leads to bit flips.
avoid the DRAM access latency. The cache memory on Intel Once bit flips are found, they can be exploited by placing any
processors is organized into sets and slices. Each set can store security-critical data structure or code page at that particu-
a certain number of lines, where the line size is 64 bytes. The lar location and triggering the bit flip again [16, 47, 60]. The
6 Least Significant Bits (LSBs) of the physical address are Rowhammer attack requires fast access to the same DRAM
used to determine the offset within a line and the remaining cells by bypassing the CPU cache, e.g., using clflush [29].
bits are used to determine which set to store the cache line in. Additionally, cache eviction based on an eviction set can
The number of physical address bits that are used for mapping also result in access to DRAM cells when clflush is not
is higher for the LLC, since it has a large number of sets, e.g., available [3, 18]. Efficiently building eviction sets may thus
8192 sets. Hence, the untranslated part of the virtual address also enhance Rowhammer attacks. For a successful Rowham-
bits which is the page offset, cannot be used to index the LLC mer attack, it is essential to collocate multiple memory pages
sets. Instead, higher physical address bits are used. Further, within the same bank and adjacent to each other. A number
each set of LLC is divided into multiple slices, one slice for of physical address bits, depending on the hardware configu-
each logical processor. The mapping of the physical addresses ration, are used to map memory pages to banks [45]. Since
to the slices uses an undocumented function [26]. When the the rows are generally placed sequentially within the banks,

USENIX Association 28th USENIX Security Symposium 623

Stored Data μOp Store Address μOp
the TLB for the complete physical address information, which
index 0 ... PA [:0]
is time consuming. Additionally, the data cache (DCACHE)
... DATA ... VA [:12] PA [19:12] VA [11:0]
index 0
... PA [:0] may hold the translated store addresses in a Physical Address
... DATA ... VA [:12] PA [19:12] VA [11:0] ...
... ... Buffer (PAB) with equal number of entries as the store buffer.
index n ... PA [:0]
... DATA index n ... VA [:12] PA [19:12] VA [11:0]
PAB
SDB SAB DCACHE
3 Speculative Load Hazards
TLB
index 0 ... PA[:0] VA[:0] DATA
... As we mentioned earlier, memory loads can be executed
index k

LB PMH out-of-order and before the preceding memory stores. If

MOB
one of the preceding stores modifies the content of a lo-
cation in memory, the memory load address is referring to,
out-of-order execution of the load will operate on stale data,
Figure 1: The Memory Order Buffer includes circular buffers which results in invalid execution of a program. This out-of-
SDB, SAB and LB. SDB, SAB and PAB of the DCACHE order execution of the memory load is a speculative behavior,
have the same number of entries. SAB may initially hold the since there is no guarantee during the execution time of the
virtual address and the partial physical address. MOB requests load that the virtual addresses corresponding to the memory
the TLB to translate the virtual address and update the PAB stores do not conflict with the load address after translation
with the translated physical address. to physical addresses. Figure 2 demonstrates this effect on
access to adjacent rows within the same bank can be achieved a hypothetical processor with 7 pipeline stages. As multiple
if we have access to contiguous physical pages. stores may be blocked due to limited resources, the execu-
tion of the load and dependent instructions in the pipeline, the
load block, will bypass the stores since the MOB assumes
2.5 Memory Order Buffer the load block to be independent of the stores. This specula-
tive behavior improves the memory bottleneck by letting other
The processor manages memory operations using the Memory instructions continue their execution. However, if the depen-
Order Buffer (MOB). MOB is tightly coupled with the data dency of the load and preceding stores is not verified, the
cache. The MOB assures that memory operations are executed load block may be computed on incorrect data which is either
efficiently by following the Intel memory ordering rule [39] falsely forwarded by store forwarding (false dependency), or
in which memory stores are executed in-order and memory loaded from a stale cache line (unresolved true dependency).
loads can be executed out-of-order. These rules have been If the processor detects a false dependency before committing
enforced to improve the efficiency of memory accesses, while the load, it has to flush the pipeline and re-execute the load
guaranteeing their correct commitment. Figure 1 shows the block. This will cause observable performance penalties and
MOB schematic according to Intel [1, 2]. The MOB includes timing behavior.
circular buffers, store buffer1 and load buffer (LB). A store
will be decoded into two micro ops to store the address and
data, respectively, to the store buffer. The store buffer enables 3.1 Dependency Resolution
the processor to continue executing other instructions before Dependency checks and resolution occur in multiple stages
commitment of the stores. As a result, the pipeline does not depending on the availability of the address information in the
have to stall for the stores to complete. This further enables store buffer. A load instruction needs to be checked against
the MOB to support out-of-order execution of the load. all preceding stores in the store buffer to avoid false depen-
Store forwarding is an optimization mechanism that sends dencies and to ensure the correctness of the data. A potential
the store data to a load if the load address matches any of design [20, 31],2 suggests the following stages for the depen-
the store buffer entries. This is a speculative process, since dency check and resolution, as shown in Figure 3:
the MOB cannot determine the true dependency of the load
on stores based on the store buffer. Intel’s implementation 1. Loosenet: The first stage is the loosenet check where
of the store buffer is undocumented, but a potential design the page offsets of the load and stores are compared3 .
suggests that it will only hold the virtual address, and it may In case of a loosenet hit, the compared load and store
include part of the physical address [1, 2, 31]. As a result, the may be dependent and the processor will proceed to the
processor may falsely forward the data, although the physical next check stage.
addresses do not match. The complete resolution will be de- 2 The implementation of the MOB used in Intel processors is unpublished
layed until the load commitment, since the MOB needs to ask and therefore we cannot be certain about the precise architecture. Our results
agree with some of the possible designs that are described in the Intel patents.
1 Store buffer consists of Store Address Buffer (SAB) and Store Data Buffer 3 According to Ld_Blocks_Partial:Address_Alias Hardware Perfor-

(SDB). For simplicity, we use Store Buffer to mention the logically combined mance Counter (HPC) event [24], loosenet is defined by Intel as the mecha-
SAB and SDB units. nism that only compare the page offsets.

624 28th USENIX Security Symposium USENIX Association

 Busy Load Block Dependency Check Flush The Pipeline
Resource Bypasses Stores Before Commit
F D X1 X2 X3 X4 C
store a → X
store b → Y
store c → Z
load d← W
inc d
(State 1) (State 2) (State 3) Hazard (State 4)

Figure 2: The speculative load is demonstrated on a hypothetical processor with 7 pipeline stages: F = Fetch, D = Decode, X1−4 =
Executions, and C = Commit. When the memory stores are blocked competing for resources (State 1), the load will bypass the
stores (State 2). The load block including the dependent instructions will not be committed until the dependency of the address
W versus X,Y ,Z are resolved (State 3). In case of a dependency hazard (State 4), the pipeline is flushed and the load is restarted.

the finenet check may be implemented based on checking the

Loosenet
Yes
Finenet
No
Physical
Address No
Redispatch partial physical address bits. As we verify later, the depen-
Hit? Hit? Load
Match?
dency resolution logic may fail to resolve the dependency at
No Yes No
multiple intermediate stages due to unavailability of the full
Partial
Physical Addr
Hit?
No physical address.
Proceed with Block Load /
Load Forward Store Yes

Yes

4 The S POILER Attack

Figure 3: The dependency check logic: loosenet initially The attack model for S POILER is the same as Rowhammer
checks the least 12 significant bits (page offset) and the finenet and cache attacks where the attacker’s code is needed to be
checks the upper address bits, related to the page number. The executed on the same underlying hardware as of the victim.
final dependency using the physical address matching might As described in Section 3, speculative loads may face other
still fail due to partial physical address checks. aliasing conditions in addition to the 4K aliasing, due to the
partial checks on the higher address bits. To confirm this, we
design an experiment to observe timing behavior of a specu-
2. Finenet: The next stage, called finenet, uses upper ad- lative load based on higher address bits. For this purpose, we
dress bits. The finenet can be implemented to check the propose Algorithm 1 that executes a speculative load after
upper virtual address bits [20], or the physical address multiple stores and further make sure to fill the store buffer
tag [31]. Either way, it is an intermediate stage, and it is with addresses that cause 4K aliasing during the execution of
not the final dependency resolution. In case of a finenet the load. Having w as the window size, the algorithm iterates
hit, the processor blocks the load and/or forwards the over a number of different memory pages, and for each page, it
store data, otherwise, the dependency resolution will go performs stores to that page and all previous w pages within
into the final stage. a window. Since the size of the store buffer varies between
different processor generations, we choose a big enough win-
3. Physical Address Matching: At the final stage, the dow (w = 64) to ensure that the load has 4K aliasing with
physical addresses will be checked. Since this stage is the maximum number of entries in the store buffer and hence
the final chance to resolve potential false dependencies, maximum potential conflicts. Following the stores, we mea-
we expect the full physical address to be checked. How- sure the timing of a load operation from a different memory
ever, one possible design suggests that if the physical ad- page, as defined by x. Since we want the load to be executed
dresses are not available, the physical address matching speculatively, we can not use a store fence such as mfence be-
returns true and continues with the store forwarding [20]. fore the load. As a result, our measurements are an estimate
of execution time for the speculatively load and nearby mi-
Since the page offset is identical between the virtual and phys- croarchitectural events. This may include a negligible portion
ical address, loosenet can be performed as soon as the store of overhead for the execution of stores, and/or any delay due
is decoded. [2] suggests that the store buffer only holds bit to the dependency resolution. If we iterate over a diverse set
19 to 12 of the physical address. Although the PAB holds the of addresses with different virtual and physical page numbers,
full translated physical address, it is not clear in which stage but the same page offset, we should be able to monitor any
this information can be available to the MOB. As a result, discrepancy.

USENIX Association 28th USENIX Security Symposium 625

 Correlation Coefficient
1
Algorithm 1 Address Aliasing
0.5
for p from w to PAGE_COUNT do
0
for i from w to 0 do
store
data −−→ bu f f er[(p − i) × PAGE_SIZE] -0.5

end for -1
0 5 10 15 20 25 30
t1 = rdtscp() Counter Number
load
data ←−− bu f f er[x × PAGE_SIZE]
t2 = rdtscp()
measure[p] ← t2 − t1 Figure 5: Correlation with HPCs listed in Table 5 in
end for the appendix. Ld_Blocks_Partial:Address_Alias and
return measure Cycle_Activity:Stalls_Ldm_Pending (both dotted red)
have strong positive and negative correlations, respectively.
600
rdtsc
Cycles

400

200

0
0 100 200 300 400 500 600 700 800 900 1000 experiment. At each iteration, only one performance counter
(a) Step-wise peaks with a very high latency can be observed on some of the is monitored alongside the aforementioned timing measure-
virtual pages ment. After each speculative load, the performance counter
value and the load time are both recorded. Finally, we obtain
1000
the timings and performance counter value pairs as depicted
Cycles

500 in Figure 4.
Stalls_Ldm_Pending
0
0 100 200 300 400 500 600 700 800 900 1000 To find any relation between the observed high latency
(b) Affected HPC event: Cycle_Activity:Stalls_Ldm_Pending and a particular event, we compute correlation coefficients
between counters and the timing measurements. Since the
20
latency only occurs in the small region of the trace where the
Dependency

10
timing increases, we only need to compute the correlation on
Address_Alias
these regions. When an increase of at least 200 clock cycles
0
0 100 200 300 400 500 600 700 800 900 1000
is detected, the next s values from timing and the HPC traces
are used to calculate the correlations, where s is the number
(c) Affected HPC event: Ld_Blocks_Partial:Address_Alias
of steps from Table 1 and 200 is the average execution time
for a load.
Figure 4: S POILER’s timing measurements and hardware per-
formance counters recorded simultaneously. As shown in Figure 5, two events have a high correla-
tion with the leakage: Cycle_Activity:Stalls_Ldm_Pending
has the highest correlation of 0.985. This event shows
4.1 Speculative Dependency Analysis
the number of cycles for which the execution is stalled
In this section, we use Algorithm 1 and Hardware Perfor- and no instructions are executed due to a pending load.
mance Counters (HPC) to perform an empirical analysis of Ld_Blocks_Partial:Address_Alias has an inverse correla-
the dependency resolution logic. HPCs can keep track of tion with the leakage. This event counts the number of false de-
low-level hardware-related events in the CPU. The counters pendencies in the MOB when loosenet resolves the 4K alias-
are accessible via special purpose registers and can be used ing condition. Separately, Exe_Activity:Bound_on_Stores
to analyze the performance of a program. They provide a increases with more number of stores within the inner
powerful tool to detect microarchitectural components that window loop in Algorithm 1, but it does not have a cor-
cause bottlenecks. Software libraries such as Performance relation with the leakage. The reason behind this behav-
Application Programming Interface (PAPI) [51] simplifies ior is that the store buffer is full, and additional store op-
programming and reading low-level HPC on Intel processors. erations are pending. However, since there is no correla-
Initially, we execute Algorithm 1 for 1000 different virtual tion with the leakage, this shows that the timing behavior
pages. Figure 4(a) shows the cycle count for each iteration is not due to the stores delay. We also attempt to profile
with a set of 4 kB aliased store addresses. Interestingly, we any existing counters related to the memory disambigua-
observe multiple step-wise peaks with a very high latency. tion. However, the events Memory_Disambiguation.Success
Then, we use PAPI to monitor 30 different performance coun- and Memory_Disambiguation.Reset are not available on the
ters listed in Table 5 in the appendix while running the same modern architectures that are tested.

626 28th USENIX Security Symposium USENIX Association

 CPU Model Architecture Steps SB Size address with the matching 1 MB aliased address, the latency is
Intel Core i7-8650U Kaby Lake R 22 56 at its highest point, marked as “1” in Figure 6. As the window
Intel Core i7-7700 Kaby Lake 22 56 loop accesses this address later in the loop, it appears closer
Intel Core i5-6440HQ Skylake 22 56 to the load with a lower latency like the steps marked as 5, 15
Intel Xeon E5-2640v3 Haswell 17 42 and 22. This observation matches the carry chain algorithm
Intel Xeon E5-2670v2 Ivy Bridge EP 14 36 described by Intel [20] where the aliasing check starts from
Intel Core i7-3770 Ivy Bridge 12 36 the most recent store. As shown in Table 1, experimenting
Intel Core i7-2670QM Sandy Bridge 12 36 with various processor generations shows that the number of
Intel Core i5-2400 Sandy Bridge 12 36 steps has a linear correlation with the size of the store buffer
Intel Core i5 650 Nehalem 11 32 which is architecture dependent. While the leakage exists on
Intel Core2Duo T9400 Core N/A 20 all Intel Core processors starting from the first generation,
Qualcomm Kryo 280 ARMv8-A N/A * the timing effect is higher for the more recent generations
AMD A6-4455M Bulldozer N/A * with a bigger store buffer size. The analyzed ARM and AMD
processors do not show similar behavior4 .
Table 1: 1 MB aliasing on various architectures: The tested As our time measurement for speculative load suggests, it
AMD and ARM architectures, and Intel Core generation do is not possible to reason whether the high timing is due to a
not show similar effects. The Store Buffer (SB) sizes are very slow load or commitment of store operations. If the step-
gathered from Intel Manual [24] and [Link] [57–59]. wise delay matches the store buffer entries, this delay may be
either due to the the dependency resolution logic performing
4.2 Leakage of the Physical Address Mapping a pipeline flush and restart of the load for each 4 kB aliased
entry starting from the 1 MB aliased entry, or due to the load
In this experiment, we evaluate whether the observed step- waiting for all the remaining stores to commit because of
wise latency has any relationship with the physical page num- an unresolved hazard. To explore this further, we perform an
bers by observing the pagemap file. As shown in Figure 6, additional experiment with all store addresses replaced with
we observe step-wise peaks with a very high latency which non-aliased addresses except for one. This experiment shows
appear once in every 256 pages on [Link] 20 least sig- that the peak disappears if there is only a single 4 kB and
nificant bits of physical address for the load matches with 1 MB aliased address in the store buffer.
the physical addresses of the stores where high peaks for Lastly, we run the same experiments on a shuffled set of vir-
virtual pages are observed. In our experiments, we always tual addresses to assure that the contiguous virtual addresses
detect peaks with different virtual addresses, which have the may not affect the observed leakage. Our experiment with the
matching least 20 bits of physical address. This observation shuffled virtual addresses exactly match the same step-wise
clearly discovers the existence of 1 MB aliasing effect based behavior suggesting that the upper bits in virtual addresses do
on the physical addresses. This 1 MB aliasing leaks informa- not affect the leakage behavior, and the leakage is solely due
tion about 8 bits of mapping that were unknown to the user to the aliasing on physical address bits.
space processes.
Matching this observation with the previously observed
4.3.1 Comparison of Address Aliasing Scenarios
Cycle_Activity:Stalls_Ldm_Pending with a high correla-
tion, the speculative load has been stalled to resolve the depen- We further test other address combinations to compare ad-
dency with conflicting store buffer entries after the occurrence ditional address aliasing scenarios using Algorithm 1. As
of a 1 MB aliased address. This observation verifies that the shown by Figure 7, when stores and the load access dif-
latency is due to the pending load. When the latency is at ferent cache sets without aliasing, the load is executed in
the highest point, Ld_Blocks_Partial:Address_Alias drops 30 cycles, which is the typical timing for an L1 data cache
to zero, and it increments at each down step of the peak. This load including the rdtscp overhead. When the stores have
implies that the loosenet check does not resolve the rest of the different memory addresses with the same page offset, but
store dependencies whenever there is a 1 MB aliased address the load has a different offset, the load takes 100 cycles to
in the store buffer. execute. This shows that even memory addresses in the store
buffer having 4K Aliasing conditions with each other that
are totally unrelated to the speculative load create a memory
4.3 Evaluation bottleneck for the load. In the next scenario, 4K aliasing be-
In the previous experiment, the execution time of the load tween the load and all stores, the average load time is about
operation that is delayed by 1 MB aliasing decreases gradually 200 cycles. While the aforementioned 4K aliasing scenarios
in each iteration (Figure 6). The number of steps to reach the may leak cross domain information about memory accesses
normal execution time is consistent on the same processor. 4 Weuse rdtscp for Intel and AMD processors and the clock_gettime
When the first store in the window loop accesses a memory for ARM processors to perform the time measurements.

USENIX Association 28th USENIX Security Symposium 627

 1500
1

1000
Cycle 15

500
22

0
0 100 200 300 400 500 600 700 800 900 1000
Page Number

Figure 6: Step-wise peaks with 22 steps and a high latency can be observed on some of the pages (Core i7-8650U processor).

Every time the counter resets to zero, the next iteration of the
load will be blocked to be checked against the store buffer
entries. Mispredictions result in performance overhead due to
pipeline flushes. To avoid repeated mispredictions, a watch-
dog mechanism monitors the success rate of the prediction,
and it can temporarily disable the memory disambiguator.
The predictor of the memory disambiguator should go into
a stable state after the first few iterations, since the mem-
ory load is always truly independent of any aliased store.
Hence the saturating counter for the target speculative load
address passes the threshold, and it never resets due to a false
Figure 7: Histogram of the measurement for the speculative prediction. As a result, the memory disambiguator should
load with various store addresses. Load will be fast, 30 cy- always fetch the data into the cache without any access to the
cles, without any dependency. If there exists 4K aliasing only store buffer. However, since the memory disambiguation per-
between the stores, the average is 100. The average is 200 forms speculation, the dependency resolution at some point
when there is 4K aliasing of load and stores. The 1 MB verifies the prediction. The misprediction watchdog is also
aliasing has a distinctive high latency. supposed to only disable the memory disambiguator when
the misprediction rate is high, but in this case we should have
a high prediction rate. Accordingly, the observed leakage oc-
( Section 7), the most interesting scenario is the 1 MB aliasing curs after the disambiguation and during the last stages of
which takes more than 1200 cycles for the highest point in dependency resolution, i.e., the memory disambiguator only
the peak. For simplicity, we refer to the 1 MB aliased address performs prediction on the 4K aliasing at the initial loosenet
as aliased address, in the rest of the paper. check, and it cannot protect the pipeline from 1 MB aliasing
that appears at a later stage.
4.4 Discussion
4.4.1 The Curious Case of Memory Disambiguation
4.4.2 Hyperthreading Effect
The processor uses an additional speculative engine, called
the memory disambiguator [10, 32], to predict memory false Similar to the 4K Aliasing [40, 49], we empirically test
dependencies and reduce the chance of their occurrences. The whether the 1 MB aliasing can be used as a covert/side chan-
main idea is to predict if a load is independent of preceding nel through logical processors. Our observation shows that
stores and proceed with the execution of the load by ignor- when we run our experiments on two logical processors on
ing the store buffer. The predictor uses a hash table that is the same physical core, the number of steps in the peaks is
indexed with the address of the load, and each entry of the exactly halved. This matches the description by Intel [24]
hash table has a saturating counter. If the pre-commitment where it is stated that the store buffer is split between the
dependency resolution does not detect false dependencies, logical processors. As a result, the 1 MB aliasing effect is not
the counter is incremented, otherwise it will be reset to zero. visible and exploitable across logical cores. [31] suggests
After multiple successful executions of the same load instruc- that loosenet checks mask out the stores on the opposite
tion, the predictor assumes that the load is safe to execute. thread.

628 28th USENIX Security Symposium USENIX Association

 50
address is picked as a witness t and tested against a
45
candidate set C. If t is not evicted by C, it is added to
C and a new witness will be picked. As soon as t gets
Timer Value

40 evicted by C, C forms an eviction set for t.

35 • contract: Addresses are subsequently removed from the

eviction set. If the set still evicts t, the next address is
30 removed. If it does not evict t anymore, the removed
address is added back to the eviction set. At the end of
25
0 50 100 150 200 this phase, we have a minimal eviction set of the size of
Page Number the set associativity.

Figure 8: Reverse engineering physical page mappings in • collect: All addresses mapping to the already found evic-
JavaScript. The markers point to addresses having same 20 tion set are removed from P by testing if they are evicted
bits of physical addresses being part of the same eviction set. by the found set. After finding 128 initial cache sets, this
approach utilizes the linearity property of the cache: For
each found eviction set, the bits 6-11 are enumerated
5 S POILER from JavaScript instead. This provides 63 more eviction sets for each
found set, leading to full cache coverage.
Microarchitectural attacks from JavaScript have a high impact
as drive-by attacks in the browser can be accomplished with- We test this approach on an Intel Core i7-4770 with four
out any privilege or physical proximity. In such attacks, co- physical cores and a shared 8MB 16-way L3 cache with
location is automatically granted by the fact that the browser Chromium 68.0.3440.106, Firefox 62 and Firefox Developer
loads a website with malicious embedded JavaScript code. Edition 63. The approach yields an 80% accuracy rate to find
The browsers provide a sandbox where some instructions like all 8192 eviction sets when starting with a pool of 4096 pages.
clflush and prefetch and file systems such as procfs are The entire eviction set creation process takes an average of
inaccessible, limiting the opportunity for attack. Genkin et 46 s. We improve the algorithm by 1) using the addresses
al. [14] showed that side-channel attacks inside a browser removed from the eviction set in the contract phase as a new
can be performed more efficiently and with greater porta- candidate set and 2) removing more than one address at a time
bility through the use of [Link], WebAssembly from the eviction set during the contract phase. The improved
introduces an additional abstraction layer, i.e. it emulates eviction set creation process takes 35 s on average.
a 32-bit environment that translates the internal addresses
to virtual addresses of the host process (the browser). We- 5.1.1 Evaluation
bAssembly only uses addresses of the emulated environment
The probability of finding a congruent address is P(C) =
and similar to JavaScript, it does not have direct access to
2γ−c−s , where c is the number of bits determining the cache
the virtual addresses. Using S POILER from JavaScript opens
set, γ is the number of bits attackers know, and s is the num-
the opportunity to puncture these abstraction layers and to
ber of slices [56]. Since S POILER allows us to control γ ≥ c
obtain physical address information directly. Figure 8 shows
bits, we are only left with uncertainty about a few address
the address search in JavaScript using S POILER. Compared
bits that influence the slice selection algorithm [26]. In the-
to native implementations, we replace the rdtscp measure-
ory, the eviction set search is sped up by a factor of 4096
ment with a timer based on a shared array buffer [19]. We
by using aliased addresses in the pool, since on average one
cannot use any fence instruction such as lfence, and as a
of 28 instead of one of 220 addresses is an aliased address.
result, there remains some negligible noise in the JavaScript
Additionally, the address pool is much smaller, where 115
implementation. However, the aliased addresses can still be
addresses are enough to find all the eviction sets. In native
clearly seen, and we can use this information to improve the
code, the overhead involved in finding the aliased addresses
state-of-the art eviction set creation for both Rowhammer and
is negligible, less than a second in our experiments. However,
cache attacks.
in JavaScript, due to the noise, it takes 9s for finding aliased
addresses and then 3s for eviction set as compared to the base-
5.1 Efficient Eviction Set Finding line of 46s for classic method in Table 2. Success rate however
We use the algorithm proposed in [14]. It is a slight improve- is 100% with S POILER as compared to 80% for the classic
ment to the former state-of-the-art brute force method [42] method. Besides, success rate of the classical method can be
and consists of three phases: affected by the availability and consumption of memory on
the system.
• expand: A large pool of addresses P is allocated with the From each aliased address pool, 4 eviction sets can be found
last twelve bits of all addresses being zero. A random (corresponding to the 4 slices which are the only unknown

USENIX Association 28th USENIX Security Symposium 629

 Algorithm R ttotal tAAS tESS Success System Model DRAM Configuration # of Bits
Classic [42] 3 46s - 100% 80% Dell XPS-L702x 1 x (4GB 2Rx8) 21
Improved [14] 3 35s - 100% 80% (Sandy Bridge) 2 x (4GB 2Rx8) 22
AA (ours) 10 10s 54% 46% 67% Dell Inspiron-580 1 x (2GB 2Rx8) (b) 21
AA (ours) 20 12s 75% 25% 100% (Nehalem) 2 x (2GB 2Rx8) (c) 22
4 x (2GB 2Rx8) (d) 23
Table 2: Comparison of different eviction set finding algo-
Dell Optiplex-7010 1 x (2GB 1Rx8) (a) 19
rithms on an Intel Core i7-4770. Classic is the method from
(Ivy Bridge) 2 x (2GB 1Rx8) 20
[42], improved is the same method with slight improvement,
1 x (4GB 2Rx8) (e) 21
Aliased Address (AA) uses S POILER. tAAS is the time percent-
2 x (4GB 2Rx8) 22
age used for finding aliased addresses. tESS is the time per-
centage for finding eviction sets. R is the number of Rounds. Table 3: Reverse engineering the DRAM memory mappings
using DRAMA tool, # of Bits represents the number of physi-
cal address bits used for the bank, rank and channel [45].
part in the mapping). These can be enumerated again to form
63 more eviction sets since we still kept the bits 6-11 fixed. To
accomplish full cache coverage, the aliased address pool has 6.1 DRAM Bank Co-location
to be constructed 32 times. The S POILER variant for finding
eviction sets is more susceptible to system noise, which is why DRAMA [45] reverse engineered the memory controller map-
it needs more repetitions i.e. R rounds to get reliable values. ping. This requires elevated privileges to access physical ad-
On the other hand, it is less prone to values deviating largely dresses from the pagemap file. The authors have suggested
from the mean, which is a problem in the classic eviction that prefetch side-channel attacks [17] may be used to gain
set creation algorithm. The classic method does not succeed physical address information instead. S POILER is an alterna-
about one out of five times in our experiments, as shown in tive way to obtain partial address information and is still fea-
Table 2. The unsuccessful attempts occur due to aborts if the sible when the prefetch instruction is not available, e.g. in
algorithm takes much longer than statistically expected. As a JavaScript. In our approach, we use S POILER to detect aliased
result, S POILER can be incorporated in an end-to-end attack virtual memory addresses where the 20 LSBs of the physical
such as drive-by key-extraction cache attacks by Genkin et addresses match. The memory controller uses these bits for
al. [14]. S POILER increases both speed and reliability of the mapping the physical addresses to the DRAM banks [45].
eviction set finding and therefore the entire attack. Even though the memory controller may use additional bits,
the majority of the bits are known using S POILER. An at-
tacker can directly hammer such aliased addresses to perform
a more efficient single-sided Rowhammer attack with a sig-
nificantly increased probability of hitting the same bank. As
shown in Table 3, we reverse engineer the DRAM mappings
6 Rowhammer Attack using S POILER
for different hardware configurations using the DRAMA tool,
and only a few bits of physical address entropy beyond the 20
To perform a Rowhammer attack, the adversary needs to ef- bits will remain unknown.
ficiently access DRAM rows adjacent to a victim row. In a To verify if our aliased virtual addresses co-locate on the
single-sided Rowhammer attack, only one row is activated same bank, we use the row conflict side channel as proposed
repeatedly to induce bit flips on one of the nearby rows. For in [13] (timings in the appendix, Section 10.2). We observe
this purpose, the attacker needs to make sure that multiple that whenever the number of physical address bits used by
virtual pages co-locate on the same bank. The probability of the memory controller to map data to physical memory is
co-locating on the same bank is low without the knowledge of equal to or less than 20, we always hit the same bank. For
physical addresses and their mapping to memory banks. In a each additional bit the memory controller uses, the probabil-
double-sided Rowhammer attack, the attacker tries to access ity of hitting the same bank is divided by 2 as there is one
two different rows n + 1 an n − 1 to induce bit flips in the more bit of entropy. In general, we can formulate that our
row n placed between them. While double-sided Rowham- probability p to hit the same bank is p = 1/2n , where n is
mer attacks induce bit flips faster due to the extra charge on the number of unknown physical address bits in the mapping.
the nearby cells of the victim row n, they further require ac- We experimentally verify the success rate for the setups listed
cess to contiguous memory pages. In this section, we show in Table 3, as depicted in Figure 9. In summary, S POILER
that S POILER can help boosting both single and double-sided drastically improves the efficiency of finding addresses map-
Rowhammer attacks by its additional 8-bit physical address ping to the same bank without administrative privilege or
information and resulting detection of contiguous memory. reverse engineering the memory controller mapping.

630 28th USENIX Security Symposium USENIX Association

 Cycles
600 1000

Cycles
400
200 500
(a) 19 bits used by memory controller, no unknown bits
0
106

Frame Numbers
Cycles

600
400 2
106
1.982468
200 1.982466

(b) 21 bits used by memory controller, 1 unknown bit 1.5

1.982464
5641 5642 5643 5644 5645

0 2000 4000 6000 8000 10000

Cycles

600 Page Numbers

400
200
(c) 22 bits used by memory controller, 2 unknown bits Figure 10: Relation between leakage peaks and the physical
600
page numbers. The dotted plot shows the leakage peaks from
Cycles

400 S POILER. The solid plot shows the decimal values of the phys-
200 ical frame numbers from the pagemap file. Once the peaks
0 20 40 60 80 100
Peak Number
in the dotted plot become regular, the solid plot is linearly
increasing, which shows contiguous memory allocation.
(d) 23 bits used by memory controller, 3 unknown bits

Figure 9: Bank co-location for various DRAM configurations 6.3 Double-Sided Rowhammer with S POILER
(a), (b), (c) & (d) from Table 3. The regularity of the peaks
shows that the allocated memory was contiguous, which is As double-sided Rowhammer attacks are based on the as-
coincidental. sumption that rows within a bank are contiguous, we mount a
practical double-sided Rowhammer attack on several DRAM
modules using S POILER without any root privileges. First,
6.2 Contiguous Memory we use S POILER to detect a suitable amount of contiguous
memory. If enough contiguous memory is available in the
system, S POILER finds it, otherwise a double-sided Rowham-
For a double-sided Rowhammer attack, we need to hammer mer attack is not feasible. In our experiments, we empirically
rows adjacent to the victim row in the same bank. This re- configure S POILER to detect 10 MB of contiguous memory.
quires detecting contiguous memory pages in the allocated Second, we apply the row conflict side channel only to the
memory, since the rows are written to the banks sequentially. located contiguous memory, and get a list of virtual addresses
Without contiguous memory, the banks will be filled randomly which are contiguously mapped within a bank. Finally, we
and we will not be able to locate neighboring rows. We show start performing a double-sided Rowhammer attack by se-
that an attacker can use S POILER to detect contiguous memory lecting 3 consecutive addresses from our list. While we have
using 1 MB aliasing peaks. For this purpose, we compare the demonstrated the bit flips in our own process, we can free that
physical frame numbers to the S POILER leakage for 10000 memory which can then be assigned to a victim process by
different virtual pages allocated using malloc. Figure 10 using previously known techniques like spraying and memory
shows the relation between 1 MB aliasing peaks and physical waylaying [16]. As the bit flips are highly reproducible, we
page frame numbers. When the distance between the peaks can again flip the same bits in the victim process to demon-
is random, the trend of frame numbers also change randomly. strate a full attack. Table 4 shows some of the DRAM modules
After around 5000 pages, we observe that the frame numbers susceptible to Rowhammer attack.
increase sequentially. The number of pages between the peaks
The native version of Rowhammer in this work is also ap-
remains constant at 256 where this distance comes from the 8
plicable in JavaScript. The JavaScript-only variant implemen-
bits of physical address leakage due to 1 MB aliasing.
tation of Rowhammer by Gruss et al. [18], named rowham-
We also compare the accuracy of obtaining contiguous mer.js5 , can be combined with S POILER to implement an
memory detected by S POILER by analyzing the actual physi- end-to-end attack. In the original [Link], 2MB huge
cal addresses from the pagemap file. By checking the differ- pages were assumed to get a contiguous chunk of physical
ence between physical page numbers for each detected virtual memory. With S POILER, this assumption is no longer required
page, we can determine the accuracy of our detection method: as explained in Section 6.3.
the success rate for finding contiguous memory is above 99% Figure 11 shows the number of hammers compared to the
disregarding the availability of the contiguous pages. For de- the amount of bit flips for configuration (e) in Table 3. We
tailed experiment on the availability of the contiguous pages,
see Section 10.3 in the appendix. 5 [Link]

USENIX Association 28th USENIX Security Symposium 631

 DRAM Model Architecture Flippy 20 nop

10
M378B5273DH0-CK0 Ivy Bridge X
0

Number of Steps
M378B5273DH0-CK0 Sandy Bridge X 0 500 1000 1500 2000 2500 3000 3500 4000
20 add
M378B5773DH0-CH9 Sandy Bridge X
10
M378B5173EB0-CK0 Sandy Bridge ×
0
NT2GC64B88G0NF-CG Sandy Bridge × 0 100 200 300 400 500 600 700 800 900 1000
KY996D-ELD Sandy Bridge × 20 leal

M378B5773DH0-CH9 Nehalem X 10

NT4GC64B8HG0NS-CG Sandy Bridge × 0

0 200 400 600 800 1000 1200 1400 1600 1800 2000
HMA41GS6AFR8N-TF Skylake × Number of Operations

Table 4: DRAM modules susceptible to double-sided

Rowhammer attack using S POILER. Figure 12: The depth of S POILER leakage with respect to
different instructions and execution units.
25
Amount of Bit Flips

20 2d, 6h 2d, 17h

1d, 19h timing and the load address can leak secrets [61]. Due to
15 1d, 9h the nature of S POILER, the victim should access the memory
10 while there are aliased addresses in the store buffer, i.e. if the
21hr, 40m

5 10h, 50m
stores are committed before the victim’s speculative load,
1h, 5m
there will be no dependency resolution hazard.
0
0 1 2 3 4 5 6 We first perform an analysis of the depth of the operations
Number of Hammers 108 that can be executed between the stores and the load to
investigate the viability of S POILER. In this experiment, we
Figure 11: Amount of bit flips increases with the increase in repeat a number of instructions between stores and the load
number of hammerings. The timings do not include the time that are free from memory operations. Figure 12 shows the
taken for reboots and 1 minute sleep time. number of stall steps due to the dependency hazard with the
added instructions. Although nop is not supposed to take any
cycle, adding 4000 nop will diffuse the timing latency. Then,
repeat this experiment 30 times for every measurement and we test add and leal, which use the Arithmetic Logic Unit
the results are then averaged out. On every experiment, the (ALU) and the Address Generation Unit (AGU), respectively.
system is rebooted using a script because once the memory Figure 12 shows that only 1000 adds can be executed be-
becomes fragmented, no more contiguous memory is avail- tween the stores and load before the S POILER effect is lost.
able. The number of bit flips increases with more number of Since each add typically takes about 1 cycle to execute, this
hammerings. Hammering for 500 million times is found to roughly gives a 1000 cycle depth for S POILER. Considering
be an optimal number for this DRAM configuration, as the the observed depth, we discuss potential attacks that can track
continuation of hammering is not increasing bit flips. the speculative load in the following two scenarios.

7 Tracking Speculative Loads With S POILER 7.1 S POILER Context Switch

Single-threaded attacks can be used to steal information from In this attack, we are interested in tracking a memory access in
other security contexts running before/after the attacker code the privileged kernel environment after a context switch. First,
on the same thread [8, 41]. Example scenarios are I) context we fill the store buffer with addresses that have the same page
switches between processes of different users, or II) between offset, and then execute a system call. During the execution
a user process and a kernel thread, and III) Intel Software of the system call, we expect to observe a delayed execution
Guard eXtensions (SGX) secure enclaves [41, 54]. In such at- if a secret load address has aliasing with the stores. We
tacks, the adversary puts the microarchitecture to a particular utilize S POILER to iterate over various virtual pages, thus
state, waits for the context switch and execution of the victim some of the pages have more noticeable latency due to the
thread, and then tries to observe the microarchitectural state 1 MB aliasing. We analyze multiple syscalls with various
after the victim’s execution. We propose an attack where the execution times. For instance, Figure 13 shows the execution
adversary 1) fills the store buffer with arbitrary addresses, 2) time for mincore. In the first experiment (red/1 MB Conflict),
issues the victim context switch and lets the victim perform a we fill the store buffer with addresses that have aliasing with
secret-dependent memory access, and 3) measures the execu- a memory load operation in the kernel code space. The 1 MB
tion time of the victim. Any correlation between the victim’s aliasing delay with 7 steps suggests that we can track the

632 28th USENIX Security Symposium USENIX Association

 1400 2000
1 MB Conflict
1200 No Conflict 1800
No Store
1000
1600
Cycle

800

Cycle
1400
600
1200
400

200 1000
0 50 100 150 200 250 300
Page Number 800
200 300 400 500 600 700 800 900 1000
Page Number
Figure 13: Execution time of mincore system call. When a
kernel load address has aliasing with the attacker’s stores Figure 14: The effect of S POILER on TLB flush. The execu-
(red/1MB Conflict), the step-wise delay will appear. These tion cycle always increases for 4 kB aliased addresses, except
timings are measured with Kernel Page Table Isolation dis- for some of the virtual pages inside in the store buffer where
abled. we observe step-wise hills.

address of a kernel memory load by the knowledge of our relation due to the speculative load. As a result, we can not
arbitrary filled store addresses. The blue (No Conflict) line use S POILER to track memory accesses inside an enclave.
shows the timing when there is no aliasing between the target Further exploration of the root cause of the TLB flush effect
memory load and the attackers store. Surprisingly, only by can be carried out as a future work.
filling the store buffer, the system call executes much slower:
the normal execution time for mincore should be around
250 cycles (cyan/No Store). This proof of concept shows 8 Mitigations
that S POILER can be used to leak information from more
privileged contexts, however this is limited only to loads that
appear at the beginning of the next context. Software Mitigations The attack exploits the fact that when
there is a load instruction after a number of store instruc-
tions, the physical address conflict causes a high timing be-
7.2 Negative Result: S POILER SGX havior. This happens because of the speculatively executed
In this experiment, we try to combine S POILER with the load before all the stores are finished executing. There is
CacheZoom [41] approach to create a novel single-threaded no software mitigation that can completely erase this prob-
side-channel attack against SGX enclaves with high temporal lem. While the timing behavior can be removed by inserting
and spatial resolution (4-byte) [40]. We use SGX-STEP [53] store fences between the loads and stores, this cannot be
to precisely interrupt every single instruction. Nemesis [54] enforced to the user’s code space, i.e., the user can always
shows that the interrupt handler context switch time is depen- leak the physical address information. Another yet less robust
dent on the execution time of the currently running instruction. approach is to execute other instructions between the loads
On our test platform, Core i7-8650U, each context switch on and stores to decrease the depth of the attack. However,
an enclave takes about 12000 cycles to execute. If we fill both of the approaches are only applicable to defend against
the store buffer with memory addresses that match the page attacks such as the one described in Section 7.
offset of a load inside the enclave in the interrupt handler, As for most attacks on JavaScript, removing accurate timers
the context switch timing is increased to about 13500 cycles. from the browser would be effective against S POILER. Indeed,
While we cannot observe any correlation between the matched some timers have been removed or distorted by jitters as a
4 kB or 1 MB aliased addresses, we do see unexpected peri- response to attacks [35]. There is however a wide range of
odic downward peaks with a similar step-wise behavior as timers with varying precision available, and removing all of
S POILER(Figure 14). We later reproduce a similar behavior them seems impractical [13, 46].
by running S POILER before an ioctl routine that flushes When it is not possible to mitigate the microarchitectural
the TLB on each call. Intel SGX also performs an implicit attacks, developers can use dynamic tools to at least de-
TLB flush during each context switch. We can thus infer that tect the presence of such leakage [6, 9, 63]. One of the dy-
the downward peaks occur due to the TLB flush, especially namic approaches is gained by monitoring hardware perfor-
since the addresses for the downward peaks do not have any mance counters in real-time. As explained in Section 4.1, two
address correlation with the load address. This suggests that of the counters Ld_Blocks_Partial:Address_Alias and
the TLB flush operation itself is affected by S POILER. This Cycle_Activity:Stalls_Ldm_Pending have high correla-
effect eliminates the opportunity to observe any potential cor- tions with the leakage.

USENIX Association 28th USENIX Security Symposium 633

Hardware Mitigations The hardware design for the mem- This work is supported by U.S. Department of State, Bu-
ory disambiguator may be revised to prevent such physical reau of Educational and Cultural Affairs’ Fulbright Program
address leakage, but modifying the speculative behavior may and National Science Foundation under grant CNS-1618837
cause performance impacts. For instance, partial address com- and CNS-1814406. We also thank Cloudflare for their gener-
parison was a design choice for performance. Full address ous gift to support our research.
comparison may address this vulnerability, but will also im-
pact performance. Moreover, hardware patches are difficult to References
be applied to legacy systems and take years to be deployed.
[1] Jeffery M Abramson, Haitham Akkary, Andrew F Glew, Glenn J Hinton,
Kris G Konigsfeld, and Paul D Madland. Method and apparatus for
9 Conclusion performing a store operation, April 23 2002. US Patent 6,378,062.
[2] Jeffrey M Abramson, Haitham Akkary, Andrew F Glew, Glenn J Hinton,
We introduced S POILER, a novel approach for gaining phys- Kris G Konigsfeld, Paul D Madland, David B Papworth, and Michael A
ical address information by exploiting a new information Fetterman. Method and apparatus for dispatching and executing a load
operation to memory, February 10 1998. US Patent 5,717,882.
leakage due to speculative execution. To exploit the leakage,
we used the speculative load behavior after jamming the store [3] Zelalem Birhanu Aweke, Salessawi Ferede Yitbarek, Rui Qiao, Reetu-
parna Das, Matthew Hicks, Yossi Oren, and Todd Austin. Anvil:
buffer. S POILER can be executed from user space and requires Software-based protection against next-generation rowhammer attacks.
no special privileges. We exploited the leakage to reveal in- ACM SIGPLAN Notices, 51(4):743–755, 2016.
formation on the 8 least significant bits of the physical page [4] Naomi Benger, Joop van de Pol, Nigel P. Smart, and Yuval Yarom.
number, which are critical for many microarchitectural at- “ooh aah... just a little bit” : A small amount of side channel can go a
tacks such as Rowhammer and cache attacks. We analyzed long way. In Cryptographic Hardware and Embedded Systems – CHES
the causes of the discovered leakage in detail and showed how 2014, pages 75–92, Berlin, Heidelberg, 2014. Springer.
to exploit it to extract physical address information. [5] Daniel J Bernstein. Cache-timing attacks on aes, 2005.
Further, we showed the impact of S POILER by performing [6] Samira Briongos, Gorka Irazoqui, Pedro Malagón, and Thomas Eisen-
a highly targeted Rowhammer attack in a native user-level barth. Cacheshield: Detecting cache attacks through self-observation.
In Proceedings of the Eighth ACM Conference on Data and Application
environment. We further demonstrated the applicability of Security and Privacy, CODASPY ’18, pages 224–235, New York, NY,
S POILER in sandboxed environments by constructing effi- USA, 2018. ACM.
cient eviction sets from JavaScript, an extremely restrictive [7] Claudio Canella, Jo Van Bulck, Michael Schwarz, Moritz Lipp, Ben-
environment that usually does not grant any access to physical jamin von Berg, Philipp Ortner, Frank Piessens, Dmitry Evtyushkin,
addresses. Gaining even partial knowledge of the physical and Daniel Gruss. A systematic evaluation of transient execution at-
address will make new attack targets feasible in browsers even tacks and defenses. arXiv preprint arXiv:1811.05441, 2018.
though JavaScript-enabled attacks are known to be difficult to [8] Guoxing Chen, Sanchuan Chen, Yuan Xiao, Yinqian Zhang, Zhiqiang
Lin, and Ten H Lai. Sgxpectre attacks: Stealing intel secrets from sgx
realize in practice due to the limited nature of the JavaScript
enclaves via speculative execution. arXiv preprint arXiv:1802.09085,
environment. Broadly put, the leakage described in this paper 2018.
will enable attackers to perform existing attacks more effi- [9] Marco Chiappetta, Erkay Savas, and Cemal Yilmaz. Real time detec-
ciently, or to devise new attacks using the novel knowledge. tion of cache-based side-channel attacks using hardware performance
The source code for S POILER is available on GitHub6 . counters. Applied Soft Computing, 49:1162–1174, 2016.

Responsible Disclosure We informed the Intel Product Secu- [10] Jack Doweck. Inside intel R core microarchitecture. In Hot Chips 18
Symposium (HCS), 2006 IEEE, pages 1–35. IEEE, 2006.
rity Incident Response Team (iPSIRT) of our findings. iPSIRT
[11] Dmitry Evtyushkin, Dmitry Ponomarev, and Nael Abu-Ghazaleh. Jump
thanked for reporting the issue and for the coordinated dis-
over aslr: Attacking branch predictors to bypass aslr. In The 49th
closure. iPSIRT then released the public advisory and CVE. Annual IEEE/ACM International Symposium on Microarchitecture,
Here is the time line for the responsible disclosure: MICRO-49, pages 40:1–40:13, Piscataway, NJ, USA, 2016. IEEE Press.
[12] Agner Fog. The microarchitecture of intel, amd and via cpus: An
• 12/01/2018: We informed our findings to iPSIRT. optimization guide for assembly programmers and compiler makers.
• 12/03/2018: iPSIRT acknowledged the receipt. Copenhagen University College of Engineering, pages 02–29, 2012.
• 04/09/2019: iPSIRT released public advisory (INTEL- [13] Pietro Frigo, Cristiano Giuffrida, Herbert Bos, and Kaveh Razavi.
SA-00238) and assigned CVE (CVE-2019-0162). Grand pwning unit: Accelerating microarchitectural attacks with the
gpu. In Grand Pwning Unit: Accelerating Microarchitectural Attacks
with the GPU, page 0, Washington, DC, USA, 2018. IEEE, IEEE Com-
Acknowledgments puter Society.
[14] Daniel Genkin, Lev Pachmanov, Eran Tromer, and Yuval Yarom. Drive-
We thank Yuval Yarom, our shepherd Eric Wustrow and the by key-extraction cache attacks from portable code. In International
anonymous reviewers for their valuable comments for improv- Conference on Applied Cryptography and Network Security, pages
83–102. Springer, 2018.
ing the quality of this paper.
[15] Mel Gorman. Understanding the Linux Virtual Memory Manager.
6 [Link] Prentice Hall, London, 2004.

634 28th USENIX Security Symposium USENIX Association

[16] Daniel Gruss, Moritz Lipp, Michael Schwarz, Daniel Genkin, Jonas [33] Moritz Lipp, Daniel Gruss, Michael Schwarz, David Bidner, Clémen-
Juffinger, Sioli O’Connell, Wolfgang Schoechl, and Yuval Yarom. An- tine Maurice, and Stefan Mangard. Practical keystroke timing attacks
other flip in the wall of rowhammer defenses. In 2018 IEEE Symposium in sandboxed javascript. In Computer Security – ESORICS 2017, pages
on Security and Privacy (SP), pages 245–261. IEEE, 2018. 191–209. Springer, 2017.
[17] Daniel Gruss, Clémentine Maurice, Anders Fogh, Moritz Lipp, and [34] Moritz Lipp, Daniel Gruss, Raphael Spreitzer, Clémentine Maurice,
Stefan Mangard. Prefetch side-channel attacks: Bypassing smap and and Stefan Mangard. Armageddon: Cache attacks on mobile devices.
kernel aslr. In Proceedings of the 2016 ACM SIGSAC Conference on In 25th USENIX Security Symposium (USENIX Security 16), pages
Computer and Communications Security, CCS ’16, pages 368–379, 549–564, Austin, TX, 2016. USENIX Association.
New York, NY, USA, 2016. ACM. [35] Moritz Lipp, Michael Schwarz, Daniel Gruss, Thomas Prescher, Werner
[18] Daniel Gruss, Clémentine Maurice, and Stefan Mangard. Rowham- Haas, Anders Fogh, Jann Horn, Stefan Mangard, Paul Kocher, Daniel
[Link]: A remote software-induced fault attack in javascript. In Detec- Genkin, Yuval Yarom, and Mike Hamburg. Meltdown: Reading ker-
tion of Intrusions and Malware, and Vulnerability Assessment, pages nel memory from user space. In 27th USENIX Security Symposium
300–321. Springer, 2016. (USENIX Security 18), Baltimore, MD, 2018. USENIX Association.
[19] Lars T Hansen. Shared memory: Side-channel information leaks, 2016. [36] Fangfei Liu, Yuval Yarom, Qian Ge, Gernot Heiser, and Ruby B. Lee.
Last-level cache side-channel attacks are practical. In Proceedings
[20] Sebastien Hily, Zhongying Zhang, and Per Hammarlund. Resolving of the 2015 IEEE Symposium on Security and Privacy, SP ’15, pages
false dependencies of speculative load instructions, October 13 2009. 605–622, Washington, DC, USA, 2015. IEEE Computer Society.
US Patent 7,603,527.
[37] Errol L. Lloyd and Michael C. Loui. On the worst case performance of
[21] Jann Horn. speculative execution, variant 4: speculative store bypass, buddy systems. Acta Informatica, 22(4):451–473, Oct 1985.
2018.
[38] Giorgi Maisuradze and Christian Rossow. ret2spec: Speculative ex-
[22] Ralf Hund, Carsten Willems, and Thorsten Holz. Practical timing side ecution using return stack buffers. In Proceedings of the 2018 ACM
channel attacks against kernel space aslr. In 2013 IEEE Symposium on SIGSAC Conference on Computer and Communications Security, pages
Security and Privacy, pages 191–205. IEEE, 2013. 2109–2122. ACM, 2018.
[23] Mehmet Sinan İnci, Berk Gulmezoglu, Gorka Irazoqui, Thomas Eisen- [39] Intel 64 Architecture Memory Ordering White Paper. [Link]
barth, and Berk Sunar. Cache attacks enable bulk key recovery on the [Link]/~410-f10/doc/Intel_Reordering_318147.pdf, 2008.
cloud. In Cryptographic Hardware and Embedded Systems – CHES Accessed: 2018-11-26.
2016, pages 368–388, Berlin, Heidelberg, 2016. Springer.
[40] Ahmad Moghimi, Thomas Eisenbarth, and Berk Sunar. Memjam: A
[24] Intel. Intel R 64 and IA-32 Architectures Optimization Reference false dependency attack against constant-time crypto implementations
Manual. in SGX. In Topics in Cryptology - CT-RSA 2018 - The Cryptographers’
[25] Gorka Irazoqui, Thomas Eisenbarth, and Berk Sunar. S$a: A shared Track at the RSA Conference 2018, San Francisco, CA, USA, April
cache attack that works across cores and defies vm sandboxing – and 16-20, 2018, Proceedings, pages 21–44, 2018.
its application to aes. In Proceedings of the 2015 IEEE Symposium on [41] Ahmad Moghimi, Gorka Irazoqui, and Thomas Eisenbarth. Cachezoom:
Security and Privacy, SP ’15, pages 591–604, Washington, DC, USA, How sgx amplifies the power of cache attacks. In Cryptographic
2015. IEEE Computer Society. Hardware and Embedded Systems – CHES 2017, pages 69–90. Springer,
2017.
[26] Gorka Irazoqui, Thomas Eisenbarth, and Berk Sunar. Systematic re-
verse engineering of cache slice selection in intel processors. In 2015 [42] Yossef Oren, Vasileios P. Kemerlis, Simha Sethumadhavan, and An-
Euromicro Conference on Digital System Design (DSD), pages 629– gelos D. Keromytis. The spy in the sandbox: Practical cache attacks
636. IEEE, 2015. in javascript and their implications. In Proceedings of the 22Nd ACM
SIGSAC Conference on Computer and Communications Security, CCS
[27] Yeongjin Jang, Sangho Lee, and Taesoo Kim. Breaking kernel address
’15, pages 1406–1418, New York, NY, USA, 2015. ACM.
space layout randomization with intel tsx. In Proceedings of the 2016
ACM SIGSAC Conference on Computer and Communications Security, [43] Colin Percival. Cache missing for fun and profit, 2005.
pages 380–392. ACM, 2016. [44] Cesar Pereida García, Billy Bob Brumley, and Yuval Yarom. "make sure
[28] Vasileios P Kemerlis, Michalis Polychronakis, and Angelos D dsa signing exponentiations really are constant-time". In Proceedings of
Keromytis. ret2dir: Rethinking kernel isolation. In USENIX Secu- the 2016 ACM SIGSAC Conference on Computer and Communications
rity Symposium, pages 957–972, 2014. Security, CCS ’16, pages 1639–1650, New York, NY, USA, 2016. ACM.
[29] Yoongu Kim, Ross Daly, Jeremie Kim, Chris Fallin, Ji Hye Lee, [45] Peter Pessl, Daniel Gruss, Clémentine Maurice, Michael Schwarz, and
Donghyuk Lee, Chris Wilkerson, Konrad Lai, and Onur Mutlu. Flip- Stefan Mangard. Drama: Exploiting dram addressing for cross-cpu
ping bits in memory without accessing them: An experimental study of attacks. In USENIX Security Symposium, pages 565–581, 2016.
dram disturbance errors. In ACM SIGARCH Computer Architecture [46] Michael Schwarz, Clémentine Maurice, Daniel Gruss, and Stefan Man-
News, volume 42, pages 361–372. IEEE Press, 2014. gard. Fantastic timers and where to find them: high-resolution mi-
[30] Paul Kocher, Daniel Genkin, Daniel Gruss, Werner Haas, Mike croarchitectural attacks in javascript. In International Conference on
Hamburg, Moritz Lipp, Stefan Mangard, Thomas Prescher, Michael Financial Cryptography and Data Security, pages 247–267. Springer,
Schwarz, and Yuval Yarom. Spectre attacks: Exploiting speculative 2017.
execution. ArXiv e-prints, January 2018. [47] Mark Seaborn and Thomas Dullien. Exploiting the dram rowhammer
[31] Steffen Kosinski, Fernando Latorre, Niranjan Cooray, Stanislav bug to gain kernel privileges. Black Hat, 15, 2015.
Shwartsman, Ethan Kalifon, Varun Mohandru, Pedro Lopez, Tom [48] Julian Stecklina and Thomas Prescher. Lazyfp: Leaking fpu reg-
Aviram-Rosenfeld, Jaroslav Topp, Li-Gao Zei, et al. Store forwarding ister state using microarchitectural side-channels. arXiv preprint
for data caches, November 29 2016. US Patent 9,507,725. arXiv:1806.07480, 2018.
[32] Evgeni Krimer, Guillermo Savransky, Idan Mondjak, and Jacob [49] Dean Sullivan, Orlando Arias, Travis Meade, and Yier Jin. Microar-
Doweck. Counter-based memory disambiguation techniques for se- chitectural minefields: 4k-aliasing covert channel and multi-tenant de-
lectively predicting load/store conflicts, October 1 2013. US Patent tection in iaas clouds. In Network and Distributed Systems Security
8,549,263. (NDSS) Symposium. The Internet Society, 2018.

USENIX Association 28th USENIX Security Symposium 635

[50] Andrei Tatar, Radhesh Krishnan, Elias Athanasopoulos, Cristiano Giuf- 10 Appendix
frida, Herbert Bos, and Kaveh Razavi. Throwhammer: Rowhammer
attacks over the network and defenses. In 2018 USENIX Annual Tech-
nical Conference (USENIX ATC 18), Boston, MA, 2018. USENIX 10.1 Tested Hardware Performance Counters
Association.
[51] Dan Terpstra, Heike Jagode, Haihang You, and Jack Dongarra. Col-
lecting performance data with papi-c. In Tools for High Performance Counters Correlation
Computing 2009, pages 157–173. Springer, 2010.
UNHALTED_CORE_CYCLES 0.3077
[52] Jo Van Bulck, Marina Minkin, Ofir Weisse, Daniel Genkin, Baris UNHALTED_REFERENCE_CYCLES 0.1527
Kasikci, Frank Piessens, Mark Silberstein, Thomas F Wenisch, Yu-
INSTRUCTION_RETIRED 0.2718
val Yarom, and Raoul Strackx. Foreshadow: Extracting the keys to the
intel sgx kingdom with transient out-of-order execution. In Proceed- INSTRUCTIONS_RETIRED 0.2827
ings of the 27th USENIX Security Symposium. USENIX Association, BRANCH_INSTRUCTIONS_RETIRED 0.3143
2018. MISPREDICTED_BRANCH_RETIRED 0.0872
[53] Jo Van Bulck, Frank Piessens, and Raoul Strackx. Sgx-step: A practical CYCLE_ACTIVITY:CYCLES_L2_PENDING -0.0234
attack framework for precise enclave execution control. In Proceed-
CYCLE_ACTIVITY:STALLS_LDM_PENDING 0.9819
ings of the 2Nd Workshop on System Software for Trusted Execution,
SysTEX’17, pages 4:1–4:6, New York, NY, USA, 2017. ACM. CYCLE_ACTIVITY:CYCLES_NO_EXECUTE 0.2317
RESOURCE_STALLS:ROB 0
[54] Jo Van Bulck, Frank Piessens, and Raoul Strackx. Nemesis: Studying
microarchitectural timing leaks in rudimentary cpu interrupt logic. In RESOURCE_STALLS:SB -0.0506
Proceedings of the 2018 ACM SIGSAC Conference on Computer and RESOURCE_STALLS:RS -0.0044
Communications Security, pages 178–195. ACM, 2018. LD_BLOCKS_PARTIAL:ADDRESS_ALIAS -0.9511
[55] Victor Van Der Veen, Yanick Fratantonio, Martina Lindorfer, Daniel IDQ_UOPS_NOT_DELIVERED -0.1455
Gruss, Clémentine Maurice, Giovanni Vigna, Herbert Bos, Kaveh
IDQ:ALL_DSB_CYCLES_ANY_UOPS 0.0332
Razavi, and Cristiano Giuffrida. Drammer: Deterministic rowham-
mer attacks on mobile platforms. In Proceedings of the 2016 ACM ILD_STALL:IQ_FULL 0.1021
SIGSAC conference on computer and communications security, pages ITLB_MISSES:MISS_CAUSES_A_WALK 0
1675–1689. ACM, 2016. TLB_FLUSH:STLB_THREAD 0
[56] Pepe Vila, Boris Köpf, and José Francisco Morales. Theory and practice ICACHE:MISSES 0
of finding eviction sets. arXiv preprint arXiv:1810.01497, 2018. ICACHE:IFETCH_STALL 0
[57] WikiChip. Ivy Bridge - Microarchitectures - Intel. https: L1D:REPLACEMENT 0.3801
//[Link]/wiki/intel/microarchitectures/ivy_
L2_DEMAND_RQSTS:WB_HIT 0.2436
bridge_(client). Accessed: 2019-02-05.
LONGEST_LAT_CACHE:MISS 0.0633
[58] WikiChip. Kaby Lake - Microarchitectures - Intel. [Link]
CYCLE_ACTIVITY:CYCLES_L1D_PENDING -0.0080
[Link]/wiki/intel/microarchitectures/kaby_lake.
Accessed: 2019-02-05. LOCK_CYCLES:CACHE_LOCK_DURATION 0

[59] WikiChip. Skylake (client) - Microarchitectures - Intel. LOAD_HIT_PRE:SW_PF 0

[Link] LOAD_HIT_PRE:HW_PF 0
skylake_(client). Accessed: 2019-02-05. MACHINE_CLEARS:CYCLES 0
[60] Yuan Xiao, Xiaokuan Zhang, Yinqian Zhang, and Radu Teodorescu. OFFCORE_REQUESTS_BUFFER:SQ_FULL 0
One bit flips, one cloud flops: Cross-vm row hammer attacks and privi- OFFCORE_REQUESTS:DEMAND_DATA_RD 0.1765
lege escalation. In USENIX Security Symposium, pages 19–35, 2016.
[61] Yuval Yarom, Daniel Genkin, and Nadia Heninger. CacheBleed: a tim- Table 5: Counters profiled for correlation test
ing attack on OpenSSL constant-time RSA. Journal of Cryptographic
Engineering, 7(2):99–112, 2017.
[62] Bennet Yee, David Sehr, Gregory Dardyk, J Bradley Chen, Robert Muth,
Tavis Ormandy, Shiki Okasaka, Neha Narula, and Nicholas Fullagar.
Native client: A sandbox for portable, untrusted x86 native code. In 10.2 Row conflict Side Channel
Security and Privacy, 2009 30th IEEE Symposium on, pages 79–93.
IEEE, 2009.
The row conflict side channel retrieves the timing information
[63] Tianwei Zhang, Yinqian Zhang, and Ruby B. Lee. Cloudradar: A real-
time side-channel attack detection system in clouds. In Research in
of the CPU while doing direct accesses (using clflush) from
Attacks, Intrusions, and Defenses, pages 118–140. Springer, 2016. the DRAM. A higher timing indicates that the two addresses
are mapped to the same bank in the DRAM because reading
an address from the same bank forces the row buffer to copy
the previous contents back to the original row and then load
the newly accessed data into the row buffer. Whereas, a low
timings indicates that two addresses are not in the same bank
(not sharing the same row buffer) and are loaded into separate
row buffers. Figure 15 shows a wide gap (around 100 cycles)
between row hits and row conflicts.

636 28th USENIX Security Symposium USENIX Association

 gets like high-end servers where restarting is impractical.
The observed behavior can be explained by the binary
buddy allocator which is responsible for the physical address
allocation in the Linux OS [15]. This type of allocator is
known to fragment memory significantly under certain cir-
cumstances [37]. The Linux OS uses a SLAB/SLOB allocator
in order to circumvent the fragmentation problems. How-
ever, the allocator only serves the kernel directly. User space
memory therefore still suffers from the fragmentation that the
buddy allocator introduces. This also means that getting the
contiguous memory required for a double-sided Rowhammer
attack becomes more difficult if the system under attack has
been active for a while.
Figure 15: Timings for accessing the aliased virtual addresses
(random addresses where 20 LSB of the physical address 100

Contiguous Memory (%)

match). Row hits (orange/low timings) are clearly distinguish- 80
able from row conflicts (blue/high timings). 60

40

10.3 Memory Utilization and Contiguity 20 520KB Contiguous Memory from pagemap File
520KB Contiguous Memory from Leakage Peaks
The probability of obtaining contiguous memory depends on 0
20 30 40 50 60 70 80 90
memory utilization of the system. We conduct an experiment System Memory Consumption (%)
to examine the effect of memory utilization on availability
of contiguous memory. In this experiment, 1 GB memory
is allocated. During the experiment, the memory utilization Figure 16: Finding contiguous memory of 520 kB with in-
of the system is increased gradually from 20% to 90%. We creasing memory utilization. The overlap between the red
measure the probability of getting the contiguous memory and blue plot indicates the high accuracy of the contiguous
with two methods. The first one is checking the physical frame memory detection capability of S POILER as verified by the
numbers from pagemap file to look for 520 kB of contiguous pagemap file.
memory. The second method is using S POILER to find the 520
kB of contiguous memory. This 520 kB is required to get three
25
consecutive rows within a bank for a DRAM configuration 520KB Contiguous Memory from pagemap File
Contiguous Memory (%)

520KB Contiguous Memory from Leakage Peaks

having 256 kB row offset and 8 kB row size. 20

Figure 16 and Figure 17 show that when the memory has 15

been fragmented after intense memory usage, it gets more 10
difficult to allocate a contiguous chunk of memory. Even de-
5
creasing the memory usage does not help to get a contiguous
block of memory. Figure 17 depicts that after the memory 0
90 80 70 60 50 40 30 20
utilization has been decreased from 70% to 60% and so on, System Memory Consumption (%)
there is not enough contiguous memory to mount a success-
ful double-sided Rowhammer attack. Until the machine is
restarted, the memory remains fragmented which makes a Figure 17: Finding contiguous memory of 520 kB with de-
double-sided Rowhammer attack difficult, especially on tar- creasing memory utilization.

USENIX Association 28th USENIX Security Symposium 637