1. Spectre Attacks: Exploiting Speculative Execution
Paul Kocher [1] , Daniel Genkin [2] , Daniel Gruss [3] , Werner Haas [4] , Mike Hamburg [5] ,
Moritz Lipp [3] , Stefan Mangard [3] , Thomas Prescher [4] , Michael Schwarz [3] , Yuval Yarom [6]
1 Independent
2 University of Pennsylvania and University of Maryland
3 Graz University of Technology
4 Cyberus Technology
5 Rambus, Cryptography Research Division
6 University of Adelaide and Data61 1

2. Outline Attack description Background Spectre attack
Spectre variations
Mitigation options
Strengths
Weaknesses
Discussion 2

3. Attack description 3

4. Attack description 4

5. Attack description
Spectre exploit gives the attacker the ability to read out the memory of a bug-free victim process 5

6. Attack description
Spectre exploit gives the attacker the ability to read out the memory of a bug-free victim process
Works on Intel, AMD and ARM 6

7. Attack description
Spectre exploit gives the attacker the ability to read out the memory of a bug-free victim process
Works on Intel, AMD and ARM
How? 7

8. Background 8

9. Background: Virtual Memory 9

10. Background: Virtual Memory 10

11. Background: Virtual Memory 11

12. Background: Covert channel12

13. Background: Covert channel
When two processes cooperate to communicate, not by architecturally defined means but by changing the microarchitectural state in a suitable way 13

14. Background: Covert channel
When two processes cooperate to communicate, not by architecturally defined means but by changing the microarchitectural state in a suitable way
Example of state that can be used: 14

15. Background: Covert channel
When two processes cooperate to communicate, not by architecturally defined means but by changing the microarchitectural state in a suitable way
Example of state that can be used:
Cache timing 15

16. Background: Covert channel
When two processes cooperate to communicate, not by architecturally defined means but by changing the microarchitectural state in a suitable way
Example of state that can be used:
Cache timing
Instruction timing 16

17. Background: Covert channel
When two processes cooperate to communicate, not by architecturally defined means but by changing the microarchitectural state in a suitable way
Example of state that can be used:
Cache timing
Instruction timing
ALU contention 17

18. Background: Covert channel
When two processes cooperate to communicate, not by architecturally defined means but by changing the microarchitectural state in a suitable way
Example of state that can be used:
Cache timing
Instruction timing
ALU contention
Memory contention 18

19. Background: Cache
CPU
Cache
Memory 19

20. Background: Cache
CPU
Cache
Memory 20

21. Background: Cache
Cache miss (slow)
CPU
Cache
Memory 21

22. Background: Cache
Cache miss (slow)
CPU
Cache
Memory 22

23. Background: Cache
Cache miss (slow)
Request
CPU
Cache
Memory 23

24. Background: Cache
Cache miss (slow)
Request
CPU
Cache
Memory 24

25. Background: Cache CPU Cache Memory Request Response Cache miss (slow)25

26. Background: Cache CPU Cache Memory Request Response Cache miss (slow)26

27. Background: Cache CPU Cache Memory Request Response Cache miss (slow)
Cache hit (fast)
Memory
Response 27

28. Background: Covert channel28

29. Background: Covert channel
Example: cache timing as covert channel 29

30. Background: Covert channel
Example: cache timing as covert channel
Sender process has a value it wants to transmit to the receiver process 30

31. Background: Covert channel
Example: cache timing as covert channel
Sender process has a value it wants to transmit to the receiver process
Sender changes the cache (loading, evicting) in a value-dependent way 31

32. Background: Covert channel
Example: cache timing as covert channel
Sender process has a value it wants to transmit to the receiver process
Sender changes the cache (loading, evicting) in a value-dependent way
Receiver can’t see the value in the cache directly but can time the cache and thus infer the value 32

33. Background: Speculative Execution33

34. Background: Speculative Execution
Predicting/Speculating for example: 34

35. Background: Speculative Execution
Predicting/Speculating for example:
Prefetcher (what will be needed in the future) 35

36. Background: Speculative Execution
Predicting/Speculating for example:
Prefetcher (what will be needed in the future)
Branch Predictor (Speculate if direct branch taken or not) 36

37. Background: Speculative Execution
Predicting/Speculating for example:
Prefetcher (what will be needed in the future)
Branch Predictor (Speculate if direct branch taken or not)
Branch Target Buffer/BTB (Speculate what a value will be) 37

38. Background: Speculative Execution
Predicting/Speculating for example:
Prefetcher (what will be needed in the future)
Branch Predictor (Speculate if direct branch taken or not)
Branch Target Buffer/BTB (Speculate what a value will be)
Leads to improved Instruction Level Parallelism 38

39. Background: Speculative Execution
Predicting/Speculating for example:
Prefetcher (what will be needed in the future)
Branch Predictor (Speculate if direct branch taken or not)
Branch Target Buffer/BTB (Speculate what a value will be)
Leads to improved Instruction Level Parallelism
Otherwise CPU would have to sit idle while waiting for results 39

40. Background: Speculative Execution
Branch predictor
if (slow condition){
//do something
} else { }
Branch predictor 40

41. Background: Speculative Execution
Branch predictor
if (slow condition){
//do something
} else { }
Branch predictor 41

42. Background: Speculative Execution
Branch predictor
Start evaluating condition
if (slow condition){
//do something
} else { }
Branch predictor 42

43. Background: Speculative Execution
Branch predictor
Start evaluating condition
if (slow condition){
//do something
} else { }
Ask branch predictor
Branch predictor 43

44. Background: Speculative Execution
Branch predictor
Start evaluating condition
if (slow condition){
//do something
} else { }
Ask branch predictor
Taken
Branch predictor 44

45. Background: Speculative Execution
Branch predictor
if (slow condition){
//do something
} else { }
Branch predictor 45

46. Background: Speculative Execution46

47. Background: Speculative Execution
Up to 200 instruction ahead 47

48. Background: Speculative Execution
Up to 200 instruction ahead
Revert the result of incorrect execution 48

49. Background: Speculative Execution
Up to 200 instruction ahead
Revert the result of incorrect execution
=> No correctness issues? 49

50. Background: Speculative Execution
Up to 200 instruction ahead
Revert the result of incorrect execution
=> No correctness issues?
But speculative execution has measurable side effects 50

51. Spectre Attacks 51

52. Spectre Attacks 52

53. Spectre Attacks
Locate sequence of instructions which act as covert channel transmitter 53

54. Spectre Attacks
Locate sequence of instructions which act as covert channel transmitter
Setup phase: Mistrain CPU into speculatively executing these instructions 54

55. Spectre Attacks 55

56. Spectre Attacks
Second phase: speculatively execute instruction that leak information 56

57. Spectre Attacks
Second phase: speculatively execute instruction that leak information
Via syscall/socket/file 57

58. Spectre Attacks
Second phase: speculatively execute instruction that leak information
Via syscall/socket/file
Misexecute own code (e.g. sandbox, interpreter, JIT) 58

59. Spectre Attacks 59

60. Spectre Attacks
Final phase: Recover data by retrieving over covert channel 60

61. Spectre Attacks
Final phase: Recover data by retrieving over covert channel
Cache 61

62. Spectre Attacks
Final phase: Recover data by retrieving over covert channel
Cache
Execution time 62

63. Spectre Attacks
Final phase: Recover data by retrieving over covert channel
Cache
Execution time
ALU contention 63

64. Spectre Attacks
Final phase: Recover data by retrieving over covert channel
Cache
Execution time
ALU contention
Memory contention 64

65. Spectre Attacks
Final phase: Recover data by retrieving over covert channel
Cache
Execution time
ALU contention
Memory contention
Other microarchitectural state 65

66. Spectre Variants 66

67. Variant 1: Exploiting Conditional Branch Misprediction
Address
Value
000 4
001 13
010 9
011 2
100 12
101 75
110 24
111 87 k 67

68. Variant 1: Exploiting Conditional Branch Misprediction
We want to find out what a certain byte in the virtual address of the victim is
Address
Value
000 4
001 13
010 9
011 2
100 12
101 75
110 24
111 87 k 68

69. Variant 1: Exploiting Conditional Branch Misprediction
We want to find out what a certain byte in the virtual address of the victim is
Let’s call this secret byte k
Address
Value
000 4
001 13
010 9
011 2
100 12
101 75
110 24
111 87 k 69

70. Variant 1: Exploiting Conditional Branch Misprediction70

71. Variant 1: Exploiting Conditional Branch Misprediction
Locate a conditional which matches this pattern in the software you want to attack 71

72. Variant 1: Exploiting Conditional Branch Misprediction
Locate a conditional which matches this pattern in the software you want to attack
Setup phase: 72

73. Variant 1: Exploiting Conditional Branch Misprediction
Locate a conditional which matches this pattern in the software you want to attack
Setup phase:
call many times with some x < array1_size to mistrain branch predictor 73

74. Variant 1: Exploiting Conditional Branch Misprediction
Locate a conditional which matches this pattern in the software you want to attack
Setup phase:
call many times with some x < array1_size to mistrain branch predictor
Evict array1_size and array2, but leave secret byte k in cache 74

75. Variant 1: Exploiting Conditional Branch Misprediction75

76. Variant 1: Exploiting Conditional Branch Misprediction
Second phase: Choose x out-of-bounds such that array1[x] resolves to secret byte 76

77. Variant 1: Exploiting Conditional Branch Misprediction
Victim
Attacker
Address
Value
000 4
001 13
010 9
011 2
100 12
101 75
110 24
111 87
array1
Tag
Value
Set 0
Set 1 01 2 k
array2 77

78. Variant 1: Exploiting Conditional Branch Misprediction
Victim
Attacker
Address
Value
000 4
001 13
010 9
011 2
100 12
101 75
110 24
111 87
array1
Tag
Value
Set 0
Set 1 01 2 k
array2 78

79. Variant 1: Exploiting Conditional Branch Misprediction
Victim
Attacker
x = 4
Address
Value
000 4
001 13
010 9
011 2
100 12
101 75
110 24
111 87
array1
Tag
Value
Set 0
Set 1 01 2 k
array2 79

80. Variant 1: Exploiting Conditional Branch Misprediction
Victim
Attacker
x = 4
Address
Value
000 4
001 13
010 9
011 2
100 12
101 75
110 24
111 87
array1
Tag
Value
Set 0
Set 1 01 2 k
array2 80

81. Variant 1: Exploiting Conditional Branch Misprediction
Cache miss
Victim
Attacker
x = 4
Address
Value
000 4
001 13
010 9
011 2
100 12
101 75
110 24
111 87
array1
Tag
Value
Set 0
Set 1 01 2 k
array2 81

82. Variant 1: Exploiting Conditional Branch Misprediction
Cache miss
Victim
Attacker
x = 4
Address
Value
000 4
001 13
010 9
011 2
100 12
101 75
110 24
111 87
array1
Tag
Value
Set 0
Set 1 01 2 k
array2 82

83. Variant 1: Exploiting Conditional Branch Misprediction
Cache miss
Victim
Attacker
x = 4
Address
Value
000 4
001 13
010 9
011 2
100 12
101 75
110 24
111 87
array1
Tag
Value
Set 0
Set 1 01 2 k
array2 83

84. Variant 1: Exploiting Conditional Branch Misprediction
Cache miss
Victim
Attacker
x = 4
Address
Value
000 4
001 13
010 9
011 2
100 12
101 75
110 24
111 87
array1
Tag
Value
Set 0
Set 1 01 2 k
array2 84

85. Variant 1: Exploiting Conditional Branch Misprediction85
[1] OSVIK, D. A., SHAMIR, A.,ANDTROMER, E. Cache attacks and countermeasures: The case of AES

86. Variant 1: Exploiting Conditional Branch Misprediction
Final phase: 86
[1] OSVIK, D. A., SHAMIR, A.,ANDTROMER, E. Cache attacks and countermeasures: The case of AES

87. Variant 1: Exploiting Conditional Branch Misprediction
Final phase:
If array2 is readable by attacker, load array2[n] for all n, will be fast for n==k 87
[1] OSVIK, D. A., SHAMIR, A.,ANDTROMER, E. Cache attacks and countermeasures: The case of AES

88. Variant 1: Exploiting Conditional Branch Misprediction
Final phase:
If array2 is readable by attacker, load array2[n] for all n, will be fast for n==k
Otherwise detect eviction 88
[1] OSVIK, D. A., SHAMIR, A.,ANDTROMER, E. Cache attacks and countermeasures: The case of AES

89. Variant 1: Exploiting Conditional Branch Misprediction
Final phase:
If array2 is readable by attacker, load array2[n] for all n, will be fast for n==k
Otherwise detect eviction
Prime & Probe [1] 89
[1] OSVIK, D. A., SHAMIR, A.,ANDTROMER, E. Cache attacks and countermeasures: The case of AES

90. Variant 1: Exploiting Conditional Branch Misprediction
Final phase:
If array2 is readable by attacker, load array2[n] for all n, will be fast for n==k
Otherwise detect eviction
Prime & Probe [1]
Call method again with in bounds value of x, if array1[x’] == k, will be fast 90
[1] OSVIK, D. A., SHAMIR, A.,ANDTROMER, E. Cache attacks and countermeasures: The case of AES

91. Variant 1: Implementations91

92. Variant 1: Implementations
In C: 92

93. Variant 1: Implementations
In C:
Wrote a victim function which has the pattern 93

94. Variant 1: Implementations
In C:
Wrote a victim function which has the pattern
Attacker function 94

95. Variant 1: Implementations
In C:
Wrote a victim function which has the pattern
Attacker function
Were able to read out address space at 10 kB/second 95

96. Variant 1: Implementations
In C:
Wrote a victim function which has the pattern
Attacker function
Were able to read out address space at 10 kB/second
In JS: 96

97. Variant 1: Implementations
In C:
Wrote a victim function which has the pattern
Attacker function
Were able to read out address space at 10 kB/second
In JS:
JS gets JITed and bounds checks inserted 97

98. Variant 1: Implementations
In C:
Wrote a victim function which has the pattern
Attacker function
Were able to read out address space at 10 kB/second
In JS:
JS gets JITed and bounds checks inserted
Works even though no high res. timer available 98

99. Variant 1: Implementations
In C:
Wrote a victim function which has the pattern
Attacker function
Were able to read out address space at 10 kB/second
In JS:
JS gets JITed and bounds checks inserted
Works even though no high res. timer available
Able to read out browser’s address space 99

100. Variant 2: Poisoning Indirect Branches
100

101. Variant 2: Poisoning Indirect Branches
Locate gadgets whose execution will leak the chosen memory in the process you want to attack (either source code or in shared library)
101

102. Variant 2: Poisoning Indirect Branches
Locate gadgets whose execution will leak the chosen memory in the process you want to attack (either source code or in shared library)
Example gadget:
102

103. Variant 2: Poisoning Indirect Branches
Locate gadgets whose execution will leak the chosen memory in the process you want to attack (either source code or in shared library)
Example gadget:
add R2, [R1]
103

104. Variant 2: Poisoning Indirect Branches
Locate gadgets whose execution will leak the chosen memory in the process you want to attack (either source code or in shared library)
Example gadget:
add R2, [R1]
mov R3, [R2]
104

105. Background: Speculative Execution
Branch Target Buffer
jmp //slow computation
Branch Target Buffer
105

106. Background: Speculative Execution
Branch Target Buffer
jmp //slow computation
Branch Target Buffer
106

107. Background: Speculative Execution
Branch Target Buffer
Start evaluating
jmp //slow computation
Branch Target Buffer
107

108. Background: Speculative Execution
Branch Target Buffer
Start evaluating
jmp //slow computation
Ask BTB
Branch Target Buffer
108

109. Background: Speculative Execution
Branch Target Buffer
Start evaluating
jmp //slow computation
Ask BTB
Predicted target address
Branch Target Buffer
109

110. Background: Speculative Execution
Branch Target Buffer
Start evaluating
jmp //slow computation
Ask BTB
Predicted target address
Branch Target Buffer
110

111. Variant 2: Poisoning Indirect Branches
111

112. Variant 2: Poisoning Indirect Branches
Setup phase:
112

113. Variant 2: Poisoning Indirect Branches
Setup phase:
Train branch target buffer in attacker thread to jump to the chosen gadget’s virtual address
113

114. Variant 2: Poisoning Indirect Branches
Setup phase:
Train branch target buffer in attacker thread to jump to the chosen gadget’s virtual address
This works because the BTB is unaware/doesn’t care about process ids
114

115. Variant 2: Poisoning Indirect Branches
Setup phase:
Train branch target buffer in attacker thread to jump to the chosen gadget’s virtual address
This works because the BTB is unaware/doesn’t care about process ids
Example of indirect branch:
115

116. Variant 2: Poisoning Indirect Branches
Setup phase:
Train branch target buffer in attacker thread to jump to the chosen gadget’s virtual address
This works because the BTB is unaware/doesn’t care about process ids
Example of indirect branch:
jmp eax
116

117. Variant 2: Poisoning Indirect Branches
117

118. Variant 2: Poisoning Indirect Branches
Second phase:
118

119. Variant 2: Poisoning Indirect Branches
Second phase:
Victim speculatively jumps to gadget, which then leaks information
119

120. Variant 2: Poisoning Indirect Branches
Second phase:
Victim speculatively jumps to gadget, which then leaks information
Final phase: Recover over covert channel
120

121. Variant 2: Implementation in Windows
121

122. Variant 2: Implementation in Windows
Creates random key, calls sleep, reads from file, calls crypto
122

123. Variant 2: Implementation in Windows
Creates random key, calls sleep, reads from file, calls crypto
When compiled with optimization,Sleep() gets made with file data in registers ebx and edi
123

124. Variant 2: Implementation in Windows
Creates random key, calls sleep, reads from file, calls crypto
When compiled with optimization,Sleep() gets made with file data in registers ebx and edi
Found in ntdll.dll
124

125. Variant 2: Implementation in Windows
Creates random key, calls sleep, reads from file, calls crypto
When compiled with optimization,Sleep() gets made with file data in registers ebx and edi
Found in ntdll.dll
adc edi,dword ptr [ebx+edx+13BE13BDh]
125

126. Variant 2: Implementation in Windows
Creates random key, calls sleep, reads from file, calls crypto
When compiled with optimization,Sleep() gets made with file data in registers ebx and edi
Found in ntdll.dll
adc edi,dword ptr [ebx+edx+13BE13BDh]
adc dl,byte ptr [edi]
126

127. Variant 2: Implementation in Windows
127

128. Variant 2: Implementation in Windows
Branch to mistrain found in Sleep()
128

129. Variant 2: Implementation in Windows
Branch to mistrain found in Sleep()
“jmp dword ptr ds:[76AE0078h]”
129

130. Variant 2: Implementation in Windows
Branch to mistrain found in Sleep()
“jmp dword ptr ds:[76AE0078h]”
Speed: 41 B/s
130

131. Other Methods of achieving speculative execution
[1] Spectre Returns! Speculation Attacks using the Return Stack Buffer
By Esmaiel Mohammadian Koruyeh, Khaled Khasawneh,
Chengyu Song and Nael Abu-Ghazaleh
131

132. Other Methods of achieving speculative execution
Mistraining return instructions [1]
[1] Spectre Returns! Speculation Attacks using the Return Stack Buffer
By Esmaiel Mohammadian Koruyeh, Khaled Khasawneh,
Chengyu Song and Nael Abu-Ghazaleh
132

133. Other Methods of achieving speculative execution
Mistraining return instructions [1]
Return from interrupts
[1] Spectre Returns! Speculation Attacks using the Return Stack Buffer
By Esmaiel Mohammadian Koruyeh, Khaled Khasawneh,
Chengyu Song and Nael Abu-Ghazaleh
133

134. Method of leaking information
134

135. Method of leaking information
Evict+Time
135

136. Method of leaking information
Evict+Time
136

137. Method of leaking information
Evict+Time
Instruction Timing
137

138. Method of leaking information
Evict+Time
Instruction Timing
138

139. Method of leaking information
Evict+Time
Instruction Timing
Contention on the Register File
139

140. Mitigation Options
140
[2]
[1]

141. Mitigation Options Turn off speculation 141
[2]
[1]

142. Mitigation Options Turn off speculation
=>very large performance impact
142
[2]
[1]

143. Mitigation Options Turn off speculation
=>very large performance impact
Itanium, Mill architectures not vulnerable
143
[2]
[1]

144. Mitigation Options Turn off speculation
=>very large performance impact
Itanium, Mill architectures not vulnerable
Retpoline [1]
144
[2]
[1]

145. Mitigation Options Turn off speculation
=>very large performance impact
Itanium, Mill architectures not vulnerable
Retpoline [1]
swaps indirect branches for returns, to avoid using predictions which come from the BTB
145
[2]
[1]

146. Mitigation Options Turn off speculation
=>very large performance impact
Itanium, Mill architectures not vulnerable
Retpoline [1]
swaps indirect branches for returns, to avoid using predictions which come from the BTB
Masking, etc.
146
[2]
[1]

147. Mitigation Options Turn off speculation
=>very large performance impact
Itanium, Mill architectures not vulnerable
Retpoline [1]
swaps indirect branches for returns, to avoid using predictions which come from the BTB
Masking, etc.
Addressing Spectre Variant 1 (CVE ) in Software [2]
147
[2]
[1]

148. Mitigation Options
[1] oo7: Low-overhead Defense against Spectre Attacks via Binary Analysis
Guanhua Wang, Sudipta Chattopadhyay, Ivan Gotovchits, Tulika Mitra, Abhik Roychoudhury
148

149. Mitigation Options
Halt speculative execution on potentially sensitive execution paths
[1] oo7: Low-overhead Defense against Spectre Attacks via Binary Analysis
Guanhua Wang, Sudipta Chattopadhyay, Ivan Gotovchits, Tulika Mitra, Abhik Roychoudhury
149

150. Mitigation Options
Halt speculative execution on potentially sensitive execution paths
Not enough only on security-critical code because non-security-critical code in same process.
[1] oo7: Low-overhead Defense against Spectre Attacks via Binary Analysis
Guanhua Wang, Sudipta Chattopadhyay, Ivan Gotovchits, Tulika Mitra, Abhik Roychoudhury
150

151. Mitigation Options
Halt speculative execution on potentially sensitive execution paths
Not enough only on security-critical code because non-security-critical code in same process.
Compiler can’t find automatically [1]
[1] oo7: Low-overhead Defense against Spectre Attacks via Binary Analysis
Guanhua Wang, Sudipta Chattopadhyay, Ivan Gotovchits, Tulika Mitra, Abhik Roychoudhury
151

152. Mitigation Options
Halt speculative execution on potentially sensitive execution paths
Not enough only on security-critical code because non-security-critical code in same process.
Compiler can’t find automatically [1]
Need to recompile (what about legacy software?)
[1] oo7: Low-overhead Defense against Spectre Attacks via Binary Analysis
Guanhua Wang, Sudipta Chattopadhyay, Ivan Gotovchits, Tulika Mitra, Abhik Roychoudhury
152

153. Mitigation Options
Halt speculative execution on potentially sensitive execution paths
Not enough only on security-critical code because non-security-critical code in same process.
Compiler can’t find automatically [1]
Need to recompile (what about legacy software?)
Flush branch prediction state on context switch
[1] oo7: Low-overhead Defense against Spectre Attacks via Binary Analysis
Guanhua Wang, Sudipta Chattopadhyay, Ivan Gotovchits, Tulika Mitra, Abhik Roychoudhury
153

154. Mitigation Options
154

155. Mitigation Options
Countermeasures limited to cache likely insufficient
155

156. Mitigation Options
Countermeasures limited to cache likely insufficient
=> different microarchitectural state can be used to leak information
156

157. Novelty
157

158. Novelty
158

159. Novelty
First to exploit speculative execution
159

160. Novelty First to exploit speculative execution
Developers now need to know about microarchitecture to code non-vulnerable software!
160

161. Strengths
161

162. Strengths of the Paper
162

163. Strengths of the Paper
Hits at fundamentals of modern CPU
163

164. Strengths of the Paper Hits at fundamentals of modern CPU
No good mitigations
164

165. Strengths of the Paper Hits at fundamentals of modern CPU
No good mitigations
Non-buggy software affected
165

166. Strengths of the Paper Hits at fundamentals of modern CPU
No good mitigations
Non-buggy software affected
Can be used by JS
166

167. Strengths of the Paper Hits at fundamentals of modern CPU
No good mitigations
Non-buggy software affected
Can be used by JS
And even remotely:
167

168. Strengths of the Paper Hits at fundamentals of modern CPU
No good mitigations
Non-buggy software affected
Can be used by JS
And even remotely:
NetSpectre: Read Arbitrary Memory over Network by Michael Schwarz, Martin Schwarzl, Moritz Lipp, Daniel Gruss
168

169. Strengths of the Paper Hits at fundamentals of modern CPU
No good mitigations
Non-buggy software affected
Can be used by JS
And even remotely:
NetSpectre: Read Arbitrary Memory over Network by Michael Schwarz, Martin Schwarzl, Moritz Lipp, Daniel Gruss
Very well written paper
169

170. Strengths of the Paper Hits at fundamentals of modern CPU
No good mitigations
Non-buggy software affected
Can be used by JS
And even remotely:
NetSpectre: Read Arbitrary Memory over Network by Michael Schwarz, Martin Schwarzl, Moritz Lipp, Daniel Gruss
Very well written paper
Gives a refresher on virtual memory, caches, CPU architecture
170

171. Weaknesses
171

172. Weaknesses/Limitations of the Paper
172

173. Weaknesses/Limitations of the Paper
Have to target specific application and find gadgets in those
173

174. Weaknesses/Limitations of the Paper
Have to target specific application and find gadgets in those
=> But one can search in shared libraries
174

175. Weaknesses/Limitations of the Paper
Have to target specific application and find gadgets in those
=> But one can search in shared libraries
Doesn’t tell us the speed of the Javascript implementation
175

176. Related papers
176

177. Related papers
MeltdownPrime and SpectrePrime: Automatically-Synthesized Attacks Exploiting Invalidation-Based Coherence Protocols by Caroline Trippel, Daniel Lustig, Margaret Martonosi
177

178. Related papers
MeltdownPrime and SpectrePrime: Automatically-Synthesized Attacks Exploiting Invalidation-Based Coherence Protocols by Caroline Trippel, Daniel Lustig, Margaret Martonosi
Trusted Browsers for Uncertain Times by David Kohlbrenner and Hovav Shacham
178

179. Related papers
MeltdownPrime and SpectrePrime: Automatically-Synthesized Attacks Exploiting Invalidation-Based Coherence Protocols by Caroline Trippel, Daniel Lustig, Margaret Martonosi
Trusted Browsers for Uncertain Times by David Kohlbrenner and Hovav Shacham
Foreshadow: Extracting the Keys to the {Intel SGX} Kingdom with Transient Out-of-Order Execution by Van Bulck, Jo and Minkin, Marina and Weisse, Ofir and Genkin, Daniel and Kasikci, Baris and Piessens, Frank and Silberstein, Mark and Wenisch, Thomas F. and Yarom, Yuval and Strackx, Raoul
179

180. Related papers
MeltdownPrime and SpectrePrime: Automatically-Synthesized Attacks Exploiting Invalidation-Based Coherence Protocols by Caroline Trippel, Daniel Lustig, Margaret Martonosi
Trusted Browsers for Uncertain Times by David Kohlbrenner and Hovav Shacham
Foreshadow: Extracting the Keys to the {Intel SGX} Kingdom with Transient Out-of-Order Execution by Van Bulck, Jo and Minkin, Marina and Weisse, Ofir and Genkin, Daniel and Kasikci, Baris and Piessens, Frank and Silberstein, Mark and Wenisch, Thomas F. and Yarom, Yuval and Strackx, Raoul
A Systematic Evaluation of Transient Execution Attacks and Defenses by Claudio Canella, Jo Van Bulck, Michael Schwarz, Moritz Lipp, Benjamin von Berg, Philipp Ortner, Frank Piessens, Dmitry Evtyushkin, Daniel Gruss
180

181. Discussion Starters
181

182. Discussion Starters
Is there a fundamental tradeoff between security and speed?
182

183. Discussion Starters
Is there a fundamental tradeoff between security and speed?
Can Spectre be fixed in hardware?
183