SCIENCE PASSION TECHNOLOGY Microarchitectural Attacks: From the Basics to Arbitrary Read and Write Primitives without any Software Bugs Daniel Gruss June 19, 2018 Graz University of Technology 1 Daniel Gruss — Graz University of Technology
SCIENCE PASSION TECHNOLOGY
Microarchitectural Attacks:
From the Basics to Arbitrary Read and Write Primitives without any Software Bugs
Daniel Gruss
June 19, 2018
Graz University of Technology
1 Daniel Gruss — Graz University of Technology
2 Daniel Gruss — Graz University of Technology
2 Daniel Gruss — Graz University of Technology
2 Daniel Gruss — Graz University of Technology
2 Daniel Gruss — Graz University of Technology
1337 4242
Revolutionary concept!
Store your food at home, never go to the grocery store during cooking.
Can store ALL kinds of food.
ONLY TODAY INSTEAD OF $1,300
ORDER VIA PHONE: +555 12345
2 Daniel Gruss — Graz University of Technology
CPU Cache www.tugraz.at
printf("%d", i);
printf("%d", i);
3 Daniel Gruss — Graz University of Technology
CPU Cache www.tugraz.at
printf("%d", i);Cache
miss
printf("%d", i);
3 Daniel Gruss — Graz University of Technology
CPU Cache www.tugraz.at
printf("%d", i);Cache
miss Request
printf("%d", i);
3 Daniel Gruss — Graz University of Technology
CPU Cache www.tugraz.at
printf("%d", i);Cache
miss Request
Response
printf("%d", i);
3 Daniel Gruss — Graz University of Technology
CPU Cache www.tugraz.at
printf("%d", i);Cache
miss Request
Responsei
printf("%d", i);
3 Daniel Gruss — Graz University of Technology
CPU Cache www.tugraz.at
printf("%d", i);Cache
miss Request
Responsei
printf("%d", i);
Cache hit
3 Daniel Gruss — Graz University of Technology
CPU Cache www.tugraz.at
printf("%d", i);Cache
miss Request
Responsei
printf("%d", i);
Cache hit
DRAM access,slow
3 Daniel Gruss — Graz University of Technology
CPU Cache www.tugraz.at
printf("%d", i);Cache
miss Request
Responsei
printf("%d", i);
Cache hit
No DRAM access,
much faster
DRAM access,slow
3 Daniel Gruss — Graz University of Technology
Flush+Reload www.tugraz.at
Shared Memory
ATTACKER VICTIM
flushaccess
access
4 Daniel Gruss — Graz University of Technology
Flush+Reload www.tugraz.at
Shared Memory
ATTACKER
Shared Memory
cached
cached
VICTIM
flushaccess
access
4 Daniel Gruss — Graz University of Technology
Flush+Reload www.tugraz.at
Shared Memory
ATTACKER
Shared Memory
VICTIM
flushaccess
access
4 Daniel Gruss — Graz University of Technology
Flush+Reload www.tugraz.at
Shared Memory
ATTACKER VICTIM
flushaccess
access
4 Daniel Gruss — Graz University of Technology
Flush+Reload www.tugraz.at
Shared Memory
ATTACKER VICTIM
flushaccess
access
4 Daniel Gruss — Graz University of Technology
Flush+Reload www.tugraz.at
Shared Memory
ATTACKER
Shared Memory
VICTIM
flushaccess
access
4 Daniel Gruss — Graz University of Technology
Flush+Reload www.tugraz.at
Shared Memory
ATTACKER
Shared Memory
VICTIM
flushaccess
access
4 Daniel Gruss — Graz University of Technology
Flush+Reload www.tugraz.at
Shared Memory
ATTACKER
Shared Memory
VICTIM
flushaccess
access
fast if victim accessed data,slow otherwise
4 Daniel Gruss — Graz University of Technology
Memory Access Latency www.tugraz.at
50 100 150 200 250 300 350 400
101
104
107
Access time [CPU cycles]
Nu
mb
erof
acce
sses
Cache Hits
5 Daniel Gruss — Graz University of Technology
Memory Access Latency www.tugraz.at
50 100 150 200 250 300 350 400
101
104
107
Access time [CPU cycles]
Nu
mb
erof
acce
sses
Cache Hits Cache Misses
5 Daniel Gruss — Graz University of Technology
Cache Template Attack Demo
Cache Template www.tugraz.at
Address
Keyg h i j k l m n o p q r s t u v w x y z
0x7c680
0x7c6c0
0x7c700
0x7c740
0x7c780
0x7c7c0
0x7c800
0x7c840
0x7c880
0x7c8c0
0x7c900
0x7c940
0x7c980
0x7c9c0
0x7ca00
0x7cb80
0x7cc40
0x7cc80
0x7ccc0
0x7cd00
7 Daniel Gruss — Graz University of Technology
Back to Work
7 Daniel Gruss — Graz University of Technology
7 Daniel Gruss — Graz University of Technology
7 Daniel Gruss — Graz University of Technology
Wait for an hour
7 Daniel Gruss — Graz University of Technology
Wait for an hour
LATENCY
7 Daniel Gruss — Graz University of Technology
7 Daniel Gruss — Graz University of Technology
ParallelizeD
epen
denc
y
7 Daniel Gruss — Graz University of Technology
Out-of-order Execution www.tugraz.at
1 int width = 10, height = 5;
2
3 float diagonal = sqrt(width * width
4 + height * height);
5 int area = width * height;
6
7 printf("Area %d x %d = %d\n", width , height , area);
8 Daniel Gruss — Graz University of Technology
Out-of-order Execution www.tugraz.at
1 int width = 10, height = 5;
2
3 float diagonal = sqrt(width * width
4 + height * height);
5 int area = width * height;
6
7 printf("Area %d x %d = %d\n", width , height , area);
ParallelizeD
epen
denc
y
8 Daniel Gruss — Graz University of Technology
Building Meltdown www.tugraz.at
1 char data = *(char*)0xffffffff81a000e0;
2 printf("%c\n", data);
1 segfault at ffffffff81a000e0 ip 0000000000400535
2 sp 00007 ffce4a80610 error 5 in reader
• Kernel addresses are not accessible
• Are privilege checks also done when executing instructions out of order?
9 Daniel Gruss — Graz University of Technology
Building Meltdown www.tugraz.at
1 char data = *(char*)0xffffffff81a000e0;
2 printf("%c\n", data);
1 segfault at ffffffff81a000e0 ip 0000000000400535
2 sp 00007 ffce4a80610 error 5 in reader
• Kernel addresses are not accessible
• Are privilege checks also done when executing instructions out of order?
9 Daniel Gruss — Graz University of Technology
Building Meltdown www.tugraz.at
1 char data = *(char*)0xffffffff81a000e0;
2 printf("%c\n", data);
1 segfault at ffffffff81a000e0 ip 0000000000400535
2 sp 00007 ffce4a80610 error 5 in reader
• Kernel addresses are not accessible
• Are privilege checks also done when executing instructions out of order?
9 Daniel Gruss — Graz University of Technology
Building Meltdown www.tugraz.at
1 char data = *(char*)0xffffffff81a000e0;
2 printf("%c\n", data);
1 segfault at ffffffff81a000e0 ip 0000000000400535
2 sp 00007 ffce4a80610 error 5 in reader
• Kernel addresses are not accessible
• Are privilege checks also done when executing instructions out of order?
9 Daniel Gruss — Graz University of Technology
Building Meltdown www.tugraz.at
• Adapted code
1 *( volatile char*)0;
2 array [84 * 4096] = 0; // unreachable
• Static code analyzer is not happy
1 warn ing : De r e f e r e n c e o f n u l l p o i n t e r
2 ∗( v o l a t i l e char ∗) 0 ;
10 Daniel Gruss — Graz University of Technology
Building Meltdown www.tugraz.at
• Adapted code
1 *( volatile char*)0;
2 array [84 * 4096] = 0; // unreachable
• Static code analyzer is not happy
1 warn ing : De r e f e r e n c e o f n u l l p o i n t e r
2 ∗( v o l a t i l e char ∗) 0 ;
10 Daniel Gruss — Graz University of Technology
Building Meltdown www.tugraz.at
• Flush+Reload over all pages of the array
0 50 100 150 200 250
300
400
500
Page
Accesstime
[cycles]
• “Unreachable” code line was actually executed
• Exception was only thrown afterwards
11 Daniel Gruss — Graz University of Technology
Building Meltdown www.tugraz.at
• Flush+Reload over all pages of the array
0 50 100 150 200 250
300
400
500
Page
Accesstime
[cycles]
• “Unreachable” code line was actually executed
• Exception was only thrown afterwards
11 Daniel Gruss — Graz University of Technology
Building Meltdown www.tugraz.at
• Combine the two things
1 char data = *(char*)0xffffffff81a000e0;
2 array[data * 4096] = 0;
• Then check whether any part of array is cached
12 Daniel Gruss — Graz University of Technology
Building Meltdown www.tugraz.at
• Combine the two things
1 char data = *(char*)0xffffffff81a000e0;
2 array[data * 4096] = 0;
• Then check whether any part of array is cached
12 Daniel Gruss — Graz University of Technology
Building Meltdown www.tugraz.at
• Flush+Reload over all pages of the array
0 50 100 150 200 250
300
400
500
Page
Accesstime
[cycles]
• Index of cache hit reveals data
• Permission check is in some cases not fast enough
13 Daniel Gruss — Graz University of Technology
Building Meltdown www.tugraz.at
• Flush+Reload over all pages of the array
0 50 100 150 200 250
300
400
500
Page
Accesstime
[cycles]
• Index of cache hit reveals data
• Permission check is in some cases not fast enough
13 Daniel Gruss — Graz University of Technology
Leaking Passwords from your Password Manager www.tugraz.at
18 Daniel Gruss — Graz University of Technology
How to mitigate Meltdown?
18 Daniel Gruss — Graz University of Technology
Take the kernel addresses... www.tugraz.at
• Kernel addresses in user space are a problem
• Why don’t we take the kernel addresses...
19 Daniel Gruss — Graz University of Technology
Take the kernel addresses... www.tugraz.at
• Kernel addresses in user space are a problem
• Why don’t we take the kernel addresses...
19 Daniel Gruss — Graz University of Technology
...and remove them www.tugraz.at
• ...and remove them if not needed?
• User accessible check in hardware is not reliable
20 Daniel Gruss — Graz University of Technology
...and remove them www.tugraz.at
• ...and remove them if not needed?
• User accessible check in hardware is not reliable
20 Daniel Gruss — Graz University of Technology
20 Daniel Gruss — Graz University of Technology
20 Daniel Gruss — Graz University of Technology
Kernel Address Isolation to have Side channels Efficiently Removed
20 Daniel Gruss — Graz University of Technology
Kernel Address Isolation to have Side channels Efficiently Removed
KAISER /ˈkʌɪzə/1. [german] Emperor,ruler of an empire2. largest penguin, emperor penguin
20 Daniel Gruss — Graz University of Technology
KAISER Illustration www.tugraz.at
Without KAISER:
Shared address space
User memory Kernel memory
0 −1
context switch
With KAISER:
User address space
User memory Not mapped
0 −1
Kernel address space
SMAP + SMEP Kernel memory
0 −1
context switch
switch
addr.
space
Interrupt
dispatcher
21 Daniel Gruss — Graz University of Technology
Kernel Address Space Isolation www.tugraz.at
• We published KAISER in July 2017
• Intel and others improved and merged it into Linux as KPTI (Kernel
Page Table Isolation)
• Microsoft implemented similar concept in Windows 10
• Apple implemented it in macOS 10.13.2 and called it “Double Map”
• All share the same idea: switching address spaces on context switch
22 Daniel Gruss — Graz University of Technology
Kernel Address Space Isolation www.tugraz.at
• We published KAISER in July 2017
• Intel and others improved and merged it into Linux as KPTI (Kernel
Page Table Isolation)
• Microsoft implemented similar concept in Windows 10
• Apple implemented it in macOS 10.13.2 and called it “Double Map”
• All share the same idea: switching address spaces on context switch
22 Daniel Gruss — Graz University of Technology
Kernel Address Space Isolation www.tugraz.at
• We published KAISER in July 2017
• Intel and others improved and merged it into Linux as KPTI (Kernel
Page Table Isolation)
• Microsoft implemented similar concept in Windows 10
• Apple implemented it in macOS 10.13.2 and called it “Double Map”
• All share the same idea: switching address spaces on context switch
22 Daniel Gruss — Graz University of Technology
Kernel Address Space Isolation www.tugraz.at
• We published KAISER in July 2017
• Intel and others improved and merged it into Linux as KPTI (Kernel
Page Table Isolation)
• Microsoft implemented similar concept in Windows 10
• Apple implemented it in macOS 10.13.2 and called it “Double Map”
• All share the same idea: switching address spaces on context switch
22 Daniel Gruss — Graz University of Technology
Kernel Address Space Isolation www.tugraz.at
• We published KAISER in July 2017
• Intel and others improved and merged it into Linux as KPTI (Kernel
Page Table Isolation)
• Microsoft implemented similar concept in Windows 10
• Apple implemented it in macOS 10.13.2 and called it “Double Map”
• All share the same idea: switching address spaces on context switch
22 Daniel Gruss — Graz University of Technology
Meltdown and Spectre www.tugraz.at
23 Daniel Gruss — Graz University of Technology
Meltdown and Spectre www.tugraz.at
23 Daniel Gruss — Graz University of Technology
23 Daniel Gruss — Graz University of Technology
Prosciutto23 Daniel Gruss — Graz University of Technology
Funghi23 Daniel Gruss — Graz University of Technology
Diavolo23 Daniel Gruss — Graz University of Technology
Diavolo23 Daniel Gruss — Graz University of Technology
Diavolo23 Daniel Gruss — Graz University of Technology
Diavolo23 Daniel Gruss — Graz University of Technology
»A table for 6 please«
23 Daniel Gruss — Graz University of Technology
23 Daniel Gruss — Graz University of Technology
Speculative Cooking
23 Daniel Gruss — Graz University of Technology
»A table for 6 please«
23 Daniel Gruss — Graz University of Technology
23 Daniel Gruss — Graz University of Technology
23 Daniel Gruss — Graz University of Technology
23 Daniel Gruss — Graz University of Technology
23 Daniel Gruss — Graz University of Technology
What does Spectre do? www.tugraz.at
• Mistrains branch prediction
• CPU speculatively executes code which should not be executed
• Can also mistrain indirect calls
→ Spectre “convinces” program to execute code
24 Daniel Gruss — Graz University of Technology
What does Spectre do? www.tugraz.at
• Mistrains branch prediction
• CPU speculatively executes code which should not be executed
• Can also mistrain indirect calls
→ Spectre “convinces” program to execute code
24 Daniel Gruss — Graz University of Technology
What does Spectre do? www.tugraz.at
• Mistrains branch prediction
• CPU speculatively executes code which should not be executed
• Can also mistrain indirect calls
→ Spectre “convinces” program to execute code
24 Daniel Gruss — Graz University of Technology
What does Spectre do? www.tugraz.at
• Mistrains branch prediction
• CPU speculatively executes code which should not be executed
• Can also mistrain indirect calls
→ Spectre “convinces” program to execute code
24 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
index = 0;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
index = 0;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
Speculate
index = 0;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
Execute
index = 0;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
index = 1;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
index = 1;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
Speculate
index = 1;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
index = 1;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
index = 2;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
index = 2;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
Speculate
index = 2;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
index = 2;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
index = 3;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
index = 3;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
Speculate
index = 3;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
index = 3;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
index = 4;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
index = 4;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
Speculate
index = 4;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
Execute
index = 4;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
index = 5;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
index = 5;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
Speculate
index = 5;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
Execute
index = 5;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
index = 6;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
index = 6;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
Speculate
index = 6;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 1) www.tugraz.at
Execute
index = 6;
if (index < 4)
char* data = "textKEY";
LUT[data[index] * 4096] 0
then
else
Prediction
25 Daniel Gruss — Graz University of Technology
Spectre (variant 2) www.tugraz.at
a->move()
Animal* a = bird;
LUT[data[index] * 4096] 0
fly()
Prediction
swim()swim
()
26 Daniel Gruss — Graz University of Technology
Spectre (variant 2) www.tugraz.at
Speculate
a->move()
Animal* a = bird;
LUT[data[index] * 4096] 0
fly()
Prediction
swim()swim
()
26 Daniel Gruss — Graz University of Technology
Spectre (variant 2) www.tugraz.at
a->move()
Animal* a = bird;
LUT[data[index] * 4096] 0
fly()
Prediction
swim()swim
()
26 Daniel Gruss — Graz University of Technology
Spectre (variant 2) www.tugraz.at
Execute
a->move()
Animal* a = bird;
LUT[data[index] * 4096] 0
fly()
Prediction
swim()swim
()
26 Daniel Gruss — Graz University of Technology
Spectre (variant 2) www.tugraz.at
a->move()
Animal* a = bird;
LUT[data[index] * 4096] 0
fly()
Prediction
fly()swim
()
26 Daniel Gruss — Graz University of Technology
Spectre (variant 2) www.tugraz.at
Speculate
a->move()
Animal* a = bird;
LUT[data[index] * 4096] 0
fly()
Prediction
fly()swim
()
26 Daniel Gruss — Graz University of Technology
Spectre (variant 2) www.tugraz.at
a->move()
Animal* a = bird;
LUT[data[index] * 4096] 0
fly()
Prediction
fly()swim
()
26 Daniel Gruss — Graz University of Technology
Spectre (variant 2) www.tugraz.at
a->move()
Animal* a = fish;
LUT[data[index] * 4096] 0
fly()
Prediction
fly()swim
()
26 Daniel Gruss — Graz University of Technology
Spectre (variant 2) www.tugraz.at
Speculate
a->move()
Animal* a = fish;
LUT[data[index] * 4096] 0
fly()
Prediction
fly()swim
()
26 Daniel Gruss — Graz University of Technology
Spectre (variant 2) www.tugraz.at
a->move()
Animal* a = fish;
LUT[data[index] * 4096] 0
fly()
Prediction
fly()swim
()
26 Daniel Gruss — Graz University of Technology
Spectre (variant 2) www.tugraz.at
Execute
a->move()
Animal* a = fish;
LUT[data[index] * 4096] 0
fly()
Prediction
fly()swim
()
26 Daniel Gruss — Graz University of Technology
Spectre (variant 2) www.tugraz.at
a->move()
Animal* a = fish;
LUT[data[index] * 4096] 0
fly()
Prediction
swim()swim
()
26 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
index = 0;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
index = 0;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
Speculate
index = 0;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
index = 0;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
index = 1;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
index = 1;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
Speculate
index = 1;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
index = 1;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
index = 2;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
index = 2;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
Speculate
index = 2;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
index = 2;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
index = 3;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
index = 3;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
Speculate
index = 3;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
index = 3;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
index = 4;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
index = 4;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
Speculate
index = 4;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
Execute
index = 4;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
index
=0 ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
index = 5;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
index = 5;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
Speculate
index = 5;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
Execute
index = 5;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
index
=1 ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
index = 6;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
index = 6;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
Speculate
index = 6;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
consid
er ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Spectre (variant 4) www.tugraz.at
Execute
index = 6;
index = index & 0x3; // sanitization
char* data = "textKEY";
LUT[data[index] * 4096] LUT[data[index] * 4096]
index
=2 ignore
Prediction
27 Daniel Gruss — Graz University of Technology
Mitigating Spectre www.tugraz.at
• Trivial approach: disable speculative execution
• No wrong speculation if there is no speculation
• Problem: massive performance hit!
• Also: How to disable it?
• Speculative execution is deeply integrated into CPU
28 Daniel Gruss — Graz University of Technology
Mitigating Spectre www.tugraz.at
• Trivial approach: disable speculative execution
• No wrong speculation if there is no speculation
• Problem: massive performance hit!
• Also: How to disable it?
• Speculative execution is deeply integrated into CPU
28 Daniel Gruss — Graz University of Technology
Mitigating Spectre www.tugraz.at
• Trivial approach: disable speculative execution
• No wrong speculation if there is no speculation
• Problem: massive performance hit!
• Also: How to disable it?
• Speculative execution is deeply integrated into CPU
28 Daniel Gruss — Graz University of Technology
Mitigating Spectre www.tugraz.at
• Trivial approach: disable speculative execution
• No wrong speculation if there is no speculation
• Problem: massive performance hit!
• Also: How to disable it?
• Speculative execution is deeply integrated into CPU
28 Daniel Gruss — Graz University of Technology
Mitigating Spectre www.tugraz.at
• Trivial approach: disable speculative execution
• No wrong speculation if there is no speculation
• Problem: massive performance hit!
• Also: How to disable it?
• Speculative execution is deeply integrated into CPU
28 Daniel Gruss — Graz University of Technology
Spectre Variant 1 Mitigations www.tugraz.at
• Workaround: insert instructions stopping speculation
→ insert after every bounds check
• x86: LFENCE, ARM: CSDB
• Available on all Intel CPUs, retrofitted to existing
ARMv7 and ARMv8
29 Daniel Gruss — Graz University of Technology
Spectre Variant 1 Mitigations www.tugraz.at
• Workaround: insert instructions stopping speculation
→ insert after every bounds check
• x86: LFENCE, ARM: CSDB
• Available on all Intel CPUs, retrofitted to existing
ARMv7 and ARMv8
29 Daniel Gruss — Graz University of Technology
Spectre Variant 1 Mitigations www.tugraz.at
• Workaround: insert instructions stopping speculation
→ insert after every bounds check
• x86: LFENCE, ARM: CSDB
• Available on all Intel CPUs, retrofitted to existing
ARMv7 and ARMv8
29 Daniel Gruss — Graz University of Technology
Spectre Variant 1 Mitigations www.tugraz.at
• Workaround: insert instructions stopping speculation
→ insert after every bounds check
• x86: LFENCE, ARM: CSDB
• Available on all Intel CPUs, retrofitted to existing
ARMv7 and ARMv8
29 Daniel Gruss — Graz University of Technology
Spectre Variant 1 Mitigations www.tugraz.at
• Workaround: insert instructions stopping speculation
→ insert after every bounds check
• x86: LFENCE, ARM: CSDB
• Available on all Intel CPUs, retrofitted to existing
ARMv7 and ARMv8
29 Daniel Gruss — Graz University of Technology
Spectre Variant 1 Mitigations www.tugraz.at
• Speculation barrier requires compiler supported
• Already implemented in GCC, LLVM, and MSVC
• Can be automated (MSVC) → not really reliable
• Explicit use by programmer: builtin load no speculate
30 Daniel Gruss — Graz University of Technology
Spectre Variant 1 Mitigations www.tugraz.at
• Speculation barrier requires compiler supported
• Already implemented in GCC, LLVM, and MSVC
• Can be automated (MSVC) → not really reliable
• Explicit use by programmer: builtin load no speculate
30 Daniel Gruss — Graz University of Technology
Spectre Variant 1 Mitigations www.tugraz.at
• Speculation barrier requires compiler supported
• Already implemented in GCC, LLVM, and MSVC
• Can be automated (MSVC) → not really reliable
• Explicit use by programmer: builtin load no speculate
30 Daniel Gruss — Graz University of Technology
Spectre Variant 1 Mitigations www.tugraz.at
• Speculation barrier requires compiler supported
• Already implemented in GCC, LLVM, and MSVC
• Can be automated (MSVC) → not really reliable
• Explicit use by programmer: builtin load no speculate
30 Daniel Gruss — Graz University of Technology
Spectre Variant 1 Mitigations www.tugraz.at
• Speculation barrier requires compiler supported
• Already implemented in GCC, LLVM, and MSVC
• Can be automated (MSVC) → not really reliable
• Explicit use by programmer: builtin load no speculate
30 Daniel Gruss — Graz University of Technology
Spectre Variant 1 Mitigations www.tugraz.at
31 Daniel Gruss — Graz University of Technology
Spectre Variant 1 Mitigations www.tugraz.at
31 Daniel Gruss — Graz University of Technology
Spectre Variant 1 Mitigations www.tugraz.at
• Speculation barrier works if affected code constructs are
known
• Programmer has to fully understand vulnerability
• Automatic detection is not reliable
• Non-negligible performance overhead of barriers
32 Daniel Gruss — Graz University of Technology
Spectre Variant 1 Mitigations www.tugraz.at
• Speculation barrier works if affected code constructs are
known
• Programmer has to fully understand vulnerability
• Automatic detection is not reliable
• Non-negligible performance overhead of barriers
32 Daniel Gruss — Graz University of Technology
Spectre Variant 1 Mitigations www.tugraz.at
• Speculation barrier works if affected code constructs are
known
• Programmer has to fully understand vulnerability
• Automatic detection is not reliable
• Non-negligible performance overhead of barriers
32 Daniel Gruss — Graz University of Technology
Spectre Variant 1 Mitigations www.tugraz.at
• Speculation barrier works if affected code constructs are
known
• Programmer has to fully understand vulnerability
• Automatic detection is not reliable
• Non-negligible performance overhead of barriers
32 Daniel Gruss — Graz University of Technology
Spectre Variant 1 Mitigations www.tugraz.at
• Speculation barrier works if affected code constructs are
known
• Programmer has to fully understand vulnerability
• Automatic detection is not reliable
• Non-negligible performance overhead of barriers
32 Daniel Gruss — Graz University of Technology
Spectre Variant 2 Mitigations (Microcode/MSRs) www.tugraz.at
Intel released microcode updates
• Indirect Branch Restricted Speculation (IBRS):
• Do not speculate based on anything before entering IBRS mode
→ lesser privileged code cannot influence predictions
• Indirect Branch Predictor Barrier (IBPB):
• Flush branch-target buffer
• Single Thread Indirect Branch Predictors (STIBP):
• Isolates branch prediction state between two hyperthreads
33 Daniel Gruss — Graz University of Technology
Spectre Variant 2 Mitigations (Microcode/MSRs) www.tugraz.at
Intel released microcode updates
• Indirect Branch Restricted Speculation (IBRS):
• Do not speculate based on anything before entering IBRS mode
→ lesser privileged code cannot influence predictions
• Indirect Branch Predictor Barrier (IBPB):
• Flush branch-target buffer
• Single Thread Indirect Branch Predictors (STIBP):
• Isolates branch prediction state between two hyperthreads
33 Daniel Gruss — Graz University of Technology
Spectre Variant 2 Mitigations (Microcode/MSRs) www.tugraz.at
Intel released microcode updates
• Indirect Branch Restricted Speculation (IBRS):
• Do not speculate based on anything before entering IBRS mode
→ lesser privileged code cannot influence predictions
• Indirect Branch Predictor Barrier (IBPB):
• Flush branch-target buffer
• Single Thread Indirect Branch Predictors (STIBP):
• Isolates branch prediction state between two hyperthreads
33 Daniel Gruss — Graz University of Technology
Spectre Variant 2 Mitigations (Microcode/MSRs) www.tugraz.at
Intel released microcode updates
• Indirect Branch Restricted Speculation (IBRS):
• Do not speculate based on anything before entering IBRS mode
→ lesser privileged code cannot influence predictions
• Indirect Branch Predictor Barrier (IBPB):
• Flush branch-target buffer
• Single Thread Indirect Branch Predictors (STIBP):
• Isolates branch prediction state between two hyperthreads
33 Daniel Gruss — Graz University of Technology
Spectre Variant 2 Mitigations (Microcode/MSRs) www.tugraz.at
Intel released microcode updates
• Indirect Branch Restricted Speculation (IBRS):
• Do not speculate based on anything before entering IBRS mode
→ lesser privileged code cannot influence predictions
• Indirect Branch Predictor Barrier (IBPB):
• Flush branch-target buffer
• Single Thread Indirect Branch Predictors (STIBP):
• Isolates branch prediction state between two hyperthreads
33 Daniel Gruss — Graz University of Technology
Spectre Variant 2 Mitigations (Microcode/MSRs) www.tugraz.at
Intel released microcode updates
• Indirect Branch Restricted Speculation (IBRS):
• Do not speculate based on anything before entering IBRS mode
→ lesser privileged code cannot influence predictions
• Indirect Branch Predictor Barrier (IBPB):
• Flush branch-target buffer
• Single Thread Indirect Branch Predictors (STIBP):
• Isolates branch prediction state between two hyperthreads
33 Daniel Gruss — Graz University of Technology
Spectre Variant 2 Mitigations (Microcode/MSRs) www.tugraz.at
Intel released microcode updates
• Indirect Branch Restricted Speculation (IBRS):
• Do not speculate based on anything before entering IBRS mode
→ lesser privileged code cannot influence predictions
• Indirect Branch Predictor Barrier (IBPB):
• Flush branch-target buffer
• Single Thread Indirect Branch Predictors (STIBP):
• Isolates branch prediction state between two hyperthreads
33 Daniel Gruss — Graz University of Technology
Spectre Variant 2 Mitigations (Software) www.tugraz.at
Retpoline (compiler extension)
1 push <call_target >
2 call 1f
3 2: ; speculation will continue here
4 lfence ; speculation barrier
5 jmp 2b ; endless loop
6 1:
7 lea 8(% rsp), %rsp ; restore stack pointer
8 ret ; the actual call to <call_target >
→ always predict to enter an endless loop
• instead of the correct (or wrong) target function → performance?
• On Broadwell or newer:
• ret may fall-back to the BTB for prediction
→ microcode patches to prevent that
34 Daniel Gruss — Graz University of Technology
Spectre Variant 2 Mitigations (Software) www.tugraz.at
Retpoline (compiler extension)
1 push <call_target >
2 call 1f
3 2: ; speculation will continue here
4 lfence ; speculation barrier
5 jmp 2b ; endless loop
6 1:
7 lea 8(% rsp), %rsp ; restore stack pointer
8 ret ; the actual call to <call_target >
→ always predict to enter an endless loop
• instead of the correct (or wrong) target function → performance?
• On Broadwell or newer:
• ret may fall-back to the BTB for prediction
→ microcode patches to prevent that
34 Daniel Gruss — Graz University of Technology
Spectre Variant 2 Mitigations (Software) www.tugraz.at
Retpoline (compiler extension)
1 push <call_target >
2 call 1f
3 2: ; speculation will continue here
4 lfence ; speculation barrier
5 jmp 2b ; endless loop
6 1:
7 lea 8(% rsp), %rsp ; restore stack pointer
8 ret ; the actual call to <call_target >
→ always predict to enter an endless loop
• instead of the correct (or wrong) target function
→ performance?
• On Broadwell or newer:
• ret may fall-back to the BTB for prediction
→ microcode patches to prevent that
34 Daniel Gruss — Graz University of Technology
Spectre Variant 2 Mitigations (Software) www.tugraz.at
Retpoline (compiler extension)
1 push <call_target >
2 call 1f
3 2: ; speculation will continue here
4 lfence ; speculation barrier
5 jmp 2b ; endless loop
6 1:
7 lea 8(% rsp), %rsp ; restore stack pointer
8 ret ; the actual call to <call_target >
→ always predict to enter an endless loop
• instead of the correct (or wrong) target function → performance?
• On Broadwell or newer:
• ret may fall-back to the BTB for prediction
→ microcode patches to prevent that
34 Daniel Gruss — Graz University of Technology
Spectre Variant 2 Mitigations (Software) www.tugraz.at
Retpoline (compiler extension)
1 push <call_target >
2 call 1f
3 2: ; speculation will continue here
4 lfence ; speculation barrier
5 jmp 2b ; endless loop
6 1:
7 lea 8(% rsp), %rsp ; restore stack pointer
8 ret ; the actual call to <call_target >
→ always predict to enter an endless loop
• instead of the correct (or wrong) target function → performance?
• On Broadwell or newer:
• ret may fall-back to the BTB for prediction
→ microcode patches to prevent that
34 Daniel Gruss — Graz University of Technology
Spectre Variant 2 Mitigations (Software) www.tugraz.at
Retpoline (compiler extension)
1 push <call_target >
2 call 1f
3 2: ; speculation will continue here
4 lfence ; speculation barrier
5 jmp 2b ; endless loop
6 1:
7 lea 8(% rsp), %rsp ; restore stack pointer
8 ret ; the actual call to <call_target >
→ always predict to enter an endless loop
• instead of the correct (or wrong) target function → performance?
• On Broadwell or newer:
• ret may fall-back to the BTB for prediction
→ microcode patches to prevent that
34 Daniel Gruss — Graz University of Technology
Spectre Variant 2 Mitigations (Software) www.tugraz.at
Retpoline (compiler extension)
1 push <call_target >
2 call 1f
3 2: ; speculation will continue here
4 lfence ; speculation barrier
5 jmp 2b ; endless loop
6 1:
7 lea 8(% rsp), %rsp ; restore stack pointer
8 ret ; the actual call to <call_target >
→ always predict to enter an endless loop
• instead of the correct (or wrong) target function → performance?
• On Broadwell or newer:
• ret may fall-back to the BTB for prediction
→ microcode patches to prevent that
34 Daniel Gruss — Graz University of Technology
Spectre Variant 2 Mitigations (Software) www.tugraz.at
• ARM provides hardened Linux kernel
• Clears branch-predictor state on context switch
• Either via instruction (BPIALL)...
• ...or workaround (disable/enable MMU)
• Non-negligible performance overhead (≈ 200-300 ns)
35 Daniel Gruss — Graz University of Technology
Spectre Variant 2 Mitigations (Software) www.tugraz.at
• ARM provides hardened Linux kernel
• Clears branch-predictor state on context switch
• Either via instruction (BPIALL)...
• ...or workaround (disable/enable MMU)
• Non-negligible performance overhead (≈ 200-300 ns)
35 Daniel Gruss — Graz University of Technology
Spectre Variant 2 Mitigations (Software) www.tugraz.at
• ARM provides hardened Linux kernel
• Clears branch-predictor state on context switch
• Either via instruction (BPIALL)...
• ...or workaround (disable/enable MMU)
• Non-negligible performance overhead (≈ 200-300 ns)
35 Daniel Gruss — Graz University of Technology
Spectre Variant 2 Mitigations (Software) www.tugraz.at
• ARM provides hardened Linux kernel
• Clears branch-predictor state on context switch
• Either via instruction (BPIALL)...
• ...or workaround (disable/enable MMU)
• Non-negligible performance overhead (≈ 200-300 ns)
35 Daniel Gruss — Graz University of Technology
Spectre Variant 2 Mitigations (Software) www.tugraz.at
• ARM provides hardened Linux kernel
• Clears branch-predictor state on context switch
• Either via instruction (BPIALL)...
• ...or workaround (disable/enable MMU)
• Non-negligible performance overhead (≈ 200-300 ns)
35 Daniel Gruss — Graz University of Technology
Spectre Variant 4 Mitigations (Microcode/MSRs) www.tugraz.at
Intel released microcode updates
• Disable store-to-load-forward speculation
• Performance impact of 2–8%
36 Daniel Gruss — Graz University of Technology
Spectre Variant 4 Mitigations (Microcode/MSRs) www.tugraz.at
Intel released microcode updates
• Disable store-to-load-forward speculation
• Performance impact of 2–8%
36 Daniel Gruss — Graz University of Technology
What does not work www.tugraz.at
• Prevent access to high-resolution timer
→ Own timer using timing thread
• Flush instruction only privileged
→ Cache eviction through memory accesses
• Just move secrets into secure world
→ Spectre works on secure enclaves
37 Daniel Gruss — Graz University of Technology
What does not work www.tugraz.at
• Prevent access to high-resolution timer
→ Own timer using timing thread
• Flush instruction only privileged
→ Cache eviction through memory accesses
• Just move secrets into secure world
→ Spectre works on secure enclaves
37 Daniel Gruss — Graz University of Technology
What does not work www.tugraz.at
• Prevent access to high-resolution timer
→ Own timer using timing thread
• Flush instruction only privileged
→ Cache eviction through memory accesses
• Just move secrets into secure world
→ Spectre works on secure enclaves
37 Daniel Gruss — Graz University of Technology
What does not work www.tugraz.at
• Prevent access to high-resolution timer
→ Own timer using timing thread
• Flush instruction only privileged
→ Cache eviction through memory accesses
• Just move secrets into secure world
→ Spectre works on secure enclaves
37 Daniel Gruss — Graz University of Technology
What does not work www.tugraz.at
• Prevent access to high-resolution timer
→ Own timer using timing thread
• Flush instruction only privileged
→ Cache eviction through memory accesses
• Just move secrets into secure world
→ Spectre works on secure enclaves
37 Daniel Gruss — Graz University of Technology
What does not work www.tugraz.at
• Prevent access to high-resolution timer
→ Own timer using timing thread
• Flush instruction only privileged
→ Cache eviction through memory accesses
• Just move secrets into secure world
→ Spectre works on secure enclaves
37 Daniel Gruss — Graz University of Technology
Meltdown vs. Spectre www.tugraz.at
Meltdown
• Out-of-Order Execution
• has nothing to do with branch prediction
• turning off speculative execution entirely
has no effect on Meltdown
→ melts down the isolation provided by the
user accessible-bit
• in theory: OoO not required, pipelining
can be sufficient
• mitigated by KAISER
Spectre
• Speculative Execution (subset of
Out-of-Order Execution)
• fundamentally builds on branch
(mis)prediction
• turning off speculative execution entirely
would work
• has nothing to do with the
user accessible-bit
• KAISER has no effect on Spectre at all
38 Daniel Gruss — Graz University of Technology
Meltdown vs. Spectre www.tugraz.at
Meltdown
• Out-of-Order Execution
• has nothing to do with branch prediction
• turning off speculative execution entirely
has no effect on Meltdown
→ melts down the isolation provided by the
user accessible-bit
• in theory: OoO not required, pipelining
can be sufficient
• mitigated by KAISER
Spectre
• Speculative Execution (subset of
Out-of-Order Execution)
• fundamentally builds on branch
(mis)prediction
• turning off speculative execution entirely
would work
• has nothing to do with the
user accessible-bit
• KAISER has no effect on Spectre at all
38 Daniel Gruss — Graz University of Technology
Meltdown vs. Spectre www.tugraz.at
Meltdown
• Out-of-Order Execution
• has nothing to do with branch prediction
• turning off speculative execution entirely
has no effect on Meltdown
→ melts down the isolation provided by the
user accessible-bit
• in theory: OoO not required, pipelining
can be sufficient
• mitigated by KAISER
Spectre
• Speculative Execution (subset of
Out-of-Order Execution)
• fundamentally builds on branch
(mis)prediction
• turning off speculative execution entirely
would work
• has nothing to do with the
user accessible-bit
• KAISER has no effect on Spectre at all
38 Daniel Gruss — Graz University of Technology
Meltdown vs. Spectre www.tugraz.at
Meltdown
• Out-of-Order Execution
• has nothing to do with branch prediction
• turning off speculative execution entirely
has no effect on Meltdown
→ melts down the isolation provided by the
user accessible-bit
• in theory: OoO not required, pipelining
can be sufficient
• mitigated by KAISER
Spectre
• Speculative Execution (subset of
Out-of-Order Execution)
• fundamentally builds on branch
(mis)prediction
• turning off speculative execution entirely
would work
• has nothing to do with the
user accessible-bit
• KAISER has no effect on Spectre at all
38 Daniel Gruss — Graz University of Technology
Meltdown vs. Spectre www.tugraz.at
Meltdown
• Out-of-Order Execution
• has nothing to do with branch prediction
• turning off speculative execution entirely
has no effect on Meltdown
→ melts down the isolation provided by the
user accessible-bit
• in theory: OoO not required, pipelining
can be sufficient
• mitigated by KAISER
Spectre
• Speculative Execution (subset of
Out-of-Order Execution)
• fundamentally builds on branch
(mis)prediction
• turning off speculative execution entirely
would work
• has nothing to do with the
user accessible-bit
• KAISER has no effect on Spectre at all
38 Daniel Gruss — Graz University of Technology
Meltdown vs. Spectre www.tugraz.at
Meltdown
• Out-of-Order Execution
• has nothing to do with branch prediction
• turning off speculative execution entirely
has no effect on Meltdown
→ melts down the isolation provided by the
user accessible-bit
• in theory: OoO not required, pipelining
can be sufficient
• mitigated by KAISER
Spectre
• Speculative Execution (subset of
Out-of-Order Execution)
• fundamentally builds on branch
(mis)prediction
• turning off speculative execution entirely
would work
• has nothing to do with the
user accessible-bit
• KAISER has no effect on Spectre at all
38 Daniel Gruss — Graz University of Technology
Meltdown vs. Spectre www.tugraz.at
Meltdown
• Out-of-Order Execution
• has nothing to do with branch prediction
• turning off speculative execution entirely
has no effect on Meltdown
→ melts down the isolation provided by the
user accessible-bit
• in theory: OoO not required, pipelining
can be sufficient
• mitigated by KAISER
Spectre
• Speculative Execution (subset of
Out-of-Order Execution)
• fundamentally builds on branch
(mis)prediction
• turning off speculative execution entirely
would work
• has nothing to do with the
user accessible-bit
• KAISER has no effect on Spectre at all
38 Daniel Gruss — Graz University of Technology
Meltdown vs. Spectre www.tugraz.at
Meltdown
• performs illegal memory accesses → we
need to take care of processor exceptions
• exception handling
• exception suppression with TSX
• exception suppression with branch
misprediction
Spectre
• performs only legal memory accesses
• has nothing to do with exception
handling
or suppression
• abc
• abc
39 Daniel Gruss — Graz University of Technology
Meltdown vs. Spectre www.tugraz.at
Meltdown
• performs illegal memory accesses → we
need to take care of processor exceptions
• exception handling
• exception suppression with TSX
• exception suppression with branch
misprediction
Spectre
• performs only legal memory accesses
• has nothing to do with exception
handling
or suppression
• abc
• abc
39 Daniel Gruss — Graz University of Technology
Meltdown vs. Spectre www.tugraz.at
Meltdown
• performs illegal memory accesses → we
need to take care of processor exceptions
• exception handling
• exception suppression with TSX
• exception suppression with branch
misprediction
Spectre
• performs only legal memory accesses
• has nothing to do with exception
handling
or suppression
• abc
• abc
39 Daniel Gruss — Graz University of Technology
Meltdown vs. Spectre www.tugraz.at
Meltdown
• performs illegal memory accesses → we
need to take care of processor exceptions
• exception handling
• exception suppression with TSX
• exception suppression with branch
misprediction
Spectre
• performs only legal memory accesses
• has nothing to do with exception
handling or suppression
• abc
• abc
39 Daniel Gruss — Graz University of Technology
Meltdown vs. Spectre www.tugraz.at
Meltdown
• performs illegal memory accesses → we
need to take care of processor exceptions
• exception handling
• exception suppression with TSX
• exception suppression with branch
misprediction
Spectre
• performs only legal memory accesses
• has nothing to do with exception
handling or suppression
• abc
• abc
39 Daniel Gruss — Graz University of Technology
What if we want to modify data?
39 Daniel Gruss — Graz University of Technology
DRAM organization www.tugraz.at
channel 0
channel 1
back of DIMM: rank 1
front of DIMM:
rank 0
chip
40 Daniel Gruss — Graz University of Technology
DRAM organization www.tugraz.at
channel 0
channel 1
back of DIMM: rank 1
front of DIMM:
rank 0
chip
40 Daniel Gruss — Graz University of Technology
DRAM organization www.tugraz.at
channel 0
channel 1
back of DIMM: rank 1
front of DIMM:
rank 0
chip
40 Daniel Gruss — Graz University of Technology
DRAM organization www.tugraz.at
channel 0
channel 1
back of DIMM: rank 1
front of DIMM:
rank 0
chip
40 Daniel Gruss — Graz University of Technology
DRAM organization www.tugraz.at
chip
bank 0
row 0
row 1
row 2
. . .
row 32767
row buffer
64k cells
1 capacitor,
1 transitor each
41 Daniel Gruss — Graz University of Technology
DRAM organization www.tugraz.at
chip
bank 0
row 0
row 1
row 2
. . .
row 32767
row buffer
64k cells
1 capacitor,
1 transitor each
41 Daniel Gruss — Graz University of Technology
Rowhammer www.tugraz.at
DRAM bank
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
. . .
1 1 1 1 1 1 1 1 1 1 1 1 1 1
row buffer
• Cells leak → repetitive refresh
necessary
• Maximum interval between
refreshes to guarantee data
integrity
• Cells leak faster upon proximate
accesses → Rowhammer
42 Daniel Gruss — Graz University of Technology
Rowhammer www.tugraz.at
DRAM bank
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
. . .
1 1 1 1 1 1 1 1 1 1 1 1 1 1
row buffer
activate
row buffer
copy
• Cells leak → repetitive refresh
necessary
• Maximum interval between
refreshes to guarantee data
integrity
• Cells leak faster upon proximate
accesses → Rowhammer
42 Daniel Gruss — Graz University of Technology
Rowhammer www.tugraz.at
DRAM bank
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
. . .
1 1 1 1 1 1 1 1 1 1 1 1 1 1
row buffer
activate
row buffer
copy
• Cells leak → repetitive refresh
necessary
• Maximum interval between
refreshes to guarantee data
integrity
• Cells leak faster upon proximate
accesses → Rowhammer
42 Daniel Gruss — Graz University of Technology
Rowhammer www.tugraz.at
DRAM bank
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
. . .
1 1 1 1 1 1 1 1 1 1 1 1 1 1
row buffer
activate
row buffer
copy
• Cells leak → repetitive refresh
necessary
• Maximum interval between
refreshes to guarantee data
integrity
• Cells leak faster upon proximate
accesses → Rowhammer
42 Daniel Gruss — Graz University of Technology
Rowhammer www.tugraz.at
DRAM bank
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
. . .
1 1 1 1 1 1 1 1 1 1 1 1 1 1
row buffer
activate
row buffer
copy
• Cells leak → repetitive refresh
necessary
• Maximum interval between
refreshes to guarantee data
integrity
• Cells leak faster upon proximate
accesses → Rowhammer
42 Daniel Gruss — Graz University of Technology
Rowhammer www.tugraz.at
DRAM bank
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
. . .
1 1 1 1 1 1 1 1 1 1 1 1 1 1
row bufferrow buffer
1 0 1 1 1 1 1 0 1 0 1 1 1 1
bit flips in row 2! • Cells leak → repetitive refresh
necessary
• Maximum interval between
refreshes to guarantee data
integrity
• Cells leak faster upon proximate
accesses → Rowhammer
42 Daniel Gruss — Graz University of Technology
Hammering techniques www.tugraz.at
• There are two different hammering techniques
• #1: Hammer one row next to victim row and other random rows
• #2: Hammer two rows neighboring victim row
• #3: Hammer only one row next to victim row
43 Daniel Gruss — Graz University of Technology
Hammering techniques www.tugraz.at
• There are two different hammering techniques
• #1: Hammer one row next to victim row and other random rows
• #2: Hammer two rows neighboring victim row
• #3: Hammer only one row next to victim row
43 Daniel Gruss — Graz University of Technology
Hammering techniques www.tugraz.at
• There are two different hammering techniques
• #1: Hammer one row next to victim row and other random rows
• #2: Hammer two rows neighboring victim row
• #3: Hammer only one row next to victim row
43 Daniel Gruss — Graz University of Technology
Hammering techniques www.tugraz.at
• There are three different hammering techniques
• #1: Hammer one row next to victim row and other random rows
• #2: Hammer two rows neighboring victim row
• #3: Hammer only one row next to victim row
43 Daniel Gruss — Graz University of Technology
#1 - Single-sided hammering www.tugraz.at
DRAM bank
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
activate
44 Daniel Gruss — Graz University of Technology
#1 - Single-sided hammering www.tugraz.at
DRAM bank
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
activate
44 Daniel Gruss — Graz University of Technology
#1 - Single-sided hammering www.tugraz.at
DRAM bank
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
activate
44 Daniel Gruss — Graz University of Technology
#1 - Single-sided hammering www.tugraz.at
DRAM bank
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1activate
44 Daniel Gruss — Graz University of Technology
#1 - Single-sided hammering www.tugraz.at
DRAM bank
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
activate
44 Daniel Gruss — Graz University of Technology
#1 - Single-sided hammering www.tugraz.at
DRAM bank
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 0 1 1 1 1 1 0 1 0 1 1 1 1
bit flips
44 Daniel Gruss — Graz University of Technology
#2 - Double-sided hammering www.tugraz.at
DRAM bank
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
activate
45 Daniel Gruss — Graz University of Technology
#2 - Double-sided hammering www.tugraz.at
DRAM bank
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
activate
45 Daniel Gruss — Graz University of Technology
#2 - Double-sided hammering www.tugraz.at
DRAM bank
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
activate
45 Daniel Gruss — Graz University of Technology
#2 - Double-sided hammering www.tugraz.at
DRAM bank
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
activate
45 Daniel Gruss — Graz University of Technology
#2 - Double-sided hammering www.tugraz.at
DRAM bank
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
activate
45 Daniel Gruss — Graz University of Technology
#2 - Double-sided hammering www.tugraz.at
DRAM bank
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
activate
1 0 1 1 1 1 1 0 1 0 1 1 1 1
bit flips
45 Daniel Gruss — Graz University of Technology
#3 - One-location hammering www.tugraz.at
DRAM bank
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
activate
46 Daniel Gruss — Graz University of Technology
#3 - One-location hammering www.tugraz.at
DRAM bank
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
46 Daniel Gruss — Graz University of Technology
#3 - One-location hammering www.tugraz.at
DRAM bank
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
activate
46 Daniel Gruss — Graz University of Technology
#3 - One-location hammering www.tugraz.at
DRAM bank
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
46 Daniel Gruss — Graz University of Technology
#3 - One-location hammering www.tugraz.at
DRAM bank
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
activate
46 Daniel Gruss — Graz University of Technology
#3 - One-location hammering www.tugraz.at
DRAM bank
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 0 1 1 1 1 1 0 1 0 1 1 1 1
bit flips
46 Daniel Gruss — Graz University of Technology
How to exploit random bit flips? www.tugraz.at
• They are not random → highly reproducible flip pattern!
1. Choose a data structure that you can place at arbitrary memory
locations
2. Scan for “good” flips
3. Place data structure there
4. Trigger bit flip again
47 Daniel Gruss — Graz University of Technology
How to exploit random bit flips? www.tugraz.at
• They are not random → highly reproducible flip pattern!
1. Choose a data structure that you can place at arbitrary memory
locations
2. Scan for “good” flips
3. Place data structure there
4. Trigger bit flip again
47 Daniel Gruss — Graz University of Technology
How to exploit random bit flips? www.tugraz.at
• They are not random → highly reproducible flip pattern!
1. Choose a data structure that you can place at arbitrary memory
locations
2. Scan for “good” flips
3. Place data structure there
4. Trigger bit flip again
47 Daniel Gruss — Graz University of Technology
How to exploit random bit flips? www.tugraz.at
• They are not random → highly reproducible flip pattern!
1. Choose a data structure that you can place at arbitrary memory
locations
2. Scan for “good” flips
3. Place data structure there
4. Trigger bit flip again
47 Daniel Gruss — Graz University of Technology
How to exploit random bit flips? www.tugraz.at
• They are not random → highly reproducible flip pattern!
1. Choose a data structure that you can place at arbitrary memory
locations
2. Scan for “good” flips
3. Place data structure there
4. Trigger bit flip again
47 Daniel Gruss — Graz University of Technology
How to exploit random bit flips? www.tugraz.at
• They are not random → highly reproducible flip pattern!
1. Choose a data structure that you can place at arbitrary memory
locations
2. Scan for “good” flips
3. Place data structure there
4. Trigger bit flip again
47 Daniel Gruss — Graz University of Technology
How to exploit random bit flips? www.tugraz.at
• They are not random → highly reproducible flip pattern!
1. Choose a data structure that you can place at arbitrary memory
locations
2. Scan for “good” flips
3. Place data structure there
4. Trigger bit flip again
47 Daniel Gruss — Graz University of Technology
How to exploit random bit flips? www.tugraz.at
• They are not random → highly reproducible flip pattern!
1. Choose a data structure that you can place at arbitrary memory
locations
2. Scan for “good” flips
3. Place data structure there
4. Trigger bit flip again
47 Daniel Gruss — Graz University of Technology
What if we cannot target kernel pages? www.tugraz.at
• Many applications perform actions as root
• They can be used by unprivileged users as well
• sudo
48 Daniel Gruss — Graz University of Technology
What if we cannot target kernel pages? www.tugraz.at
• Many applications perform actions as root
• They can be used by unprivileged users as well
• sudo
48 Daniel Gruss — Graz University of Technology
What if we cannot target kernel pages? www.tugraz.at
• Many applications perform actions as root
• They can be used by unprivileged users as well
• sudo
48 Daniel Gruss — Graz University of Technology
What if we cannot target kernel pages? www.tugraz.at
• Many applications perform actions as root
• They can be used by unprivileged users as well
• sudo
48 Daniel Gruss — Graz University of Technology
What if we cannot target kernel pages? www.tugraz.at
• Many applications perform actions as root
• They can be used by unprivileged users as well
• sudo
48 Daniel Gruss — Graz University of Technology
What if we cannot target kernel pages? www.tugraz.at
• Many applications perform actions as root
• They can be used by unprivileged users as well
• sudo
48 Daniel Gruss — Graz University of Technology
What if we cannot target kernel pages? www.tugraz.at
• Many applications perform actions as root
• They can be used by unprivileged users as well
• sudo
48 Daniel Gruss — Graz University of Technology
What if we cannot target kernel pages? www.tugraz.at
• Many applications perform actions as root
• They can be used by unprivileged users as well
• sudo
48 Daniel Gruss — Graz University of Technology
Opcode Flipping - Conditional Jump www.tugraz.at
JE0 1 1 1 0 1 0 0
HLT1 1 1 1 0 1 0 0
<prefix>0 1 1 0 0 1 0 0
49 Daniel Gruss — Graz University of Technology
Opcode Flipping - Conditional Jump www.tugraz.at
JE0 1 1 1 0 1 0 0
XORB0 0 1 1 0 1 0 0
<prefix>0 1 1 0 0 1 0 0
49 Daniel Gruss — Graz University of Technology
Opcode Flipping - Conditional Jump www.tugraz.at
JE0 1 1 1 0 1 0 0
PUSHQ0 1 0 1 0 1 0 0
<prefix>0 1 1 0 0 1 0 0
49 Daniel Gruss — Graz University of Technology
Opcode Flipping - Conditional Jump www.tugraz.at
JE0 1 1 1 0 1 0 0
<prefix>0 1 1 0 0 1 0 0
49 Daniel Gruss — Graz University of Technology
Opcode Flipping - Conditional Jump www.tugraz.at
JE0 1 1 1 0 1 0 0
JL0 1 1 1 1 1 0 0
<prefix>0 1 1 0 0 1 0 0
49 Daniel Gruss — Graz University of Technology
Opcode Flipping - Conditional Jump www.tugraz.at
JE0 1 1 1 0 1 0 0
JO0 1 1 1 0 0 0 0
<prefix>0 1 1 0 0 1 0 0
49 Daniel Gruss — Graz University of Technology
Opcode Flipping - Conditional Jump www.tugraz.at
JE0 1 1 1 0 1 0 0
JBE0 1 1 1 0 1 1 0
<prefix>0 1 1 0 0 1 0 0
49 Daniel Gruss — Graz University of Technology
Opcode Flipping - Conditional Jump www.tugraz.at
JE0 1 1 1 0 1 0 0
JNE0 1 1 1 0 1 0 1
<prefix>0 1 1 0 0 1 0 0
49 Daniel Gruss — Graz University of Technology
ECC memory vs. refresh rate www.tugraz.at
Apple had a great idea:
• lowering the refresh rate saves energy but produces more bit flips
→ use ECC memory to mitigate bit flips
• in the end: it’s an optimization problem.
• too aggressive? bit flips will be possible
• too cautious? waste of energy
• what if the “too aggressive” changes over time?
• what if attackers come up with slightly better attacks?
→ difficult to optimize with an intelligent adversary
50 Daniel Gruss — Graz University of Technology
ECC memory vs. refresh rate www.tugraz.at
Apple had a great idea:
• lowering the refresh rate saves energy but produces more bit flips
→ use ECC memory to mitigate bit flips
• in the end: it’s an optimization problem.
• too aggressive? bit flips will be possible
• too cautious? waste of energy
• what if the “too aggressive” changes over time?
• what if attackers come up with slightly better attacks?
→ difficult to optimize with an intelligent adversary
50 Daniel Gruss — Graz University of Technology
ECC memory vs. refresh rate www.tugraz.at
Apple had a great idea:
• lowering the refresh rate saves energy but produces more bit flips
→ use ECC memory to mitigate bit flips
• in the end: it’s an optimization problem.
• too aggressive? bit flips will be possible
• too cautious? waste of energy
• what if the “too aggressive” changes over time?
• what if attackers come up with slightly better attacks?
→ difficult to optimize with an intelligent adversary
50 Daniel Gruss — Graz University of Technology
ECC memory vs. refresh rate www.tugraz.at
Apple had a great idea:
• lowering the refresh rate saves energy but produces more bit flips
→ use ECC memory to mitigate bit flips
• in the end: it’s an optimization problem.
• too aggressive? bit flips will be possible
• too cautious? waste of energy
• what if the “too aggressive” changes over time?
• what if attackers come up with slightly better attacks?
→ difficult to optimize with an intelligent adversary
50 Daniel Gruss — Graz University of Technology
ECC memory vs. refresh rate www.tugraz.at
Apple had a great idea:
• lowering the refresh rate saves energy but produces more bit flips
→ use ECC memory to mitigate bit flips
• in the end: it’s an optimization problem.
• too aggressive? bit flips will be possible
• too cautious? waste of energy
• what if the “too aggressive” changes over time?
• what if attackers come up with slightly better attacks?
→ difficult to optimize with an intelligent adversary
50 Daniel Gruss — Graz University of Technology
ECC memory vs. refresh rate www.tugraz.at
Apple had a great idea:
• lowering the refresh rate saves energy but produces more bit flips
→ use ECC memory to mitigate bit flips
• in the end: it’s an optimization problem.
• too aggressive? bit flips will be possible
• too cautious? waste of energy
• what if the “too aggressive” changes over time?
• what if attackers come up with slightly better attacks?
→ difficult to optimize with an intelligent adversary
50 Daniel Gruss — Graz University of Technology
ECC memory vs. refresh rate www.tugraz.at
Apple had a great idea:
• lowering the refresh rate saves energy but produces more bit flips
→ use ECC memory to mitigate bit flips
• in the end: it’s an optimization problem.
• too aggressive? bit flips will be possible
• too cautious? waste of energy
• what if the “too aggressive” changes over time?
• what if attackers come up with slightly better attacks?
→ difficult to optimize with an intelligent adversary
50 Daniel Gruss — Graz University of Technology
ECC memory vs. refresh rate www.tugraz.at
Apple had a great idea:
• lowering the refresh rate saves energy but produces more bit flips
→ use ECC memory to mitigate bit flips
• in the end: it’s an optimization problem.
• too aggressive? bit flips will be possible
• too cautious? waste of energy
• what if the “too aggressive” changes over time?
• what if attackers come up with slightly better attacks?
→ difficult to optimize with an intelligent adversary
50 Daniel Gruss — Graz University of Technology
What do we learn from it? www.tugraz.at
We have ignored microarchitectural attacks for many many years:
• attacks on crypto → “software should be fixed”
• attacks on ASLR → “ASLR is broken anyway”
• attacks on SGX and TrustZone → “not part of the threat model”
• Rowhammer attacks → “only affects cheap sub-standard modules”
→ for years we solely optimized for performance
51 Daniel Gruss — Graz University of Technology
What do we learn from it? www.tugraz.at
We have ignored microarchitectural attacks for many many years:
• attacks on crypto
→ “software should be fixed”
• attacks on ASLR → “ASLR is broken anyway”
• attacks on SGX and TrustZone → “not part of the threat model”
• Rowhammer attacks → “only affects cheap sub-standard modules”
→ for years we solely optimized for performance
51 Daniel Gruss — Graz University of Technology
What do we learn from it? www.tugraz.at
We have ignored microarchitectural attacks for many many years:
• attacks on crypto → “software should be fixed”
• attacks on ASLR → “ASLR is broken anyway”
• attacks on SGX and TrustZone → “not part of the threat model”
• Rowhammer attacks → “only affects cheap sub-standard modules”
→ for years we solely optimized for performance
51 Daniel Gruss — Graz University of Technology
What do we learn from it? www.tugraz.at
We have ignored microarchitectural attacks for many many years:
• attacks on crypto → “software should be fixed”
• attacks on ASLR
→ “ASLR is broken anyway”
• attacks on SGX and TrustZone → “not part of the threat model”
• Rowhammer attacks → “only affects cheap sub-standard modules”
→ for years we solely optimized for performance
51 Daniel Gruss — Graz University of Technology
What do we learn from it? www.tugraz.at
We have ignored microarchitectural attacks for many many years:
• attacks on crypto → “software should be fixed”
• attacks on ASLR → “ASLR is broken anyway”
• attacks on SGX and TrustZone → “not part of the threat model”
• Rowhammer attacks → “only affects cheap sub-standard modules”
→ for years we solely optimized for performance
51 Daniel Gruss — Graz University of Technology
What do we learn from it? www.tugraz.at
We have ignored microarchitectural attacks for many many years:
• attacks on crypto → “software should be fixed”
• attacks on ASLR → “ASLR is broken anyway”
• attacks on SGX and TrustZone
→ “not part of the threat model”
• Rowhammer attacks → “only affects cheap sub-standard modules”
→ for years we solely optimized for performance
51 Daniel Gruss — Graz University of Technology
What do we learn from it? www.tugraz.at
We have ignored microarchitectural attacks for many many years:
• attacks on crypto → “software should be fixed”
• attacks on ASLR → “ASLR is broken anyway”
• attacks on SGX and TrustZone → “not part of the threat model”
• Rowhammer attacks → “only affects cheap sub-standard modules”
→ for years we solely optimized for performance
51 Daniel Gruss — Graz University of Technology
What do we learn from it? www.tugraz.at
We have ignored microarchitectural attacks for many many years:
• attacks on crypto → “software should be fixed”
• attacks on ASLR → “ASLR is broken anyway”
• attacks on SGX and TrustZone → “not part of the threat model”
• Rowhammer attacks
→ “only affects cheap sub-standard modules”
→ for years we solely optimized for performance
51 Daniel Gruss — Graz University of Technology
What do we learn from it? www.tugraz.at
We have ignored microarchitectural attacks for many many years:
• attacks on crypto → “software should be fixed”
• attacks on ASLR → “ASLR is broken anyway”
• attacks on SGX and TrustZone → “not part of the threat model”
• Rowhammer attacks → “only affects cheap sub-standard modules”
→ for years we solely optimized for performance
51 Daniel Gruss — Graz University of Technology
What do we learn from it? www.tugraz.at
We have ignored microarchitectural attacks for many many years:
• attacks on crypto → “software should be fixed”
• attacks on ASLR → “ASLR is broken anyway”
• attacks on SGX and TrustZone → “not part of the threat model”
• Rowhammer attacks → “only affects cheap sub-standard modules”
→ for years we solely optimized for performance
51 Daniel Gruss — Graz University of Technology
When you read the manuals... www.tugraz.at
After learning about a side channel you realize:
• the side channels were documented in the Intel manual
• only now we understand the implications
52 Daniel Gruss — Graz University of Technology
When you read the manuals... www.tugraz.at
After learning about a side channel you realize:
• the side channels were documented in the Intel manual
• only now we understand the implications
52 Daniel Gruss — Graz University of Technology
When you read the manuals... www.tugraz.at
After learning about a side channel you realize:
• the side channels were documented in the Intel manual
• only now we understand the implications
52 Daniel Gruss — Graz University of Technology
What do we learn from it? www.tugraz.at
Motor Vehicle Deaths in U.S. by Year
53 Daniel Gruss — Graz University of Technology
Attacks vs. Defenses www.tugraz.at
• moral obligation to invest more time on defenses than on attacks
• dangerous: we overlooked Meltdown and Spectre for decades
• we don’t know all problems. do we know at least the most important subset?
• are we hammering on a small subset of problems and forgot about the bigger picture?
54 Daniel Gruss — Graz University of Technology
Attacks vs. Defenses www.tugraz.at
• moral obligation to invest more time on defenses than on attacks
• dangerous: we overlooked Meltdown and Spectre for decades
• we don’t know all problems. do we know at least the most important subset?
• are we hammering on a small subset of problems and forgot about the bigger picture?
54 Daniel Gruss — Graz University of Technology
Attacks vs. Defenses www.tugraz.at
• moral obligation to invest more time on defenses than on attacks
• dangerous: we overlooked Meltdown and Spectre for decades
• we don’t know all problems. do we know at least the most important subset?
• are we hammering on a small subset of problems and forgot about the bigger picture?
54 Daniel Gruss — Graz University of Technology
Attacks vs. Defenses www.tugraz.at
• moral obligation to invest more time on defenses than on attacks
• dangerous: we overlooked Meltdown and Spectre for decades
• we don’t know all problems. do we know at least the most important subset?
• are we hammering on a small subset of problems and forgot about the bigger picture?
54 Daniel Gruss — Graz University of Technology
Attacks vs. Defenses www.tugraz.at
• moral obligation to invest more time on defenses than on attacks
• dangerous: we overlooked Meltdown and Spectre for decades
• we don’t know all problems. do we know at least the most important subset?
• are we hammering on a small subset of problems and forgot about the bigger picture?
54 Daniel Gruss — Graz University of Technology
Attacks vs. Defenses www.tugraz.at
• moral obligation to invest more time on defenses than on attacks
• dangerous: we overlooked Meltdown and Spectre for decades
• we don’t know all problems. do we know at least the most important subset?
• are we hammering on a small subset of problems and forgot about the bigger picture?
54 Daniel Gruss — Graz University of Technology
Conclusions www.tugraz.at
A unique chance to
• rethink processor design
• grow up, like other fields (car industry, construction industry)
• dedicate more time into identifying problems and not solely in
mitigating known problems
55 Daniel Gruss — Graz University of Technology
Conclusions www.tugraz.at
A unique chance to
• rethink processor design
• grow up, like other fields (car industry, construction industry)
• dedicate more time into identifying problems and not solely in
mitigating known problems
55 Daniel Gruss — Graz University of Technology
Conclusions www.tugraz.at
A unique chance to
• rethink processor design
• grow up, like other fields (car industry, construction industry)
• dedicate more time into identifying problems and not solely in
mitigating known problems
55 Daniel Gruss — Graz University of Technology
SCIENCE PASSION TECHNOLOGY
Microarchitectural Attacks:
From the Basics to Arbitrary Read and Write Primitives without any Software Bugs
Daniel Gruss
June 19, 2018
Graz University of Technology
56 Daniel Gruss — Graz University of Technology