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