Jump Over ASLR:
Attacking Branch Predictors to Bypass ASLR
Dmitry Evtyushkin

Dmitry Ponomarev

Nael Abu-Ghazaleh

Department of Computer Science
State University of New Yorkat Binghamton
devtyushkin@cs.binghamton.edu

Department of Computer Science
State University of New Yorkat Binghamton
dima@cs.binghamton.edu

Computer Science andEngineering Department
University of California, Riverside
naelag@ucr.edu

Abstract—
Address Space Layout Randomization (ASLR) is a widelyused technique that protects systems against a range of attacks.
ASLR works by randomizing the offset of key program segments
in virtual memory, making it difficult for an attacker to derive
the addresses of specific code objects and consequently redirect
the control flow to this code. In this paper, we develop an attack
to derive kernel and user-level ASLR offset using a side-channel
attack on the branch target buffer (BTB). Our attack exploits theobservation that an adversary can create BTB collisions between
the branch instructions of the attacker process and either theuser-level victim process or on the kernel executing on its behalf.
These collisions, in turn, can impact the timing of the attacker’s
code, allowing the attacker to identify the locations of known
branch instructions in the address space of the victim process or
the kernel. We demonstrate that our attack can reliably recoverkernel ASLR in about 60 milliseconds when performed on a real
Haswell processor running a recent version of Linux. Finally, we
describe several possible protection mechanisms, both in softwareand in hardware.
Index Terms—Address Space Layout Randomization, Bypass,Side Channel, Timing Channel, Timing Attacks, Kernel Vulnerabilities, Exploit Mitigation.

I. I NTRODUCTION
Memory corruption attacks such as stack and heap overflows [1], [2] and format string attacks [3] can lead tocontrol hijacking and arbitrary code execution by the attackers.
Despite significant efforts to prevent such attacks [4], [5], [6],[7], [8], they remain a serious exploitable class of vulnerabilities present in many types of software. Since creating a
bug-free environment is practically impossible, systems areoften hardened using techniques that substantially reduce theprobability of a successful attack.
One such hardening technique is Address Space Layout
Randomization (ASLR). ASLR provides protection by randomizing positions of key program components in virtual
memory. The randomization targets code and data segments,
stack, heap and libraries. The purpose of ASLR is to make it
difficult, if not impossible, for the attacker to know the location
978-1-5090-3508-3/16/$31.00 c 2016 IEEEof specific code pages in the program’s address space. For
example, even if the attacker successfully hijacks the control
flow, it would be difficult to perform a meaningful returnoriented programming (ROP) [9], [10], [11] attack under
ASLR, because the addresses of ROP gadgets to inject on
the stack are not known due to randomization. Relying onbrute-force solutions to discover required gadget addresses
can cause the program to crash, or it can take prohibitively
long time [12], enabling detection by system software [13].
Discovering and exploiting other vulnerabilities that disclose
the randomization algorithm significantly complicates the attack [14]. Non-control-data attacks [15] require the attacker
to know locations of various data structures. Although ourattack directly recovers ASLR for the code segment only,
data segments are typically not decoupled from code segments [16]; thus a successful attack on code ASLR reveals thelocations of data structures. Today, ASLR-based defenses arewidely adopted in all major Operating Systems (OS), including
Linux [17], Windows [18] and OS X [19]. Smartphone system
software such as iOS [20] and Android [13] also use ASLR.
ASLR implementations across different operating systems
differ by the amount of entropy used and by the frequency atwhich memory addresses are randomized. These characteristics directly determine the resilience of ASLR implementations
to possible attacks. For example, 32-bit systems have a muchsmaller addressable space, limiting the amount of space thatcan be dedicated to randomization, making it possible to build
fast brute-force attacks [12]. The randomization frequency
can range from a single randomization at boot or compile
time to dynamic randomization during program execution.
More frequent re-randomization reduces the probability of a
successful attack.
Traditionally, ASLR has only been considered as a protection mechanism against remote attacks. As a result, and also
for performance reasons [21], some ASLR implementations
randomize positions of libraries only one time during thesystem boot. Consequently, all processes executed on a machine receive the same mappings of the libraries, thus making

return-to-libc [22], [23] or other code reuse attacks possible
within the same system. The presence of many high-privileged
processes in the system makes the attack surface large. For
example, on our experimental machine, an OS with only basic
services executes 30 and 80 root background processes inUbuntu 14.04 LTS and OS X El Capitan 10.11.2 respectively.
If one of these processes is subverted by an attacker, the entire
system becomes compromised with respect to ASLR.
All current operating systems supporting randomizations
implement variants of ASLR for both user and kernel-level address spaces. Kernel-level ASLR (KASLR) randomizes kernel
code segments and can stop attacks that require knowledge ofthe kernel address space layout (including ROP, jump-oriented
programming (JOP), return-to-libc, ret-2-user [24] and otherattacks). Unfortunately, current implementations of KASLR
are often criticized for incompleteness and insufficient entropy [25]. A small entropy is typically justified by the fact that
it is infeasible for an adversary to mount a brute-force attack
against KASLR. If the attacker guesses the randomization
incorrectly, the kernel typically crashes and the attack fails.
In this paper, we demonstrate a new attack that can recover
all random bits of the kernel addresses and reduce the entropyof user-level randomization by using side-channel informationfrom the Branch Target Buffer (BTB). Our attack only requires
the control of a user-level process and does not rely on
any explicit memory disclosures. The key insight that makes
the new BTB-based side-channel possible is that the BTB
collisions between two user-level processes, and between auser process and the kernel, can be created by the attacker ina controlled and robust manner. The collisions can be easily
detected by the attacker because they impact the timing of theattacker-controlled code. Identifying the BTB collisions allows
the attacker to determine the exact locations of known branch
instructions in the code segment of the kernel or of the victim
process, thus disclosing the ASLR offset.
Our attacks exploit two types of collisions in the BTB. The
first collision type, exploited to bypass KASLR, is between auser-level branch and a kernel-level branch - we call it crossdomain collisions, or CDC. CDC occurs because these two
branches, located at different virtual addresses, can map to
the same entry in the BTB with the same target address. The
reason is that the BTB addressing schemes in recent processors
ignore the upper-order bits of the address, thus trading offsome performance for lower design complexity. The second
type of BTB collisions is between two user-level branches thatbelong to two different applications. We call these collisions
same-domain collisions, or SDC. SDCs are used to attack
user-level ASLR, allowing one process to identify the ASLR
offset used in another. An SDC occurs when two branches,
one in each process, have the same virtual address and thesame target.
We demonstrate our attack on a real system with Haswell

CPU and a recent version of Linux kernel equipped with
ASLR. Since this new attack adds to the arsenal of a potential
adversary, we also discuss a number of possible softwareand hardware-supported mitigation mechanisms to thwart this
attack. The solutions range from further hardening the ASLR
implementations to reconsidering the hardware designs of the
BTB to avoid collisions.
In summary, this paper makes the following contributions:• We describe a new technique to bypass existing ASLR
schemes by exploiting a side-channel created throughshared BTB. We show how an adversary can createa robust side-channel between a user process and thekernel, as well as between two user processes in acontrolled manner.
• We show how the details of the BTB addressing scheme,
needed for creating a reliable BTB side channel, can bereverse-engineered.
• We show how the new BTB side-channel attack can beused to recover kernel and user-level ASLR in a fastand reliable fashion. We implement our attacks on a realsystem with Haswell CPU and recent Linux kernel andshow that kernel-level ASLR can be recovered in about
60 milliseconds.
• We propose several software and hardware countermeasures against the new attack and also place our attack inthe context of the related work.
II. T HREAT M ODEL AND A SSUMPTIONS
We consider two distinct attacks/threat models: one on
KASLR and one on user-level ASLR. In this section we
describe our assumptions about the underlying system and thecapabilities of the attacker in each case.
A. KASLR Attack
We assume that an attacker has control over a process
running on the target system with normal user privileges. We
refer to this process as the spy process. We further assume
that the kernel implements some form of KASLR and thatthe kernel’s code and module segments are randomly placed
during boot in accordance with the KASLR algorithm. The
attacker knows which bits of the address are randomized andwhich bits are fixed. Beyond that, the attacker does not haveany knowledge on how the random bits were generated. The
spy process can only execute normal user-level instructions,
including instructions for time measurement (such as rdtsc)
and perform regular interactions with the kernel throughsystem calls. We assume that the spy process cannot bruteforce the correct address. We do not assume any weaknesses
in KASLR implementation: in other words, randomized offset
values were generated using strong sources of entropy withno algorithmic weaknesses [26]. The goal of the attacker is torecover the address of a kernel routine, such as a system callhandler in virtual memory.

B. Attack on User Process ASLR
In this case, we assume that two user processes are present
in the system. The first process is a process that is thetarget of an attack typically because it runs as root or has
permissions to access sensitive data. We refer to this process
as the victim process. The other process is the spy process
and it is controlled by the attacker who seeks to recover
ASLR of the victim as a first step of further attacks on it.
We assume that the system supports ASLR and the victim iscompiled as a position-independent executable to fully benefit
from it. As a result, the segments in the process image are
randomly shifted in virtual memory. We assume that there are
no weaknesses in the ASLR implementation and the spy does
not have any means to directly obtain the randomized ASLR
offset, for example via a memory disclosure vulnerability. The
spy can only execute normal user-level instructions, including
instructions for time measurement. The spy can also perform
regular interactions with the victim via any interfaces it offers,
for example via initializing network connections.
We assume that the spy can achieve virtual core coresidency with the victim process. This assumption is required
because BTB collisions can only be achieved within thesame virtual core on Haswell CPU. This assumption is notunrealistic because, as we demonstrate in Section V-A, it ispossible for the spy to control the cores on which the victim
process is scheduled.
III. C REATING THE BTB S IDE -C HANNEL
Branch predictors are critical to performance of modern processors. One of the main components of the branch prediction
hardware is the Branch Target Buffer (BTB). The BTB storestarget addresses of recently executed branch instructions, sothat those addresses can be obtained directly from a BTB
lookup to fetch instructions starting at the target in the next cycle. Since the BTB is shared by several applications executing
on the same core, information leakage from one application
to another through the BTB side-channel is possible. For
example, several previous works demonstrated the feasibilityof recovering secret encryption key bits using branch predictor
side channel [27], [28]. As another example, a recent studyof [29], [30] demonstrated that a reliable and high speed covert
communication channel can be created between two malicious
applications that share the branch prediction logic.
In this paper we describe a new security threat associated with shared branch prediction hardware. Specifically, wedemonstrate how a user-level spy process can gain information
about the position of code blocks in the address space of either
a victim process or the kernel by aligning its code to intentionally create BTB collisions between these two address spaces.
The attacker performs a series of time measurements, eachto test a hypothesis about the location of a specific branch.
These experiments allow the attacking process to discover the

precise location of a branch in the kernel address space, orthe address space of another process, thus bypassing kernellevel ASLR and user level ASLR respectively. In principle,
our approach has a potential to bypass even some recently
proposed fine-grained ASLR solutions [31], [32], [33], [34].
The BTB side-channel that we exploit in this paper for
attacking ASLR is based on creating BTB collisions between
unconditional branch instructions belonging to two different
execution entities. We consider two types of collisions: collisions between two user-level processes (to attack user-level
ASLR) and collisions between user-level and the kernel (toattack KASLR). While no specific BTB addressing details areneeded by the attacker to perform the attack on the user-levelprocess, some reverse-engineering and understanding of the
BTB addressing scheme is required for an attack on the kernel.
A. Creating BTB Collisions in User SpaceTo create a BTB-based side-channel, three conditions mustbe satisfied. First, one application has to fill a BTB entry byexecuting a branch instruction. Second, the execution timeof another application running on the same core must be
affected by the state of the BTB. This condition is satisfied
when both applications use the same BTB entry, perhaps withdifferent targets stored. Third, the second application must beable to detect the impact on its execution by performing timemeasurements. We call the BTB collisions created between
two processes executing in the same protection domain (e.g.
two user-level processes) as Same-Domain Collisions (SDC).
An example of a SDC collision that can be exploited by our
attack is shown in Figure 1.
Kernel space

Kernel space

User space

User space

jmp1

jmp2

BTB
Address tag

Target0xebe45a82 0x7fefebe45ad6

0x7fefebe45a82
0x7fefebe45ad6

Fig. 1: SDC Example
To verify the sufficiency of the above assumptions forcreating SDCs, we designed and conducted the following
experiment on a machine with an Intel Haswell processor.
We executed two processes on the system: the victim and thespy. The victim process writes some data into the BTB byexecuting branch instructions. The goal of the spy process is
to use the branch instructions and time measurement tools
to detect the information that was written to the BTB by
the victim process. Since the goal of this experiment is todemonstrate the possibility of data transmission through the
BTB side-channel, we allow the victim and the spy to coordinate their actions by communicating with each other using

signals. The BTB manipulations are performed by executing
3000 <victim_func>:
the jmp instruction. Conditional branches can also be used,
3000 push %rbp
but for the sake of simplicity we demonstrate our attack using 3001 mov %rsp,%rbp
unconditional jumps.
3004 nop
The key code block executed by both processes contains a 3005 nop
single jmp instruction with additional nop instructions. The . . .
outline of this code is depicted in Listing 1. The code has 3021 jmp <T2>
two possible jump targets. However, when compiled, the target 3023 nop
is statically set in the binary. We placed this code in both . . .
processes. The functions where this code was placed are called 302d <T1>302d nop
spy_func() and victim_func() accordingly.
. . .
asm("jmp target2;");3037 <T2>
asm("nop; nop; ... ");3037 nopasm("Target1:");. . .
asm("nop; nop; ... ");3041 pop %rbp
asm("Target2:");3042 retq
asm("nop; nop; ... ");Listing 1: Code example with jump instructions
The goal of this experiment is to record the execution
time of the spy process when the measured jmp instructionaligns with a similar instruction in the victim process. Our
expectation is that the two branch instructions will map to thesame BTB entry if they are located at the same virtual address.
Assuming BT B index() is the BTB indexing function, then
BT B index(Avictim ) = BT B index(Aspy ) if Avictim andAspy are identical virtual addresses. As a result, the data
placed at this address by the victim will affect the execution
time of the spy due to the created SDC.
The victim and the spy processes are compiled and linked
specifically to align the jump instructions. The spy alsomeasures the number of execution cycles required to executethe jump block using the rdtscp instruction. We adjust the
number of nop instructions in the spy in order to compensate
for the length of the rdtscp instruction and keep the addresses of the jump and both targets aligned with the victim’s
addresses. The disassembly of the key functions is depicted in
Listing 2.
We executed the spy and the victim processes under two
settings. In the first setting, the targets of the spy and the victim
are the same, as demonstrated in Listing 2. In the second
setting, the targets are different and the victim jumps to target
T1. The use of different targets results in extra BTB misses
and thus performance slowdown for the spy, as the spy’s BTB
entry is overwritten by the victim, but with a different target
address. By running the spy under both settings, we obtainthe number of cycles required by the spy to execute the jumpcode block.
The timing diagram depicting the stages of the experiment ispresented in Figure 3. The affinity masks of the two processes
are set to force them to execute on a single virtual coreinterchangeably. First, the spy process sends a signal 1 to the3000 <spy_func>:
3000 push %rbp
3001 mov %rsp,%rbp3004 rdtscp
3005 nop. . .
3021 jmp <T2>3023 nop. . .
302d <T1>302d nop. . .
3037 <T2>3037 nop. . .
3041 rdtscp. . .
306c pop %rbp
306d retq

Listing 2: Disassembly of the functions containing the jumpblock in the victim and the spy. Pictured an example withaligned jump and target addresses.
victim process. To assure the delivery and the correct response
before the spy continues, the spy process calls the sleep() 3function immediately after sending the signal. The victim
handles the signal by executing the victim_func() 2function. At this stage, an entry in the BTB will be createdor updated. After a short sleep, the spy process executes
the spy_func() 4 and measures the number of cycles
to execute its jump block. After this step, the measurement
process is repeated again. When enough measurements are
obtained, the same experiment is repeated with the victim
jumping to a different target. We ran this experiment togenerate 100,000 measurements under each setting.
Victim T2
Victim T1

Spy T255.76
64.93 (+9.17)

Spy T169.38 (+11.12)
58.26

TABLE I: Averaged time of the jump code block (in cycles)
as measured by the spy with different victim settings.
The results of this experiment are shown as a histogram in
Figure 2. As can be observed from the graph, there are two
separate groups of time measurement values. The difference
between the averages of these two groups is about 9 cycles.
According to Intel developer’s manual, the frontend resteer
following an incorrect BTB prediction introduces an 8-cycle
bubble into the instruction fetch pipeline. This value is similar
to the observed slowdown.
In order to verify the consistency of our results, we also
repeated the experiment with the spy having the jump target

0.7

Average matching
Average mismatching
Matching
Mismatching

0.6
0.5
0.4
0.3
0.2
0.1
0.0
45

50

55

60

65

70

75

80

85

Fig. 2: Distribution of the execution time of the jump code
block (in cycles) when victim process jumps to matching andmismatching target addresses.

set to T1. The results are summarized in Table I. Note thatsince T1 is located closer to the jump instruction in the code
segment, the spy executes more instructions when jumping to
T1. Consequently, T1’s measurements are higher comparing
to T2’s with the victim performing jumps to the matchingtarget. However, the relative difference between the matching
and mismatching targets is similar in both cases.
VictimSpykill(victim_pid) 1
signalvictim_func() 2

sleep() 3n_cyclesspy_func()

4

repeatFig. 3: Interactions between the spy and the victim
These results validate our hypotheses that the BTB accessperformed by one process impact the execution time of anotherprocess. The stability of the results offers an opportunity to
use the BTB as a side-channel to monitor the branch activityof a victim process.
B. Creating Cross-Domain BTB Collisions
We now describe how the BTB collisions can be createdbetween a user-level process (the attacker) and the kernel
as it executes on behalf of the user process. We call suchcollisions Cross-Domain Collisions (CDC) because the spy
and the victim belong to different protection domains. If thefull virtual address was used for BTB addressing, then CDCs
would not exist, because the kernel code and the user code arelocated at different virtual addresses. In this case, the BTB
tags would be different and the user process would neverexperience a BTB hit on a data placed in the BTB by the
kernel.

However, modern processors typically use long (48-bits incurrent implementations) virtual addresses when they run in
the 64-bit mode [35]. Assuming that each BTB entry also
needs to store the absolute value of the target address, thetotal size of each BTB entry becomes large if the entire virtual
address is used for tagging and indexing. For example, for a
BTB with 8K sets, 35 bits for the tag and 48 bits for the target
address will be needed, adding up to 83 bits of storage for eachentry, which is expensive and power-consuming. Therefore,
current CPUs typically store only a part of the upper-orderaddress bits as tags, and some upper-order bits are ignoredfor BTB addressing, possibly creating more collisions but
significantly simplifying the design and the BTB area andpower requirements.
The knowledge of the precise addressing scheme in the BTB
has significant implications on both types of attacks that we
consider in this paper. For the user-level attack that exploits
SDCs, this information is important because the address bitsthat are not used in BTB addressing cannot be recovered
using our attack. In other words, this knowledge gives theattacker information about the maximum possible benefits ofa successful attack. In terms of attacks against KASLR that
exploits CDC, the knowledge of the addressing mechanism isessential even for creating the CDC collisions themselves.
On the Haswell processor used in our experiments, only asubset of the virtual address bits is used for BTB addressing.
We used the following algorithm to discover which particular
bits are used for addressing the BTB. First, we created a
detectable SDC between two jump instructions in two separate
processes (as described in the previous section). Second, bychanging the address bits in the colliding instructions, we
determined if the specific bits were used for BTB addressing.
In particular, when inverting a specific address bit eliminatesa previously observed collision, the conclusion is that this bit
was used in the BTB addressing; otherwise it was not used.
To determine the relevant bits for Haswell processor, we
repeated the experiment similar to the one described above in
Section III-A under different settings. The main difference wasthat while we kept the address of the jump instruction the samein the victim process, we changed the address bits of the jump
instruction in the spy process. We discovered that all lower bitsof the address are used continuously and only the higher bits of
the address were cut off and not used in the BTB addressing.
In particular, bits 0 to 30 of the virtual address are used,
and bits 31 to 47 are ignored. The reverse engineered BTB
addressing scheme in the Haswell processor is depicted in
Figure 4. Figure 5 shows how a kernel-level branch instruction
and a user-level branch instruction can create a CDC in the
BTB.
Equipped with the understanding of the BTB addressing
scheme, the attacker can now create CDCs in the BTB and
exploit them for the kernel-level attack. The kernel-based

Branch Target Buﬀer

Haswell300Virtual Address: 0xAAAA AAAAAAAA

Indexing
functionf(x)Fig. 4: BTB addressing scheme in Haswell processor
Kernel space
jmp1

0xffffa9fe8756

BTB
Address tag Target
0xa9fe8756

User space
jmp2

0x000a9fe8756

Fig. 5: CDC Example

attack flow is described in detail in the next section. After
presenting the kernel-level attack, we show how a complete
attack on user-level process can be realized using SDCs in the
BTB.
IV. R ECOVERING ASLR B ITS OF K ERNEL C ODE
A DDRESSESIn this section, we demonstrate how the BTB side-channel
can be used to effectively recover the randomized offset bits
used in kernel ASLR in a short amount of time. We use arecent Linux kernel (version 4.5) for our experiments.
A. KASLR in Linux
Modern desktop and server operating systems implement
kernel ASLR (KASLR). Starting from kernel version 3.14,
KASLR is also included in the mainstream Linux kernel
distribution. To provide the necessary background, we first
explain the KASLR implementation in 64-bit mode Linuxkernel.
When KASLR is disabled, the kernel image is always
placed at the same physical address during system’s boot.
The address translation in kernel mode can be performed bysimply subtracting a predefined PAGE_OFFSET value (which
is 0xffffffff80000000 for a 64-bit kernel) from thevirtual address. Thus, the location of the kernel image is fixedin both the virtual and physical address spaces.
When KASLR is enabled, a sequence of random bits isgenerated during early boot process. These bits are used to
calculate the randomized offset at which the kernel imageis placed in physical memory. The virtual-to-physical addresstranslation for kernel addresses remains unchanged. The randomized placement of kernel code in physical memory is
mirrored by the same offset being applied to the virtual addresses in virtual memory. This leads to a critical observation:
if an attacker discovers the position of the kernel code either

in physical or virtual address space, the address layout isdisclosed, and the location of any address in the static kernel
image can be determined from there. Since our attack is built
around virtually-addressed BTB, for the rest of this section
we focus on virtual addresses. Note that since the kernel ismapped into the address space of every process, deriving the
KASLR offset on any process exposes KASLR for all.
Due to the specifics of the Linux kernel memory layout, the64-bit kernel currently randomizes only 9 bits of the virtual
addresses. In particular, the kernel code must be aligned at
2MB boundaries. As a result, only the Page Directory Entry(PDE) bits of virtual addresses are randomized. While it would
have been possible to extend the relocation mechanism, thisrequires significant reorganization of the physical memory layout and will likely result in performance degradation. Figure 6
demonstrates the randomized bits as well as how the bits areused for page translation on x86 64 machines operating withlarge 2MB pages. The figure also shows possible range of
kernel code addresses.
2MB page translation:
39 38
30 29
47
21 20
Page Map
Page Dirrectory Page Directory
Level 4 Oﬀset Pointer Oﬀset
Oﬀset
Kernel addresses randomization:
30 29
47
Always Fixed

111111111111111110

0Page Oﬀset

21 20

Randomized
during Load0

Determined during
Compilation

Example of min and max randomized addresses:
Min: 0xffffffff801e8756
Max: 0xffffffffbffe8756

Fig. 6: KASLR used in 64-bit Linux kernel. Only the Page
Directory Entry (PDE) bits are randomized.
B. Using the BTB Channel for KASLR Bits Recovery
In Section III we demonstrated how two independent jump
instructions can collide inside the BTB to create contention
for BTB entries, resulting in a measurable slowdown of thecolliding jump instructions. We now describe how this sidechannel can be used to discover the random address bits of
one kernel function. This, in turn, allows the discovery of arandomized offset value generated during the boot process.
To prepare the attack, an adversary needs to locate a branch
instruction whose execution can be easily triggered by the spy
process. One way to achieve this is to analyze the code ofsystem calls available to a user process and locate a systemcall that performs a branch instruction. In order to make theattack faster and to minimize noise, first consideration should
be given to system calls with a small number of instructions.
Next, the attacker creates a list of all possible locations forthat branch taking into account the randomization scheme andthe location of that branch in the compiled kernel code. After
that, for each address A from that list, the attacker performs
the following steps:

C. Results of KASLR Bit Recovery
We implemented the attack discussed above and executed
it on our test machine equipped with a Haswell CPU. In our
experiments, we used the open system call to locate a branch
instruction in the kernel code. This system call opens a file andreturns a file descriptor. However, prior to accessing the filesystem, the OS checks for any errors. This check involves acomparison performed using a conditional branch instruction.
The branch instruction is located at a predictable address andtherefore can be used for the attack.
One of the possible errors that occurs during the system callis when the provided file name is larger than the maximum
length allowed by the system. In order to make the attack fast
and to minimize noise, we intentionally provided the erroneous
filename. After the kernel detects the length violation, thecontrol flow is immediately returned to the user process thatrequested this system call.
The results of this experiment are presented in Figure 7.
The nine random address bits correspond to 512 possible
A addresses. For each such address A, we collected 50
measurements. As seen from the graph, there is a single
point that has the average timing that is much higher than
the rest of the points on the graph. This point corresponds tothe colliding branch instruction. In particular, the user space
jump instruction at address 0xa9fe8756 collides with another branch instruction at address 0xffffa9fe8756. This
collision results in a significant slowdown due to the wrongpath instruction fetch after the BTB prediction. Therefore, thevalue of the KASLR bits is a9f in this case. The describedattack takes a very short time: only 60 milliseconds are needed
to collect the required number of samples.
V. R ECOVERING ASLR B ITS IN U SER A PPLICATION C ODE
User-level processes can also be the victims of attacks
attempting to compromise ASLR. Privileged processes or100

90
Cycles to execute spy's code block1) It allocates a buffer at the required address in the spy
process.
2) It loads this buffer with a block of code containing asingle jump instruction. The loading is done in a waythat creates collisions in the BTB with a possible kernelbranch instruction at address A. This block of code also
contains an instruction to measure the time to executethe jump instruction.
3) The target branch instruction in the kernel code isactivated by executing the identified system call.
4) The block of code in the spy process is executed anumber of times and the number of cycles taken to
execute it is recorded.
5) Finally, the results are analyzed. The block with higher
average cycle measurement corresponds to the situation
when the jump instruction in the spy’s code block
collides with the kernel branch at address A.

0xa9fe8756

80

70

60

50

40
7d0

834

898

8fc

960

9c4 a28 a8c
KASLR bits

af0

b54

bb8

c1c

c80

Fig. 7: Results of the BTB-based Attack on KASLR

processes that have access to specific data can be attacked byother processes running in the same system; as part of suchan attack, reverse engineering the ASLR offset is necessary.
While system security settings may only allow an attacker toremotely create a process with user privileges, the attacker canuse this user process as a starting point for discovering andattacking other processes with higher privileges.
A typical system has many daemon processes executing
with administrative privileges and these daemons can havecommon exploitable vulnerabilities. For example, a recently
reported vulnerability [36] in the cupsd printing scheduler(which is found on most Unix-like systems and is executing
as root), allows a remote attacker to execute arbitrary code.
Typically, ASLR interferes with the attacker’s ability to perform a subsequent attack, such as a code reuse attack, that
follows the exploitation of the vulnerability e.g. by means ofbuffer overflow. To complete a successful attack, the adversary
first needs to de-randomize the victim process prior to enabling
the correct exploitation of the vulnerability without crashingthe victim process.
Another relevant application of a user-level ASLR attack
is to perform layout de-randomization in isolated execution
environments, where application secrets are protected inside
enclaves or compartments [37], [38], [39], [40]. The compartment code layout is usually kept secret in such systems, andde-randomizing it opens avenue for side-channel attacks oncompartments, similar to the ones reported by Xu et al. [41].
The BTB side-channel presents one way of de-randomizing
the code segment of a running process in this scenario. Ourcontribution is to demonstrate the principles of such userspace attack. Similar to the attack on kernel ASLR describedin previous section, the attack on user-level ASLR is basedon the ability of the spy process to trigger some activity inthe victim process. Such triggering can be accomplished inseveral different ways depending on the interfaces offered by
the victim process. For example, with the cupsd daemon,
the spy can send some requests via the network to force somecode to be executed as needed. In the attack preparation stage,
the attacker analyzes the victim’s executable to find functions
that can be triggered and also locates jump instructions in suchfunctions. The stages of the attack are presented in Figure 8.
Specifically, the spy process performs the following steps foreach possible address A where the victim’s branch instruction
can reside:1) It allocates a buffer at the required address.
2) It fills the buffer with the code containing a single jump
instruction at address A.
3) It triggers 1 an activity in the victim process 2 in orderto force the victim to create a BTB entry.
4) It waits 3 for the activity to complete.
5) It executes the jump block several times and measuresthe execution time 4 .
6) It changes the target of the jump instruction 5 andrepeats the measurement stages.
7) Finally, the spy discovers the address at which the
behavior of the jump is similar to what we describedin Section IV.
We now discuss the requirements for this attack and mechanisms that allow the attacker to fulfill these requirements.

— Dummy— Spy04— Victim— Conext swith
1

Phys Core 02

65Phys Core 1
3

7

Phys Core 2
Phys Core 3(a) Dummy processes force the OS to schedule thevictim on a desired virtual core (prior the spy)
041Phys Core 02

65Phys Core 1
3

7

Spy

VictimTrigger victim 1
requestvictim_activity

sleep() 32n_cyclesspy_func()

4

Change jmp target 5
Trigger victim
requestvictim_activity

Phys Core 2
Phys Core 3(b) A copy of the spy process is executed on eachcore

Fig. 9: Two types of spy scheduling. Both produce context
switches from the victim to the spy allowing leakage ofsensitive data.

sleep()
n_cyclesspy_func()

Fig. 8: Stages of the user ASLR attack
A. Achieving Co-residency of the Victim and the Spy
The attack on kernel ASLR described in previous section
does not have to be tied to a specific core. When a process
performs a system call, the process switches to kernel modeand executes the kernel code which is mapped into its address
space; i.e., the kernel code executes on the same core withoutcausing a context switch. After that, the kernel returns to theprocess and allows it to continue.
The situation is quite different for the user-level attack. Our
experiments with the BTB side-channel on both Sandy Bridgeand Haswell CPUs revealed that a BTB collision between two
user-level processes can only happen when both processes arescheduled consecutively on the same virtual core (or hardware
thread context) of a hyper-threaded processor. The collision
does not happen when the two processes are executed onparallel hardware contexts. This observation implies that either
each virtual core has a dedicated area in the BTB, or every
BTB entry is marked with a virtual core ID. Consequently, thefirst goal of the user-level attack is to ensure co-residency ofthe victim and the spy on the same virtual core.
The virtual core co-residency requirement can be met inseveral ways. One method is to inject dummy processes in thesystem on all other virtual cores in order to alter the schedulingmechanism and force the spy to be placed on the same virtual
core as the victim. Another option is to execute the spy on all
virtual cores. These two schemes are summarized in Figure 9
and are described below.

1) Manipulating the OS Scheduler: One way to achieve coresidency is to manipulate process scheduling by the kernel.
We assume that it is possible for a user process to schedule
itself on an arbitrary core. In Linux, such capability is available
through a call to sched_setaffinity() [42]. Schedulingmanipulation is possible because of predictability of the task
placement algorithm. In order to efficiently and equally utilize
the CPU computational and power resources, the OS attempts
to spread the load equally among all cores. With that constraint, the OS is more likely to schedule a process on a corewith a lower utilization level. To exploit this algorithm, theattacker can substantially load all cores in the system withdummy tasks, except for the core on which it wishes to place
the victim process.
To validate that it is possible for a user-level process tocontrol the placement of other processes (including privilegedones) in the system, we examined the scheduling of thesshd daemon process (OpenSSH server) that was executed
as root. First, we did not introduce any dummy processes
in the background and allowed the OS to freely choose any
cores to schedule this process on. We performed a series ofobservations recording which core the process was scheduledon. During each observation, we initialized a new ssh connection in order to force the OS to wake up the process
and place it on one of the cores. For the second part of theexperiment, we executed dummy CPU-bound processes (asshown in Figure 9a), loading all but a single virtual core to
the maximum. We repeated the same series of observations,recording the cores on which the sshd process was placed.
We executed the above experiment to capture 1 million data
points for each case. For this experiment, we used a machinewith Intel Core i7-4800MQ quad-core processor. Note that
although the CPU has 4 physical cores, the hyper-threading
technology makes the OS recognize 8 virtual cores with 2
threads per physical core. Our machine was running Ubuntu
14.04 LTS with the generic Linux kernel version 3.16.0-48.
The results of these experiments are presented in Figure 10.
As seen from the graphs, when there are no dummy processes
running on the CPU, the OS spreads the load among thecores equally. However, when there is a core with much lower
utilization level, the OS would typically schedule the sshd
daemon on that core. Another interesting observation is that
the OS is more likely to choose virtual cores 0 – 3 (thusspreading the load among all four physical cores) before using
virtual cores 4 – 7, which add another process on the same
physical core via hyper-threading.
2) Executing Multiple Spies: An alternative method ofachieving context switches from the victim to the spy on
the same virtual core is to execute multiple copies of the
spy process and allowing the OS to freely choose any coreto schedule the victim process on. Figure 9b illustrates thisapproach. Even if a task migration happens, the victim process

will be placed on a core with a copy of the spy process
running. This method requires a slightly more complex spy
organization. In order to achieve a continuous side-channel,
the scheduled group of spy processes needs to detect which
one of the spies is co-located with the victim process at the
moment. They also need to communicate this information
to each other. Detecting co-residency can be done either bydirectly obtaining such information from the OS or by relying
on side-channel analysis [43].
In our experimental system, which was configured with thedefault parameters, the OS allows all user processes to obtain
the placement information on any other process, including
privileged processes. This information includes the status of
the process (active, sleeping, etc.) and the core number onwhich the target process is/was executing. Such information
is provided through the /proc [44] virtual file system. This
makes the detection of core co-residency straightforward.
Moreover, the OS is more likely to reschedule a process tothe same core due to scheduling policies favoring cache affinity [45], [46]. This scheduling approach reduces the number oftimes the process is migrated between the cores and promotes
uninterrupted collection of side-channel data.
B. Experimental results
We implemented a prototype of the attack on user-level
ASLR by modifying the experiment described in Section IV.
First, we compiled the victim process with full ASLR support.
Second, we equipped the spy process with the capability tocheck possible locations of the victim branch. The victim has ajump with target T2, while the spy repeatedly tries two targets:the matching target T2 and the mismatching target T1. The
results are presented in Figure 11. For demonstration purposes,
we only show the recovery of 8 bits of the address.
The results are obtained following the methodology ofSection 3.1. The victim and the spy code is the same as shownin Listing 2. The spy executes more instructions when jumping
to target T1, therefore the blue points are higher than the green
points on Figure 11. The vertical line in the middle of thegraph shows the situation when the victim’s branch and the
spy’s branch hash to the same BTB entry, causing a collision
and additional delay at the spy. While the latency increasein T1 is expected, the slight increase in T2 (matching target)is due to collisions and contention on other shared virtuallyaddressed resources, such as the uop cache. The collisions are
not through BTB in this case because both victim and spy will
get the BTB hits for the same virtual address and the sametarget address (T2).
Our prototype code tests 100 addresses in a second. Further
optimizations can make the throughput even higher. Please
note that current BTB addressing scheme (as used in Haswellprocessor used for our experiments) allows us to recover only
a limited number of ASLR bits. The number of bits that are25.0%

24.80%

22.32%

20.0%

80.0%

15.0%

60.0%

Frequency

Frequency

21.19%

10.0%
5.0%

40.0%
20.0%

2.07% 2.54% 2.18% 1.44%
0.0%

99.59%

100.0%

23.46%

0

1

2

3

4

5

Schedule Frequency by Core

67(a) No scheduling manipulation

0.0% 0.07% 0.06% 0.06%
0
1
2

3

0.03% 0.02% 0.02% 0.17%
45
67

Schedule Frequency by Core(b) The spy forces scheduling at core number 3

Fig. 10: Scheduling of the victim process to virtual cores.

randomizes is implementation specific. However, according
to [47], the full ASLR in Linux randomizes 12th to 40th bitsof the virtual address. Since 30th and higher bits are not usedin BTB addressing, only 18 bits can be recovered using the
BTB attack on Haswell. However, this significantly reduces
the entropy, making the brute force of the remaining 11 bits
more feasible.

120

Cycles to execute spy's code block

115
110
105
100
95
90

T1

85
80

0x7fefebe45a82

T275
7efebe3e8

7efebe44c
7efebe4b0
Randomized part of the instruction address

7efebe514

Fig. 11: Results of the BTB-based Attack on User-level ASLR

VI. M ITIGATING BTB- BASED ATTACKSIn this section we describe several possible countermeasuresthat can either make the ASLR schemes less vulnerable to
the BTB side-channel attacks presented above, or completely
suppress the side-channel. We categorize possible solutions
into two groups: purely software solutions and hardwaresupported solutions.

A. Software Mitigations
Software countermeasures are limited because they are notable to control how branches are mapped to the BTB entries,
thus they do not address the root cause of the side channel.
However, several software countermeasures are possible thatcan make the recovery of the ASLR bits difficult or even
impossible.
Traditional ASLR schemes randomize only the offset of thesegments within the program address space. However, recent
research efforts suggested finer-grained ASLR schemes thatcan randomize code at the granularity of functions [31], basic
blocks [48] or instructions [49], [50]. While most of thesesolutions focus on user-level ASLR, fine-grained KASLR isalso possible. Reconstructing the code layout in memory ismuch harder when such fine-grained protection schemes areapplied. The BTB attack described in this paper has a potential
to bypass even these fine-grained techniques, provided thatthey preserve the basic block structure, because it discovers
the position of individual branch instructions in memory.
However, such an attack on fine-grain ASLR would requiresignificantly more effort from the attacker. In addition, if an
ASLR technique randomizes the sizes of basic blocks, the spy
process will not be able to distinguish basic blocks from one
another, thus closing the BTB side-channel.
Another approach to mitigating the BTB side channel (aswell as many others) is to make the accurate execution
time readings difficult by fuzzing the time stamp counter, ordisabling it completely [51], [52]. However, such a solution
could interfere with many legitimate applications that needto have precise time measurement capability. Moreover, some
implementations have been shown to be insecure [53].
1) Kernel ASLR Reinforcement: As was demonstrated in
Section IV-A using the example of Linux, today’s operating
systems rely on limited entropy for KASLR. A small number

of randomized bits makes the KASLR side-channel attack
possible. In addition, the bits being randomized fall into thelower 30 bits of the virtual address1 , making the BTB-based
attack possible. A simple solution which does not require
any hardware changes is to ensure that more higher-order
bits are randomized during every system load. The memoryorganization on x86 64 machines allows the use of 48 bits ofvirtual address with the most significant bit used to distinguishbetween the lower half and the upper half of virtual memory.
Thus, assuming 2MB pages for kernel code (and thus 21
bits in the page offset), the maximum number of bits thatcan be theoretically randomized is 26 (48-1-21). Since 17 ofthese bits (the upper order bits of the address) are not used
for BTB addressing, the BTB side-channel will not provide
sufficient information to derive ASLR. The 17 bits correspondto approximately 131,000 possible kernel positions. Sincebrute-force attacks in kernel space are infeasible, this levelof entropy is likely to provide sufficient security.
Randomization schemes interfere with the way the kernel
normally organizes its memory layout. In current implementations, large memory areas are fixed and reserved for devices,the hypervisor and other service structures. Therefore, implementing such a scheme would require significant memory
reorganization in order to benefit from high levels of entropy.
B. Hardware Mitigations
The BTB side channel attack is possible because of two
types of BTB collisions. The first type of collision occurs when
two branches residing in different protection rings and locatedat different addresses are mapped to the same BTB entry this opens the door for BTB-based attack against KASLR.
The second type of BTB collision occurs when two different
branch instructions are located at identical virtual addresses
but belong to different processes - this collision is the basis
for an attack on user-level ASLR.
A hardware solution that would fundamentally mitigate
the BTB-based attacks is to change the BTB addressing
mechanism in a way that prevents exploitable collisions in the
BTB. The attack against KASLR can be mitigated by using
full virtual address for accessing the BTB, thus eliminating
collisions between the user code and the kernel code. This
would require adding extra bits in the BTB, as the tag size
will increase significantly (by 17 bits compared to Haswell
implementation for 48-bit virtual addresses).
Alternatively, the BTB can use different indexing functions
for user and kernel-level code. For example, a secret value canbe added to the existing BTB hash function when the CPU
is executing in the kernel mode. To prevent the user processfrom discovering this value and reverse-engineering the hashfunction, this value can be randomized during each system’sboot.
1 The number of bits can be different on other microarchitectures

In order to apply the same protection technique to mitigate
user-level ASLR attack, each process needs to have a uniquevalue that will be used in the BTB hashing function. Thiscan be the hardware Address Space Identifier (ASID) [54],or the values of the CR3 register, which are unique for eachprocess. Of course, these values must be kept secret from otherprocesses.
Other possible hardware-supported mitigation techniques
include flushing the BTB on context switches or marking each
BTB entry with unique process ID to distinguish the entries
set up by different processes.
VII. R ELATED W ORK
Hardware side channels are well-known threats to securityof sensitive data. A large number of prior works studied different aspects of side channels in instruction and data caches [55],[56], [57], [58], [59]. Aciicmez et al [27], [28]. were the first to
demonstrate side channel attacks on branch prediction units torecover secret keys. In another recent work [30], [29], branchpredictor’s pattern history tables were used to build a covert
channel and to pass information from one process to another.
In this paper, we show how the specially-constructed new BTB
side channel can be used to discover the memory layout of
another process or the kernel, thus bypassing existing KASLR
schemes and reducing the entropy of user-level ASLR.
Several works have demonstrated how ASLR can be defeated through brute-force approach [12], and by using memory disclosure attacks [60]. Some studies also showed how to
bypass ASLR on mobile platforms [61] and novel shieldedsystems [41]. In [62], Gu et al. addressed the problem ofde-randomizing kernel address space based on signaturesgenerated from kernel memory snapshots.
Hund et al [63] demonstrated an attack on kernel ASLR
using cache-based timing side channel analysis. In that work,
three different attacks were demonstrated. The first attack
relied on the collision of kernel and user objects in the lastlevel caches. This attack requires the attacker to know thephysical address of data that he places in the cache. In addition,
the attack is hard to perform in realistic scenario because ofexcessive amount of noise in the last-level caches from otherprocessor cores. The second attack described in [63] exploits
a particular property of Intel’s CPUs. In particular, when auser process tries to access a location in the kernel memory
space, an exception is generated. Even though the access isdenied, the TLB entry is still created, which can be detected
later by the user process. This attack allows the spy process todiscover which memory pages are allocated in kernel space.
The third attack of [63] is based on observing the time needed
for a page walk. To perform the cache-based attack, the spy
process first flushes all cache levels and then invokes somesystem service. After that, it performs a memory access, times
it, and uses this information to determine what kernel code

resides on what page. Compared to the cache-based attacks,
the BTB-based attacks proposed in this paper are significantly
simpler and allow the adversary to perform the attack under amuch more controlled setting. Indeed, the attacker no longer
needs to deal with noisy measurements from the last-level
cache and does not require any knowledge about the physicaladdressing. All our attacks are based on virtual addressing andthe exploitation of simple BTB collisions. While the attacks
on KASLR using side-channel information were previously
considered, as described above, to the best of our knowledge
this paper is the first to consider side-channel analysis torecover user-level ASLR.
To harden the security properties of ASLR schemes against
emerging attacks, researchers have proposed various finegrain ASLR techniques. These schemes enforce the enhanced
randomization at different levels, such as at the level of functions [31], basic blocks [48] or instructions [49], [50]. Whilesome of fine-grain ASLR solutions can thwart our BTB attackby randomizing the relative positions of branch instructions inmemory, they usually have significant performance overhead
and are not widely adopted. In addition, our attack can still be
used to locate the position of individual branch instructions
in memory. This information can potentially lead to thedevelopment of other techniques to eventually reconstruct thecode layout in memory despite deep randomization.
Snow et al. [64] presented just-in-time code reuse attack as
an effective technique against sophisticated fine-grained randomization schemes. The attack is based by scanning and constructing the Return-Oriented-Programming (ROP) payload at
the runtime exploiting memory disclosures. A system called
Heisenbyte [65] has been proposed to protect against suchjust-in-time attacks by addressing memory disclosure attacks.
Heisenbyte defeats memory disclosure attacks by introducing
the concept of destructive code reads. Since our BTB attack
does not rely on code reads from memory, it can still be used in
an arsenal of tools to create memory disclosures and eventuallyreconstruct the address randomization schemes.
VIII. C ONCLUDING R EMARKS
Address Space Layout Randomization (ASLR) is a widelyadopted security mechanism, both in kernel and applicationlevels, to protect systems from code reuse attacks. In thispaper, we exploited collisions in shared BTBs to create BTB
side-channels and allow the attacker process to recover the
memory layout of both the kernel and user-level applications.
We demonstrated a successful attack on a system with Haswell
CPU and a recent version of Linux kernel. We showed that
our attack is robust and can bypass KASLR in a very shortamount time. In addition, the attack can reduce the entropy ofthe user-level ASLR. Since this BTB attack adds to the arsenalof tools available to the attackers, we also described possible

software and hardware countermeasures to mitigate this new
security threat.
IX. ACKNOWLEDGMENT
This material is based on research sponsored by the National
Science Foundation grant CNS-1422401.
R EFERENCES[1] A. One, “Smashing the stack for fun and profit,” Phrack magazine,
vol. 7, no. 49, pp. 14–16, 1996.
[2] C. Cowan, P. Wagle, C. Pu, S. Beattie, and J. Walpole, “Buffer overflows:
Attacks and defenses for the vulnerability of the decade,” in DARPA
Information Survivability Conference and Exposition, 2000. DISCEX’00.
Proceedings, vol. 2. IEEE, 2000, pp. 119–129.
[3] T. Newsham, “Format string attacks,” 2000.
[4] F. Qin, S. Lu, and Y. Zhou, “SafeMem: Exploiting ECC-memory for
detecting memory leaks and memory corruption during production runs,”in High-Performance Computer Architecture, 2005. HPCA-11. 11th
International Symposium on. IEEE, 2005, pp. 291–302.
[5] S. Chen, J. Xu, N. Nakka, Z. Kalbarczyk, and R. K. Iyer, “Defeating
memory corruption attacks via pointer taintedness detection,” in Dependable Systems and Networks, 2005. DSN 2005. Proceedings. International
Conference on. IEEE, 2005, pp. 378–387.
[6] J. Xu, P. Ning, C. Kil, Y. Zhai, and C. Bookholt, “Automatic diagnosis
and response to memory corruption vulnerabilities,” in Proceedings ofthe 12th ACM conference on Computer and communications security.
ACM, 2005, pp. 223–234.
[7] D. Jang, Z. Tatlock, and S. Lerner, “SafeDispatch: Securing C++ VirtualCalls from Memory Corruption Attacks.” in NDSS, 2014.
[8] E. C. Sezer, P. Ning, C. Kil, and J. Xu, “Memsherlock: an automated debugger for unknown memory corruption vulnerabilities,” in Proceedingsof the 14th ACM conference on Computer and communications security.
ACM, 2007, pp. 562–572.
[9] S. Checkoway, L. Davi, A. Dmitrienko, A.-R. Sadeghi, H. Shacham,and M. Winandy, “Return-oriented programming without returns,” inProceedings of the 17th ACM conference on Computer and communications security. ACM, 2010, pp. 559–572.
[10] M. Kayaalp, M. Ozsoy, N. Abu-Ghazaleh, and D. Ponomarev, “Branch
regulation: Low-overhead protection from code reuse attacks,” in Computer Architecture (ISCA), 2012 39th Annual International Symposium
on. IEEE, 2012, pp. 94–105.
[11] M. Kayaalp, T. Schmitt, J. Nomani, D. Ponomarev, and N. AbuGhazaleh, “SCRAP: Architecture for signature-based protection fromcode reuse attacks,” in High Performance Computer Architecture(HPCA2013), 2013 IEEE 19th International Symposium on. IEEE,
2013, pp. 258–269.
[12] H. Shacham, M. Page, B. Pfaff, E.-J. Goh, N. Modadugu, and D. Boneh,“On the effectiveness of address-space randomization,” in Proceedingsof the 11th ACM conference on Computer and communications security.
ACM, 2004, pp. 298–307.
[13] H. Bojinov, D. Boneh, R. Cannings, and I. Malchev, “Address space
randomization for mobile devices,” in Proceedings of the fourth ACM
conference on Wireless network security. ACM, 2011, pp. 127–138.
[14] “CVE-2015-3108.” Available from NVD, CVE-ID CVE-2015-3108,
Sep. 6 2015, [Online; accessed Feb. 2 2016 https://web.nvd.nist.gov/
view/vuln/detail?vulnId=CVE-2015-3108].
[15] S. Chen, J. Xu, E. C. Sezer, P. Gauriar, and R. K. Iyer, “Non-control-dataattacks are realistic threats.” in Usenix Security, vol. 5, 2005.
[16] K. Lu, C. Song, B. Lee, S. P. Chung, T. Kim, and W. Lee, “ASLRGuard: Stopping address space leakage for code reuse attacks,” inProceedings of the 22nd ACM SIGSAC Conference on Computer andCommunications Security. ACM, 2015, pp. 280–291.
[17] PaX Team, “Address space layout randomization,” Phrack, March, 2003.
[18] M. Howard, “Address space layout randomization in Windows Vista,”
Microsoft Corporation, vol. 26, 2006.
[19] D. Keuper, “XNU: A security evaluation,” December 2012.

[20] D. A. Dai Zovi, “Apple iOS 4 security evaluation,” Black Hat USA, pp.
1–29, 2011.
[21] M. Payer, “Too much PIE is bad for performance,” 2012.
[22] S. Designer, “return-to-libc attack,” Bugtraq, Aug, 1997.
[23] H. Shacham, “The geometry of innocent flesh on the bone: Return-intolibc without function calls (on the x86),” in Proceedings of the 14th
ACM conference on Computer and communications security. ACM,
2007, pp. 552–561.
[24] V. P. Kemerlis, G. Portokalidis, and A. D. Keromytis, “kGuard:
lightweight kernel protection against return-to-user attacks,” in Presented
as part of the 21st USENIX Security Symposium (USENIX Security 12),2012, pp. 459–474.
[25] B. Spengler and PaX Team, “KASLR: An Exercise in Cargo Cult
Security,” Available online, Mar. 20 2013, [Online; accessed Feb. 2 2016
http://forums.grsecurity.net/viewtopic.php?f=7&t=3367#p12726/].
[26] T. Mandt, “Revisiting iOS Kernel (In) Security: Attacking theearly random() PRNG.”[27] O. Aciicmez, K. Koc, and J. Seifert, “On the power of simple branchprediction analysis,” in Symposium on Information, Computer andCommunication Security (ASIACCS). IEEE, 2007.
[28] ——, “Predicting secret keys via branch prediction,” in The cryptographers’ track at the RSA conference, 2007.
[29] D. Evtyushkin, D. Ponomarev, and N. Abu-Ghazaleh, “Understanding
and mitigating covert channels through branch predictors,” ACM Transactions on Architecture and Code Optimization (TACO), vol. 13, no. 1,
p. 10, 2016.
[30] ——, “Covert channels through branch predictors: a feasibility study,”
in Proceedings of the Fourth Workshop on Hardware and Architectural
Support for Security and Privacy (HASP). ACM, 2015, p. 5.
[31] C. Kil, J. Jun, C. Bookholt, J. Xu, and P. Ning, “Address space layout
permutation (ASLP): Towards fine-grained randomization of commodity
software,” in null. IEEE, 2006, pp. 339–348.
[32] C. Giuffrida, A. Kuijsten, and A. S. Tanenbaum, “Enhanced operating
system security through efficient and fine-grained address space randomization,” in Presented as part of the 21st USENIX Security Symposium(USENIX Security 12), 2012, pp. 475–490.
[33] H. Xu and S. J. Chapin, “Improving address space randomization witha dynamic offset randomization technique,” in Proceedings of the 2006
ACM symposium on Applied computing. ACM, 2006, pp. 384–391.
[34] S. Bhatkar, D. C. DuVarney, and R. Sekar, “Efficient techniques for comprehensive protection from memory error exploits.” in Usenix Security,
2005.
[35] C. N. Keltcher, K. J. McGrath, A. Ahmed, and P. Conway, “The AMD
Opteron processor for multiprocessor servers,” IEEE Micro, no. 2, pp.
66–76, 2003.
[36] “CVE-2015-1158.” Available from NVD, CVE-ID CVE-2015-1158,
Sep. 6 2015, [Online; accessed Feb. 2 2016 https://web.nvd.nist.gov/
view/vuln/detail?vulnId=CVE-2015-1158].
[37] I. Anati, S. Gueron, S. Johnson, and V. Scarlata, “Innovative technology
for CPU based attestation and sealing,” in Proceedings of the 2ndinternational workshop on hardware and architectural support for
security and privacy, vol. 13, 2013.
[38] D. Evtyushkin, J. Elwell, M. Ozsoy, D. Ponomarev, N. A. Ghazaleh,
and R. Riley, “Iso-x: A flexible architecture for hardware-managed
isolated execution,” in Microarchitecture (MICRO), 2014 47th Annual
IEEE/ACM International Symposium on. IEEE, 2014, pp. 190–202.
[39] ——, “Flexible hardware-managed isolated execution: Architecture,
software support and applications,” IEEE Transactions on Dependable
and Secure Computing (TDSC), 2016.
[40] V. Costan, I. Lebedev, and S. Devadas, “Sanctum: Minimal hardware
extensions for strong software isolation,” in 25th USENIX Security
Symposium (USENIX Security 16). Austin, TX: USENIX Association,
Aug. 2016. [Online]. Available: https://www.usenix.org/conference/
usenixsecurity16/technical-sessions/presentation/costan[41] Y. Xu, W. Cui, and M. Peinado, “Controlled-channel attacks: Deterministic side channels for untrusted operating systems,” 2015.
[42] M. Kerrisk et al., “SCHED SETAFFINITY(2) linux programme’s manual,” Dec 2015.

[43] Y. Zhang, A. Juels, A. Oprea, and M. K. Reiter, “Homealone: Coresidency detection in the cloud via side-channel analysis,” in security
and Privacy (SP), 2011 IEEE Symposium on. IEEE, 2011, pp. 313–328.
[44] M. Kerrisk et al., “proc(5) Linux Programmer’s Manual,” Dec 2015.
[45] V. Kazempour, A. Fedorova, and P. Alagheband, “Performance implications of cache affinity on multicore processors,” in Euro-Par 2008–
Parallel Processing. Springer, 2008, pp. 151–161.
[46] J. Torrellas, A. Tucker, and A. Gupta, “Evaluating the performance of
cache-affinity scheduling in shared-memory multiprocessors,” Journal of
Parallel and Distributed Computing, vol. 24, no. 2, pp. 139–151, 1995.
[47] H. Marco-Gisbert and I. Ripoll, “On the Effectiveness of Full-ASLR on
64-bit Linux,” 2014.
[48] R. Wartell, V. Mohan, K. W. Hamlen, and Z. Lin, “Binary stirring:Self-randomizing instruction addresses of legacy x86 binary code,” inProceedings of the 2012 ACM conference on Computer and communications security. ACM, 2012, pp. 157–168.
[49] V. Pappas, M. Polychronakis, and A. D. Keromytis, “Smashing thegadgets: Hindering return-oriented programming using in-place code
randomization,” in Security and Privacy (SP), 2012 IEEE Symposium
on. IEEE, 2012, pp. 601–615.
[50] S. Shamasunder, “On the Effectiveness of Heterogeneous-ISA Program
State Relocation against Return-Oriented Programming,” Ph.D. dissertation, UNIVERSITY OF CALIFORNIA, SAN DIEGO, 2015.
[51] R. Martin, J. Demme, and S. Sethumadhavan, “TimeWarp: rethinking
timekeeping and performance monitoring mechanisms to mitigate sidechannel attacks,” ACM SIGARCH Computer Architecture News, vol. 40,
no. 3, pp. 118–129, 2012.
[52] D. Gullasch, E. Bangerter, and S. Krenn, “Cache games–bringing accessbased cache attacks on AES to practice,” in Security and Privacy (SP),2011 IEEE Symposium on. IEEE, 2011, pp. 490–505.
[53] S. Bhattacharya, C. Rebeiro, and D. Mukhopadhyay, “Unraveling timewarp: What all the fuzz is about?” in Workshop on Hardware andArchitectural Support for Security and Privacy (HASP), 2013.
[54] B. Jacob and T. Mudge, “Virtual memory in contemporary microprocessors,” Micro, IEEE, vol. 18, no. 4, pp. 60–75, 1998.
[55] D. Gruss, C. Maurice, and K. Wagner, “Flush+ Flush: A Stealthier LastLevel Cache Attack,” arXiv preprint arXiv:1511.04594, 2015.
[56] Z. Wang and R. B. Lee, “Covert and side channels due to processor
architecture,” in null. IEEE, 2006, pp. 473–482.
[57] F. Liu, Y. Yarom, Q. Ge, G. Heiser, and R. B. Lee, “Last-level cacheside-channel attacks are practical,” in IEEE Symposium on Security andPrivacy, 2015, pp. 605–622.
[58] Y. Yarom and K. Falkner, “Flush+ reload: a high resolution, low noise,
L3 cache side-channel attack,” in 23rd USENIX Security Symposium(USENIX Security 14), 2014, pp. 719–732.
[59] M. Kayaalp, N. Abu-Ghazaleh, D. Ponomarev, and A. Jaleel, “A highresolution side-channel attack on last-level cache,” in Proceedings of the
53rd Annual Design Automation Conference. ACM, 2016, p. 72.
[60] G. F. Roglia, L. Martignoni, R. Paleari, and D. Bruschi, “Surgically
returning to randomized libc,” in Computer Security Applications Conference, 2009. ACSAC’09. Annual. IEEE, 2009, pp. 60–69.
[61] B. Lee, L. Lu, T. Wang, T. Kim, and W. Lee, “From zygote to morula:
Fortifying weakened ASLR on Android,” in Security and Privacy (SP),2014 IEEE Symposium on. IEEE, 2014, pp. 424–439.
[62] Y. Gu and Z. Lin, “Derandomizing kernel address space layout for
memory introspection and forensics,” in Proceedings of the Sixth ACM
on Conference on Data and Application Security and Privacy. ACM,
2016, pp. 62–72.
[63] R. Hund, C. Willems, and T. Holz, “Practical timing side channel attacks
against kernel space ASLR,” in Security and Privacy (SP), 2013 IEEE
Symposium on. IEEE, 2013, pp. 191–205.
[64] K. Z. Snow, F. Monrose, L. Davi, A. Dmitrienko, C. Liebchen, and A.-R.
Sadeghi, “Just-in-time code reuse: On the effectiveness of fine-grainedaddress space layout randomization,” in Security and Privacy (SP), 2013
IEEE Symposium on. IEEE, 2013, pp. 574–588.
[65] A. Tang, S. Sethumadhavan, and S. Stolfo, “Heisenbyte: Thwarting
memory disclosure attacks using destructive code reads,” in Proceedingsof the 22nd ACM SIGSAC Conference on Computer and Communications Security. ACM, 2015, pp. 256–267.