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 the
target 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 is
compiled 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 co-
residency with the victim process. This assumption is required
because BTB collisions can only be achieved within the
same virtual core on Haswell CPU. This assumption is not
unrealistic because, as we demonstrate in Section V-A, it is
possible for the spy to control the cores on which the victim
process is scheduled.
III. CREATING THE BTB SIDE-CHANNEL
Branch predictors are critical to performance of modern pro-
cessors. One of the main components of the branch prediction
hardware is the Branch Target Buffer (BTB). The BTB stores
target addresses of recently executed branch instructions, so
that those addresses can be obtained directly from a BTB
lookup to fetch instructions starting at the target in the next cy-
cle. 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 feasibility
of recovering secret encryption key bits using branch predictor
side channel [27], [28]. As another example, a recent study
of [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 associ-
ated with shared branch prediction hardware. Specifically, we
demonstrate 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 intention-
ally create BTB collisions between these two address spaces.
The attacker performs a series of time measurements, each
to 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, or
the address space of another process, thus bypassing kernel-
level 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: col-
lisions between two user-level processes (to attack user-level
ASLR) and collisions between user-level and the kernel (to
attack KASLR). While no specific BTB addressing details are
needed by the attacker to perform the attack on the user-level
process, some reverse-engineering and understanding of the
BTB addressing scheme is required for an attack on the kernel.
A. Creating BTB Collisions in User Space
To create a BTB-based side-channel, three conditions must
be satisfied. First, one application has to fill a BTB entry by
executing a branch instruction. Second, the execution time
of 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 with
different targets stored. Third, the second application must be
able to detect the impact on its execution by performing time
measurements. 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
BTB
Address tag Target
jmp1 jmp2
0x7fefebe45a82
0xebe45a82
0x7fefebe45ad6
0x7fefebe45ad6
Fig. 1: SDC Example
To verify the sufficiency of the above assumptions for
creating 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 the
spy. The victim process writes some data into the BTB by
executing 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 to
demonstrate the possibility of data transmission through the
BTB side-channel, we allow the victim and the spy to coor-
dinate their actions by communicating with each other using