Breaking Kernel Address Space Layout Randomization with Intel TSX
Yeongjin Jang, Sangho Lee, and Taesoo Kim
Georgia Institute of Technology

Windows Vista
Kernel/User space

Abstract
Kernel hardening has been an important topic, as many
applications and security mechanisms often consider the
kernel as part of their Trusted Computing Base (TCB).
Among various hardening techniques, Kernel Address
Space Layout Randomization (KASLR) is the most effective and widely adopted defense mechanism that canpractically mitigate various memory corruption vulnerabilities, such as buffer overflow and use-after-free. In
principle, KASLR is secure as long as no memory leakvulnerability exists and high entropy is ensured.
In this paper, we introduce a novel timing attack against
KASLR, called DrK, that can precisely de-randomize thememory layout of the kernel without violating any suchassumptions. DrK exploits a hardware feature called Intel
Transactional Synchronization Extension (TSX) that isreadily available in most modern commodity CPUs. One
surprising behavior of TSX, which is essentially the root
cause of this security loophole, is that it aborts a transaction without notifying the underlying kernel even when
the transaction fails due to a critical error, such as a pagefault or an access violation, which traditionally requires
kernel intervention. DrK turned this property into a precise timing channel that can determine the mapping status(i.e., mapped versus unmapped) and execution status (i.e.,
executable versus non-executable) of the privileged, kernel address space. In addition to its surprising accuracy
and precision, DrK is universally applicable to all OSes,even on a virtualized environment, and generates no visible footprint, making it difficult to detect in practice. We
demonstrated that DrK could break KASLR of all major
OSes (i.e., Windows, Linux, and OS X) with near-perfectaccuracy in under a second. Finally, we propose a few
potential countermeasures that can effectively prevent or
mitigate the DrK attack.
We urge our community to be aware of the potential
threat of having Intel TSX, which is present in most recentIntel CPUs—100% in workstation and 60% in high-end
Intel CPUs since Skylake—and is even available on Ama-

2005

2007

Linux 2.6.12
User-space

OS X 10.5
User-space

iOS 5
User-space

OS X 10.8
Kernel-space

2011

2012

Linux 3.14
Kernel-space
2014

Years

Android 4.0
iOS 6
User-space Kernel-space

Figure 1: The adoption status of both user-space and kernelspace ASLR in popular operating systems, ordered by year [62].

zon EC2 (X1).

1

Introduction

Enhancing the security of operating systems (OSes) has
been an active, important research topic as the underlying
OS is commonly considered to be the Trusted Computing Base (TCB) for user applications and their security
mechanisms. Among various hardening techniques, Kernel Address Space Layout Randomization (KASLR) is
the most comprehensive but effective security mechanismthat raises a practical hurdle for exploiting memory corruption vulnerabilities [32, 33], such as buffer overflow
and use-after-free. In this regard, today’s major commodity OSes (e.g., Windows, Linux and OS X) as well as
mobile OSes (e.g., Android and iOS) have implemented
and deployed KASLR to protect the core kernel image
and their device drivers from exploitation (see Figure 1).
In principle, KASLR can effectively (i.e., statistically)
mitigate exploitation, as long as two assumptions hold: 1)
no memory disclosure vulnerability exists and 2) enoughentropy of the randomness is guaranteed. Therefore,
typical attacks against the kernel require a preceding attack, which focuses either on leaking code or data pointers [17, 41, 43] to directly figure out the memory layout, or on exploiting implementation caveats to indirectly
break the imperfect randomness [45], as a stepping stone
for the ultimate control-hijacking attack.
To the best of our knowledge, exploiting the cache1

Grade/Generation

SkylakeBroadwell

HaswellServer/Workstation
High-end Consumer
Low-end Consumer

17/17 (100.0%)
23/38 (60.1%)
4/32 (12.5%)

19/19 (100.0%)
11/22 (50.0%)
2/16 (12.5%)

37/85 (43.5%)
2/92 (2.2%)
0/79 (0.0%)(see Table 1). Our attack has higher precision (e.g., executable bits of pages), higher accuracy (e.g., near-prefectde-randomization of memory layout), and is faster (e.g.,under a second) than the state-of-the-art cache-based attack. More importantly, DrK does not generate distinctive
footprints that look abnormal to system monitoring tools,
and is universally applicable to all OSes, even under avirtualized environment (e.g., Amazon EC2).
The key idea of DrK is to exploit an unusual behavior
of TSX in handling erroneous situations inside a transaction. When a transaction aborts (typically due to read or
write conflicts), the CPU directly invokes an abort handler (specified by a user) to resolve such conflicts without
interrupting the underlying OS. However, even when an
unrecoverable error happens inside a transaction (e.g., an
access violation or a page fault), the CPU similarly aborts
the transaction without informing the underlying OS, although these errors traditionally require the interventionof the underlying OS.
In DrK, we turned this property into a better timing
channel, enabling us to precisely determine the mapping
status (i.e., mapped versus unmapped) and executablestatus (i.e., executable versus non-executable) of the privileged address space, by intentionally generating accessviolation inside a transaction (e.g., accessing or jumping
into kernel address regions).
In this paper, we make three significant contributions:• A practical attack. We demonstrate that DrK could
break KASLR of popular OSes, including the latest
Windows, Linux and OS X, with near-perfect accuracy and high precision with sub-second executiontime.
• Analysis. We provide an in-depth analysis of the
DrK attack with our hypothesis and designs of experiments. We show our results in three major OSesto understand the root cause (i.e., CPU internal architecture) of the timing differences.
• Countermeasures. Although we believe there
might be no practical software-based mitigation, we
propose a few hardware modifications that can effectively prevent a DrK attack.
The remainder of this paper is organized as follows. §2introduces KASLR and Intel TSX. §3 explains how ourattack works. §4 shows our evaluation results. §5 provides
an in-depth analysis of DrK to understand the hardware
characteristics. §6 proposes possible countermeasures.
§7 discusses the limitations of DrK. §8 compares it withother projects, and §9 concludes this paper.

Table 1: Commodity Intel CPUs supporting TSX, varying CPU
grades and generations (February 2016). Server CPUs include
Xeon and Pentium D server, high-end consumer CPUs include
i5 and i7, and low-end consumer CPUs include i3, m, and others.
All recent CPUs for server/workstation and more than half ofhigh-end consumer CPUs support TSX [29].

based timing channel [28] is the first attempt to universally break KASLR without violating the two fundamental assumptions. The key idea of the cache-based timing
attack is to exploit a timing difference (i.e., cache miss andhit) for accessing mapped (i.e., cached) and unmapped(i.e., not-cached) pages to determine page mapping status. More precisely, it deliberately fills or evicts certain
cache lines to indirectly affect the execution time in the
kernel space. Such timing differences can be observedby measuring how quickly a system call returns from thekernel space, or how quickly a faulty access to the kernel
space gets to the OS page fault handler. Under a typicalthreat model—local privilege escalation, this attack canbreak KASLR (i.e., leaking the partial bits of a randomized address) in theory, but it barely works in practicefor three reasons. First, it generates strong signals (e.g.,
segmentation faults and lots of system calls) that typicalsystem monitoring tools (e.g., fail2ban and sysdig) consider to be abnormal behavior, thereby resulting in prompt
mitigation.
Second, it requires a large page (2 MB) to accurately
locate the virtual address regions to intentionally generatecache conflicts to the targeted physical pages, which unfortunately requires higher privileges than a normal user
in most commodity OSes: hugetlbfs in Linux [57], and
SeLockMemoryPrivilege in Windows [13, 63].
Lastly, the attack is neither accurate (i.e., reversely
mapping a conflicted cache line to its preimage set) nor
fast enough (e.g., their double page fault attack took 17.3–
72.9 s to probe the entire kernel space of 32-bit Windows
7 in the carefully controlled environment) for practicaluse. In fact, these practical hurdles are the essential foundation of currently proposed software-based mitigation
schemes [28].
In this paper, we introduce a new timing attack against
KASLR, called DrK ([dIræk] De-Randomize Kernel address space), which is similar in spirit to the previous universal attack [28], but with higher accuracy and better performance. To break KASLR in an OS-agnostic way, DrK
exploits a timing side-channel in a new hardware feature,
called Intel Transactional Synchronization Extension (Intel TSX), that is widely deployed in modern Intel CPUs—in our survey, 100% of CPUs for server/workstation and
60% in high-end computers since Skylake have Intel TSX

2

BackgroundIn this section, we provide a technical overview of
KASLR and Intel TSX as a basis for understanding thetechnical details of the DrK attack.
2

OS

Types

Entropy#SlotsAddress Range

Align Base

Align SizeLinux

KernelModules

6 bits
10 bits64
1,024

0xffffffff80000000 – 0xffffffffc0000000
0xffffffffc0000000 – 0xffffffffc0400000

0x1000000
0x1000

16 MB
4 KB

Broken by DrK?
✓✓

(100.00%)(100.0%)Windows

KernelModules*13 bits*13 bits

8,192
8,192

0xfffff80000000000 – 0xfffff80400000000
0xfffff80000000000 – 0xfffff80400000000

0x200000
0x200000

2 MB
2 MB

✓
✓

(100.0%)(99.98%)OS X

Kernel8 bits256

0xffffff8000000000 – 0xffffff8020000000

0x200000

2 MB✓(100.0%)

Table 2: Summary of KASLR implementations in popular OSes. According to our experiment, all KASLR implementations wetested generate a random address by adding a random offset to the fixed base address (i.e., kernel or module base) either at thebooting time or when loading modules. The numbers marked in blue color indicate varying, randomized ranges, so called entropy.
(*) Johnson and Miller [32] reported that Windows has 17-bit worth of entropy for the kernel and 19-bit for modules, but we have
only observed 13-bit of entropy during our experiments.

2.1

1

Kernel ASLR

2
3

ASLR is a comprehensive, popular defense mechanismthat mitigates memory corruption attacks in a probabilisticmanner. To exploit a memory corruption vulnerability,
such as use-after-free, attackers need to figure out the
memory layout of a target process or the system aheadof time. ASLR mitigates such attacks by incorporatinga non-deterministic behavior in laying out the program’sor system’s address space. More specifically, whenevera program is loaded or a system is booted, the ASLR
mechanism randomizes their address spaces, includingcode and data pages.
Since ASLR is highly effective in practice, most real
exploits first have to bypass ASLR (or KASLR) before
attempting to launch a real control-hijacking attack, suchas return-oriented programming (ROP). For example,
most web browser exploits demonstrated in the latest
Pwn2Own competition [42, 44] include one or more information leak vulnerabilities to bypass KASLR, thereby
escaping a user-level sandbox. For this reason, all majorcommodity OSes, including Windows, Linux, and OS X,
as well as mobile OSes, including Android and iOS, have
deployed ASLR in user space and recently applied it tokernel space.
Adoption. Figure 1 shows the timeline of the ASLR
deployment in popular OSes. Microsoft started supporting KASLR since Windows Vista (2007) and Apple started its support from iOS 5 and OS X 10.8
(2012). Linux has provided KASLR as an option (i.e.,
CONFIG_RANDOMIZE_BASE=y) since kernel version 3.14
(2014) and, recently, popular distributions (e.g., Ubuntu
15.04) have enabled KASLR by default in their kernel.
Implementation. Table 2 summarizes how 64-bit commodity OSes implement KASLR for kernel text and modules in terms of entropy (i.e., amount of randomness) andgranularity (i.e., unit of randomization). The entropy of
KASLR is determined by the kernel address range (e.g.,
1 GB–16 GB) and the size of alignment, which is usuallya multiple of the page size (e.g., 4 KB–16 MB) for better performance and memory utilization. For example,
Linux’s kernel address range is 1 GB (30 bits) and its

4
5
6
7
8
9
10

// begin a transaction
if (_xbegin() == _XBEGIN_STARTED) {// the transaction starts...
// this transaction successfully terminated_xend();} else {// the transaction is aborted
abort_handler();}

Figure 2: A minimal code snippet that derives TSX: this example executes the code block in the if-statement transactionally,
meaning that any error inside the code block makes it roll back.

alignment size for kernel text is 16 MB (24 bits), so that
its KASLR entropy is only 6 bits (i.e., 64 slots for thelocation). In contrast, Windows 10’s kernel address range
is 16 GB (34 bits) and its alignment size for kernel text is
2 MB (21 bits), so that its KASLR entropy is 13 bits (i.e.,
8,192 slots for the location). Thus, a set of all possible
randomized base addresses is{base_address + s × align_size : 0 ≤ s < #slots}.

2.2Intel TSX

In this section, we explain the basic concept of IntelTSX to help understand the DrK attack. Intel TSX isIntel’s implementation of hardware transactional memory(HTM) [24, 37, 38, 58, 61]. HTM provides lock-lesssynchronization among threads by ensuring transactional
execution at the hardware level; i.e., it enables concurrent
access to the shared memory by multiple threads anddiscards any memory changes they made if a read-write
conflict, a write-write conflict, or any other error happens
during the transaction.
Note that this paper’s main concern is not how we effectively use TSX to process transactions, but how we
exploit the way it handles an exception, which accidentally exposes a clear, stable timing channel.
Example code. To explain our attack, we first introduce
how a transaction can be implemented by using TSX,
which we will use as a template for the actual attack. Figure 2 shows a minimal source snippet to run a transaction.
A transaction region starts with _xbegin() and terminates
when _xend() is invoked (i.e., committed). Then, all3

3.1

instructions (e.g., if-statement in Figure 2) in the transactional region are guaranteed to be atomically executed.
However, a transaction might fail (i.e., abort) as well: forexample, when two or more concurrent transactions affecteach other during the execution—a read-write or a writewrite conflict, depending on how they affect each other.
In such a case, it automatically rolls back the aborted
transactions (e.g., cleaning up the overwritten memory
space) and invokes an abort handler specified by a user(e.g., else-branch in Figure 2). The more interesting situation, in terms of security, is when erroneous situations
occur during the execution: for example, segmentation
faults, page faults, or even interrupts.
Suppressing exceptions. According to Intel’s manual([31, §15.3.7]), a transaction aborts when such a hardware exception occurs during the execution of the transaction. However, unlike normal situations where the OS
intervenes and handles these exceptions gracefully, TSX
instead invokes a user-specified abort handler, without
informing the underlying OS. More precisely, TSX treatsthese exceptions in a synchronous manner—immediately
executing an abort handler while suppressing the exception itself. In other words, the exception inside the transaction will not be communicated to the underlying OS. This
allows us to engage in abnormal behavior (e.g., attempting
to access privileged, i.e., kernel, memory regions) withoutworrying about crashing the program. In DrK, we break
KASLR by turning this surprising behavior into a timing
channel that leaks the status (e.g., mapped or unmapped)of all kernel pages.

3

Threat Model

The DrK attack is built on four realistic assumptions:
1. The attacker has unrestricted access to the local, userlevel, and non-root privilege execution environmentof the target system.
2. The attacker knows a memory corruption vulnerability in the kernel space, but needs to bypass KASLR
deployed in the target system in order to exploit thisvulnerability.
3. The attacker does not have any explicit way to figureout the kernel memory layout.
4. The attacker can gather the information of the target system: for example, the OS version or CPU
information.
This threat model is very realistic. For example,
the platform-as-a-service (PaaS) cloud services such as
Heroku [26] provide a local execution environment thatsatisfies all of the assumptions above. Similarly, theseassumptions hold true in exploiting the vulnerabilities inmodern web browsers due to their user-level sandbox;
the real exploits demonstrated in the Pwn2Own competition [42, 44] are performed under the same threat modelas the DrK attack. Moreover, the operating systems disallow user-level code to access to their kernel address
space information. In Ubuntu, access to /proc/kallsyms,
which shows all mappings of kernel space, is prohibitedto the non-root users. In Windows 10, there is a system call NtQuerySystemInformation() which allows anormal user to see the current mapping of the kernel.
However, in the LOW or UNTRUSTED integrity level that is
generally set as the running level of sandboxed applications (e.g., the renderer process of Google Chrome), it is
not allowed to access the system call to get the addresslayout of the kernel. We confirmed that DrK works insuch restricted integrity levels.

The DrK Attack

In this section, we provide a a high-level description of the
DrK attack, which breaks KASLR by exploiting a timing
channel in TSX. As explained in §2.2, when an exception
occurs inside a transaction, TSX aborts its execution and,
importantly, suppresses the exception (i.e., no OS intervention). The key idea of DrK is to measure the timing
difference in handling a transaction abort when attempting
to access mapped compared to unmapped kernel memory
regions inside the transaction. Accessing the kernel spacefrom a user process incurs an access violation (i.e., a pagefault), but TSX suppresses this exception and immediately invokes its abort handler. The mapping status of
the targeted kernel address results in a time difference(an order of a few hundred cycles) in invoking the abort
handler due to the subtleties in TSX’s micro-architecture(see §5). More importantly, this attack is not observableto the OS, as these exceptions are all suppressed. Furthermore, unlike prior attacks that only try to distinguishbetween mapped and unmapped pages, the DrK attack
can even extract the executable and non-executable bit ofevery kernel page.

3.2

Overview

Figure 3 shows a code snippet that we ran to probe akernel address for its mapping status. We perform two
types of access to a kernel address addr inside a TSX
region (if-statement, from _xbegin() to _xend()): (1) try
to execute on addr by running mov rax, addr; jmp rax(exec), and (2) try to read a value from addr by running
mov rax, [addr] (read). Note that since addr is a kernel
address, the access is not performed, instead generating
an exception, which makes the transaction abort.
We measure the timing between the initialization of the
TSX region (_xbegin()) and the abort handler (line 1516). Since the DrK attack relies on the timing difference
4

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

addr

// The given argument addr is an address for a kernel page.
uint64_t do_probe_memory(void *addr, mode_fn fn){// Timer starts
uint64_t beg = rdtsc_beg();// initiate TSX region
if (_xbegin() == _XBEGIN_STARTED) {// fn() performs either 1) or 2).
// 1) execute: mov rax, addr; jmp rax// 2) read: mov rax, [addr]
fn(addr);// commit TSX, which will never take place.
_xend();} else {// TSX aborted; end timer, return the timing.
return rdtsc_end() - beg;}errx(1, "Not reachable");}// probe the address for multiple times
uint64_t probe_memory(int ntimes, void *addr, mode_fn fn){
uint64_t min = (uint64_t)-1; // UINT64_MAX
while (ntimes --) {uint64_t clk = do_probe_memory(addr, fn);// Only record the minimum timing observed.
if (clk < min)min = clk;}
return min;}[read]★
>235 cycles<220 cycles
mapped(M)

unmapped(U)[jmp]★
<200 cycles>220 cycles

executable(X)

def probe(addr):
beg = rdtsc()
if _xbegin():[mode]★
else
end = rdtsc()
return end - beg

non-executable(NX)

Figure 4: An overview of the timing attack in DrK. From thetiming differences in calling TSX abort handler for read access(U/M) and execution access (X/NX) inside a transaction, theDrK attack can infer the memory layout of the OS, as wellas their permission status (i.e., executable or non-executable).
The numbers are collected on a system running Ubuntu 16.04
LTS (kernel 4.4.0), on Intel Core i7-6700K (Skylake) 4.0 GHz
processor.

OS Memory Spec.
Resource
budget(e.g., time)
input

Figure 3: Code snippet that probes timing for a kernel address
access. The access on address through fn(addr) always raise
an exception (i.e., access violation) which makes the transactionabort. In the DrK attack, we measure the minimum timing value
from multiple trials of probing for determining page mapping
status (e.g., 215 cycles for mapped region and 245 cycles forunmapped region).

addr

CPU Model
Knowledge Basedb

❶ Probingmemory❷ Determining
U/X/NX

Probe

Analysis

Memorymaps
outputFigure 5: Our attack consists of two steps: 1 Probing and 2
Analysis. 1 Given resource budgets provided by users (e.g.,time or iteration) and memory specification of the target OS(e.g., maps, types, and page size), we first probe the timing of
the TSX aborts in each memory region. 2 Then, with the premeasured knowledge base on the timing characteristics of each
CPU model, we determine the memory layout (e.g., mapped
regions) and status (e.g., executable regions).

on the hardware critical path (see §5), we measure theminimum timing for a memory page.
Figure 4 shows an example of how timing can determine the mapping status of a kernel page. First, we attempted to read a given kernel address. It took more than
235 cycles for unmapped pages and less than 220 cycles
for mapped pages. (see Figure 6a).
Next,
weattempted
toexecute(i.e.,
mov rax, addr; jmp rax) on a given kernel address. It
took less than 200 cycles for the executable pages andmore than 220 cycles if the page is non-executable (seeFigure 6b).
We observed a significant timing difference (±10%)that can be used for a timing channel to precisely identify
the mapping and executable permission status for a given
kernel address.
Probing strategy. Figure 5 shows how DrK works.
Basically, it consists of two steps: (1) collect timing information for the memory (probing step) and (2) determine
the kernel map using the timing information.
In (1) we first analyze the target OSes to determinesome invariant of the kernel address space layout. This
step is essential to avoid searching the entire 64-bit address space. For example, we can use the information in
Table 2 for largely reducing the random search space.
In the analysis step (2), we determine the mapping

status of the kernel address using the timing information
gathered in step (1). Note that the timing information
largely depends on the hardware characteristics (e.g., CPU
generation and clock frequency, see Table 3), so we needto know such information for the CPU. We can collectsuch information during an offline analysis and store it ina database.
Summary. The benefits of DrK, accuracy, covertness,
and OS-independence, come from the characteristics ofTSX. On accessing a kernel address, the occurrence ofa page fault inside the TSX region will directly call anabort-handling procedure in the user-space process without notifying the operating system. This shortcut not
only minimizes measuring noise but also probes any kernel address without the OS being aware of it and does
not rely on how an OS interrupt handler is implemented.
This is a clear advantage over Hund et al.’s attack against
KASLR [28], which relies on an OS interrupt handler,
leading to high noise, OS-awareness, and OS-dependency.
5CPU/Types

READ(mov rax,[addr])

JMP(mov rax,addr; jmp rax)

X

NX

<U

X<

NX

U

i7-6700K (4.0G, Skylake)
i5-6300HQ (2.3G, Skylake)
i7-5600U (2.6G, Broadwell)E3-1271v3 (3.6G, Haswell)

209
164
149
177

209
164
149
177

240
188
173
195

181
142
134
159

226
178
164
189

226
178
164
189

Table 3: The minimum observed timings over 1,000 iterationsof probing for the known kernel mappings, for each CPU. In
the DrK attack, we use timing differences to determine themapping status of the page. We measured the timings using
mov and jmp instructions, to observe the minimum timings forunmapped (U), non-executable (NX), and executable (X) pages.
The value indicates that having access with a mov instruction on
unmapped pages takes 18–31 more cycles (marked in red color)than the mapped pages. Likewise, the timing for executablepages on accessing with a jmp instruction takes 30–44 fewer
cycles (marked in blue color) than non-executable or unmapped
pages. Note that the values are observed minimums, namely, we
cannot observe the timings below the values per each mapping
status during the experiment.

4(a) Mapped vs. Unmapped

Attack Evaluation

We attempt to answer the following questions to evaluate
DrK:• How different are the TSX timing characteristics
across various CPU and OSes? (§4.1)• How effectively can DrK break KASLR of popular
OSes? (§4.2, §4.2.3)• How does DrK work in a virtualized environment(§4.3)?
• With what configuration does DrK give high precision (§4.4)?
• How much is DrK better than prior attacks on
KASLR (§4.5)?

4.1(b) Executable vs. Non-executable

Figure 6: Two timing graphs for measuring timings on Linuxkernel modules area, running on a Skylake (Core i7-6700K)
processor. The graph shows that the difference in the minimum
timing (see Table 3) is sufficient to set the threshold (the redline in each graph) for determining page mappings. In the uppergraph, the red line placed at 235 cycles clearly distinguishes the
mapped from the unmapped pages of the modules. Similarly, thered line placed at 210 cycles in the lower graph clearly separates
the executable pages from the non-executable ones (including
unmapped pages). We probed the timing on accessing each pagein the Linux kernel module area 100 times, while running kernel
version 4.4.0. Modules are loaded from 0xffffffffc0347000
to 0xffffffffc0bf9000, and the DrK attack breaks KASLR
with perfect (100%) accuracy.

Characteristics of the Timing Channel

The DrK attack uses timing information as an oracle fordetermining the mapping status of kernel memory pages.
We rely on the timing difference on accessing each typeof kernel page mappings: unmapped, mapped, and executable. A necessary condition that enables such a distinction is that there should be a prominent timing gap to
determine different mappings.
We observed that the timing channel measured with a
TSX abort handler has a significant gap between the different mappings. Table 3 shows the minimum timing that
we could observe on accessing each type of page mapping, across 4 types of processors over 1,000 times. There
are significant timing differences between mapped versus
unmapped pages, and executable versus non-executable(and unmapped) pages. When we attempted to access toarbitrary kernel memory pages using a mov instruction,
the timing differences between unmapped and mapped

pages were 18–31 cycles1 . Similarly, when we attempted
to execute arbitrary kernel memory pages using a jmp instruction, the timing differences between executable andnon-executable pages were 30–44 cycles.
While the timings depend on the architecture or clock
rate of the processor, the common characteristics of thetiming is that there is always a timing gap for the page
mapping types across different types of processors. Furthermore, the minimum number does not depend on the
OS settings. On running the experiment over multiple environments (different OSes, or under the Xen hypervisor),
we discovered that the timing is the characteristic of the
1 There was no difference between read and write attempts.

6CPU, and it did not depend on the OS (see §4.4).
The difference between minimum timings for eachpage mapping type can be exploited to determine thememory mapping status. For example, on an Intel Core
i7-6700K Skylake processor, probing on unmapped pages
always took more than 240 cycles. In contrast, probingon mapped pages took less than that, with a minimum of
209 cycles. Under this condition, if a page was probed
in 230 cycles, then it is a mapped page because for theunmapped page, it is impossible to take less than 240
cycles to probe it. Thus, we set the threshold to use indetermining page mapping status as a value less than theminimum timing of unmapped page. We also took theminimum timing of executable page for distinguishingexecutable and non-executable pages.
Figure 6 shows how the timing is measured for theactual memory pages, for 100 iterations of probing. On
probing mapped and unmapped pages (Figure 6(a)), we
set the horizontal (red) line at 235 cycles (less than theminimum of U), and use it as the threshold for mapped
pages. The line clearly separates the unmapped pages (theupper half) from the mapped pages (the lower half), andthere is a clear gap of 30 cycles between the halves. On
probing the executable permission status (Figure 6(b)),
we set 210 cycles (less than the minimum of NX) as thethreshold for executable pages. The red line on the threshold clearly separates the non-executable or unmapped
pages (the upper half) from the executable pages (thelower half), and there is a clear gap of 40 cycles between
them.
As shown in the graph, the timing channel is highly
consistent. Using this timing channel, the DrK attack canclearly determine the mapping status of a page and its executable permission by comparing measured timings withminimum threshold for the types of pages. On evaluating
DrK for breaking KASLR in the commodity OSes (in§4.2), we observed that the DrK attack can achieve 100%
accuracy in determining page mapping and executablestatus across multiple runs of the attacks.

4.2

Table 4 summarizes the result of the DrK attack
on various hardware and software configurations. In
short, the DrK attack demonstrates around 99%–100%
of accuracy—not just mapped and unmapped pages, butalso executable pages, independent to the OS—for determining kernel address mappings in all major OSes andeven in a virtualized environment, in few seconds withnear-perfect accuracy. To the best of our knowledge, thislevel of accuracy, speed, and generality in a cache timing
side-channel attack has never been demonstrated before.
1. Accuracy. The DrK attack is highly accurate. It canidentify the mapping status of a kernel address atthe page-level granularity. In comparing the result
from the DrK attack with the ground truth page table
mappings, we achieved 100% accuracy in detecting
the correct page mapping across the OSes and CPUs.
The high accuracy of DrK lets the attacker infer
more information about the kernel; for example, themapping addresses can be used for detecting theexact location of some kernel modules. The DrK
attack can accurately identify the location of thedriver code in Windows, by correctly determining
the base address of 97 specific drivers among a total
141 loaded drivers using the unique signature of
X/NX/U mapping size information.
2. Speed. DrK can scan the entire possible kernel allocation space of 64-bit OSes very quickly. For attacking the start address of the kernel image, i.e., getting
the ASLR slide, DrK is very fast: it only took 5 ms
to successfully identify the base address of the Linux
Kernel. For the full scanning of the Linux kerneland modules pages (around 6,000 pages), it took lessthan a second while achieving 100% accuracy.
3. Generality. DrK does not depend on software settings. The attack works well over the latest versionof all three commodity OSes (Windows, Linux, andOS X), and even worked on the virtualized environment (Linux guest under Xen HVM). The root causeof the timing channel in the DrK attack bounds to thehardware specifications; therefore, if the processor
supports TSX, then the system is vulnerable to theattack. This also indicates that the attack would bevery difficult to defeat using software-level countermeasures.

Breaking KASLR in Popular OSes

To demonstrate the feasibility of the DrK attack in realistic settings, we evaluated the attack on commodity 64-bit
OSes that use KASLR, namely, Linux kernel 4.4.0, Windows 10 10.0.10586, and Mac OS X El Capitan 10.11.4
2 . Furthermore, we also mounted the DrK attack on aLinux virtual machine (VM) running on Xen hardware
virtual machine (HVM) mode to test against cloud environment settings. This setting resembles that of an X1
instance [2] in the Amazon Elastic Compute Cloud (EC2),
which (will) support TSX on the cloud.

Attack strategy. The DrK attack consists of two stages.
First, we scan all possible slots of kernel pages mentioned
in Table 2 to find the base and the end address of bothkernel and drivers (modules). In this step, the base address (ASLR slide) is found. The second step is to obtain
more accurate mapping information at a page-level granularity. We try to measure the permission of each page

2 All tested operating systems are the latest version as of May 2016.

7

Accuracy
OS

CPU

Type

# Pages

M/U

M/U

X/NX/U

X/NX/U

KernelModuleKernelModule

Max M

Max X

# IterTime (s)ClockSkylake (i7-6700K)
Skylake (i7-6700K)
Skylake (i5-6300HQ)
Haswell (E3-1271 v3)

Kernel/Modules
Kernel/Modules
Kernel/Modules
Kernel/Modules

6,147
6,147
6,147
6,147

100.00%100.00%100.00%100.00%100.00%100.00%100.00%100.00%100.00%100.00%100.00%100.00%100.00%100.00%100.00%100.00%

235
235
183
192

210
210
163
177

100
20
100
100

0.54
0.45
0.63
0.53

3.9 GHz
3.9 GHz
3.0 GHz
3.9 GHz

Windows

Skylake (i5-6300HQ)Skylake (i5-6300HQ)Skylake (i5-6300HQ)

Kernel/Driver
Kernel/Driver
Kernel/Driver

34,25834,25834,258100.00%100.00%100.00%100.00%100.00%100.00%See (a)See (a)See (a)90.45%
98.60%
99.28%

183
183
183

163
163
163

100
500
1,000

4.96
22.5
45.9

2.8 GHz
2.8 GHz
2.8 GHzLinux Xen

Skylake (i5-6300HQ)Skylake (i5-6300HQ)
Haswell (E3-1271 v3)
Haswell (E3-1271 v3)

Kernel/Modules
Kernel/Modules
Kernel/Modules
Kernel/Modules

5,633
5,633
5,375
5,375

100.00%100.00%99.95%
99.99%

100.00%100.00%99.51%
100.00%99.98%
100.00%99.95%
99.99%

99.98%
100.00%99.51%
100.00%580 (b)580 (b)192
192

530 (b)530 (b)
177
177

100
500
100
500

1.68
3.70
0.94
1.45

2.3 GHz
2.3 GHz
3.6 GHz
3.6 GHzLinux
Windows
OS X

Skylake (i7-6700K)
Skylake (i5-6300HQ)Skylake (i7-6700K)

Kernel Base Addr
Kernel Base Addr
Kernel Base Addr

64
8,192
256

100.00%100.00%100.00%

-

-

-

235
183
235

-

100
100
100

5ms
797ms
31ms

3.9 GHz
3.0 GHz
3.9 GHzLinux

Table 4: Summary of the evaluation results of the DrK attack. To calculate the accuracy, we ran the full attack 10 times, thencalculated the geometric mean to show consistency of the result over multiple runs. To break KASLR in Linux, it took around a halfsecond with 100% accuracy in detecting the mapping status of each page. For Windows, while the attack on determining mapped /unmapped address resulted 100% accuracy over 100 probing iterations, the attack on the executable permission did not. Runningmore iterations gives better accuracy: 98.60% and 99.28% on 500, and 1,000 iterations respectively. The DrK attack also works wellin a virtualized environment. We ran Linux over a Xen hypervisor using two different kind of processors, and both resulted 100% of
accuracy over 500 iterations. For the last three rows, we only ran the DrK attack to find the base address of the kernel. It only took
5 ms for Linux, 31 ms for OS X, and 797 ms for Windows to find the ASLR slide. (a) In Windows, all pages of the kernel (HAL andntkrnlmp.exe) are mapped with executable permissions. Therefore, we did not run X/NX detection for the pages. (b) See §4.3 and§4.4 for the effect of frequency scaling on the timings.

starting from the base address to the end address. Then,
we compare the result with the ground truth information
extracted from page table entries to evaluate the accuracyof the DrK attack.
In the following, we describe in detail the experimentconfiguration, settings, and interesting issues and tricks
specific to each OS and virtualized environment.
4.2.1

end of module mapping area from this information, we
use the number of modules that is currently loaded in the
OS. This is available through a user level program lsmod,
which shows the list of currently loaded modules. If thenumber of detected unmapped region matches the total
number of modules, we set the end address at that point.
Windows. Unlike Linux, Windows does not have separated areas for kernel and driver mappings. Specifically, kernel pages and driver pages can both lie
in the same address range of 0xfffff80000000000–
0xfffff80400000000. To distinguish between kernel
pages and drivers, we use the following facts: 1) all kernel
pages in Windows are mapped with executable permission, 2) the kernel uses a page size of 2 MB, and its total
size is at most 6 pages (12 MB in size for the tested version of Windows 10), and 3) the kernel can either comefirst or come last.
Knowing this, we scan the whole available address
space from one end to the other, to find the first and thelast mapped pages in the area. If first and the last pages arefound, we look for a consecutive 12 MB area mapped withexecutable permissions at either end. This area contains
kernel pages. After the kernel page range is determined,
we know the remaining space that is mapped to be themodule area.

Finding the Base and End Address

We used the following OS-specific information to get thecurrent mapping range of the running OS (see Table 2).
Linux. In Linux, kernel and modules addresses are
mapped in different regions. The base address of the kernel is in the 0xffffffff80000000–0xffffffffc0000000
address range, and there are only 64 slots where the kernel
can start (aligned at 16 MB). For the modules, the baseaddress can start in the range of 0xffffffffc0000000–
0xffffffffc0400000, and 1,024 slots are available forbase addresses for the modules (aligned at 4 KB). To findthe base address of each region, we sequentially scanthose slots.
After successfully determining the base address of theregion, we find the end address of each region as follows.
For the kernel, since it is always mapped as a whole chunkin Linux, we set the first found unmapped page from thekernel base address as the end address of the kernel area.
For the modules, while each module is mapped as a chunk,there is a region of unmapped pages between the modules.
Thus, finding unmapped pages in the region can only tell
the number of modules loaded in the area. To identify the

OS X. For OS X, we only launched the attack tofind the base address (i.e., ASLR slide) of the kernel
image. Since the kernel can be mapped in the rangeof 0xffffff8000000000–0xffffff8020000000 over 256
slots, we scan them to find the first mapped address.
8Fine-grained module detection. The DrK attack allows for a very accurate picture of the kernel address
space layout. This can be further exploited to identify
the exact location of a specific module (driver). For example, from the mapping information, we can infer theaddresses of modules such as raid, drm, and libahci inLinux, and locating the drivers such as NTFS, pci, andmsrpc in Windows.
The DrK attack uses the size information of executable
and non-executable pages of the module as a signature.
Figure 7 shows the list of module mappings in Linux. In
Linux, module mapping always start with a code area(.text), which has executable permission. Subsequently,
areas such as .bss, .rodata with NX permission are
mapped. Note that the size of any single module is likely
different from that of the others. We set the size of X/NX
areas as the signature (e.g., X:0x2000 and NX:0x3000 for
i2c_hid module).
Among a total of 80 modules loaded in Ubuntu 16.04
LTS, we can determine the exact location of 29 modules
that have a unique size signature. However, the method
cannot detect modules with the same size. For example,
for the worst case, there were 27 modules with minimal
size which have a one page (0x1000) of X area and three
pages (0x3000) of NX area. Despite such a limitation,
this module detection can still be useful in the attacks
because the attacker can reduce the uncertainty of theaddress (from targeting 80 modules to only targeting 27
modules in the worst case).
For Windows, we can uniquely detect 97 drivers amonga total of 141 drivers using size-based driver signatures.
Since the kernel drivers of Windows have discardable
mappings after initialization, we cannot directly use thesame signature for detecting Linux kernel modules. Instead, we use two sizes that are unchanging during the
lifetime of the module to build the signature: 1) the total
size of the driver memory region (from start of the driver,
but before the start address of the next mapped driver),and the size of first contiguous executable region. On theexperiment, we observed 97 unique size signatures for
detecting the driver addresses.
A prior work [28] tried a similar method for detecting
kernel drivers on Windows. However, since the work cannot distinguish X pages from NX pages, their detection
result is far smaller (21) than ours (97). Detection of
X/NX gives much better precision for determining the location of the drivers, as it provides unique size signatures
for the drivers.

On all tested operating systems, finding the kernel baseand end address can be done very quickly. All scans werecompleted within several milliseconds (5 ms, 31 ms, and
797 ms in Linux, OS X and Windows, respectively).
4.2.2

Accuracy: Detecting Page Mappings

After discovering the base and the end address of kernel
mappings, we performed accuracy testing of the DrK
attack. Basically, we probed all mapped areas with DrK,
then compared the result from the attack to the groundtruth mappings extracted from the page tables.
Table 4 shows the result of our accuracy testing.
Linux. For Linux, we ran the attack on three different
CPUs (i7-6700K, i5-6300HQ, and E3-1271 v3), and on
the kernel version 4.4.0 running Ubuntu 16.04 LTS. DrK
measured 6,147 pages in total (3,075 for kernel and 3,072
pages for the modules) and it was able to identify their
mappings with 100% accuracy. In total, the attack tookaround a half second (from retrieving the base address todetermining all page permissions).
Windows. For Windows, we ran the DrK attack on Skylake i5-6300HQ processor running Windows 10 version
10.0.10586. Both kernel and drivers consisted of 34,258
pages (probing 8,192 of 2 MB pages for the base and end
addresses, and 26,066 pages for measuring 4 KB pages
for the module addresses) to be scanned. The total attack,including scanning slots for the base address and measuring each page, completed in under five seconds with
100 iterations of probing, which yields 100% (mapping)and 90.45% (executable) accuracy in detecting module
mappings.
Running more iterations on Windows gives better results in finding executable pages. When running 1,000
iterations on each page, it yields 99.28% accuracy in detecting executable pages, while taking long (45.9 s) for
probing.
4.2.3
1
2
3
4
5
6
7
8
9
10
11

Detecting Module Addresses// BASE_ADDR
END_ADDR
PERM
NAME
0xffffffffc035b000-0xffffffffc0360000 U
0xffffffffc0360000-0xffffffffc0364000 X libahci
0xffffffffc0364000-0xffffffffc0368000 NX libahci
0xffffffffc0368000-0xffffffffc036c000 U
0xffffffffc036c000-0xffffffffc036e000 X i2c_hid
0xffffffffc036e000-0xffffffffc0371000 NX i2c_hid
0xffffffffc0371000-0xffffffffc0376000 U
0xffffffffc0376000-0xffffffffc039a000 X drm
0xffffffffc039a000-0xffffffffc03cc000 NX drm
0xffffffffc03cc000-0xffffffffc03cd000 U

SIZE
4000
4000
2000
3000
24000
32000

4.3

Figure 7: List of module mappings in Linux kernel 4.4.0. Notethat the mapping is always done in the following sequence: X,
NX, U, and a chunk of unmapped pages separates the mappingsof consecutive modules. The sizes of X and NX pages arediverse by the modules.

DrK in Virtualized Environment

To test the feasibility of the DrK attack in a cloud environment, we carried out the attack on Linux running in a
hardware virtualized environment, i.e., HVM, under the
Xen hypervisor 4.4, to check whether the attack can be9Iterations# incorrect
Accuracy (%)

2

5

20

50

100

239
92.22

70
97.72

18
99.41

8
99.74

0
100.0

nally, probing with 100 iteration, the accuracy reached
100%.
Note that the number of iterations to achieve the perfectaccuracy depends on the environment, such as processor
generation or software settings for generating interruptsthat is asynchronously handled in TSX. For example,
unlike Haswell that needed 100 iterations to get the 100%
accuracy on Linux, Skylake only required 10 iterations
to achieve the perfect accuracy (see the second row on
Table 4). For the virtualized environment, the measured
accuracy is slightly lower than the bare-metal runningwith the same number (at 100) of iterations (100% vs99.95%). However, still, we can manage the noise byincreasing the number of iterations: e.g., 500 iterations
achieved 99.99%–100% accuracy.
Dynamic frequency scaling (i.e., Intel Speed Step orIntel Turbo Boost) also affects the timings. Since we use
the number of clock cycles (using rdtscp) to measuretiming, a change in the clock frequency would affect thetiming measurements [31, §17.14].
We solved this problem by making the processor busy.
We empirically observed that running two dummy loops
consuming 100% of CPU time was enough to maximize
the processor clock rate, and achieved the perfect accuracy
in this condition. This also implies that the DrK attack
works well with processors with high workload; i.e., when
the processor runs jobs other than the attacks.

Table 5: Achieved accuracy over the number of iterations for themodules pages (3,072 pages in total) of Linux Kernel 4.4.0 on
Haswell (Xeon E3-1271 v3) processor. Probing the address withmore iterations gives better accuracy. For measuring with only 2
iterations (minimum iterations to measure TLB cache hit), 239
mapped pages were detected as unmapped pages, which renders
92.22% of accuracy. With more iterations, such as 20, 50, and100, the number of incorrectly measured pages decreases as
18, 8, and 0, respectively. With 100 iterations, the DrK attack
achieves perfect accuracy on breaking KASLR.

launched within the VM. The setup emulates that of an
Amazon X1 instance [2]3 , which uses Xen hypervisor
on the TSX-enabled Haswell processor. We did the same
experiment with the test that we did on the Linux that runs
on a bare-metal machine, in two (Skylake and Haswell)systems.
Results. The DrK attack can detect 99.99%–100% of
kernel mappings in a virtualized environment. The accuracy is slightly lower than the bare-metal result. We
believe that the difference in accuracy is caused by thefactors that can affect TSX execution, such as virtualinterrupts generated by hypervisor (e.g., VMEXIT).
Interestingly, we observed that a Skylake laptop processor (Core i5-6300HQ) with Xen resulted in timings thatwere very different from other environments (Table 4).
We believe that this was due to speed throttling, i.e., Intel
Speed Step and Turbo Boost, because its clock rate waslower than the same processor in a bare-metal environment (2.3 GHz versus 3.0 GHz). We will cover moreissues on clock speed in §4.4.

4.4

4.5

Comparison with the Prior Attack

We summarize the evaluation result of the DrK attack bycomparing it with the prior attack presented by Hund etal. [28].
Speed and accuracy. The DrK attack took about 0.5
seconds in Linux and about 5 seconds in Windows toachieve 100% accuracy of detecting the full mapping
information of kernel and driver space. In contrast, theprior attack requires 17 seconds to obtain 96% accuracy.
Noise of the channel. Compare to the prior attack,
DrK is strong against measurement noise. As shownin Figure 6, the timing difference between mapped andunmapped pages was over 10% in DrK. In contrast, inthe prior attack, the timing difference between mapped
and unmapped pages was only around 1% (30–50 cycles
from 5,000 cycle), which can easily fluctuate.
Executable page detection.
Unlike the prior attack, DrK can distinguish executable pages from nonexecutable pages. Our new finding is to demonstrate an
accurate way of distinguishing executable pages from themapped pages, which allows an attacker to effectively
break KASLR, especially when detecting the exact location of kernel drivers.
Module detection. As mentioned in §4.2.3, DrK detected a larger number of drivers (97) than the prior attack

Controlling the Noise

Since DrK is a cache-based timing channel attack, it is
not free from the noise of the channel. On determining
page mapping status and executable status, we used theminimum cycle observed when probing the pages as thethreshold. However, occasionally, we observed measurement errors possibly due to hardware characteristics (e.g.,cache coherence traffic and cache conflict).
We minimized such measurement errors by probing acertain address multiple times. Table 5 shows how theaccuracy changes by the number of iterations. On the iteration 2, 239 mapped pages were detected as unmapped,among 3,072 pages in the scanned area (92.22% of accuracy). However, as the number of iterations increasedsuch as 5, 20, and 50, the number of mis-detected pages
was drastically reduced, 70, 18, and 8, respectively. Fi3 Although Amazon X1 instance is up on the day of May 18th, 2016,
the instance is available upon request. We tried to request access for theevaluation, but could not get the access on time.

10

READ
M

5.1

JUMP
NX

U

dTLB-loads
3,021,847 3,020,043 3,018,191 3,018,857
dTLB-load-misses
84 2,000,086
64
91
iTLB-loads
267
425
590 1,000,247
iTLB-load-misses
6
6
31
12
L1-icache-load-misses
1,092
1,027
1,157
1,190
L1-dcache-loads
3,021,885 3,020,081 3,018,229 3,018,895
L1-dcache-load-misses 1,000,856 1,000,787 1,002,456 1,000,603

3,025,769
109
272
1,000,175
1,391
3,025,807
1,002,539

Trace pointU

X

Table 6: The number of TLB and cache loads and misses when
DrK probes single kernel memory page 1,000,000 times, measured by hardware performance counters. Probing methods arereading mapped (M) and unmapped (U) pages, and jumping
into executable (X), non-executable (NX), and unmapped (U)pages. Tracepoints are data TLB loads/misses, instruction TLB
loads/misses, L1 instruction cache misses, and L1 data cacheload/misses. Reading of U page generated data TLB misses andjumping into NX page or U page generated instruction TLB
loads or misses. The remaining tracepoints were similar to eachother.

L1
icache

Fetch

NX
U
L2
cache

L2
TLB

Memory(page table)

M
Execution
Unit

MemoryUnit

L1dcacheL1
dTLB

Figure 8: Simplified Intel Skylake architecture including
pipeline and cache hierarchy. We omitted L2, last level, and anyother page table caches for simplicity. Each M, U, X, and NX indicates the locations where access violation checks are checkedaccording to our measurements. Note that decoded icache,which caches decoded micro-ops, is inside L1 icache [31].

Note that we were unable to measure L1-icache-loads
because all CPUs supporting TSX we had (listed in Table 3) did not support the counter for it. Table 6 summarizes the results measured in the Linux machine with Intel
Core i7-6700K (Skylake) 4.0 GHz CPU.

(5–21). This was because DrK had better accuracy thanthe prior attack and DrK was able to use not only size
signatures but also executable mapping status.

5

1. read a mapped kernel page
2. read an unmapped kernel page
3. jump into an executable kernel page
4. jump into a non-executable kernel page
5. jump into an unmapped kernel page.

1. dTLB-loads: the total number of attempts to load
data translation lookaside buffer (dTLB), including
cache hit on dTLB.
2. dTLB-load-misses: the number of failed attempts toload dTLB; cache miss on dTLB.
3. iTLB-loads: the total number of attempts to load instruction TLB (iTLB), including cache hit on iTLB.
4. iTLB-load-misses: the number of failed attempts toload iTLB; cache miss on iTLB.
5. L1-icache-load-misses: the number of failed attempts to load L1 instruction cache (icache), cache
miss on icache.
6. L1-dcache-loads: the total number of attempts toload L1 data cache (dcache), including dcache hit.
7. L1-dcache-load-misses: the number of failed attempts to load L1 dcache; dcache miss.

X

Instruction
Scheduler

We probed a memory page 1,000,000 times while measuring hardware events using the HPC. We tested thefollowing five of memory probings:

On probing, we set tracepoints to measure:

L1
iTLB

DecodedicacheDecodeMeasuring Hardware Events

5.2

Mapped versus Unmapped Pages

We conjecture that dTLB makes timings for mapped
and unmapped kernel pages differently, by its different
caching behavior on page mappings. As introduced in §3and §4, a TSX abort handler for a violation of reading
mapped kernel memory (M) was called faster than that fora violation of reading unmapped kernel memory (U). We
believe that the timing difference is originated by dTLB
hit on accessing a mapped memory (fast), and dTLB missfor an unmapped memory (slow).
Table 6 supports this hypothesis: while reading an unmapped (U) page generated a lot of (over two millions)dTLB misses (dTLB-load-misses, marked in red), accessing on a mapped page (M) was not. The counter showsthat the access to a mapped kernel memory is cached in
dTLB, and in subsequent probing, the page privilege ischecked with just accessing on dTLB. This results faster
determination of page fault exception. In contrast, theaccess to an unmapped kernel memory is not cached,In-depth Analysis of DrK

In this section we figure out what causes DrK observetiming differences. Since the internal characteristics of Intel processors are barely documented, we first take a look
into detailed measurements on hardware events during
the DrK attack using the hardware performance counter(HPC) (§5.1). Then, we analyzed the measurement results
to figure out what causes the time difference between
mapped and unmapped pages (§5.2) and between executable and non-executable pages (§5.3), in accordancewith a simplified Intel CPU architecture diagram (Figure 8).
11because it has no corresponding physical address to becached in dTLB. After suffering dTLB-miss, the probing
should wait until the processor seek the page table entry
then figuring out the page fault exception. Thus, a readattempt to an unmapped page took longer time for raising
the page fault exception (and calling TSX abort handler).
We note that this explanation corresponded to Hund etal. [28]’s finding.

case that other cores have updated the permission on thepage table. Walking through the page table resulted as
the page is non-executable, then the processor generates
a page fault exception.
U page takes the same path as the mapped versus unmapped case. After the iTLB miss, the processor walks
through the page table, figures out the address is not
mapped, and generates a page fault.

5.3

6

ExecutablePages

versusNon-executable

Potential Countermeasures

We discuss potential countermeasures against the DrK
attack. In summary, we see there are no effective countermeasures that can prevent DrK without hurting usability
and performance.

We conjecture that decoded icache is the hardware components that handle executable and non-executable kernel
pages differently, as shown in timing differences. In the
DrK attack, timing of probing executable (X) page wasmeasured as faster than that of non-executable (NX) page.
While it could be thought as caching in iTLB would generate such timing difference, nonetheless, it is not true.
Table 6 supports the hypothesis as follows.
iTLB is not the origin.
Unlike the result on
mapped/unmapped pages, jumping into X did not generate any additional iTLB loads (590 in iTLB-loads on 1 M
accesses). This means that iTLB hit did not even happen
on the probing. Moreover, although iTLB actually hits on
probing NX page, the timing of NX page is not as fast as
X. Further, although probing on U page generates many
iTLB misses, the timing of NX page and U was the same(see Table 3). This proves that iTLB is not the origin of
the timing channel.
Decoded icache for faster timing on X. Table 6 also
implies that, unlike executing NX and U, probing on X
did not need to translate the virtual address to the physical address to fetch instructions. From the observation,
we come up with a hypothesis that decoded icache is theorigin of the timing channel; decoded icache is the placein which fetched and decoded micro-ops are cached (Figure 8). On probing an executable memory page, once thepage is cached (in iTLB) and decoded, the processor nolonger needs to translate the address. Instead, it directly
fetches instructions from the decoded icache, however, theactual execution fails due to the access violation. Since
the probing only plays with cached data, the exception is
generated relatively faster than probing other page mappings.
Page walk for NX and U. We conjecture that page faults
for NX and U pages are generated when the processor
finished the page table walk, since their timings are thesame (Table 3). For a non-executable (NX) page, wehypothesize the flow as follows. Although the translation
is cached in iTLB, the cached page table entry is marked
as non-executable. Due to this mismatch, the processor isrequired to resolve the latest page table entry. Since there
is no coherency mechanism in TLB [25], there could be a

6.1

Eliminating Timing Channel

One of the most fundamental countermeasures against
DrK is eliminating any timing differences when probing
the kernel addresses at the user-level execution. When theIntel CPU handles exceptions for unprivileged accesses,
it takes different hardware paths according to whether
the accessed memory region is executable, mapped, or
unmapped. §5 shows our measurements about the differences in terms of the loads and misses of cache and
TLB.
Hardware modification. One possible way to flatten
the timing differences is modifying the hardware. For
example, we can change the CPU to not cache unprivileged accesses to kernel addresses, which makes every
unprivileged memory access take the same hardware path.
Any timing channel attacks, including DrK and Hund etal. [28], cannot observe timing differences and would
therefore fail. However, since this solution demands hardware modifications, it cannot protect already deployedCPUs from DrK.
Kernel page table separation. Another countermeasureagainst DrK is separating the kernel page table from a user
page table. If no kernel memory is mapped into a user
page table, DrK would have no chance to break KASLR.
However, the kernel address space is mapped into a user
page table to minimize the execution overhead of privileged instructions (e.g., system call). Without this, thesystem would need to flush TLBs whenever a user process
invokes a system call, which would significantly reduce
the overall system performance [6, 28]. For example, Xen
uses separated page tables for kernel and user processes
when a guest machine is a 64-bit para-virtualized machine(PVM), but this degrades system performance such thatthe 64-bit PVM is not recommended [47] for use. Therefore, It is impractical to adopt this countermeasure due toperformance degradation.
12

6.2

Monitoring Hardware Eventsbug (Erratum HSD136 in [30]). However, this solution
is problematic because TSX is already widely used; e.g.,glibc uses TSX in its pthread library for synchronization
and Java uses TSX for thread scheduling [35, 46].
Different caching policy. TSX only works with memory regions configured as write-back ([31, §15.3.8.2]),
which is a default configuration due to its efficiency. On
our experiment, we observed a few (288 pages among
26,066 pages in Windows) memory pages in driver area
configured as write-through or uncacheable and DrK misjudged them as unmapped pages. Although those pages
are not belong to any kernel drivers, (i.e., it does not affect on the accuracy evaluation) this implies that if an OS
makes the entire kernel memory either write-through or
uncachable, it can be secure against DrK. However, thisconfiguration is impractical, as it results in huge performance degradation [6].
Noisy timer. Finally, a noisy timer or coarse-grained
timer is a well-known countermeasure against timing attacks. The system can add some noise when returning atimer value or prevent a user program from using a finegrained timer (e.g., rdtsc). However, the noisy timer isjust a work-around such that it cannot completely prevent DrK. Also, many benign programs need to use finegrained timer, e.g., to precisely measure performance.

Modern CPUs provide HPC interfaces to monitor hardware events that occur inside a CPU, such as the numbers of retired instructions, taken branches, and cacheloads/misses. Although the OS cannot observe any pagefaults while being attacked by DrK, it can infer whether
DrK is being performed by using the hardware event information. For example, we identified that during the
DrK attack, a CPU generates lots of loads/misses onboth TLBs and the L1 i-cache (see Table 6). Further,the HPC provides information about the number of transactional aborts (tx-abort) generated by a CPU. This number would be large when the system is under attack by
DrK because each memory probing generates an abort.
However, monitoring hardware events has limitations
to detect DrK in terms of accuracy and performance. First,
a benign program can show a similar behavior with DrK
when it randomly accesses different memory regions or
heavily uses TSX. Further, DrK can cloak its behavior
by decreasing the frequency of memory probing. Thus,
the system cannot avoid false detection problems. Next,
monitoring all processes of the OS is unrealistic due tothe overhead of checking HPC: about 20% performance
overhead [60]. System-wide monitoring could reduce
the overhead, but, in that case, it is difficult to determine
which process engages in suspicious behavior.

6.3

Live Re-randomization
grained KASLR

and

7

Fine-

Limitations. DrK has some limitations. First, DrK
always treats uncachable, write-through, and paged-out
memory regions as unmapped. DrK relies on Intel TSX,
which only works with memory pages configured as writeback ([31, §15.3.8.2]). Thus, it cannot probe memory
pages configured as uncachable or write-through; its access to such memory pages always aborts. DrK also treats
swapped-out pages as unmapped because access to suchpages generates a page fault which aborts the transaction([31, §15.3.8.2]).
However, we did not observe write-through pages forcode and data area of kernel and drivers, in both Linuxand Windows, because write-through pages are slower
than write-back pages. Due to the performance issues,
kernel developers would not use the write-through pages
in general. Further, most of the important kernel pages,
such as kernel text, data, and drivers, are frequently used,
so they are usually kept in memory (i.e., not paged out).
Therefore, these limitations are negligible.
Breaking “security by memory obscurity”. DrK canalso be applied to launch an undetectable, crash-resistantmemory mapping probing [21]. Some system protection mechanisms, such as CPI [36], ASLR-Guard [40],and Kenali [54], assume a secret memory location thatthe attacker cannot know to store sensitive information

One possible approach to cope with DrK is to use finegrained ASLR and live re-randomization [23]. They not
only adjust the base addresses of kernel code and modules, but also randomize all kernel code, static data, stack,dynamic data, and modules while re-randomizing them
periodically.
However, as shown in Table 4, DrK only took around
0.5 seconds in Linux for detecting full page mappings
with 100% of accuracy. Moreover, to detect a single
module not the whole space, the attack can be more faster(proportional to the scan size). This implies that the OS
needs to re-randomize its address space more than once
per each second, which is problematic due to performance
overhead.

6.4

Discussions

Other Countermeasures

Lastly, we introduce a few mechanisms that can preventor mitigate DrK, but these are less practical.
Disabling TSX. The strongest countermeasure against
DrK, though a naïve one, is disabling TSX. As a CPU
manufacturer, Intel can disable the feature via a microcode
update or product line change. In fact, Intel had alreadydisabled TSX of the Haswell CPU due to its hardware
13

for integrity protection. However, using DrK, such anassumption could be broken if such a secret address is
not selected carefully, because the DrK attack can fully
search for the address space without any crash. We plan
to figure out how we can use DrK to break such protection
mechanisms.

8

to a long execution path inside the OS. Furthermore, thislets the OS know which user process frequently accesses
kernel memory pages, so that the OS can easily detect theattack.
In contrast, DrK uses a TSX abort handler to probe akernel memory page, whose execution path is shorter thanthat of OS page fault handler, making it less error-prone
and even able to recognize the small difference between
accessing executable and non-executable pages. Also, it
is difficult for the OS to detect DrK because it cannot
directly observe the behavior of DrK (§4).
In addition, Forgh and Gruss [19, 20] exploit theprefetch instruction on the processor, which loads a specific address into a certain cache level, to probe mapping information without causing exceptions. However,since the prefetch instruction targets data, this attack
cannot identify whether an address is executable or nonexecutable, unlike DrK.
One of the adCrash-resistant memory probing.
vantages of DrK is that it does not generate a crashwhen probing the kernel’s address space. Recently, Gawlik et al. [21] have shown a similar web attack for crashresistant memory probing. They found that memory access violations by some JavaScript methods do not crashmodern web browsers having fault-tolerant functionality, which allows for memory probing without a browser
crash. However, OSes can identify whether such an attack
is performed because it cannot suppress the exception,
unlike DrK. Also, as the authors mention, this attack canbe mitigated by limiting the number of faults that can becaused, checking the exception information, using guard
pages, and using memory safety solutions. However, noneof these approaches can mitigate DrK.
TSX timing channel. We found two blog articles [1, 64]
that depicted kernel timing attacks using TSX while we
conducted this research. Note that although this paper andthe two blog articles are based on similar observations,this work makes the following important contributions,unlike the blog articles which only conjecture that suchan attack is possible. First, we did comprehensive evaluations. We demonstrated and analyzed DrK with threedifferent Intel CPU generations (§4.1) in all major OSes(§4.2 and §4.2.3). Moreover, we give instructions oncontrolling the noise of timing channel to get the best precision (§4.4). Second, we showed what causes this timing
channel through experiments. We studied the architectureof the modern Intel CPU in depth and discovered which
execution paths lead to such a timing channel (§5). We
monitored the behavior of the Intel CPU in detail using
the HPC and checked its architectural details to figure out
the root cause. Lastly, we discovered that the TSX timing
channel can be used to determine whether a memory pageis executable or non-executable (§3 and §4). Note thatneither the two blog articles nor Hund et al. [28]’s work

Related WorkIn this section, we provide a comprehensive landscape of
past research related to the DrK attack.
Endless war in ASLR. Since the most modern OSes
adapt W⊕X and ASLR to prevent code injection andcode reuse attacks [12, 49, 51, 52], attackers and defenders continuously find new attacks to break ASLR
and develop countermeasures against them. Researchers
find that many ASLR implementations are insecure because they do not fully randomize address spaces (e.g.,shared libraries without ASLR and fixed memory allocation) and do not provide enough entropy (e.g., limited mapping range and large alignment size) to avoid
performance degradation. These make the ASLR implementations vulnerable to prediction and brute-force
attacks [9, 12, 18, 51, 52]. To prevent such attacks,
researchers propose fine-grained ASLR technologies
that randomize the location of functions [7, 34], basic
blocks [59], and even instructions and registers [27, 48].
On the other hand, researchers also discover that evenfine-grained ASLR can be broken by information leakvulnerabilities [50, 55], since they let attackers know derandomized addresses. By using it, Snow et al. [53]break the fine-grained ASLR. To mitigate such an attack, three kinds of schemes have been proposed: (1)dynamic (re-)randomization [4, 8, 16, 22, 23, 39] tomake leaked information useless, (2) execution-only memory [3, 11, 15] and destructive code read [56] to prevent
attackers from reading any code gadgets, and (3) pointerintegrity [14, 36, 40] to prevent code pointer manipulation.
In addition, researchers recently found that memoryde-duplication can be used to break ASLR without information leak vulnerabilities [5, 10].
Timing attacks against KASLR. Hund et al. [28]present a timing side channel attack against kernel space
ASLR, which is the work most relevant to DrK. The main
advantage of these timing attacks over the previous ASLR
attacks is that they neither relies on weak implementationsof ASLR nor information leak vulnerabilities.
Hund et al.’s attack and DrK focus on similar timing
differences caused by how a processor handles a pagefault for mapped compared to unmapped kernel memory
pages. However, unlike DrK, Hund et al.’s attack should
call the OS page fault handler whenever probing eachkernel memory page, which suffers from high noise due
14discovered this timing channel.

9[9] A. Bittau, A. Belay, A. Mashtizadeh, D. Mazières, and D. Boneh.
Hacking Blind. In Proceedings of the 35th IEEE Symposium on
Security and Privacy (Oakland), San Jose, CA, May 2014.
[10] E. Bosman, K. Razavi, H. Bos, and C. Giuffrida. Dedup Est
Machina: Memory Deduplication as an Advanced Exploitation
Vector. In Proceedings of the 37th IEEE Symposium on Security
and Privacy (Oakland), San Jose, CA, May 2016.
[11] K. Braden, S. Crane, L. Davi, M. Franz, P. Larsen, C. Liebchen,
and A.-R. Sadeghi. Leakage-Resilient Layout Randomization for
Mobile Devices. In Proceedings of the 2016 Annual Network andDistributed System Security Symposium (NDSS), San Diego, CA,
Feb. 2016.
[12] S. Checkoway, L. Davi, A. Dmitrienko, A.-R. Sadeghi,
H. Shacham, and M. Winandy. Return-Oriented Programming
without Returns. In Proceedings of the 17th ACM Conference on
Computer and Communications Security (CCS), Chicago, IL, Oct.
2010.
[13] R. Chen.
Some remarks on VirtualAlloc and MEM_LARGE_PAGES. https://blogs.msdn.microsoft.com/
oldnewthing/20110128-00/?p=11643.
[14] C. Cowan, S. Beattie, J. Johansen, and P. Wagle. PointGuardTM :Protecting Pointers From Buffer Overflow Vulnerabilities. In
Proceedings of the 12th USENIX Security Symposium (Security),
Washington, DC, Aug. 2003.
[15] S. Crane, C. Liebchen, A. Homescu, L. Davi, P. Larsen, A.-R.
Sadeghi, S. Brunthaler, and M. Franz. Readactor: Practical CodeRandomization Resilient to Memory Disclosure. In Proceedingsof the 36th IEEE Symposium on Security and Privacy (Oakland),San Jose, CA, May 2015.
[16] L. Davi, C. Liebchen, A.-R. Sadeghi, K. Z. Snow, and F. Monrose. Isomeron: Code Randomization Resilient to (Just-In-Time)
Return-Oriented Programming. In Proceedings of the 2015 Annual
Network and Distributed System Security Symposium (NDSS), San
Diego, CA, Feb. 2015.
[17] S. Esser. mach_port_kobject() and the Kernel Address Obfuscation. https://sektioneins.de/en/blog/14-12-23-mach_
port_kobject.html.
[18] I. Evans, S. Fingeret, J. Gonzalez, U. Otgonbaatar, T. Tang,
H. Shrobe, S. Sidiroglou-Douskos, M. Rinard, and H. Okhravi.
Missing the Point(er): On the Effectiveness of Code Pointer Integrity. In Proceedings of the 36th IEEE Symposium on Security
and Privacy (Oakland), San Jose, CA, May 2015.
Breaking KASLR with micro architecture[19] A. Fogh.
Part 1. http://dreamsofastone.blogspot.de/2016/02/
breaking-kasrl-with-micro-architecture.html.
[20] A. Fogh and D. Gruss. Using Undocumented CPU Behavior to See
Into Kernel Mode and Break KASLR in the Process. In Blackhat
USA, 2016.
[21] R. Gawlik, B. Kollenda, P. Koppe, B. Garmany, and T. Holz. Enabling Client-Side Crash-Resistance to Overcome Diversification
and Information Hiding. In Proceedings of the 2016 Annual Network and Distributed System Security Symposium (NDSS), San
Diego, CA, Feb. 2016.
[22] J. Gionta, W. Enck, and P. Ning. HideM: Protecting the Contentsof Userspace Memory in the Face of Disclosure Vulnerabilities. In
Proceedings of the 5th ACM Conference on Data and Application
Security and Privacy (CODASPY), 2015.
[23] C. Giuffrida, A. Kuijsten, and A. S. Tanenbaum. Enhanced Operating System Security Through Efficient and Fine-grained Address
Space Randomization. In Proceedings of the 21st USENIX Security Symposium (Security), Bellevue, WA, Aug. 2012.
[24] L. Guan, J. Lin, B. Luo, J. Jing, and J. Wang. Protecting Private
Keys against Memory Disclosure Attacks using Hardware Transactional Memory. In Proceedings of the 36th IEEE Symposium on
Security and Privacy (Oakland), San Jose, CA, May 2015.
[25] Henry. TLB and Pagewalk Coherence in x86 Processors. http://

Conclusion

To protect the kernel memory from the attacks in thewild, commodity OSes have adopted KASLR, which isproven to be a practical defense mechanism against many
memory corruption attacks. In this paper, we introduced
DrK, a timing side channel attack that almost perfectly
de-randomized KASLR using the Intel CPU’s new instruction set, TSX. Our evaluation showed DrK was much better than the prior side channel attack in terms of precision,
platform independence, covertness, and speed. We further analyzed which architectural characteristics exposedsuch timing differences and proposed a few hardware
modifications to eliminate it.
Responsible vulnerability disclosure. Following theguidance of responsible vulnerability disclosure, we havenot made public any findings or proof-of-concept code
discussed in this paper. We confidentially reported thevulnerability to through US-CERT (VU#954695) and Microsoft Security Response Center (MSRC) (Case 32737,
TRK:0001003139), and ready to share this manuscript
and work with affected vendors closely to resolve the
newly discovered security threat. After the public disclosure, we will release the source of the DrK attack to the
public.

References[1] Anababa. What Does Transactional Synchronization Extensions(TSX) Processor Technology Mean to Vulnerability Exploits (e.g.
Brute Forcing)?,. http://hypervsir.blogspot.com/2014/
11/what-does-transactional-synchronization.html.
[2] AWS Blog. Amazon EC2 X1 Instances. https://aws.amazon.
com/ec2/instance-types/x1/.
[3] M. Backes, T. Holz, B. Kollenda, P. Koppe, S. Nürnberger, and
J. Pewny. You Can Run but You Can’t Read: Preventing Disclosure
Exploits in Executable Code. In Proceedings of the 21st ACM
Conference on Computer and Communications Security (CCS),
Scottsdale, Arizona, Nov. 2014.
[4] M. Backes and S. Nürnberger. Oxymoron: Making Fine-Grained
Memory Randomization Practical by Allowing Code Sharing. In
Proceedings of the 23rd USENIX Security Symposium (Security),
San Diego, CA, Aug. 2014.
[5] A. Barresi, K. Razavi, M. Payer, and T. R. Gross. CAIN: Silently
breaking ASLR in the cloud. In 9th USENIX Workshop on Offensive Technologies (WOOT), Washington, D.C., Aug. 2015.
[6] K. Bhandari, D. R. Chakrabarti, and H.-J. Boehm. Implications ofCPU caching on byte-addressable non-volatile memory programming, 2012.
[7] S. Bhatkar, R. Sekar, and D. C. DuVarney. Efficient Techniques
for Comprehensive Protection from Memory Error Exploits. In
Proceedings of the 14th USENIX Security Symposium (Security),
Baltimore, MD, Aug. 2005.
[8] D. Bigelow, T. Hobson, R. Rudd, W. Streilein, and H. Okhravi.
Timely Rerandomization for Mitigating Memory Disclosures. In
Proceedings of the 22nd ACM Conference on Computer and Communications Security (CCS), Denver, Colorado, Oct. 2015.

15

[48] V. Pappas, M. Polychronakis, and A. D. Keromytis. Smashing
the Gadgets: Hindering Return-Oriented Programming Using InPlace Code Randomization. In Proceedings of the 33rd IEEE
Symposium on Security and Privacy (Oakland), San Francisco,
CA, May 2012.
[49] PaX Team. PaX address space layout randomization (ASLR),
2003. https://pax.grsecurity.net/docs/aslr.txt.
[50] F. J. Serna. The info leak era on software exploitation. In Blackhat
USA, 2012.
[51] H. Shacham. The Geometry of Innocent Flesh on the Bone:
Return-into-libc without Function Calls (on the x86). In Proceedings of the 14th ACM Conference on Computer and Communications Security (CCS), Alexandria, VA, Oct.–Nov. 2007.
[52] H. Shacham, M. Page, B. Pfaff, E.-J. Goh, N. Modadugu, and
D. Boneh. On the Effectiveness of Address-Space Randomization.
In Proceedings of the 11th ACM Conference on Computer andCommunications Security (CCS), Washington, DC, Oct. 2004.
[53] 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-Grained Address Space Layout Randomization. In
Proceedings of the 34th IEEE Symposium on Security and Privacy(Oakland), San Francisco, CA, May 2013.
[54] C. Song, B. Lee, K. Lu, W. R. Harris, T. Kim, and W. Lee. Enforcing Kernel Security Invariants with Data Flow Integrity. In
Proceedings of the 2016 Annual Network and Distributed System
Security Symposium (NDSS), San Diego, CA, Feb. 2016.
[55] R. Strackx, Y. Younan, P. Philippaerts, F. Piessens, S. Lachmund,and T. Walter. Breaking the Memory Secrecy Assumption. In
Proceedings of the Second European Workshop on System Security(EUROSEC), 2009.
[56] A. Tang, S. Sethumadhavan, and S. Stolfo. Heisenbyte: Thwarting Memory Disclosure Attacks using Destructive Code Reads.
In Proceedings of the 22nd ACM Conference on Computer andCommunications Security (CCS), Denver, Colorado, Oct. 2015.
[57] The Linux Kernel Archives. Huge Pages. https://www.kernel.
org/doc/Documentation/vm/hugetlbpage.txt.
[58] Z. Wang, H. Qian, J. Li, and H. Chen. Using Restricted Transactional Memory to Build a Scalable In-Memory Database. In
Proceedings of the ACM EuroSys Conference, Amsterdam, The
Netherlands, Apr. 2014.
[59] R. Wartell, V. Mohan, K. W. Hamlen, and Z. Lin. Binary Stirring:Self-randomizing Instruction Addresses of Legacy x86 Binary
Code. In Proceedings of the 19th ACM Conference on Computerand Communications Security (CCS), Raleigh, NC, Oct. 2012.
Linux perf event Features and Overhead,[60] V. Weaver.
2013. http://researcher.watson.ibm.com/researcher/files/us-ajvega/FastPath_Weaver_Talk.pdf.
[61] X. Wei, J. Shi, Y. Chen, R. Chen, and H. Chen. Fast In-memory
Transaction Processing using RDMA and HTM. In Proceedingsof the 25th ACM Symposium on Operating Systems Principles(SOSP), Monterey, CA, Oct. 2015.
[62] Wikiwand.
Address space layout randomization.
http://www.wikiwand.com/en/Address_space_layout_
randomization.
[63] Windows Dev Center. Creating a File Mapping Using Large
Pages.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa366543(v=vs.85).aspx.
[64] R. Wojtczuk.
TSX Improves Timing Attacks Against
KASLR.
https://labs.bromium.com/2014/10/27/
tsx-improves-timing-attacks-against-kaslr/.

blog.stuffedcow.net/2015/08/pagewalk-coherence/.
[26] Heroku. Heroku: Cloud Application Platform. https://www.
heroku.com/.
[27] J. Hiser, A. Nguyen-Tuong, M. Co, M. Hall, and J. W. Davidson.
ILR: Where’d My Gadgets Go? In Proceedings of the 33rd IEEE
Symposium on Security and Privacy (Oakland), San Francisco,
CA, May 2012.
[28] R. Hund, C. Willems, and T. Holz. Practical Timing Side Channel Attacks Against Kernel Space ASLR. In Proceedings of the34th IEEE Symposium on Security and Privacy (Oakland), San
Francisco, CA, May 2013.
[29] Intel. ARK | Your Source for Intel Protect Specifications. http://ark.intel.com.
[30] Intel Corporation. Desktop 4th Generation Intel CoreTM Processor Family, Desktop Intel Pentium Processor Family, and DesktopIntel Celeron Processor Family, 2015.
[31] Intel Corporation. Intel 64 and IA-32 Architectures Developer’s
Manual, 2015.
[32] K. Johnson and M. Miller. Exploit Mitigation Improvements in
Windows 8. In Black Hat USA, 2012.
[33] D. Keuper. XNU: a security evaluation. 2012.
[34] C. Kil, J. Jun, C. Bookholt, J. Xu, and P. Ning. Address spacelayout permutation (ASLP): Towards fine-grained randomizationof commodity software. In Proceedings of the Annual Computer
Security Applications Conference (ACSAC), Chicago, IL, Dec.
2006.
[35] A. Kleen. Lock elision in the GNU C library, 2013. https://lwn.net/Articles/534758/.
[36] V. Kuznetsov, L. Szekeres, M. Payer, G. Candea, R. Sekar, andD. Song. Code-Pointer Integrity. In Proceedings of the 11th
Symposium on Operating Systems Design and Implementation(OSDI), Broomfield, Colorado, Oct. 2014.
[37] V. Leis, A. Kemper, and T. Neumann. Exploiting Hardware Transactional Memory in Main-Memory Databases. In Proceedingsof the 30th IEEE International Conference on Data Engineering
Workshop, Chicago, IL, Mar.–Apr. 2014.
[38] Y. Liu, Y. Xia, H. Guan, B. Zang, and H. Chen. Concurrent andConsistent Virtual Machine Introspection with Hardware Transactional Memory. In Proceedings of the 20th IEEE Symposium on
High Performance Computer Architecture (HPCA), Orlando, FL,
USA, Feb. 2014.
[39] K. Lu, S. Nurnberger, M. Backes, and W. Lee. How to Make
ASLR Win the Clone Wars: Runtime Re-Randomization. In
Proceedings of the 2016 Annual Network and Distributed System
Security Symposium (NDSS), San Diego, CA, Feb. 2016.
[40] K. Lu, C. Song, B. Lee, S. P. Chung, T. Kim, and W. Lee. ASLRGuard: Stopping Address Space Leakage for Code Reuse Attacks.
In Proceedings of the 22nd ACM Conference on Computer andCommunications Security (CCS), Denver, Colorado, Oct. 2015.
[41] MITRE Corporation. CVE-2015-1097. https://cve.mitre.
org/cgi-bin/cvename.cgi?name=CVE-2015-1097.
[42] MITRE Corporation. CVE-2015-1674. http://www.cve.
mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1674.
[43] MITRE Corporation. CVE-2015-8569. https://cve.mitre.
org/cgi-bin/cvename.cgi?name=CVE-2015-8569.
[44] MITRE Corporation. CVE-2016-0175. http://www.cve.
mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0175.
[45] NES CONSEIL.
Bypassing Windows 7 Kernel ASLR.
https://dl.packetstormsecurity.net/papers/bypass/
NES-BypassWin7KernelAslr.pdf.
[46] Oracle. Java Platform, Standard Edition Tools Reference.
https://docs.oracle.com/javase/8/docs/technotes/
tools/unix/java.html.
[47] Oracle.
Oracle VM Performance and Tuning - Part
5.
https://blogs.oracle.com/jsavit/entry/oracle_
vm_performance_and_tuning4.

16