SlideShare a Scribd company logo

Hardware/software security contracts: Principled foundations for building secure microarchitectures

Facultad de Informática UCM
Facultad de Informática UCM

Microarchitectural attacks, such as Spectre and Meltdown, are a class of security threats that affect almost all modern processors. These attacks exploit the side-effects resulting from processor optimizations to leak sensitive information and compromise a system’s security. Over the years, a large number of hardware and software mechanisms for preventing microarchitectural leaks have been proposed. Intuitively, more defensive mechanisms are less efficient, while more permissive mechanisms may offer more performance but require more defensive programming. Unfortunately, there are no hardware-software contracts that would turn this intuition into a basis for principled co-design. In this talk, we present a framework for specifying hardware/software security contracts, an abstraction that captures a processor’s security guarantees in a simple, mechanism-independent manner by specifying which program executions a microarchitectural attacker can distinguish.

1 of 276
Download to read offline
1
Hardware-software security contracts Principled foundations for building secure microarchitectures 1 Marco Guarnieri IMDEA Software Institute Contacts: marco.guarnieri@imdea.org 
 @MarcoGuarnier1 Based on joint work with Boris Köpf @ Microsoft Research Jan Reineke @ Saarland University José F. Morales, Pepe Vila, Andrés Sánchez @ IMDEA Software Institute Marco Patrignani @ CISPA
2
2 • Security • Programming 
 languages • Formal methods 2
3
Outline • Introduction • Speculative execution attacks • Hardware countermeasures and limitations • Hardware/software security contracts for secure speculation • Next steps & challenges 3
4
4
5
4
6
4 Attacks exploit μarchitectural side-e ff ects 
 invisible at ISA level
7
ISA: Benefits 5 High-level language Microarchitecture Instruction set architecture (ISA)
8
ISA: Benefits 5 High-level language Microarchitecture Instruction set architecture (ISA) Can program independently of 
 microarchitecture
9
ISA: Benefits 5 High-level language Microarchitecture Instruction set architecture (ISA) Can program independently of 
 microarchitecture Can implement arbitrary 
 optimizations as long as 
 ISA semantics are obeyed
10
ISA: (security) pitfalls 6 High-level language Microarchitecture Instruction set architecture (ISA)
11
ISA: (security) pitfalls 6 High-level language Microarchitecture Instruction set architecture (ISA) No guarantees about timing 
 and side channels
12
ISA: (security) pitfalls 6 High-level language Microarchitecture Instruction set architecture (ISA) Can implement arbitrary insecure 
 optimizations as long as ISA 
 semantics are obeyed No guarantees about timing 
 and side channels
13
ISA: (security) pitfalls 6 High-level language Microarchitecture Instruction set architecture (ISA) Can implement arbitrary insecure 
 optimizations as long as ISA 
 semantics are obeyed No guarantees about timing 
 and side channels
14
ISA: (security) pitfalls 6 High-level language Microarchitecture Instruction set architecture (ISA) Can implement arbitrary insecure 
 optimizations as long as ISA 
 semantics are obeyed No guarantees about timing 
 and side channels Impossible to program securely 
 cryptographic algorithms? sandboxing untrusted code?
15
A Way Forward: HW/SW Security Contracts 7 Succinctly captures possible information leakage Hw-Sw contract = ISA + X
16
A Way Forward: HW/SW Security Contracts 7 Can program securely on top contract 
 independently of microarchitecture Succinctly captures possible information leakage Hw-Sw contract = ISA + X
17
A Way Forward: HW/SW Security Contracts 7 Can program securely on top contract 
 independently of microarchitecture Can implement arbitrary insecure optimizations 
 as long as contract is obeyed Succinctly captures possible information leakage Hw-Sw contract = ISA + X
18
A Way Forward: HW/SW Security Contracts 7 Can program securely on top contract 
 independently of microarchitecture Can implement arbitrary insecure optimizations 
 as long as contract is obeyed Succinctly captures possible information leakage Hw-Sw contract = ISA + X In this talk 
 Proof-of-concept of HW/SW contracts for secure speculation
19
Speculative execution attacks 8
20
Exploits speculative execution Almost all modern CPUs are affected P. Kocher, J. Horn, A. Fogh, D. Genkin, D. Gruss, W. Haas, M. Hamburg, M. Lipp, S. Mangard, T. Prescher, M. Schwarz, Y. Yarom — Spectre Attacks: Exploiting Speculative Execution — S&P 2019 9
21
if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 10 Size of array A
22
if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 10 Size of array A
23
if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 10 Size of array A Branch predictor
24
if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 10 Size of array A Branch predictor Prediction based on branch history & program structure
25
if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 10 Size of array A Branch predictor Prediction based on branch history & program structure
26
if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 10 Size of array A Branch predictor Prediction based on branch history & program structure Wrong predicton? Rollback changes! Architectural (ISA) state Microarchitectural state
27
Spectre 101 11
28
Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] 11
29
Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] 11
30
Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] 11
31
Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] 11 What is in A[128]? A_size=16 B[0]B[1] ... B
32
Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 12 A_size=16 B[0]B[1] ... B
33
Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 12 A_size=16 B[0]B[1] ... B
34
Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 12 A_size=16 B[0]B[1] ... B
35
Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 12 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
36
B[A[128]] ] Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 12 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
37
B[A[128]] ] Depends on A[128] Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 12 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
38
B[A[128]] ] Depends on A[128] Persistent across speculations Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 12 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
39
B[A[128]] ] Depends on A[128] Persistent across speculations Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 4) Extract from cache 12 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
40
Countermeasures 13
41
Hardware countermeasures 14
42
Hardware countermeasures 14
43
Hardware countermeasures 14
44
Hardware countermeasures 14
45
Hardware countermeasures 14
46
Hardware countermeasures 14
47
Hardware countermeasures 4 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end
48
Hardware countermeasures 4 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end
49
Hardware countermeasures 4 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end
50
Hardware countermeasures 4 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end Delay loads until 
 they can be retired 
 [Sakalis et al., ISCA’19] Delay loads until they cannot be squashed 
 [Sakalis et al., ISCA’19]
51
Hardware countermeasures 4 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end Delay loads until 
 they can be retired 
 [Sakalis et al., ISCA’19] Delay loads until they cannot be squashed 
 [Sakalis et al., ISCA’19] Taint speculatively loaded data + delay tainted loads 
 [STT and NDA, MICRO’19]
52
Hardware countermeasures 5 1. y = A[x] 2. if (x < A_size) 3. z = B[y] 4. end
53
Hardware countermeasures 5 1. y = A[x] 2. if (x < A_size) 3. z = B[y] 4. end Delay loads until 
 they can be retired 
 [Sakalis et al., ISCA'19] Delay loads until they cannot be squashed 
 [Sakalis et al., ISCA'19]
54
Hardware countermeasures 5 1. y = A[x] 2. if (x < A_size) 3. z = B[y] 4. end Delay loads until 
 they can be retired 
 [Sakalis et al., ISCA'19] Delay loads until they cannot be squashed 
 [Sakalis et al., ISCA'19] Taint speculatively loaded data + delay tainted loads 
 [STT and NDA, MICRO’19]
55
Hardware countermeasures 6
56
Hardware countermeasures 6 Security guarantees?
57
How can we capture security guarantees? 18 Software Hardware C
 o
 n
 t
 r
 a
 c
 t
58
Hardware/software security contracts 19 Guarnieri, Köpf, Reineke, Vila — Hardware-software contracts for secure speculation — IEEE S&P 2021 
 https://arxiv.org/abs/2006.03841
59
Contracts for side-channel-free systems 20
60
Contracts for side-channel-free systems 20 Contracts specify which program executions a side-channel adversary can distinguish
61
Contracts for side-channel-free systems 20 Contracts specify which program executions a side-channel adversary can distinguish Goals • Capture security guarantees of HW • Basis for secure programming
62
Contracts 21
63
Contract ISA extended with observations Contracts 21
64
Contract ISA extended with observations Contracts 21 Observations expose security-relevant 
 μarch events
65
Contract ISA extended with observations Contracts 21 Observations expose security-relevant 
 μarch events Contract traces: (p, σ)
66
Contract ISA extended with observations Contracts 21 Observations expose security-relevant 
 μarch events Contract traces: (p, σ) Hardware Formal model of 
 processor
67
Contract ISA extended with observations Contracts 21 Observations expose security-relevant 
 μarch events Contract traces: (p, σ) Hardware Formal model of 
 processor Hardware traces: (p, σ)
68
Contract ISA extended with observations Contracts 21 Observations expose security-relevant 
 μarch events Attacker observes sequences of μarch states Contract traces: (p, σ) Hardware Formal model of 
 processor Hardware traces: (p, σ)
69
Contract ISA extended with observations Contracts 21 Contract satisfaction Hardware satis fi es contract if for all programs and arch. states , : if then p σ σ′  (p, σ)= (p, σ′  ) (p, σ) = (p, σ′  ) Observations expose security-relevant 
 μarch events Attacker observes sequences of μarch states Contract traces: (p, σ) Hardware Formal model of 
 processor Hardware traces: (p, σ)
70
Contract ISA extended with observations Contracts 21 Contract satisfaction Hardware satis fi es contract if for all programs and arch. states , : if then p σ σ′  (p, σ)= (p, σ′  ) (p, σ) = (p, σ′  ) Observations expose security-relevant 
 μarch events Attacker observes sequences of μarch states Contract traces: (p, σ) Hardware Formal model of 
 processor Hardware traces: (p, σ)
71
Contract ISA extended with observations Contracts 21 Contract satisfaction Hardware satis fi es contract if for all programs and arch. states , : if then p σ σ′  (p, σ)= (p, σ′  ) (p, σ) = (p, σ′  ) Observations expose security-relevant 
 μarch events Attacker observes sequences of μarch states Contract traces: (p, σ) Hardware Formal model of 
 processor Hardware traces: (p, σ)
72
Contracts for secure speculation 22
73
Contracts for secure speculation 22 Contract = 
 Execution Mode · Observer Mode
74
Contracts for secure speculation 22 Contract = 
 Execution Mode · Observer Mode How are programs executed?
75
Contracts for secure speculation 22 Contract = 
 Execution Mode · Observer Mode How are programs executed? What is visible about the execution?
76
seq — sequential execution spec — mispredict branch instrs. Contracts for secure speculation 23 Contract = 
 Execution Mode · Observer Mode
77
pc — only program counter ct — pc + addr. of loads and stores 
 arch — ct + loaded values 
 Contracts for secure speculation 24 Contract = 
 Execution Mode · Observer Mode
78
A lattice of contracts 25 Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc ⊤ ⊥
79
A lattice of contracts 25 Leaks “everything” Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc ⊤ ⊥
80
A lattice of contracts 25 Leaks “everything” Leaks “nothing” Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc ⊤ ⊥
81
A lattice of contracts 25 Leaks “everything” Leaks “nothing” Leaks addresses of non-spec. loads/stores/ instruction fetches Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc ⊤ ⊥
82
A lattice of contracts 25 Leaks “everything” Leaks “nothing” Leaks addresses of non-spec. loads/stores/ instruction fetches Leaks all data 
 accessed non- speculatively Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc ⊤ ⊥
83
A lattice of contracts 25 Leaks “everything” Leaks “nothing” Leaks addresses of non-spec. loads/stores/ instruction fetches Leaks all data 
 accessed non- speculatively Leaks addresses of all loads/ stores/instruction fetches Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc ⊤ ⊥
84
Example: seq-ct 26 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end 😈
85
Example: seq-ct 26 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x < A_size 😈
86
Example: seq-ct 26 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x < A_size 😈 pc 2
87
Example: seq-ct 26 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x < A_size 😈 load A+x
88
Example: seq-ct 26 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x < A_size 😈 load B+A[x]
89
Example: seq-arch 27 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end 😈
90
Example: seq-arch 27 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x < A_size 😈
91
Example: seq-arch 27 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x < A_size 😈 pc 2
92
Example: seq-arch 27 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x < A_size 😈 load A+x,A[x]
93
load B+A[x],B[A[x]] Example: seq-arch 27 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x < A_size 😈
94
Example: spec-ct 28 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end 😈
95
Example: spec-ct 28 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
96
Example: spec-ct 28 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
97
Example: spec-ct 28 start pc 2 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
98
Example: spec-ct 28 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
99
Example: spec-ct 28 load A+x 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
100
Example: spec-ct 28 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
101
Example: spec-ct 28 load B+A[x] 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
102
Example: spec-ct 28 rollback pc 4 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
103
Example: spec-ct 28 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
104
Hardware countermeasures 29
105
A simple processor 30 See paper for: processor operational semantics and security proofs
106
A simple processor Speculative and out-of-order executions 30 See paper for: processor operational semantics and security proofs
107
A simple processor 3-stage pipeline 
 (fetch, execute, retire) Speculative and out-of-order executions 30 See paper for: processor operational semantics and security proofs
108
A simple processor Parametric in branch predictor and memory hierarchy 3-stage pipeline 
 (fetch, execute, retire) Speculative and out-of-order executions 30 See paper for: processor operational semantics and security proofs
109
A simple processor Parametric in branch predictor and memory hierarchy 3-stage pipeline 
 (fetch, execute, retire) Speculative and out-of-order executions 30 See paper for: processor operational semantics and security proofs Modeled as operational semantics describing how processor’s state changes 
 (inspired by [Cauligi et al. 2019]) ⇒
110
No countermeasures [The world before Spectre] 17
111
No countermeasures [The world before Spectre] 17 if (x < A_size) 
 z = A[x] 
 y = B[z]
112
No countermeasures [The world before Spectre] 17 if (x < A_size) 
 z = A[x] 
 y = B[z]
113
No countermeasures [The world before Spectre] 17 if (x < A_size) 
 z = A[x] 
 y = B[z]
114
No countermeasures [The world before Spectre] 17 Satis fi es spec-ct if (x < A_size) 
 z = A[x] 
 y = B[z]
115
Disabling speculative execution 32
116
Disabling speculative execution 32 Instructions are executed sequentially
117
Disabling speculative execution 32 Instructions are executed sequentially 🥳 No speculative leaks 🥳
118
Disabling speculative execution 32 Instructions are executed sequentially 🥳 No speculative leaks 🥳 Satis fi es seq-ct
119
Eager load delay [Sakalis et al., ISCA’19] 33
120
Eager load delay [Sakalis et al., ISCA’19] 33 Delaying loads until all sources of speculation are resolved
121
Eager load delay [Sakalis et al., ISCA’19] 33 Delaying loads until all sources of speculation are resolved Security guarantees?
122
Eager load delay [Sakalis et al., ISCA’19] 34 if (x < A_size) 
 z = A[x] 
 y = B[z]
123
Eager load delay [Sakalis et al., ISCA’19] 34 if (x < A_size) 
 z = A[x] 
 y = B[z]
124
Eager load delay [Sakalis et al., ISCA’19] 34 if (x < A_size) 
 z = A[x] 
 y = B[z] A[x]and B[z] delayed until 
 x < A_size is resolved
125
Eager load delay [Sakalis et al., ISCA’19] 34 if (x < A_size) 
 z = A[x] 
 y = B[z] A[x]and B[z] delayed until 
 x < A_size is resolved 🥳 No speculative leaks 🥳
126
Eager load delay [Sakalis et al., ISCA’19] 35 z = A[x] if(x < A_size) 
 if(z==0) 
 skip
127
Eager load delay [Sakalis et al., ISCA’19] 35 z = A[x] if(x < A_size) 
 if(z==0) 
 skip
128
Eager load delay [Sakalis et al., ISCA’19] 35 z = A[x] if(x < A_size) 
 if(z==0) 
 skip if(z==0) is not delayed
129
Eager load delay [Sakalis et al., ISCA’19] 35 z = A[x] if(x < A_size) 
 if(z==0) 
 skip if(z==0) is not delayed Program speculatively 
 leaks A[x] 😞
130
Eager load delay [Sakalis et al., ISCA’19] 36
131
Eager load delay [Sakalis et al., ISCA’19] 36 Satis fi es seq-arch Satis fi es seq/spec-ct/pc
132
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 37
133
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 37 Taint speculatively loaded data
134
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 37 Propagate taint through computation Taint speculatively loaded data
135
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 37 Propagate taint through computation Delay tainted operations Taint speculatively loaded data
136
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 37 Propagate taint through computation Delay tainted operations Taint speculatively loaded data Security guarantees?
137
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 38 if (x < A_size) 
 z = A[x] 
 y = B[z]
138
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 38 if (x < A_size) 
 z = A[x] 
 y = B[z]
139
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 38 if (x < A_size) 
 z = A[x] 
 y = B[z] A[x]tainted as unsafe 
 B[z] delayed until 
 A[x] is safe
140
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 38 if (x < A_size) 
 z = A[x] 
 y = B[z] A[x]tainted as unsafe 
 B[z] delayed until 
 A[x] is safe 🥳 No speculative leaks 🥳
141
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 39 z = A[x] 
 if (x < A_size) 
 y = B[z]
142
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 39 z = A[x] 
 if (x < A_size) 
 y = B[z]
143
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 39 z = A[x] 
 if (x < A_size) 
 y = B[z] A[x]tagged as safe 
 
 B[z] not delayed
144
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 39 z = A[x] 
 if (x < A_size) 
 y = B[z] A[x]tagged as safe 
 
 B[z] not delayed Program speculatively 
 leaks A[x] 😞
145
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 40
146
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 40 Satis fi es seq-arch Satis fi es spec-ct
147
Security guarantees 41 See paper for: models and security proofs Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc OoO NS LD TT Vanilla OoO CPU + 
 spec. exec In-order CPU 
 (no specExec) OoO CPU+load delay OoO CPU+taint tracking
148
Security guarantees 41 See paper for: models and security proofs Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc OoO NS LD TT Vanilla OoO CPU + 
 spec. exec In-order CPU 
 (no specExec) OoO CPU+load delay OoO CPU+taint tracking OoO
149
Security guarantees 41 See paper for: models and security proofs Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc OoO NS LD TT Vanilla OoO CPU + 
 spec. exec In-order CPU 
 (no specExec) OoO CPU+load delay OoO CPU+taint tracking OoO NS
150
Security guarantees 41 See paper for: models and security proofs Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc OoO NS LD TT Vanilla OoO CPU + 
 spec. exec In-order CPU 
 (no specExec) OoO CPU+load delay OoO CPU+taint tracking OoO LD NS LD
151
Security guarantees 41 See paper for: models and security proofs Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc OoO NS LD TT Vanilla OoO CPU + 
 spec. exec In-order CPU 
 (no specExec) OoO CPU+load delay OoO CPU+taint tracking OoO TT LD NS TT LD
152
Secure programming 25
153
Two flavors of secure programming 26 Sandboxing Constant-time
154
Two flavors of secure programming 26 Sandboxing Constant-time
155
Two flavors of secure programming 26 Sandboxing Constant-time
156
Constant-time Sandboxing Checking secure programming 27 Seq-ct Seq-arch Spec-ct ❌ ✓ ✓ ✓ ❌ ❌ See paper for: additional security checks, proofs, automation
157
Constant-time Sandboxing Checking secure programming 27 Seq-ct Seq-arch Spec-ct ❌ ✓ ✓ ✓ ❌ ❌ See paper for: additional security checks, proofs, automation
158
What’s next? 45
159
46 Hw-Sw security
 contracts Modeling and 
 speci fi cations Hardware Software
160
46 Hw-Sw security
 contracts Modeling and 
 speci fi cations Hardware Software
161
Contracts & Modeling 47
162
Contracts & Modeling 47 So far: toy ISA + observation modes for cache/control- fl ow leaks + execution modes for branch speculation
163
Contracts & Modeling 47 So far: toy ISA + observation modes for cache/control- fl ow leaks + execution modes for branch speculation Challenge: scale to real-world ISAs
164
Contracts & Modeling 47 So far: toy ISA + observation modes for cache/control- fl ow leaks + execution modes for branch speculation Challenge: scale to real-world ISAs What do we need? Formal models of ISAs + adequate extensions to capture leaks
165
48 Hw-Sw security
 contracts Modeling and 
 speci fi cations Hardware Software
166
48 Hw-Sw security
 contracts Modeling and 
 speci fi cations Hardware Software
167
Contracts & Hardware 49
168
Contracts & Hardware 49 So far: manual security proofs on toy CPU/ISA
169
Contracts & Hardware 49 So far: manual security proofs on toy CPU/ISA Challenge: automation for realistic CPUs
170
Contracts & Hardware 49 So far: manual security proofs on toy CPU/ISA Challenge: automation for realistic CPUs What do we need? Automated veri fi cation and testing techniques for contract satisfaction
171
50 Hw-Sw security
 contracts Modeling and 
 speci fi cations Hardware Software
172
50 Hw-Sw security
 contracts Modeling and 
 speci fi cations Hardware Software
173
Contracts & Software 51
174
Contracts & Software 51 So far: contracts as secure programming foundations + tools targeting “ fi xed contracts”
175
Contracts & Software 51 So far: contracts as secure programming foundations + tools targeting “ fi xed contracts” Challenge: support for large classes of contracts
176
Contracts & Software 51 So far: contracts as secure programming foundations + tools targeting “ fi xed contracts” Challenge: support for large classes of contracts What do we need? Contract-aware program analyses and secure compilation passes
177
Conclusions 28
178

 Contract ISA extended with observations Contracts Contract satisfaction Hardware satisfies contract if for all programs and arch. states , : if then p σ σ′ (p, σ)= (p, σ′) (p, σ) = (p, σ′) Contract traces: (p, σ) Hardware Formal model of processor Hardware traces: (p, σ) A lattice of contracts Leaks “everything” Leaks “nothing” Leaks addresses of non-spec. loads/stores/ instruction fetches Leaks all data accessed non- speculatively Leaks addresses of all loads/ stores/instruction fetches Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc ⊤ ⊥ Security guarantees Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc OoO NS LD TT Vanilla OoO CPU + spec. exec In-order CPU (no specExec) OoO CPU+load delay OoO CPU+taint tracking OoO TT LD NS TT LD Two flavors of secure programming Sandboxing Constant-time
179

 Contract ISA extended with observations Contracts Contract satisfaction Hardware satisfies contract if for all programs and arch. states , : if then p σ σ′ (p, σ)= (p, σ′) (p, σ) = (p, σ′) Contract traces: (p, σ) Hardware Formal model of processor Hardware traces: (p, σ) A lattice of contracts Leaks “everything” Leaks “nothing” Leaks addresses of non-spec. loads/stores/ instruction fetches Leaks all data accessed non- speculatively Leaks addresses of all loads/ stores/instruction fetches Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc ⊤ ⊥ Security guarantees Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc OoO NS LD TT Vanilla OoO CPU + spec. exec In-order CPU (no specExec) OoO CPU+load delay OoO CPU+taint tracking OoO TT LD NS TT LD Two flavors of secure programming Sandboxing Constant-time marco.guarnieri@imdea.org @MarcoGuarnier1 Find out more in the paper: 
 https://arxiv.org/abs/2006.03841
180
Backup 28
181
What’s next? 25
182
56 Software Hardware
183
56 Software Hardware Knows what data is sensitive
184
56 Controls microarchitectural state Software Hardware Knows what data is sensitive
185
Contracts as basis for HW/SW co-design 56 Controls microarchitectural state Software Hardware C 
 o 
 n 
 t 
 r 
 a 
 c 
 t Knows what data is sensitive
186
Contracts @ Software 57
187
Contracts @ Software 57 Program analysis + Guarnieri et al., Spectector: Principled detection of speculative leaks, S&P 2020 Program analyzers that work for arbitrary contracts
188
Contracts @ Software 57 Secure compilation Compiler Source program Target program Contract Compiler takes contracts as input Ensure security at contract level Patrignani and Guarnieri, Exorcising Spectre with secure compilers, CCS 2021 Program analysis + Guarnieri et al., Spectector: Principled detection of speculative leaks, S&P 2020 Program analyzers that work for arbitrary contracts
189
Contracts @ Hardware 58
190
Contracts @ Hardware 58 Veri fi cation Tools for checking compliance with contracts (Partially) automate contract satisfaction proofs
191
Contracts @ Hardware 58 Veri fi cation Tools for checking compliance with contracts (Partially) automate contract satisfaction proofs Testing/Fuzzing Contracts as test oracles Black box: see Oleksenko et al., Revizor: Fuzzing for Leaks in Black-box CPUs https://arxiv.org/ abs/2105.06872 White box: WIP!
192
A simple processor — Configurations 59
193
A simple processor — Configurations 59 Configurations: State of the processor during computation
194
A simple processor — Configurations 59 Configurations: State of the processor during computation ⟨m, a, buf, cs, bp, sc⟩
195
A simple processor — Configurations 59 Configurations: State of the processor during computation Memory ⟨m, a, buf, cs, bp, sc⟩
196
A simple processor — Configurations 59 Configurations: State of the processor during computation Memory Registers ⟨m, a, buf, cs, bp, sc⟩
197
A simple processor — Configurations 59 Configurations: State of the processor during computation Memory Registers Reorder 
 bu ff er ⟨m, a, buf, cs, bp, sc⟩
198
A simple processor — Configurations 59 Configurations: State of the processor during computation Memory Registers Reorder 
 bu ff er Cache 
 (metadata) ⟨m, a, buf, cs, bp, sc⟩
199
A simple processor — Configurations 59 Configurations: State of the processor during computation Memory Registers Reorder 
 bu ff er Cache 
 (metadata) Branch 
 predictor ⟨m, a, buf, cs, bp, sc⟩
200
A simple processor — Configurations 59 Configurations: State of the processor during computation Memory Registers Reorder 
 bu ff er Cache 
 (metadata) Branch 
 predictor Scheduler ⟨m, a, buf, cs, bp, sc⟩
201
A simple processor — Configurations 59 Configurations: State of the processor during computation Memory Registers Reorder 
 bu ff er Cache 
 (metadata) Branch 
 predictor Scheduler 😈 ⟨m, a, buf, cs, bp, sc⟩
202
A simple processor — Semantics 60
203
A simple processor — Semantics 60 Semantics: Describe how con fi gurations evolve
204
A simple processor — Semantics 60 Semantics: Describe how con fi gurations evolve Hardware semantics We formalize the hardware semantics of a µASM program ng a binary relation ) ✓ HwStates ⇥ HwStates that ma dware states to their successors: STEP hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) hm,a,buf,cs,bp,sci)hm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i e rule captures one execution step at the µarch. level. T
205
A simple processor — Semantics 60 Semantics: Describe how con fi gurations evolve Hardware semantics We formalize the hardware semantics of a µASM program ng a binary relation ) ✓ HwStates ⇥ HwStates that ma dware states to their successors: STEP hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) hm,a,buf,cs,bp,sci)hm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i e rule captures one execution step at the µarch. level. T Current state
206
A simple processor — Semantics 60 Semantics: Describe how con fi gurations evolve Hardware semantics We formalize the hardware semantics of a µASM program ng a binary relation ) ✓ HwStates ⇥ HwStates that ma dware states to their successors: STEP hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) hm,a,buf,cs,bp,sci)hm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i e rule captures one execution step at the µarch. level. T Current state Next state
207
A simple processor — Semantics 60 Semantics: Describe how con fi gurations evolve Hardware semantics We formalize the hardware semantics of a µASM program ng a binary relation ) ✓ HwStates ⇥ HwStates that ma dware states to their successors: STEP hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) hm,a,buf,cs,bp,sci)hm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i e rule captures one execution step at the µarch. level. T Current state Next state Directive from scheduler 
 fetch, execute i, retire
208
A simple processor — Semantics 60 Semantics: Describe how con fi gurations evolve Hardware semantics We formalize the hardware semantics of a µASM program ng a binary relation ) ✓ HwStates ⇥ HwStates that ma dware states to their successors: STEP hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) hm,a,buf,cs,bp,sci)hm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i e rule captures one execution step at the µarch. level. T Current state Next state Directive from scheduler 
 fetch, execute i, retire Semantics for pipeline stages
209
Rules capture effect of directives - Fetch 61 nents reted s) 2 ad- miss state that ocks ction edic- been ictor For each directive, i.e., fetch,execute i, and retire, we sketch below the rules that govern the definition of the auxiliary relations fetch = = ), execute i = = = = = ), and retire = = = ). 1) Fetch: Instructions are fetched in-order. Here we present selected rules modeling instruction fetch: FETCH-BRANCH-HIT a0 = apl(buf,a) |buf| < w a0 (pc) 6= ? p(a0 (pc)) = beqz x,` `0 = predict(bp,a0 (pc)) access(cs,a0 (pc)) = Hit update(cs,a0 (pc)) = cs0 hm,a,buf,cs,bpi fetch = = )hm,a,buf ·pc `0 @a0 (pc),cs0 ,bpi FETCH-MISS |buf| < w a0 = apl(buf,a) a0 (pc) 6= ? access(cs,a0 (pc)) = Miss update(cs,a0 (pc)) = cs0
210
Rules capture effect of directives - Fetch 61 nents reted s) 2 ad- miss state that ocks ction edic- been ictor For each directive, i.e., fetch,execute i, and retire, we sketch below the rules that govern the definition of the auxiliary relations fetch = = ), execute i = = = = = ), and retire = = = ). 1) Fetch: Instructions are fetched in-order. Here we present selected rules modeling instruction fetch: FETCH-BRANCH-HIT a0 = apl(buf,a) |buf| < w a0 (pc) 6= ? p(a0 (pc)) = beqz x,` `0 = predict(bp,a0 (pc)) access(cs,a0 (pc)) = Hit update(cs,a0 (pc)) = cs0 hm,a,buf,cs,bpi fetch = = )hm,a,buf ·pc `0 @a0 (pc),cs0 ,bpi FETCH-MISS |buf| < w a0 = apl(buf,a) a0 (pc) 6= ? access(cs,a0 (pc)) = Miss update(cs,a0 (pc)) = cs0 applying reorder buffer 
 to register state
211
Rules capture effect of directives - Fetch 61 nents reted s) 2 ad- miss state that ocks ction edic- been ictor For each directive, i.e., fetch,execute i, and retire, we sketch below the rules that govern the definition of the auxiliary relations fetch = = ), execute i = = = = = ), and retire = = = ). 1) Fetch: Instructions are fetched in-order. Here we present selected rules modeling instruction fetch: FETCH-BRANCH-HIT a0 = apl(buf,a) |buf| < w a0 (pc) 6= ? p(a0 (pc)) = beqz x,` `0 = predict(bp,a0 (pc)) access(cs,a0 (pc)) = Hit update(cs,a0 (pc)) = cs0 hm,a,buf,cs,bpi fetch = = )hm,a,buf ·pc `0 @a0 (pc),cs0 ,bpi FETCH-MISS |buf| < w a0 = apl(buf,a) a0 (pc) 6= ? access(cs,a0 (pc)) = Miss update(cs,a0 (pc)) = cs0 applying reorder buffer 
 to register state reorder buffer 
 is not full
212
Rules capture effect of directives - Fetch 61 nents reted s) 2 ad- miss state that ocks ction edic- been ictor For each directive, i.e., fetch,execute i, and retire, we sketch below the rules that govern the definition of the auxiliary relations fetch = = ), execute i = = = = = ), and retire = = = ). 1) Fetch: Instructions are fetched in-order. Here we present selected rules modeling instruction fetch: FETCH-BRANCH-HIT a0 = apl(buf,a) |buf| < w a0 (pc) 6= ? p(a0 (pc)) = beqz x,` `0 = predict(bp,a0 (pc)) access(cs,a0 (pc)) = Hit update(cs,a0 (pc)) = cs0 hm,a,buf,cs,bpi fetch = = )hm,a,buf ·pc `0 @a0 (pc),cs0 ,bpi FETCH-MISS |buf| < w a0 = apl(buf,a) a0 (pc) 6= ? access(cs,a0 (pc)) = Miss update(cs,a0 (pc)) = cs0 instruction is a 
 branch instruction is a 
 branch applying reorder buffer 
 to register state reorder buffer 
 is not full
213
Rules capture effect of directives - Fetch 61 nents reted s) 2 ad- miss state that ocks ction edic- been ictor For each directive, i.e., fetch,execute i, and retire, we sketch below the rules that govern the definition of the auxiliary relations fetch = = ), execute i = = = = = ), and retire = = = ). 1) Fetch: Instructions are fetched in-order. Here we present selected rules modeling instruction fetch: FETCH-BRANCH-HIT a0 = apl(buf,a) |buf| < w a0 (pc) 6= ? p(a0 (pc)) = beqz x,` `0 = predict(bp,a0 (pc)) access(cs,a0 (pc)) = Hit update(cs,a0 (pc)) = cs0 hm,a,buf,cs,bpi fetch = = )hm,a,buf ·pc `0 @a0 (pc),cs0 ,bpi FETCH-MISS |buf| < w a0 = apl(buf,a) a0 (pc) 6= ? access(cs,a0 (pc)) = Miss update(cs,a0 (pc)) = cs0 instruction is a 
 branch instruction is a 
 branch applying reorder buffer 
 to register state reorder buffer 
 is not full branch predictor 
 says is next ℓ′ 
214
Rules capture effect of directives - Fetch 61 nents reted s) 2 ad- miss state that ocks ction edic- been ictor For each directive, i.e., fetch,execute i, and retire, we sketch below the rules that govern the definition of the auxiliary relations fetch = = ), execute i = = = = = ), and retire = = = ). 1) Fetch: Instructions are fetched in-order. Here we present selected rules modeling instruction fetch: FETCH-BRANCH-HIT a0 = apl(buf,a) |buf| < w a0 (pc) 6= ? p(a0 (pc)) = beqz x,` `0 = predict(bp,a0 (pc)) access(cs,a0 (pc)) = Hit update(cs,a0 (pc)) = cs0 hm,a,buf,cs,bpi fetch = = )hm,a,buf ·pc `0 @a0 (pc),cs0 ,bpi FETCH-MISS |buf| < w a0 = apl(buf,a) a0 (pc) 6= ? access(cs,a0 (pc)) = Miss update(cs,a0 (pc)) = cs0 instruction is a 
 branch instruction is a 
 branch applying reorder buffer 
 to register state reorder buffer 
 is not full branch predictor 
 says is next ℓ′  Cache hit 
 + updating 
 cache state
215
Rules capture effect of directives - Fetch 61 nents reted s) 2 ad- miss state that ocks ction edic- been ictor For each directive, i.e., fetch,execute i, and retire, we sketch below the rules that govern the definition of the auxiliary relations fetch = = ), execute i = = = = = ), and retire = = = ). 1) Fetch: Instructions are fetched in-order. Here we present selected rules modeling instruction fetch: FETCH-BRANCH-HIT a0 = apl(buf,a) |buf| < w a0 (pc) 6= ? p(a0 (pc)) = beqz x,` `0 = predict(bp,a0 (pc)) access(cs,a0 (pc)) = Hit update(cs,a0 (pc)) = cs0 hm,a,buf,cs,bpi fetch = = )hm,a,buf ·pc `0 @a0 (pc),cs0 ,bpi FETCH-MISS |buf| < w a0 = apl(buf,a) a0 (pc) 6= ? access(cs,a0 (pc)) = Miss update(cs,a0 (pc)) = cs0 instruction is a 
 branch instruction is a 
 branch applying reorder buffer 
 to register state reorder buffer 
 is not full branch predictor 
 says is next ℓ′  Cache hit 
 + updating 
 cache state add change of pc to reorder buffer
216
Rules capture effect of directive - Retire 62 retiring only commands i@T at the head of the reorder buffer where the instruction i has been resolved, and the tag T is e indicating that there are no unresolved predictions. Selected rules for the retire directive are given below: RETIRE-ASSIGNMENT buf = x v@e ·buf0 v 2 Vals hm,a,buf,cs,bpi retire = = = )hm,a[x 7! v],buf0 ,cs,bpi RETIRE-STORE buf = store v,n@e ·buf0 v,n 2 Vals update(cs,n) = cs0 retire 0 0
217
Rules capture effect of directive - Retire 62 retiring only commands i@T at the head of the reorder buffer where the instruction i has been resolved, and the tag T is e indicating that there are no unresolved predictions. Selected rules for the retire directive are given below: RETIRE-ASSIGNMENT buf = x v@e ·buf0 v 2 Vals hm,a,buf,cs,bpi retire = = = )hm,a[x 7! v],buf0 ,cs,bpi RETIRE-STORE buf = store v,n@e ·buf0 v,n 2 Vals update(cs,n) = cs0 retire 0 0 result of instruction at head of 
 reorder buffer is resolved
218
Rules capture effect of directive - Retire 62 retiring only commands i@T at the head of the reorder buffer where the instruction i has been resolved, and the tag T is e indicating that there are no unresolved predictions. Selected rules for the retire directive are given below: RETIRE-ASSIGNMENT buf = x v@e ·buf0 v 2 Vals hm,a,buf,cs,bpi retire = = = )hm,a[x 7! v],buf0 ,cs,bpi RETIRE-STORE buf = store v,n@e ·buf0 v,n 2 Vals update(cs,n) = cs0 retire 0 0 result of instruction at head of 
 reorder buffer is resolved apply change to registers 
 and remove entry from reorder buffer
219
Eager load delay [Sakalis et al. 2019] 63 hm,a,buf,cs,bpi= )hm ,a ,buf ,cs ,bp i d = next(sc) sc0 = update(sc,buf0 #) d 2 {fetch,retire}_(d = execute i^buf|i 6= load x,e) hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i STEP-EAGER-DELAY hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) d = execute i buf|i = load x,e 8pc `@`0 2 buf[0..i 1]. `0 = e hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i and to selectively delay instruction tion. While these proposals slight are labelled and on the effects of the same building blocks and pro For this reason, we start by the Speculative Taint Tracking (S Data Access (NDA) [4] counterm a general extension to the hardwa for supporting taint-tracking schem izing a countermeasure inspired security guarantees, and we conc sure. This countermeasure consists in delaying loads until all sources of mis-speculation have been resolved. We remark that the hardware semantics of Section V supports speculation only over branch instructions. Therefore, we model the loadDelay countermeasure by preventing loads whenever there are pre- ceding, unresolved branch instructions in the reorder buffer. Using the terminology of [3], loads are delayed as long as they are under a so-called control-shadow. We formalize the loadDelay countermeasure by modifying the STEP rule of the hardware semantics as follows (changes are highlighted in blue): STEP-OTHERS hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) d 2 {fetch,retire}_(d = execute i^buf|i 6= load x,e) hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i STEP-EAGER-DELAY cution, and in addition, the progr speculative execution. This new countermeasure, leading to Theor Theorem 3. { |·| }loadDelay ` J·Kseq ct-p As the control flow during spe depend upon data previously lo security of the countermeasure can Theorem 4. { |·| }loadDelay ` J·K seq arc C. tt: Taint tracking of speculativ Recent work [4], [5] propose to and to selectively delay instruction tion. While these proposals slight are labelled and on the effects of the same building blocks and pro For this reason, we start by the Speculative Taint Tracking (S
220
Eager load delay [Sakalis et al. 2019] 63 hm,a,buf,cs,bpi= )hm ,a ,buf ,cs ,bp i d = next(sc) sc0 = update(sc,buf0 #) d 2 {fetch,retire}_(d = execute i^buf|i 6= load x,e) hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i STEP-EAGER-DELAY hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) d = execute i buf|i = load x,e 8pc `@`0 2 buf[0..i 1]. `0 = e hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i and to selectively delay instruction tion. While these proposals slight are labelled and on the effects of the same building blocks and pro For this reason, we start by the Speculative Taint Tracking (S Data Access (NDA) [4] counterm a general extension to the hardwa for supporting taint-tracking schem izing a countermeasure inspired security guarantees, and we conc Loads are executed only if prior branch instructions are resolved sure. This countermeasure consists in delaying loads until all sources of mis-speculation have been resolved. We remark that the hardware semantics of Section V supports speculation only over branch instructions. Therefore, we model the loadDelay countermeasure by preventing loads whenever there are pre- ceding, unresolved branch instructions in the reorder buffer. Using the terminology of [3], loads are delayed as long as they are under a so-called control-shadow. We formalize the loadDelay countermeasure by modifying the STEP rule of the hardware semantics as follows (changes are highlighted in blue): STEP-OTHERS hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) d 2 {fetch,retire}_(d = execute i^buf|i 6= load x,e) hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i STEP-EAGER-DELAY cution, and in addition, the progr speculative execution. This new countermeasure, leading to Theor Theorem 3. { |·| }loadDelay ` J·Kseq ct-p As the control flow during spe depend upon data previously lo security of the countermeasure can Theorem 4. { |·| }loadDelay ` J·K seq arc C. tt: Taint tracking of speculativ Recent work [4], [5] propose to and to selectively delay instruction tion. While these proposals slight are labelled and on the effects of the same building blocks and pro For this reason, we start by the Speculative Taint Tracking (S
221
Eager load delay [Sakalis et al. 2019] 63 hm,a,buf,cs,bpi= )hm ,a ,buf ,cs ,bp i d = next(sc) sc0 = update(sc,buf0 #) d 2 {fetch,retire}_(d = execute i^buf|i 6= load x,e) hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i STEP-EAGER-DELAY hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) d = execute i buf|i = load x,e 8pc `@`0 2 buf[0..i 1]. `0 = e hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i and to selectively delay instruction tion. While these proposals slight are labelled and on the effects of the same building blocks and pro For this reason, we start by the Speculative Taint Tracking (S Data Access (NDA) [4] counterm a general extension to the hardwa for supporting taint-tracking schem izing a countermeasure inspired security guarantees, and we conc Loads are executed only if prior branch instructions are resolved sure. This countermeasure consists in delaying loads until all sources of mis-speculation have been resolved. We remark that the hardware semantics of Section V supports speculation only over branch instructions. Therefore, we model the loadDelay countermeasure by preventing loads whenever there are pre- ceding, unresolved branch instructions in the reorder buffer. Using the terminology of [3], loads are delayed as long as they are under a so-called control-shadow. We formalize the loadDelay countermeasure by modifying the STEP rule of the hardware semantics as follows (changes are highlighted in blue): STEP-OTHERS hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) d 2 {fetch,retire}_(d = execute i^buf|i 6= load x,e) hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i STEP-EAGER-DELAY cution, and in addition, the progr speculative execution. This new countermeasure, leading to Theor Theorem 3. { |·| }loadDelay ` J·Kseq ct-p As the control flow during spe depend upon data previously lo security of the countermeasure can Theorem 4. { |·| }loadDelay ` J·K seq arc C. tt: Taint tracking of speculativ Recent work [4], [5] propose to and to selectively delay instruction tion. While these proposals slight are labelled and on the effects of the same building blocks and pro For this reason, we start by the Speculative Taint Tracking (S Everything else works as before
222
Hw-level taint-tracking [Yu et al. 2019, Weisse et al. 2019] 64 modeled by d). We describe later how these functions can be instantiated to model STT and NDA. We formalize the tt countermeasure by modifying the STEP rule as follows (changes are highlighted in blue): STEP d = next(sc) buful = unlbl(buf,d) hm,a, buful ,cs,bpi d = )hm0 ,a0 , buf0 ul ,cs0 ,bp0 i sc0 = update(sc,buf0 #) buf0 = lbl(buf0 ul,buf,d) hm,a,buf,cs,bp,sci)tthm0 ,a0 buf0 ,cs0 ,bp0 ,sc0 i The rule differs from the standard STEP rule in three ways: • Entries in the reorder buffer are labelled. • Before activating a step in the pipeline, i.e., before apply- ing one step of d = ), we use the unlabeling function to derive an a transmit execute no • The la fies how ne labels are u – Newly f there is no they are la assignment unsafe dat labelled as All other n – Whenev labels are p – When w eliminating
223
Hw-level taint-tracking [Yu et al. 2019, Weisse et al. 2019] 64 modeled by d). We describe later how these functions can be instantiated to model STT and NDA. We formalize the tt countermeasure by modifying the STEP rule as follows (changes are highlighted in blue): STEP d = next(sc) buful = unlbl(buf,d) hm,a, buful ,cs,bpi d = )hm0 ,a0 , buf0 ul ,cs0 ,bp0 i sc0 = update(sc,buf0 #) buf0 = lbl(buf0 ul,buf,d) hm,a,buf,cs,bp,sci)tthm0 ,a0 buf0 ,cs0 ,bp0 ,sc0 i The rule differs from the standard STEP rule in three ways: • Entries in the reorder buffer are labelled. • Before activating a step in the pipeline, i.e., before apply- ing one step of d = ), we use the unlabeling function to derive an a transmit execute no • The la fies how ne labels are u – Newly f there is no they are la assignment unsafe dat labelled as All other n – Whenev labels are p – When w eliminating Entries in the reorder buffer are labelled as safe/unsafe
224
Hw-level taint-tracking [Yu et al. 2019, Weisse et al. 2019] 64 modeled by d). We describe later how these functions can be instantiated to model STT and NDA. We formalize the tt countermeasure by modifying the STEP rule as follows (changes are highlighted in blue): STEP d = next(sc) buful = unlbl(buf,d) hm,a, buful ,cs,bpi d = )hm0 ,a0 , buf0 ul ,cs0 ,bp0 i sc0 = update(sc,buf0 #) buf0 = lbl(buf0 ul,buf,d) hm,a,buf,cs,bp,sci)tthm0 ,a0 buf0 ,cs0 ,bp0 ,sc0 i The rule differs from the standard STEP rule in three ways: • Entries in the reorder buffer are labelled. • Before activating a step in the pipeline, i.e., before apply- ing one step of d = ), we use the unlabeling function to derive an a transmit execute no • The la fies how ne labels are u – Newly f there is no they are la assignment unsafe dat labelled as All other n – Whenev labels are p – When w eliminating Entries in the reorder buffer are labelled as safe/unsafe Derive unlabeled buffer 
 (hides information tagged 
 as unsafe)
225
Hw-level taint-tracking [Yu et al. 2019, Weisse et al. 2019] 64 modeled by d). We describe later how these functions can be instantiated to model STT and NDA. We formalize the tt countermeasure by modifying the STEP rule as follows (changes are highlighted in blue): STEP d = next(sc) buful = unlbl(buf,d) hm,a, buful ,cs,bpi d = )hm0 ,a0 , buf0 ul ,cs0 ,bp0 i sc0 = update(sc,buf0 #) buf0 = lbl(buf0 ul,buf,d) hm,a,buf,cs,bp,sci)tthm0 ,a0 buf0 ,cs0 ,bp0 ,sc0 i The rule differs from the standard STEP rule in three ways: • Entries in the reorder buffer are labelled. • Before activating a step in the pipeline, i.e., before apply- ing one step of d = ), we use the unlabeling function to derive an a transmit execute no • The la fies how ne labels are u – Newly f there is no they are la assignment unsafe dat labelled as All other n – Whenev labels are p – When w eliminating Entries in the reorder buffer are labelled as safe/unsafe Derive unlabeled buffer 
 (hides information tagged 
 as unsafe) Computation on unlabeled buffer
226
Hw-level taint-tracking [Yu et al. 2019, Weisse et al. 2019] 64 modeled by d). We describe later how these functions can be instantiated to model STT and NDA. We formalize the tt countermeasure by modifying the STEP rule as follows (changes are highlighted in blue): STEP d = next(sc) buful = unlbl(buf,d) hm,a, buful ,cs,bpi d = )hm0 ,a0 , buf0 ul ,cs0 ,bp0 i sc0 = update(sc,buf0 #) buf0 = lbl(buf0 ul,buf,d) hm,a,buf,cs,bp,sci)tthm0 ,a0 buf0 ,cs0 ,bp0 ,sc0 i The rule differs from the standard STEP rule in three ways: • Entries in the reorder buffer are labelled. • Before activating a step in the pipeline, i.e., before apply- ing one step of d = ), we use the unlabeling function to derive an a transmit execute no • The la fies how ne labels are u – Newly f there is no they are la assignment unsafe dat labelled as All other n – Whenev labels are p – When w eliminating Entries in the reorder buffer are labelled as safe/unsafe Update labels Derive unlabeled buffer 
 (hides information tagged 
 as unsafe) Computation on unlabeled buffer
227
Constant-time Sandboxing Checking secure programming 27 [[⋅]]seq ct [[⋅]]seq arch [[⋅]]spec ct ✓ ✓ ✓ See paper for: security de fi nitions .. + NI wrt [[⋅]]seq arch .. + Speculative NI 
 [Guarnieri et al., S&P’20] .. + weak spec. NI
228
Constant-time Sandboxing Checking secure programming 27 [[⋅]]seq ct [[⋅]]seq arch [[⋅]]spec ct ✓ ✓ ✓ See paper for: security de fi nitions .. + NI wrt [[⋅]]seq arch .. + Speculative NI 
 [Guarnieri et al., S&P’20] .. + weak spec. NI
229
Background: Reorder buffer 66
230
Background: Reorder buffer • Key hardware data structure for 
 out-of-order and speculative execution 66
231
Background: Reorder buffer • Key hardware data structure for 
 out-of-order and speculative execution • Keeps track of “in- fl ight instructions” 66
232
Background: Reorder buffer • Key hardware data structure for 
 out-of-order and speculative execution • Keeps track of “in- fl ight instructions” • Example: 66 Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: - - 3: - - … … … c ⟵ x < A_size beqz c, END L1: load t, A + x 
 load y, B + t END:
233
Background: Reorder buffer • Key hardware data structure for 
 out-of-order and speculative execution • Keeps track of “in- fl ight instructions” • Example: 66 Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: - - 3: - - … … … c ⟵ x < A_size beqz c, END L1: load t, A + x 
 load y, B + t END: Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 1 3: - - … … … Speculative 
 Instruction Fetch
234
Background: Reorder buffer • Key hardware data structure for 
 out-of-order and speculative execution • Keeps track of “in- fl ight instructions” • Example: 67 Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: - - 3: - - … … … c ⟵ x < A_size beqz c, END L1: load t, A + x 
 load y, B + t END: Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 1 3: load y, B + t 1 … … … Speculative 
 Instruction Fetch Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 1 3: - - … … …
235
Background: Reorder buffer • Key hardware data structure for 
 out-of-order and speculative execution • Keeps track of “in- fl ight instructions” • Example: 68 Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: - - 3: - - … … … c ⟵ x < A_size beqz c, END L1: load t, A + x 
 load y, B + t END: Entry Instruction Control Dep. 0: c ⟵ 0 - 1: beqz c, END - 2: load t, A + x 1 3: load y, B + t 1 … … … Evaluate x < A_size Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 2 3: - - … … … Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 1 3: load y, B + t 1 … … …
236
Background: Reorder buffer • Key hardware data structure for 
 out-of-order and speculative execution • Keeps track of “in- fl ight instructions” • Example: 69 Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: - - 3: - - … … … c ⟵ x < A_size beqz c, END L1: load t, A + x 
 load y, B + t END: Entry Instruction Control Dep. 0: c ⟵ 0 - 1: beqz c, END - 2: - - 3: - - … … … Rollback 
 mis-speculation Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 2 3: - - … … … Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 2 3: load y, B + t 2 … … … Entry Instruction Control Dep. 0: c ⟵ 0 - 1: beqz c, END - 2: load t, A + x 1 3: load y, B + t 1 … … …
237
Background: Reorder buffer • Key hardware data structure for 
 out-of-order and speculative execution • Keeps track of “in- fl ight instructions” • Example: 70 Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: - - 3: - - … … … c ⟵ x < A_size beqz c, END L1: load t, A + x 
 load y, B + t END: Entry Instruction Control Dep. 0: beqz c, END - 1: - - 2: - - 3: - - … … … Retire Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 2 3: - - … … … Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 2 3: load y, B + t 2 … … … Entry Instruction Control Dep. 0: c ⟵ 0 - 1: beqz c, END - 2: - - 3: - - … … …
238
Speculative execution attacks 101 71
239
if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 72 Size of array A
240
if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 72 Size of array A
241
if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 72 Size of array A Branch predictor
242
if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 72 Size of array A Branch predictor Prediction based on branch history & program structure
243
if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 72 Size of array A Branch predictor Prediction based on branch history & program structure
244
if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 72 Size of array A Branch predictor Prediction based on branch history & program structure Wrong predicton? Rollback changes! Architectural (ISA) state Microarchitectural state
245
Spectre V1 73
246
Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] 73
247
Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] 73
248
Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] 73
249
Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] 73 What is in A[128]? A_size=16 B[0]B[1] ... B
250
Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 74 A_size=16 B[0]B[1] ... B
251
Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 74 A_size=16 B[0]B[1] ... B
252
Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 74 A_size=16 B[0]B[1] ... B
253
Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 74 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
254
B[A[128]] ] Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 74 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
255
B[A[128]] ] Depends on A[128] Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 74 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
256
B[A[128]] ] Depends on A[128] Persistent across speculations Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 74 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
257
B[A[128]] ] Depends on A[128] Persistent across speculations Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 4) Extract from cache 74 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
258
Secure programming — foundations 75
259
Secure programming — foundations 75 Program is non-interferent wrt contract and policy 
 if for all arch. states , : if then p π σ σ′  σ ≈π σ′  (p, σ) = (p, σ′  )
260
Secure programming — foundations 75 Program is non-interferent wrt contract and policy 
 if for all arch. states , : if then p π σ σ′  σ ≈π σ′  (p, σ) = (p, σ′  ) Specify secret data
261
Secure programming — foundations 75 Program is non-interferent wrt contract and policy 
 if for all arch. states , : if then p π σ σ′  σ ≈π σ′  (p, σ) = (p, σ′  ) Specify secret data
262
Secure programming — foundations 75 Program is non-interferent wrt contract and policy 
 if for all arch. states , : if then p π σ σ′  σ ≈π σ′  (p, σ) = (p, σ′  ) Specify secret data
263
Secure programming — foundations 75 Program is non-interferent wrt contract and policy 
 if for all arch. states , : if then p π σ σ′  σ ≈π σ′  (p, σ) = (p, σ′  ) If is non-interferent wrt contract and policy , and hardware satis fi es , then 
 is non-interferent wrt hardware and policy 
 p π p π Specify secret data
264
Secure programming — foundations 75 Program is non-interferent wrt contract and policy 
 if for all arch. states , : if then p π σ σ′  σ ≈π σ′  (p, σ) = (p, σ′  ) If is non-interferent wrt contract and policy , and hardware satis fi es , then 
 is non-interferent wrt hardware and policy 
 p π p π Specify secret data
265
Secure programming — foundations 75 Program is non-interferent wrt contract and policy 
 if for all arch. states , : if then p π σ σ′  σ ≈π σ′  (p, σ) = (p, σ′  ) If is non-interferent wrt contract and policy , and hardware satis fi es , then 
 is non-interferent wrt hardware and policy 
 p π p π Specify secret data
266
Secure programming — foundations 75 Program is non-interferent wrt contract and policy 
 if for all arch. states , : if then p π σ σ′  σ ≈π σ′  (p, σ) = (p, σ′  ) If is non-interferent wrt contract and policy , and hardware satis fi es , then 
 is non-interferent wrt hardware and policy 
 p π p π Specify secret data
267
Constant-time 76
268
Constant-time 76 Traditional CT wrt policy non-interference wrt seq-ct and π ≡ π
269
Constant-time 76 Traditional CT wrt policy non-interference wrt seq-ct and π ≡ π Control- fl ow and memory accesses 
 do not depend on secrets
270
Constant-time 76 Traditional CT wrt policy non-interference wrt seq-ct and π ≡ π General CT wrt and non-interference wrt and π ≡ π Control- fl ow and memory accesses 
 do not depend on secrets
271
Sandboxing 77
272
Sandboxing 77 Traditional SB wrt policy non-interference wrt seq-arch and π ≡ π
273
Sandboxing 77 Traditional SB wrt policy non-interference wrt seq-arch and π ≡ π Programs never access high memory locations (out-of-sandbox)
274
Sandboxing 77 Traditional SB wrt policy non-interference wrt seq-arch and π ≡ π General SB wrt and 
 Traditional SB wrt + non-interference wrt and π ≡ π π Programs never access high memory locations (out-of-sandbox)
275
Constant-time Sandboxing Checking secure programming 78 [[⋅]]seq ct [[⋅]]seq arch [[⋅]]spec ct Traditional CT .. + NI wrt [[⋅]]seq arch .. + speculative NI 
 [Guarnieri et al., S&P’20] Traditional SB Traditional SB .. + weak spec. NI
276
Constant-time Sandboxing Checking secure programming 78 [[⋅]]seq ct [[⋅]]seq arch [[⋅]]spec ct Traditional CT .. + NI wrt [[⋅]]seq arch .. + speculative NI 
 [Guarnieri et al., S&P’20] Traditional SB Traditional SB .. + weak spec. NI
Hardware-software security contracts Principled foundations for building secure microarchitectures 1 Marco Guarnieri IMDEA Software Institute Contacts: marco.guarnieri@imdea.org 
 @MarcoGuarnier1 Based on joint work with Boris Köpf @ Microsoft Research Jan Reineke @ Saarland University José F. Morales, Pepe Vila, Andrés Sánchez @ IMDEA Software Institute Marco Patrignani @ CISPA
2 • Security • Programming 
 languages • Formal methods 2
Outline • Introduction • Speculative execution attacks • Hardware countermeasures and limitations • Hardware/software security contracts for secure speculation • Next steps & challenges 3
4
4
4 Attacks exploit μarchitectural side-e ff ects 
 invisible at ISA level
ISA: Benefits 5 High-level language Microarchitecture Instruction set architecture (ISA)
ISA: Benefits 5 High-level language Microarchitecture Instruction set architecture (ISA) Can program independently of 
 microarchitecture
ISA: Benefits 5 High-level language Microarchitecture Instruction set architecture (ISA) Can program independently of 
 microarchitecture Can implement arbitrary 
 optimizations as long as 
 ISA semantics are obeyed
ISA: (security) pitfalls 6 High-level language Microarchitecture Instruction set architecture (ISA)
ISA: (security) pitfalls 6 High-level language Microarchitecture Instruction set architecture (ISA) No guarantees about timing 
 and side channels
ISA: (security) pitfalls 6 High-level language Microarchitecture Instruction set architecture (ISA) Can implement arbitrary insecure 
 optimizations as long as ISA 
 semantics are obeyed No guarantees about timing 
 and side channels
ISA: (security) pitfalls 6 High-level language Microarchitecture Instruction set architecture (ISA) Can implement arbitrary insecure 
 optimizations as long as ISA 
 semantics are obeyed No guarantees about timing 
 and side channels
ISA: (security) pitfalls 6 High-level language Microarchitecture Instruction set architecture (ISA) Can implement arbitrary insecure 
 optimizations as long as ISA 
 semantics are obeyed No guarantees about timing 
 and side channels Impossible to program securely 
 cryptographic algorithms? sandboxing untrusted code?
A Way Forward: HW/SW Security Contracts 7 Succinctly captures possible information leakage Hw-Sw contract = ISA + X
A Way Forward: HW/SW Security Contracts 7 Can program securely on top contract 
 independently of microarchitecture Succinctly captures possible information leakage Hw-Sw contract = ISA + X
A Way Forward: HW/SW Security Contracts 7 Can program securely on top contract 
 independently of microarchitecture Can implement arbitrary insecure optimizations 
 as long as contract is obeyed Succinctly captures possible information leakage Hw-Sw contract = ISA + X
A Way Forward: HW/SW Security Contracts 7 Can program securely on top contract 
 independently of microarchitecture Can implement arbitrary insecure optimizations 
 as long as contract is obeyed Succinctly captures possible information leakage Hw-Sw contract = ISA + X In this talk 
 Proof-of-concept of HW/SW contracts for secure speculation
Speculative execution attacks 8
Exploits speculative execution Almost all modern CPUs are affected P. Kocher, J. Horn, A. Fogh, D. Genkin, D. Gruss, W. Haas, M. Hamburg, M. Lipp, S. Mangard, T. Prescher, M. Schwarz, Y. Yarom — Spectre Attacks: Exploiting Speculative Execution — S&P 2019 9
if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 10 Size of array A
if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 10 Size of array A
if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 10 Size of array A Branch predictor
if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 10 Size of array A Branch predictor Prediction based on branch history & program structure
if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 10 Size of array A Branch predictor Prediction based on branch history & program structure
if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 10 Size of array A Branch predictor Prediction based on branch history & program structure Wrong predicton? Rollback changes! Architectural (ISA) state Microarchitectural state
Spectre 101 11
Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] 11
Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] 11
Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] 11
Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] 11 What is in A[128]? A_size=16 B[0]B[1] ... B
Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 12 A_size=16 B[0]B[1] ... B
Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 12 A_size=16 B[0]B[1] ... B
Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 12 A_size=16 B[0]B[1] ... B
Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 12 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
B[A[128]] ] Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 12 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
B[A[128]] ] Depends on A[128] Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 12 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
B[A[128]] ] Depends on A[128] Persistent across speculations Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 12 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
B[A[128]] ] Depends on A[128] Persistent across speculations Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 4) Extract from cache 12 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
Countermeasures 13
Hardware countermeasures 14
Hardware countermeasures 14
Hardware countermeasures 14
Hardware countermeasures 14
Hardware countermeasures 14
Hardware countermeasures 14
Hardware countermeasures 4 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end
Hardware countermeasures 4 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end
Hardware countermeasures 4 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end
Hardware countermeasures 4 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end Delay loads until 
 they can be retired 
 [Sakalis et al., ISCA’19] Delay loads until they cannot be squashed 
 [Sakalis et al., ISCA’19]
Hardware countermeasures 4 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end Delay loads until 
 they can be retired 
 [Sakalis et al., ISCA’19] Delay loads until they cannot be squashed 
 [Sakalis et al., ISCA’19] Taint speculatively loaded data + delay tainted loads 
 [STT and NDA, MICRO’19]
Hardware countermeasures 5 1. y = A[x] 2. if (x < A_size) 3. z = B[y] 4. end
Hardware countermeasures 5 1. y = A[x] 2. if (x < A_size) 3. z = B[y] 4. end Delay loads until 
 they can be retired 
 [Sakalis et al., ISCA'19] Delay loads until they cannot be squashed 
 [Sakalis et al., ISCA'19]
Hardware countermeasures 5 1. y = A[x] 2. if (x < A_size) 3. z = B[y] 4. end Delay loads until 
 they can be retired 
 [Sakalis et al., ISCA'19] Delay loads until they cannot be squashed 
 [Sakalis et al., ISCA'19] Taint speculatively loaded data + delay tainted loads 
 [STT and NDA, MICRO’19]
Hardware countermeasures 6
Hardware countermeasures 6 Security guarantees?
How can we capture security guarantees? 18 Software Hardware C
 o
 n
 t
 r
 a
 c
 t
Hardware/software security contracts 19 Guarnieri, Köpf, Reineke, Vila — Hardware-software contracts for secure speculation — IEEE S&P 2021 
 https://arxiv.org/abs/2006.03841
Contracts for side-channel-free systems 20
Contracts for side-channel-free systems 20 Contracts specify which program executions a side-channel adversary can distinguish
Contracts for side-channel-free systems 20 Contracts specify which program executions a side-channel adversary can distinguish Goals • Capture security guarantees of HW • Basis for secure programming
Contracts 21
Contract ISA extended with observations Contracts 21
Contract ISA extended with observations Contracts 21 Observations expose security-relevant 
 μarch events
Contract ISA extended with observations Contracts 21 Observations expose security-relevant 
 μarch events Contract traces: (p, σ)
Contract ISA extended with observations Contracts 21 Observations expose security-relevant 
 μarch events Contract traces: (p, σ) Hardware Formal model of 
 processor
Contract ISA extended with observations Contracts 21 Observations expose security-relevant 
 μarch events Contract traces: (p, σ) Hardware Formal model of 
 processor Hardware traces: (p, σ)
Contract ISA extended with observations Contracts 21 Observations expose security-relevant 
 μarch events Attacker observes sequences of μarch states Contract traces: (p, σ) Hardware Formal model of 
 processor Hardware traces: (p, σ)
Contract ISA extended with observations Contracts 21 Contract satisfaction Hardware satis fi es contract if for all programs and arch. states , : if then p σ σ′  (p, σ)= (p, σ′  ) (p, σ) = (p, σ′  ) Observations expose security-relevant 
 μarch events Attacker observes sequences of μarch states Contract traces: (p, σ) Hardware Formal model of 
 processor Hardware traces: (p, σ)
Contract ISA extended with observations Contracts 21 Contract satisfaction Hardware satis fi es contract if for all programs and arch. states , : if then p σ σ′  (p, σ)= (p, σ′  ) (p, σ) = (p, σ′  ) Observations expose security-relevant 
 μarch events Attacker observes sequences of μarch states Contract traces: (p, σ) Hardware Formal model of 
 processor Hardware traces: (p, σ)
Contract ISA extended with observations Contracts 21 Contract satisfaction Hardware satis fi es contract if for all programs and arch. states , : if then p σ σ′  (p, σ)= (p, σ′  ) (p, σ) = (p, σ′  ) Observations expose security-relevant 
 μarch events Attacker observes sequences of μarch states Contract traces: (p, σ) Hardware Formal model of 
 processor Hardware traces: (p, σ)
Contracts for secure speculation 22
Contracts for secure speculation 22 Contract = 
 Execution Mode · Observer Mode
Contracts for secure speculation 22 Contract = 
 Execution Mode · Observer Mode How are programs executed?
Contracts for secure speculation 22 Contract = 
 Execution Mode · Observer Mode How are programs executed? What is visible about the execution?
seq — sequential execution spec — mispredict branch instrs. Contracts for secure speculation 23 Contract = 
 Execution Mode · Observer Mode
pc — only program counter ct — pc + addr. of loads and stores 
 arch — ct + loaded values 
 Contracts for secure speculation 24 Contract = 
 Execution Mode · Observer Mode
A lattice of contracts 25 Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc ⊤ ⊥
A lattice of contracts 25 Leaks “everything” Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc ⊤ ⊥
A lattice of contracts 25 Leaks “everything” Leaks “nothing” Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc ⊤ ⊥
A lattice of contracts 25 Leaks “everything” Leaks “nothing” Leaks addresses of non-spec. loads/stores/ instruction fetches Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc ⊤ ⊥
A lattice of contracts 25 Leaks “everything” Leaks “nothing” Leaks addresses of non-spec. loads/stores/ instruction fetches Leaks all data 
 accessed non- speculatively Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc ⊤ ⊥
A lattice of contracts 25 Leaks “everything” Leaks “nothing” Leaks addresses of non-spec. loads/stores/ instruction fetches Leaks all data 
 accessed non- speculatively Leaks addresses of all loads/ stores/instruction fetches Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc ⊤ ⊥
Example: seq-ct 26 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end 😈
Example: seq-ct 26 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x < A_size 😈
Example: seq-ct 26 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x < A_size 😈 pc 2
Example: seq-ct 26 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x < A_size 😈 load A+x
Example: seq-ct 26 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x < A_size 😈 load B+A[x]
Example: seq-arch 27 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end 😈
Example: seq-arch 27 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x < A_size 😈
Example: seq-arch 27 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x < A_size 😈 pc 2
Example: seq-arch 27 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x < A_size 😈 load A+x,A[x]
load B+A[x],B[A[x]] Example: seq-arch 27 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x < A_size 😈
Example: spec-ct 28 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end 😈
Example: spec-ct 28 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
Example: spec-ct 28 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
Example: spec-ct 28 start pc 2 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
Example: spec-ct 28 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
Example: spec-ct 28 load A+x 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
Example: spec-ct 28 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
Example: spec-ct 28 load B+A[x] 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
Example: spec-ct 28 rollback pc 4 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
Example: spec-ct 28 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
Hardware countermeasures 29
A simple processor 30 See paper for: processor operational semantics and security proofs
A simple processor Speculative and out-of-order executions 30 See paper for: processor operational semantics and security proofs
A simple processor 3-stage pipeline 
 (fetch, execute, retire) Speculative and out-of-order executions 30 See paper for: processor operational semantics and security proofs
A simple processor Parametric in branch predictor and memory hierarchy 3-stage pipeline 
 (fetch, execute, retire) Speculative and out-of-order executions 30 See paper for: processor operational semantics and security proofs
A simple processor Parametric in branch predictor and memory hierarchy 3-stage pipeline 
 (fetch, execute, retire) Speculative and out-of-order executions 30 See paper for: processor operational semantics and security proofs Modeled as operational semantics describing how processor’s state changes 
 (inspired by [Cauligi et al. 2019]) ⇒
No countermeasures [The world before Spectre] 17
No countermeasures [The world before Spectre] 17 if (x < A_size) 
 z = A[x] 
 y = B[z]
No countermeasures [The world before Spectre] 17 if (x < A_size) 
 z = A[x] 
 y = B[z]
No countermeasures [The world before Spectre] 17 if (x < A_size) 
 z = A[x] 
 y = B[z]
No countermeasures [The world before Spectre] 17 Satis fi es spec-ct if (x < A_size) 
 z = A[x] 
 y = B[z]
Disabling speculative execution 32
Disabling speculative execution 32 Instructions are executed sequentially
Disabling speculative execution 32 Instructions are executed sequentially 🥳 No speculative leaks 🥳
Disabling speculative execution 32 Instructions are executed sequentially 🥳 No speculative leaks 🥳 Satis fi es seq-ct
Eager load delay [Sakalis et al., ISCA’19] 33
Eager load delay [Sakalis et al., ISCA’19] 33 Delaying loads until all sources of speculation are resolved
Eager load delay [Sakalis et al., ISCA’19] 33 Delaying loads until all sources of speculation are resolved Security guarantees?
Eager load delay [Sakalis et al., ISCA’19] 34 if (x < A_size) 
 z = A[x] 
 y = B[z]
Eager load delay [Sakalis et al., ISCA’19] 34 if (x < A_size) 
 z = A[x] 
 y = B[z]
Eager load delay [Sakalis et al., ISCA’19] 34 if (x < A_size) 
 z = A[x] 
 y = B[z] A[x]and B[z] delayed until 
 x < A_size is resolved
Eager load delay [Sakalis et al., ISCA’19] 34 if (x < A_size) 
 z = A[x] 
 y = B[z] A[x]and B[z] delayed until 
 x < A_size is resolved 🥳 No speculative leaks 🥳
Eager load delay [Sakalis et al., ISCA’19] 35 z = A[x] if(x < A_size) 
 if(z==0) 
 skip
Eager load delay [Sakalis et al., ISCA’19] 35 z = A[x] if(x < A_size) 
 if(z==0) 
 skip
Eager load delay [Sakalis et al., ISCA’19] 35 z = A[x] if(x < A_size) 
 if(z==0) 
 skip if(z==0) is not delayed
Eager load delay [Sakalis et al., ISCA’19] 35 z = A[x] if(x < A_size) 
 if(z==0) 
 skip if(z==0) is not delayed Program speculatively 
 leaks A[x] 😞
Eager load delay [Sakalis et al., ISCA’19] 36
Eager load delay [Sakalis et al., ISCA’19] 36 Satis fi es seq-arch Satis fi es seq/spec-ct/pc
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 37
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 37 Taint speculatively loaded data
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 37 Propagate taint through computation Taint speculatively loaded data
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 37 Propagate taint through computation Delay tainted operations Taint speculatively loaded data
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 37 Propagate taint through computation Delay tainted operations Taint speculatively loaded data Security guarantees?
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 38 if (x < A_size) 
 z = A[x] 
 y = B[z]
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 38 if (x < A_size) 
 z = A[x] 
 y = B[z]
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 38 if (x < A_size) 
 z = A[x] 
 y = B[z] A[x]tainted as unsafe 
 B[z] delayed until 
 A[x] is safe
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 38 if (x < A_size) 
 z = A[x] 
 y = B[z] A[x]tainted as unsafe 
 B[z] delayed until 
 A[x] is safe 🥳 No speculative leaks 🥳
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 39 z = A[x] 
 if (x < A_size) 
 y = B[z]
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 39 z = A[x] 
 if (x < A_size) 
 y = B[z]
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 39 z = A[x] 
 if (x < A_size) 
 y = B[z] A[x]tagged as safe 
 
 B[z] not delayed
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 39 z = A[x] 
 if (x < A_size) 
 y = B[z] A[x]tagged as safe 
 
 B[z] not delayed Program speculatively 
 leaks A[x] 😞
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 40
Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 40 Satis fi es seq-arch Satis fi es spec-ct
Security guarantees 41 See paper for: models and security proofs Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc OoO NS LD TT Vanilla OoO CPU + 
 spec. exec In-order CPU 
 (no specExec) OoO CPU+load delay OoO CPU+taint tracking
Security guarantees 41 See paper for: models and security proofs Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc OoO NS LD TT Vanilla OoO CPU + 
 spec. exec In-order CPU 
 (no specExec) OoO CPU+load delay OoO CPU+taint tracking OoO
Security guarantees 41 See paper for: models and security proofs Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc OoO NS LD TT Vanilla OoO CPU + 
 spec. exec In-order CPU 
 (no specExec) OoO CPU+load delay OoO CPU+taint tracking OoO NS
Security guarantees 41 See paper for: models and security proofs Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc OoO NS LD TT Vanilla OoO CPU + 
 spec. exec In-order CPU 
 (no specExec) OoO CPU+load delay OoO CPU+taint tracking OoO LD NS LD
Security guarantees 41 See paper for: models and security proofs Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc OoO NS LD TT Vanilla OoO CPU + 
 spec. exec In-order CPU 
 (no specExec) OoO CPU+load delay OoO CPU+taint tracking OoO TT LD NS TT LD
Secure programming 25
Two flavors of secure programming 26 Sandboxing Constant-time
Two flavors of secure programming 26 Sandboxing Constant-time
Two flavors of secure programming 26 Sandboxing Constant-time
Constant-time Sandboxing Checking secure programming 27 Seq-ct Seq-arch Spec-ct ❌ ✓ ✓ ✓ ❌ ❌ See paper for: additional security checks, proofs, automation
Constant-time Sandboxing Checking secure programming 27 Seq-ct Seq-arch Spec-ct ❌ ✓ ✓ ✓ ❌ ❌ See paper for: additional security checks, proofs, automation
What’s next? 45
46 Hw-Sw security
 contracts Modeling and 
 speci fi cations Hardware Software
46 Hw-Sw security
 contracts Modeling and 
 speci fi cations Hardware Software
Contracts & Modeling 47
Contracts & Modeling 47 So far: toy ISA + observation modes for cache/control- fl ow leaks + execution modes for branch speculation
Contracts & Modeling 47 So far: toy ISA + observation modes for cache/control- fl ow leaks + execution modes for branch speculation Challenge: scale to real-world ISAs
Contracts & Modeling 47 So far: toy ISA + observation modes for cache/control- fl ow leaks + execution modes for branch speculation Challenge: scale to real-world ISAs What do we need? Formal models of ISAs + adequate extensions to capture leaks
48 Hw-Sw security
 contracts Modeling and 
 speci fi cations Hardware Software
48 Hw-Sw security
 contracts Modeling and 
 speci fi cations Hardware Software
Contracts & Hardware 49
Contracts & Hardware 49 So far: manual security proofs on toy CPU/ISA
Contracts & Hardware 49 So far: manual security proofs on toy CPU/ISA Challenge: automation for realistic CPUs
Contracts & Hardware 49 So far: manual security proofs on toy CPU/ISA Challenge: automation for realistic CPUs What do we need? Automated veri fi cation and testing techniques for contract satisfaction
50 Hw-Sw security
 contracts Modeling and 
 speci fi cations Hardware Software
50 Hw-Sw security
 contracts Modeling and 
 speci fi cations Hardware Software
Contracts & Software 51
Contracts & Software 51 So far: contracts as secure programming foundations + tools targeting “ fi xed contracts”
Contracts & Software 51 So far: contracts as secure programming foundations + tools targeting “ fi xed contracts” Challenge: support for large classes of contracts
Contracts & Software 51 So far: contracts as secure programming foundations + tools targeting “ fi xed contracts” Challenge: support for large classes of contracts What do we need? Contract-aware program analyses and secure compilation passes
Conclusions 28

 Contract ISA extended with observations Contracts Contract satisfaction Hardware satisfies contract if for all programs and arch. states , : if then p σ σ′ (p, σ)= (p, σ′) (p, σ) = (p, σ′) Contract traces: (p, σ) Hardware Formal model of processor Hardware traces: (p, σ) A lattice of contracts Leaks “everything” Leaks “nothing” Leaks addresses of non-spec. loads/stores/ instruction fetches Leaks all data accessed non- speculatively Leaks addresses of all loads/ stores/instruction fetches Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc ⊤ ⊥ Security guarantees Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc OoO NS LD TT Vanilla OoO CPU + spec. exec In-order CPU (no specExec) OoO CPU+load delay OoO CPU+taint tracking OoO TT LD NS TT LD Two flavors of secure programming Sandboxing Constant-time

 Contract ISA extended with observations Contracts Contract satisfaction Hardware satisfies contract if for all programs and arch. states , : if then p σ σ′ (p, σ)= (p, σ′) (p, σ) = (p, σ′) Contract traces: (p, σ) Hardware Formal model of processor Hardware traces: (p, σ) A lattice of contracts Leaks “everything” Leaks “nothing” Leaks addresses of non-spec. loads/stores/ instruction fetches Leaks all data accessed non- speculatively Leaks addresses of all loads/ stores/instruction fetches Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc ⊤ ⊥ Security guarantees Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc OoO NS LD TT Vanilla OoO CPU + spec. exec In-order CPU (no specExec) OoO CPU+load delay OoO CPU+taint tracking OoO TT LD NS TT LD Two flavors of secure programming Sandboxing Constant-time marco.guarnieri@imdea.org @MarcoGuarnier1 Find out more in the paper: 
 https://arxiv.org/abs/2006.03841
Backup 28
What’s next? 25
56 Software Hardware
56 Software Hardware Knows what data is sensitive
56 Controls microarchitectural state Software Hardware Knows what data is sensitive
Contracts as basis for HW/SW co-design 56 Controls microarchitectural state Software Hardware C 
 o 
 n 
 t 
 r 
 a 
 c 
 t Knows what data is sensitive
Contracts @ Software 57
Contracts @ Software 57 Program analysis + Guarnieri et al., Spectector: Principled detection of speculative leaks, S&P 2020 Program analyzers that work for arbitrary contracts
Contracts @ Software 57 Secure compilation Compiler Source program Target program Contract Compiler takes contracts as input Ensure security at contract level Patrignani and Guarnieri, Exorcising Spectre with secure compilers, CCS 2021 Program analysis + Guarnieri et al., Spectector: Principled detection of speculative leaks, S&P 2020 Program analyzers that work for arbitrary contracts
Contracts @ Hardware 58
Contracts @ Hardware 58 Veri fi cation Tools for checking compliance with contracts (Partially) automate contract satisfaction proofs
Contracts @ Hardware 58 Veri fi cation Tools for checking compliance with contracts (Partially) automate contract satisfaction proofs Testing/Fuzzing Contracts as test oracles Black box: see Oleksenko et al., Revizor: Fuzzing for Leaks in Black-box CPUs https://arxiv.org/ abs/2105.06872 White box: WIP!
A simple processor — Configurations 59
A simple processor — Configurations 59 Configurations: State of the processor during computation
A simple processor — Configurations 59 Configurations: State of the processor during computation ⟨m, a, buf, cs, bp, sc⟩
A simple processor — Configurations 59 Configurations: State of the processor during computation Memory ⟨m, a, buf, cs, bp, sc⟩
A simple processor — Configurations 59 Configurations: State of the processor during computation Memory Registers ⟨m, a, buf, cs, bp, sc⟩
A simple processor — Configurations 59 Configurations: State of the processor during computation Memory Registers Reorder 
 bu ff er ⟨m, a, buf, cs, bp, sc⟩
A simple processor — Configurations 59 Configurations: State of the processor during computation Memory Registers Reorder 
 bu ff er Cache 
 (metadata) ⟨m, a, buf, cs, bp, sc⟩
A simple processor — Configurations 59 Configurations: State of the processor during computation Memory Registers Reorder 
 bu ff er Cache 
 (metadata) Branch 
 predictor ⟨m, a, buf, cs, bp, sc⟩
A simple processor — Configurations 59 Configurations: State of the processor during computation Memory Registers Reorder 
 bu ff er Cache 
 (metadata) Branch 
 predictor Scheduler ⟨m, a, buf, cs, bp, sc⟩
A simple processor — Configurations 59 Configurations: State of the processor during computation Memory Registers Reorder 
 bu ff er Cache 
 (metadata) Branch 
 predictor Scheduler 😈 ⟨m, a, buf, cs, bp, sc⟩
A simple processor — Semantics 60
A simple processor — Semantics 60 Semantics: Describe how con fi gurations evolve
A simple processor — Semantics 60 Semantics: Describe how con fi gurations evolve Hardware semantics We formalize the hardware semantics of a µASM program ng a binary relation ) ✓ HwStates ⇥ HwStates that ma dware states to their successors: STEP hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) hm,a,buf,cs,bp,sci)hm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i e rule captures one execution step at the µarch. level. T
A simple processor — Semantics 60 Semantics: Describe how con fi gurations evolve Hardware semantics We formalize the hardware semantics of a µASM program ng a binary relation ) ✓ HwStates ⇥ HwStates that ma dware states to their successors: STEP hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) hm,a,buf,cs,bp,sci)hm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i e rule captures one execution step at the µarch. level. T Current state
A simple processor — Semantics 60 Semantics: Describe how con fi gurations evolve Hardware semantics We formalize the hardware semantics of a µASM program ng a binary relation ) ✓ HwStates ⇥ HwStates that ma dware states to their successors: STEP hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) hm,a,buf,cs,bp,sci)hm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i e rule captures one execution step at the µarch. level. T Current state Next state
A simple processor — Semantics 60 Semantics: Describe how con fi gurations evolve Hardware semantics We formalize the hardware semantics of a µASM program ng a binary relation ) ✓ HwStates ⇥ HwStates that ma dware states to their successors: STEP hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) hm,a,buf,cs,bp,sci)hm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i e rule captures one execution step at the µarch. level. T Current state Next state Directive from scheduler 
 fetch, execute i, retire
A simple processor — Semantics 60 Semantics: Describe how con fi gurations evolve Hardware semantics We formalize the hardware semantics of a µASM program ng a binary relation ) ✓ HwStates ⇥ HwStates that ma dware states to their successors: STEP hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) hm,a,buf,cs,bp,sci)hm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i e rule captures one execution step at the µarch. level. T Current state Next state Directive from scheduler 
 fetch, execute i, retire Semantics for pipeline stages
Rules capture effect of directives - Fetch 61 nents reted s) 2 ad- miss state that ocks ction edic- been ictor For each directive, i.e., fetch,execute i, and retire, we sketch below the rules that govern the definition of the auxiliary relations fetch = = ), execute i = = = = = ), and retire = = = ). 1) Fetch: Instructions are fetched in-order. Here we present selected rules modeling instruction fetch: FETCH-BRANCH-HIT a0 = apl(buf,a) |buf| < w a0 (pc) 6= ? p(a0 (pc)) = beqz x,` `0 = predict(bp,a0 (pc)) access(cs,a0 (pc)) = Hit update(cs,a0 (pc)) = cs0 hm,a,buf,cs,bpi fetch = = )hm,a,buf ·pc `0 @a0 (pc),cs0 ,bpi FETCH-MISS |buf| < w a0 = apl(buf,a) a0 (pc) 6= ? access(cs,a0 (pc)) = Miss update(cs,a0 (pc)) = cs0
Rules capture effect of directives - Fetch 61 nents reted s) 2 ad- miss state that ocks ction edic- been ictor For each directive, i.e., fetch,execute i, and retire, we sketch below the rules that govern the definition of the auxiliary relations fetch = = ), execute i = = = = = ), and retire = = = ). 1) Fetch: Instructions are fetched in-order. Here we present selected rules modeling instruction fetch: FETCH-BRANCH-HIT a0 = apl(buf,a) |buf| < w a0 (pc) 6= ? p(a0 (pc)) = beqz x,` `0 = predict(bp,a0 (pc)) access(cs,a0 (pc)) = Hit update(cs,a0 (pc)) = cs0 hm,a,buf,cs,bpi fetch = = )hm,a,buf ·pc `0 @a0 (pc),cs0 ,bpi FETCH-MISS |buf| < w a0 = apl(buf,a) a0 (pc) 6= ? access(cs,a0 (pc)) = Miss update(cs,a0 (pc)) = cs0 applying reorder buffer 
 to register state
Rules capture effect of directives - Fetch 61 nents reted s) 2 ad- miss state that ocks ction edic- been ictor For each directive, i.e., fetch,execute i, and retire, we sketch below the rules that govern the definition of the auxiliary relations fetch = = ), execute i = = = = = ), and retire = = = ). 1) Fetch: Instructions are fetched in-order. Here we present selected rules modeling instruction fetch: FETCH-BRANCH-HIT a0 = apl(buf,a) |buf| < w a0 (pc) 6= ? p(a0 (pc)) = beqz x,` `0 = predict(bp,a0 (pc)) access(cs,a0 (pc)) = Hit update(cs,a0 (pc)) = cs0 hm,a,buf,cs,bpi fetch = = )hm,a,buf ·pc `0 @a0 (pc),cs0 ,bpi FETCH-MISS |buf| < w a0 = apl(buf,a) a0 (pc) 6= ? access(cs,a0 (pc)) = Miss update(cs,a0 (pc)) = cs0 applying reorder buffer 
 to register state reorder buffer 
 is not full
Rules capture effect of directives - Fetch 61 nents reted s) 2 ad- miss state that ocks ction edic- been ictor For each directive, i.e., fetch,execute i, and retire, we sketch below the rules that govern the definition of the auxiliary relations fetch = = ), execute i = = = = = ), and retire = = = ). 1) Fetch: Instructions are fetched in-order. Here we present selected rules modeling instruction fetch: FETCH-BRANCH-HIT a0 = apl(buf,a) |buf| < w a0 (pc) 6= ? p(a0 (pc)) = beqz x,` `0 = predict(bp,a0 (pc)) access(cs,a0 (pc)) = Hit update(cs,a0 (pc)) = cs0 hm,a,buf,cs,bpi fetch = = )hm,a,buf ·pc `0 @a0 (pc),cs0 ,bpi FETCH-MISS |buf| < w a0 = apl(buf,a) a0 (pc) 6= ? access(cs,a0 (pc)) = Miss update(cs,a0 (pc)) = cs0 instruction is a 
 branch instruction is a 
 branch applying reorder buffer 
 to register state reorder buffer 
 is not full
Rules capture effect of directives - Fetch 61 nents reted s) 2 ad- miss state that ocks ction edic- been ictor For each directive, i.e., fetch,execute i, and retire, we sketch below the rules that govern the definition of the auxiliary relations fetch = = ), execute i = = = = = ), and retire = = = ). 1) Fetch: Instructions are fetched in-order. Here we present selected rules modeling instruction fetch: FETCH-BRANCH-HIT a0 = apl(buf,a) |buf| < w a0 (pc) 6= ? p(a0 (pc)) = beqz x,` `0 = predict(bp,a0 (pc)) access(cs,a0 (pc)) = Hit update(cs,a0 (pc)) = cs0 hm,a,buf,cs,bpi fetch = = )hm,a,buf ·pc `0 @a0 (pc),cs0 ,bpi FETCH-MISS |buf| < w a0 = apl(buf,a) a0 (pc) 6= ? access(cs,a0 (pc)) = Miss update(cs,a0 (pc)) = cs0 instruction is a 
 branch instruction is a 
 branch applying reorder buffer 
 to register state reorder buffer 
 is not full branch predictor 
 says is next ℓ′ 
Rules capture effect of directives - Fetch 61 nents reted s) 2 ad- miss state that ocks ction edic- been ictor For each directive, i.e., fetch,execute i, and retire, we sketch below the rules that govern the definition of the auxiliary relations fetch = = ), execute i = = = = = ), and retire = = = ). 1) Fetch: Instructions are fetched in-order. Here we present selected rules modeling instruction fetch: FETCH-BRANCH-HIT a0 = apl(buf,a) |buf| < w a0 (pc) 6= ? p(a0 (pc)) = beqz x,` `0 = predict(bp,a0 (pc)) access(cs,a0 (pc)) = Hit update(cs,a0 (pc)) = cs0 hm,a,buf,cs,bpi fetch = = )hm,a,buf ·pc `0 @a0 (pc),cs0 ,bpi FETCH-MISS |buf| < w a0 = apl(buf,a) a0 (pc) 6= ? access(cs,a0 (pc)) = Miss update(cs,a0 (pc)) = cs0 instruction is a 
 branch instruction is a 
 branch applying reorder buffer 
 to register state reorder buffer 
 is not full branch predictor 
 says is next ℓ′  Cache hit 
 + updating 
 cache state
Rules capture effect of directives - Fetch 61 nents reted s) 2 ad- miss state that ocks ction edic- been ictor For each directive, i.e., fetch,execute i, and retire, we sketch below the rules that govern the definition of the auxiliary relations fetch = = ), execute i = = = = = ), and retire = = = ). 1) Fetch: Instructions are fetched in-order. Here we present selected rules modeling instruction fetch: FETCH-BRANCH-HIT a0 = apl(buf,a) |buf| < w a0 (pc) 6= ? p(a0 (pc)) = beqz x,` `0 = predict(bp,a0 (pc)) access(cs,a0 (pc)) = Hit update(cs,a0 (pc)) = cs0 hm,a,buf,cs,bpi fetch = = )hm,a,buf ·pc `0 @a0 (pc),cs0 ,bpi FETCH-MISS |buf| < w a0 = apl(buf,a) a0 (pc) 6= ? access(cs,a0 (pc)) = Miss update(cs,a0 (pc)) = cs0 instruction is a 
 branch instruction is a 
 branch applying reorder buffer 
 to register state reorder buffer 
 is not full branch predictor 
 says is next ℓ′  Cache hit 
 + updating 
 cache state add change of pc to reorder buffer
Rules capture effect of directive - Retire 62 retiring only commands i@T at the head of the reorder buffer where the instruction i has been resolved, and the tag T is e indicating that there are no unresolved predictions. Selected rules for the retire directive are given below: RETIRE-ASSIGNMENT buf = x v@e ·buf0 v 2 Vals hm,a,buf,cs,bpi retire = = = )hm,a[x 7! v],buf0 ,cs,bpi RETIRE-STORE buf = store v,n@e ·buf0 v,n 2 Vals update(cs,n) = cs0 retire 0 0
Rules capture effect of directive - Retire 62 retiring only commands i@T at the head of the reorder buffer where the instruction i has been resolved, and the tag T is e indicating that there are no unresolved predictions. Selected rules for the retire directive are given below: RETIRE-ASSIGNMENT buf = x v@e ·buf0 v 2 Vals hm,a,buf,cs,bpi retire = = = )hm,a[x 7! v],buf0 ,cs,bpi RETIRE-STORE buf = store v,n@e ·buf0 v,n 2 Vals update(cs,n) = cs0 retire 0 0 result of instruction at head of 
 reorder buffer is resolved
Rules capture effect of directive - Retire 62 retiring only commands i@T at the head of the reorder buffer where the instruction i has been resolved, and the tag T is e indicating that there are no unresolved predictions. Selected rules for the retire directive are given below: RETIRE-ASSIGNMENT buf = x v@e ·buf0 v 2 Vals hm,a,buf,cs,bpi retire = = = )hm,a[x 7! v],buf0 ,cs,bpi RETIRE-STORE buf = store v,n@e ·buf0 v,n 2 Vals update(cs,n) = cs0 retire 0 0 result of instruction at head of 
 reorder buffer is resolved apply change to registers 
 and remove entry from reorder buffer
Eager load delay [Sakalis et al. 2019] 63 hm,a,buf,cs,bpi= )hm ,a ,buf ,cs ,bp i d = next(sc) sc0 = update(sc,buf0 #) d 2 {fetch,retire}_(d = execute i^buf|i 6= load x,e) hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i STEP-EAGER-DELAY hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) d = execute i buf|i = load x,e 8pc `@`0 2 buf[0..i 1]. `0 = e hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i and to selectively delay instruction tion. While these proposals slight are labelled and on the effects of the same building blocks and pro For this reason, we start by the Speculative Taint Tracking (S Data Access (NDA) [4] counterm a general extension to the hardwa for supporting taint-tracking schem izing a countermeasure inspired security guarantees, and we conc sure. This countermeasure consists in delaying loads until all sources of mis-speculation have been resolved. We remark that the hardware semantics of Section V supports speculation only over branch instructions. Therefore, we model the loadDelay countermeasure by preventing loads whenever there are pre- ceding, unresolved branch instructions in the reorder buffer. Using the terminology of [3], loads are delayed as long as they are under a so-called control-shadow. We formalize the loadDelay countermeasure by modifying the STEP rule of the hardware semantics as follows (changes are highlighted in blue): STEP-OTHERS hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) d 2 {fetch,retire}_(d = execute i^buf|i 6= load x,e) hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i STEP-EAGER-DELAY cution, and in addition, the progr speculative execution. This new countermeasure, leading to Theor Theorem 3. { |·| }loadDelay ` J·Kseq ct-p As the control flow during spe depend upon data previously lo security of the countermeasure can Theorem 4. { |·| }loadDelay ` J·K seq arc C. tt: Taint tracking of speculativ Recent work [4], [5] propose to and to selectively delay instruction tion. While these proposals slight are labelled and on the effects of the same building blocks and pro For this reason, we start by the Speculative Taint Tracking (S
Eager load delay [Sakalis et al. 2019] 63 hm,a,buf,cs,bpi= )hm ,a ,buf ,cs ,bp i d = next(sc) sc0 = update(sc,buf0 #) d 2 {fetch,retire}_(d = execute i^buf|i 6= load x,e) hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i STEP-EAGER-DELAY hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) d = execute i buf|i = load x,e 8pc `@`0 2 buf[0..i 1]. `0 = e hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i and to selectively delay instruction tion. While these proposals slight are labelled and on the effects of the same building blocks and pro For this reason, we start by the Speculative Taint Tracking (S Data Access (NDA) [4] counterm a general extension to the hardwa for supporting taint-tracking schem izing a countermeasure inspired security guarantees, and we conc Loads are executed only if prior branch instructions are resolved sure. This countermeasure consists in delaying loads until all sources of mis-speculation have been resolved. We remark that the hardware semantics of Section V supports speculation only over branch instructions. Therefore, we model the loadDelay countermeasure by preventing loads whenever there are pre- ceding, unresolved branch instructions in the reorder buffer. Using the terminology of [3], loads are delayed as long as they are under a so-called control-shadow. We formalize the loadDelay countermeasure by modifying the STEP rule of the hardware semantics as follows (changes are highlighted in blue): STEP-OTHERS hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) d 2 {fetch,retire}_(d = execute i^buf|i 6= load x,e) hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i STEP-EAGER-DELAY cution, and in addition, the progr speculative execution. This new countermeasure, leading to Theor Theorem 3. { |·| }loadDelay ` J·Kseq ct-p As the control flow during spe depend upon data previously lo security of the countermeasure can Theorem 4. { |·| }loadDelay ` J·K seq arc C. tt: Taint tracking of speculativ Recent work [4], [5] propose to and to selectively delay instruction tion. While these proposals slight are labelled and on the effects of the same building blocks and pro For this reason, we start by the Speculative Taint Tracking (S
Eager load delay [Sakalis et al. 2019] 63 hm,a,buf,cs,bpi= )hm ,a ,buf ,cs ,bp i d = next(sc) sc0 = update(sc,buf0 #) d 2 {fetch,retire}_(d = execute i^buf|i 6= load x,e) hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i STEP-EAGER-DELAY hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) d = execute i buf|i = load x,e 8pc `@`0 2 buf[0..i 1]. `0 = e hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i and to selectively delay instruction tion. While these proposals slight are labelled and on the effects of the same building blocks and pro For this reason, we start by the Speculative Taint Tracking (S Data Access (NDA) [4] counterm a general extension to the hardwa for supporting taint-tracking schem izing a countermeasure inspired security guarantees, and we conc Loads are executed only if prior branch instructions are resolved sure. This countermeasure consists in delaying loads until all sources of mis-speculation have been resolved. We remark that the hardware semantics of Section V supports speculation only over branch instructions. Therefore, we model the loadDelay countermeasure by preventing loads whenever there are pre- ceding, unresolved branch instructions in the reorder buffer. Using the terminology of [3], loads are delayed as long as they are under a so-called control-shadow. We formalize the loadDelay countermeasure by modifying the STEP rule of the hardware semantics as follows (changes are highlighted in blue): STEP-OTHERS hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) d 2 {fetch,retire}_(d = execute i^buf|i 6= load x,e) hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i STEP-EAGER-DELAY cution, and in addition, the progr speculative execution. This new countermeasure, leading to Theor Theorem 3. { |·| }loadDelay ` J·Kseq ct-p As the control flow during spe depend upon data previously lo security of the countermeasure can Theorem 4. { |·| }loadDelay ` J·K seq arc C. tt: Taint tracking of speculativ Recent work [4], [5] propose to and to selectively delay instruction tion. While these proposals slight are labelled and on the effects of the same building blocks and pro For this reason, we start by the Speculative Taint Tracking (S Everything else works as before
Hw-level taint-tracking [Yu et al. 2019, Weisse et al. 2019] 64 modeled by d). We describe later how these functions can be instantiated to model STT and NDA. We formalize the tt countermeasure by modifying the STEP rule as follows (changes are highlighted in blue): STEP d = next(sc) buful = unlbl(buf,d) hm,a, buful ,cs,bpi d = )hm0 ,a0 , buf0 ul ,cs0 ,bp0 i sc0 = update(sc,buf0 #) buf0 = lbl(buf0 ul,buf,d) hm,a,buf,cs,bp,sci)tthm0 ,a0 buf0 ,cs0 ,bp0 ,sc0 i The rule differs from the standard STEP rule in three ways: • Entries in the reorder buffer are labelled. • Before activating a step in the pipeline, i.e., before apply- ing one step of d = ), we use the unlabeling function to derive an a transmit execute no • The la fies how ne labels are u – Newly f there is no they are la assignment unsafe dat labelled as All other n – Whenev labels are p – When w eliminating
Hw-level taint-tracking [Yu et al. 2019, Weisse et al. 2019] 64 modeled by d). We describe later how these functions can be instantiated to model STT and NDA. We formalize the tt countermeasure by modifying the STEP rule as follows (changes are highlighted in blue): STEP d = next(sc) buful = unlbl(buf,d) hm,a, buful ,cs,bpi d = )hm0 ,a0 , buf0 ul ,cs0 ,bp0 i sc0 = update(sc,buf0 #) buf0 = lbl(buf0 ul,buf,d) hm,a,buf,cs,bp,sci)tthm0 ,a0 buf0 ,cs0 ,bp0 ,sc0 i The rule differs from the standard STEP rule in three ways: • Entries in the reorder buffer are labelled. • Before activating a step in the pipeline, i.e., before apply- ing one step of d = ), we use the unlabeling function to derive an a transmit execute no • The la fies how ne labels are u – Newly f there is no they are la assignment unsafe dat labelled as All other n – Whenev labels are p – When w eliminating Entries in the reorder buffer are labelled as safe/unsafe
Hw-level taint-tracking [Yu et al. 2019, Weisse et al. 2019] 64 modeled by d). We describe later how these functions can be instantiated to model STT and NDA. We formalize the tt countermeasure by modifying the STEP rule as follows (changes are highlighted in blue): STEP d = next(sc) buful = unlbl(buf,d) hm,a, buful ,cs,bpi d = )hm0 ,a0 , buf0 ul ,cs0 ,bp0 i sc0 = update(sc,buf0 #) buf0 = lbl(buf0 ul,buf,d) hm,a,buf,cs,bp,sci)tthm0 ,a0 buf0 ,cs0 ,bp0 ,sc0 i The rule differs from the standard STEP rule in three ways: • Entries in the reorder buffer are labelled. • Before activating a step in the pipeline, i.e., before apply- ing one step of d = ), we use the unlabeling function to derive an a transmit execute no • The la fies how ne labels are u – Newly f there is no they are la assignment unsafe dat labelled as All other n – Whenev labels are p – When w eliminating Entries in the reorder buffer are labelled as safe/unsafe Derive unlabeled buffer 
 (hides information tagged 
 as unsafe)
Hw-level taint-tracking [Yu et al. 2019, Weisse et al. 2019] 64 modeled by d). We describe later how these functions can be instantiated to model STT and NDA. We formalize the tt countermeasure by modifying the STEP rule as follows (changes are highlighted in blue): STEP d = next(sc) buful = unlbl(buf,d) hm,a, buful ,cs,bpi d = )hm0 ,a0 , buf0 ul ,cs0 ,bp0 i sc0 = update(sc,buf0 #) buf0 = lbl(buf0 ul,buf,d) hm,a,buf,cs,bp,sci)tthm0 ,a0 buf0 ,cs0 ,bp0 ,sc0 i The rule differs from the standard STEP rule in three ways: • Entries in the reorder buffer are labelled. • Before activating a step in the pipeline, i.e., before apply- ing one step of d = ), we use the unlabeling function to derive an a transmit execute no • The la fies how ne labels are u – Newly f there is no they are la assignment unsafe dat labelled as All other n – Whenev labels are p – When w eliminating Entries in the reorder buffer are labelled as safe/unsafe Derive unlabeled buffer 
 (hides information tagged 
 as unsafe) Computation on unlabeled buffer
Hw-level taint-tracking [Yu et al. 2019, Weisse et al. 2019] 64 modeled by d). We describe later how these functions can be instantiated to model STT and NDA. We formalize the tt countermeasure by modifying the STEP rule as follows (changes are highlighted in blue): STEP d = next(sc) buful = unlbl(buf,d) hm,a, buful ,cs,bpi d = )hm0 ,a0 , buf0 ul ,cs0 ,bp0 i sc0 = update(sc,buf0 #) buf0 = lbl(buf0 ul,buf,d) hm,a,buf,cs,bp,sci)tthm0 ,a0 buf0 ,cs0 ,bp0 ,sc0 i The rule differs from the standard STEP rule in three ways: • Entries in the reorder buffer are labelled. • Before activating a step in the pipeline, i.e., before apply- ing one step of d = ), we use the unlabeling function to derive an a transmit execute no • The la fies how ne labels are u – Newly f there is no they are la assignment unsafe dat labelled as All other n – Whenev labels are p – When w eliminating Entries in the reorder buffer are labelled as safe/unsafe Update labels Derive unlabeled buffer 
 (hides information tagged 
 as unsafe) Computation on unlabeled buffer
Constant-time Sandboxing Checking secure programming 27 [[⋅]]seq ct [[⋅]]seq arch [[⋅]]spec ct ✓ ✓ ✓ See paper for: security de fi nitions .. + NI wrt [[⋅]]seq arch .. + Speculative NI 
 [Guarnieri et al., S&P’20] .. + weak spec. NI
Constant-time Sandboxing Checking secure programming 27 [[⋅]]seq ct [[⋅]]seq arch [[⋅]]spec ct ✓ ✓ ✓ See paper for: security de fi nitions .. + NI wrt [[⋅]]seq arch .. + Speculative NI 
 [Guarnieri et al., S&P’20] .. + weak spec. NI
Background: Reorder buffer 66
Background: Reorder buffer • Key hardware data structure for 
 out-of-order and speculative execution 66
Background: Reorder buffer • Key hardware data structure for 
 out-of-order and speculative execution • Keeps track of “in- fl ight instructions” 66
Background: Reorder buffer • Key hardware data structure for 
 out-of-order and speculative execution • Keeps track of “in- fl ight instructions” • Example: 66 Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: - - 3: - - … … … c ⟵ x < A_size beqz c, END L1: load t, A + x 
 load y, B + t END:
Background: Reorder buffer • Key hardware data structure for 
 out-of-order and speculative execution • Keeps track of “in- fl ight instructions” • Example: 66 Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: - - 3: - - … … … c ⟵ x < A_size beqz c, END L1: load t, A + x 
 load y, B + t END: Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 1 3: - - … … … Speculative 
 Instruction Fetch
Background: Reorder buffer • Key hardware data structure for 
 out-of-order and speculative execution • Keeps track of “in- fl ight instructions” • Example: 67 Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: - - 3: - - … … … c ⟵ x < A_size beqz c, END L1: load t, A + x 
 load y, B + t END: Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 1 3: load y, B + t 1 … … … Speculative 
 Instruction Fetch Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 1 3: - - … … …
Background: Reorder buffer • Key hardware data structure for 
 out-of-order and speculative execution • Keeps track of “in- fl ight instructions” • Example: 68 Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: - - 3: - - … … … c ⟵ x < A_size beqz c, END L1: load t, A + x 
 load y, B + t END: Entry Instruction Control Dep. 0: c ⟵ 0 - 1: beqz c, END - 2: load t, A + x 1 3: load y, B + t 1 … … … Evaluate x < A_size Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 2 3: - - … … … Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 1 3: load y, B + t 1 … … …
Background: Reorder buffer • Key hardware data structure for 
 out-of-order and speculative execution • Keeps track of “in- fl ight instructions” • Example: 69 Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: - - 3: - - … … … c ⟵ x < A_size beqz c, END L1: load t, A + x 
 load y, B + t END: Entry Instruction Control Dep. 0: c ⟵ 0 - 1: beqz c, END - 2: - - 3: - - … … … Rollback 
 mis-speculation Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 2 3: - - … … … Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 2 3: load y, B + t 2 … … … Entry Instruction Control Dep. 0: c ⟵ 0 - 1: beqz c, END - 2: load t, A + x 1 3: load y, B + t 1 … … …
Background: Reorder buffer • Key hardware data structure for 
 out-of-order and speculative execution • Keeps track of “in- fl ight instructions” • Example: 70 Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: - - 3: - - … … … c ⟵ x < A_size beqz c, END L1: load t, A + x 
 load y, B + t END: Entry Instruction Control Dep. 0: beqz c, END - 1: - - 2: - - 3: - - … … … Retire Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 2 3: - - … … … Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 2 3: load y, B + t 2 … … … Entry Instruction Control Dep. 0: c ⟵ 0 - 1: beqz c, END - 2: - - 3: - - … … …
Speculative execution attacks 101 71
if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 72 Size of array A
if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 72 Size of array A
if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 72 Size of array A Branch predictor
if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 72 Size of array A Branch predictor Prediction based on branch history & program structure
if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 72 Size of array A Branch predictor Prediction based on branch history & program structure
if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 72 Size of array A Branch predictor Prediction based on branch history & program structure Wrong predicton? Rollback changes! Architectural (ISA) state Microarchitectural state
Spectre V1 73
Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] 73
Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] 73
Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] 73
Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] 73 What is in A[128]? A_size=16 B[0]B[1] ... B
Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 74 A_size=16 B[0]B[1] ... B
Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 74 A_size=16 B[0]B[1] ... B
Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 74 A_size=16 B[0]B[1] ... B
Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 74 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
B[A[128]] ] Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 74 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
B[A[128]] ] Depends on A[128] Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 74 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
B[A[128]] ] Depends on A[128] Persistent across speculations Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 74 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
B[A[128]] ] Depends on A[128] Persistent across speculations Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 4) Extract from cache 74 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
Secure programming — foundations 75
Secure programming — foundations 75 Program is non-interferent wrt contract and policy 
 if for all arch. states , : if then p π σ σ′  σ ≈π σ′  (p, σ) = (p, σ′  )
Secure programming — foundations 75 Program is non-interferent wrt contract and policy 
 if for all arch. states , : if then p π σ σ′  σ ≈π σ′  (p, σ) = (p, σ′  ) Specify secret data
Secure programming — foundations 75 Program is non-interferent wrt contract and policy 
 if for all arch. states , : if then p π σ σ′  σ ≈π σ′  (p, σ) = (p, σ′  ) Specify secret data
Secure programming — foundations 75 Program is non-interferent wrt contract and policy 
 if for all arch. states , : if then p π σ σ′  σ ≈π σ′  (p, σ) = (p, σ′  ) Specify secret data
Secure programming — foundations 75 Program is non-interferent wrt contract and policy 
 if for all arch. states , : if then p π σ σ′  σ ≈π σ′  (p, σ) = (p, σ′  ) If is non-interferent wrt contract and policy , and hardware satis fi es , then 
 is non-interferent wrt hardware and policy 
 p π p π Specify secret data
Secure programming — foundations 75 Program is non-interferent wrt contract and policy 
 if for all arch. states , : if then p π σ σ′  σ ≈π σ′  (p, σ) = (p, σ′  ) If is non-interferent wrt contract and policy , and hardware satis fi es , then 
 is non-interferent wrt hardware and policy 
 p π p π Specify secret data
Secure programming — foundations 75 Program is non-interferent wrt contract and policy 
 if for all arch. states , : if then p π σ σ′  σ ≈π σ′  (p, σ) = (p, σ′  ) If is non-interferent wrt contract and policy , and hardware satis fi es , then 
 is non-interferent wrt hardware and policy 
 p π p π Specify secret data
Secure programming — foundations 75 Program is non-interferent wrt contract and policy 
 if for all arch. states , : if then p π σ σ′  σ ≈π σ′  (p, σ) = (p, σ′  ) If is non-interferent wrt contract and policy , and hardware satis fi es , then 
 is non-interferent wrt hardware and policy 
 p π p π Specify secret data
Constant-time 76
Constant-time 76 Traditional CT wrt policy non-interference wrt seq-ct and π ≡ π
Constant-time 76 Traditional CT wrt policy non-interference wrt seq-ct and π ≡ π Control- fl ow and memory accesses 
 do not depend on secrets
Constant-time 76 Traditional CT wrt policy non-interference wrt seq-ct and π ≡ π General CT wrt and non-interference wrt and π ≡ π Control- fl ow and memory accesses 
 do not depend on secrets
Sandboxing 77
Sandboxing 77 Traditional SB wrt policy non-interference wrt seq-arch and π ≡ π
Sandboxing 77 Traditional SB wrt policy non-interference wrt seq-arch and π ≡ π Programs never access high memory locations (out-of-sandbox)
Sandboxing 77 Traditional SB wrt policy non-interference wrt seq-arch and π ≡ π General SB wrt and 
 Traditional SB wrt + non-interference wrt and π ≡ π π Programs never access high memory locations (out-of-sandbox)
Constant-time Sandboxing Checking secure programming 78 [[⋅]]seq ct [[⋅]]seq arch [[⋅]]spec ct Traditional CT .. + NI wrt [[⋅]]seq arch .. + speculative NI 
 [Guarnieri et al., S&P’20] Traditional SB Traditional SB .. + weak spec. NI
Constant-time Sandboxing Checking secure programming 78 [[⋅]]seq ct [[⋅]]seq arch [[⋅]]spec ct Traditional CT .. + NI wrt [[⋅]]seq arch .. + speculative NI 
 [Guarnieri et al., S&P’20] Traditional SB Traditional SB .. + weak spec. NI
Ad

Recommended

A Short Review of the NTRU Cryptosystem
A Short Review of the NTRU CryptosystemA Short Review of the NTRU Cryptosystem
A Short Review of the NTRU Cryptosystem
OnBoard Security, Inc. - a Qualcomm Company
 
CPU vulnerabilities - where are we now?
CPU vulnerabilities - where are we now?CPU vulnerabilities - where are we now?
CPU vulnerabilities - where are we now?
DefCamp
 
Austin c-c++-meetup-feb2018-spectre
Austin c-c++-meetup-feb2018-spectreAustin c-c++-meetup-feb2018-spectre
Austin c-c++-meetup-feb2018-spectre
Kim Phillips
 
Meltdown and Spectre
Meltdown and SpectreMeltdown and Spectre
Meltdown and Spectre
yeokm1
 
Wrangling with the Ghost: An Inside Story of Mitigating Speculative Execution...
Wrangling with the Ghost: An Inside Story of Mitigating Speculative Execution...Wrangling with the Ghost: An Inside Story of Mitigating Speculative Execution...
Wrangling with the Ghost: An Inside Story of Mitigating Speculative Execution...
Priyanka Aash
 
Analyzing the Performance Effects of Meltdown + Spectre on Apache Spark Workl...
Analyzing the Performance Effects of Meltdown + Spectre on Apache Spark Workl...Analyzing the Performance Effects of Meltdown + Spectre on Apache Spark Workl...
Analyzing the Performance Effects of Meltdown + Spectre on Apache Spark Workl...
Databricks
 
Meltdown & Spectre
Meltdown & Spectre Meltdown & Spectre
Meltdown & Spectre
Marco Cipriano
 
Meltdown & spectre
Meltdown & spectreMeltdown & spectre
Meltdown & spectre
Sergio Shevchenko
 
Meltdown & Spectre attacks
Meltdown & Spectre attacksMeltdown & Spectre attacks
Meltdown & Spectre attacks
Marian Marinov
 
Exploiting Modern Microarchitectures: Meltdown, Spectre, and other Attacks
Exploiting Modern Microarchitectures: Meltdown, Spectre, and other AttacksExploiting Modern Microarchitectures: Meltdown, Spectre, and other Attacks
Exploiting Modern Microarchitectures: Meltdown, Spectre, and other Attacks
inside-BigData.com
 
The Spectre of Meltdowns
The Spectre of MeltdownsThe Spectre of Meltdowns
The Spectre of Meltdowns
Andriy Berestovskyy
 
Micro-Architectural Attacks on Cyber-Physical Systems
Micro-Architectural Attacks on Cyber-Physical SystemsMicro-Architectural Attacks on Cyber-Physical Systems
Micro-Architectural Attacks on Cyber-Physical Systems
Heechul Yun
 
Exploring Hardware Security
Exploring Hardware SecurityExploring Hardware Security
Exploring Hardware Security
Speck&Tech
 
jc_thesis_final
jc_thesis_finaljc_thesis_final
jc_thesis_final
Jonah Caplan
 
Spectre(v1%2 fv2%2fv4) v.s. meltdown(v3)
Spectre(v1%2 fv2%2fv4) v.s. meltdown(v3)Spectre(v1%2 fv2%2fv4) v.s. meltdown(v3)
Spectre(v1%2 fv2%2fv4) v.s. meltdown(v3)
Gavin Guo
 
Advanced SOHO Router Exploitation XCON
Advanced SOHO Router Exploitation XCONAdvanced SOHO Router Exploitation XCON
Advanced SOHO Router Exploitation XCON
Lyon Yang
 
Wonderful world of Microarchitectural attacks
Wonderful world of Microarchitectural attacksWonderful world of Microarchitectural attacks
Wonderful world of Microarchitectural attacks
Toshihito Kikuchi
 
Wouter Joosen, iMinds Security Department, iMinds The Conference 2013
Wouter Joosen, iMinds Security Department, iMinds The Conference 2013Wouter Joosen, iMinds Security Department, iMinds The Conference 2013
Wouter Joosen, iMinds Security Department, iMinds The Conference 2013
imec
 
Mmp hotos2003-slides
Mmp hotos2003-slidesMmp hotos2003-slides
Mmp hotos2003-slides
MUHAMMAD UMAIR
 
Ice Age melting down: Intel features considered usefull!
Ice Age melting down: Intel features considered usefull!Ice Age melting down: Intel features considered usefull!
Ice Age melting down: Intel features considered usefull!
Peter Hlavaty
 
Practical real-time operating system security for the masses
Practical real-time operating system security for the massesPractical real-time operating system security for the masses
Practical real-time operating system security for the masses
Milosch Meriac
 
ARM Architecture and Meltdown/Spectre
ARM Architecture and Meltdown/SpectreARM Architecture and Meltdown/Spectre
ARM Architecture and Meltdown/Spectre
GlobalLogic Ukraine
 
Effective Memory Protection Using Dynamic Tainting (ASE 2007)
Effective Memory Protection Using Dynamic Tainting (ASE 2007)Effective Memory Protection Using Dynamic Tainting (ASE 2007)
Effective Memory Protection Using Dynamic Tainting (ASE 2007)
James Clause
 
Resilient IoT Security: The end of flat security models
Resilient IoT Security: The end of flat security modelsResilient IoT Security: The end of flat security models
Resilient IoT Security: The end of flat security models
Milosch Meriac
 
Lec14 Computer Architecture by Hsien-Hsin Sean Lee Georgia Tech --- Coherence
Lec14 Computer Architecture by Hsien-Hsin Sean Lee Georgia Tech --- CoherenceLec14 Computer Architecture by Hsien-Hsin Sean Lee Georgia Tech --- Coherence
Lec14 Computer Architecture by Hsien-Hsin Sean Lee Georgia Tech --- Coherence
Hsien-Hsin Sean Lee, Ph.D.
 
Designing and implementing malicious processors
Designing and implementing malicious processorsDesigning and implementing malicious processors
Designing and implementing malicious processors
NebyueAwoke
 
Exspectre NDSS 2019
Exspectre NDSS 2019Exspectre NDSS 2019
Exspectre NDSS 2019
Jack Wampler
 
Intro to Hardware Firmware Hacking
Intro to Hardware Firmware HackingIntro to Hardware Firmware Hacking
Intro to Hardware Firmware Hacking
Andrew Freeborn
 
¿Por qué debemos seguir trabajando en álgebra lineal?
¿Por qué debemos seguir trabajando en álgebra lineal?¿Por qué debemos seguir trabajando en álgebra lineal?
¿Por qué debemos seguir trabajando en álgebra lineal?
Facultad de Informática UCM
 
TECNOPOLÍTICA Y ACTIVISMO DE DATOS: EL MAPEO COMO FORMA DE RESILIENCIA ANTE L...
TECNOPOLÍTICA Y ACTIVISMO DE DATOS: EL MAPEO COMO FORMA DE RESILIENCIA ANTE L...TECNOPOLÍTICA Y ACTIVISMO DE DATOS: EL MAPEO COMO FORMA DE RESILIENCIA ANTE L...
TECNOPOLÍTICA Y ACTIVISMO DE DATOS: EL MAPEO COMO FORMA DE RESILIENCIA ANTE L...
Facultad de Informática UCM
 

More Related Content

Similar to Hardware/software security contracts: Principled foundations for building secure microarchitectures (20)

Meltdown & Spectre attacks
Meltdown & Spectre attacksMeltdown & Spectre attacks
Meltdown & Spectre attacks
Marian Marinov
 
Exploiting Modern Microarchitectures: Meltdown, Spectre, and other Attacks
Exploiting Modern Microarchitectures: Meltdown, Spectre, and other AttacksExploiting Modern Microarchitectures: Meltdown, Spectre, and other Attacks
Exploiting Modern Microarchitectures: Meltdown, Spectre, and other Attacks
inside-BigData.com
 
The Spectre of Meltdowns
The Spectre of MeltdownsThe Spectre of Meltdowns
The Spectre of Meltdowns
Andriy Berestovskyy
 
Micro-Architectural Attacks on Cyber-Physical Systems
Micro-Architectural Attacks on Cyber-Physical SystemsMicro-Architectural Attacks on Cyber-Physical Systems
Micro-Architectural Attacks on Cyber-Physical Systems
Heechul Yun
 
Exploring Hardware Security
Exploring Hardware SecurityExploring Hardware Security
Exploring Hardware Security
Speck&Tech
 
jc_thesis_final
jc_thesis_finaljc_thesis_final
jc_thesis_final
Jonah Caplan
 
Spectre(v1%2 fv2%2fv4) v.s. meltdown(v3)
Spectre(v1%2 fv2%2fv4) v.s. meltdown(v3)Spectre(v1%2 fv2%2fv4) v.s. meltdown(v3)
Spectre(v1%2 fv2%2fv4) v.s. meltdown(v3)
Gavin Guo
 
Advanced SOHO Router Exploitation XCON
Advanced SOHO Router Exploitation XCONAdvanced SOHO Router Exploitation XCON
Advanced SOHO Router Exploitation XCON
Lyon Yang
 
Wonderful world of Microarchitectural attacks
Wonderful world of Microarchitectural attacksWonderful world of Microarchitectural attacks
Wonderful world of Microarchitectural attacks
Toshihito Kikuchi
 
Wouter Joosen, iMinds Security Department, iMinds The Conference 2013
Wouter Joosen, iMinds Security Department, iMinds The Conference 2013Wouter Joosen, iMinds Security Department, iMinds The Conference 2013
Wouter Joosen, iMinds Security Department, iMinds The Conference 2013
imec
 
Mmp hotos2003-slides
Mmp hotos2003-slidesMmp hotos2003-slides
Mmp hotos2003-slides
MUHAMMAD UMAIR
 
Ice Age melting down: Intel features considered usefull!
Ice Age melting down: Intel features considered usefull!Ice Age melting down: Intel features considered usefull!
Ice Age melting down: Intel features considered usefull!
Peter Hlavaty
 
Practical real-time operating system security for the masses
Practical real-time operating system security for the massesPractical real-time operating system security for the masses
Practical real-time operating system security for the masses
Milosch Meriac
 
ARM Architecture and Meltdown/Spectre
ARM Architecture and Meltdown/SpectreARM Architecture and Meltdown/Spectre
ARM Architecture and Meltdown/Spectre
GlobalLogic Ukraine
 
Effective Memory Protection Using Dynamic Tainting (ASE 2007)
Effective Memory Protection Using Dynamic Tainting (ASE 2007)Effective Memory Protection Using Dynamic Tainting (ASE 2007)
Effective Memory Protection Using Dynamic Tainting (ASE 2007)
James Clause
 
Resilient IoT Security: The end of flat security models
Resilient IoT Security: The end of flat security modelsResilient IoT Security: The end of flat security models
Resilient IoT Security: The end of flat security models
Milosch Meriac
 
Lec14 Computer Architecture by Hsien-Hsin Sean Lee Georgia Tech --- Coherence
Lec14 Computer Architecture by Hsien-Hsin Sean Lee Georgia Tech --- CoherenceLec14 Computer Architecture by Hsien-Hsin Sean Lee Georgia Tech --- Coherence
Lec14 Computer Architecture by Hsien-Hsin Sean Lee Georgia Tech --- Coherence
Hsien-Hsin Sean Lee, Ph.D.
 
Designing and implementing malicious processors
Designing and implementing malicious processorsDesigning and implementing malicious processors
Designing and implementing malicious processors
NebyueAwoke
 
Exspectre NDSS 2019
Exspectre NDSS 2019Exspectre NDSS 2019
Exspectre NDSS 2019
Jack Wampler
 
Intro to Hardware Firmware Hacking
Intro to Hardware Firmware HackingIntro to Hardware Firmware Hacking
Intro to Hardware Firmware Hacking
Andrew Freeborn
 
Meltdown & Spectre attacks
Meltdown & Spectre attacksMeltdown & Spectre attacks
Meltdown & Spectre attacks
Marian Marinov
 
Exploiting Modern Microarchitectures: Meltdown, Spectre, and other Attacks
Exploiting Modern Microarchitectures: Meltdown, Spectre, and other AttacksExploiting Modern Microarchitectures: Meltdown, Spectre, and other Attacks
Exploiting Modern Microarchitectures: Meltdown, Spectre, and other Attacks
inside-BigData.com
 
The Spectre of Meltdowns
The Spectre of MeltdownsThe Spectre of Meltdowns
The Spectre of Meltdowns
Andriy Berestovskyy
 
Micro-Architectural Attacks on Cyber-Physical Systems
Micro-Architectural Attacks on Cyber-Physical SystemsMicro-Architectural Attacks on Cyber-Physical Systems
Micro-Architectural Attacks on Cyber-Physical Systems
Heechul Yun
 
Exploring Hardware Security
Exploring Hardware SecurityExploring Hardware Security
Exploring Hardware Security
Speck&Tech
 
jc_thesis_final
jc_thesis_finaljc_thesis_final
jc_thesis_final
Jonah Caplan
 
Spectre(v1%2 fv2%2fv4) v.s. meltdown(v3)
Spectre(v1%2 fv2%2fv4) v.s. meltdown(v3)Spectre(v1%2 fv2%2fv4) v.s. meltdown(v3)
Spectre(v1%2 fv2%2fv4) v.s. meltdown(v3)
Gavin Guo
 
Advanced SOHO Router Exploitation XCON
Advanced SOHO Router Exploitation XCONAdvanced SOHO Router Exploitation XCON
Advanced SOHO Router Exploitation XCON
Lyon Yang
 
Wonderful world of Microarchitectural attacks
Wonderful world of Microarchitectural attacksWonderful world of Microarchitectural attacks
Wonderful world of Microarchitectural attacks
Toshihito Kikuchi
 
Wouter Joosen, iMinds Security Department, iMinds The Conference 2013
Wouter Joosen, iMinds Security Department, iMinds The Conference 2013Wouter Joosen, iMinds Security Department, iMinds The Conference 2013
Wouter Joosen, iMinds Security Department, iMinds The Conference 2013
imec
 
Mmp hotos2003-slides
Mmp hotos2003-slidesMmp hotos2003-slides
Mmp hotos2003-slides
MUHAMMAD UMAIR
 
Ice Age melting down: Intel features considered usefull!
Ice Age melting down: Intel features considered usefull!Ice Age melting down: Intel features considered usefull!
Ice Age melting down: Intel features considered usefull!
Peter Hlavaty
 
Practical real-time operating system security for the masses
Practical real-time operating system security for the massesPractical real-time operating system security for the masses
Practical real-time operating system security for the masses
Milosch Meriac
 
ARM Architecture and Meltdown/Spectre
ARM Architecture and Meltdown/SpectreARM Architecture and Meltdown/Spectre
ARM Architecture and Meltdown/Spectre
GlobalLogic Ukraine
 
Effective Memory Protection Using Dynamic Tainting (ASE 2007)
Effective Memory Protection Using Dynamic Tainting (ASE 2007)Effective Memory Protection Using Dynamic Tainting (ASE 2007)
Effective Memory Protection Using Dynamic Tainting (ASE 2007)
James Clause
 
Resilient IoT Security: The end of flat security models
Resilient IoT Security: The end of flat security modelsResilient IoT Security: The end of flat security models
Resilient IoT Security: The end of flat security models
Milosch Meriac
 
Lec14 Computer Architecture by Hsien-Hsin Sean Lee Georgia Tech --- Coherence
Lec14 Computer Architecture by Hsien-Hsin Sean Lee Georgia Tech --- CoherenceLec14 Computer Architecture by Hsien-Hsin Sean Lee Georgia Tech --- Coherence
Lec14 Computer Architecture by Hsien-Hsin Sean Lee Georgia Tech --- Coherence
Hsien-Hsin Sean Lee, Ph.D.
 
Designing and implementing malicious processors
Designing and implementing malicious processorsDesigning and implementing malicious processors
Designing and implementing malicious processors
NebyueAwoke
 
Exspectre NDSS 2019
Exspectre NDSS 2019Exspectre NDSS 2019
Exspectre NDSS 2019
Jack Wampler
 
Intro to Hardware Firmware Hacking
Intro to Hardware Firmware HackingIntro to Hardware Firmware Hacking
Intro to Hardware Firmware Hacking
Andrew Freeborn
 

More from Facultad de Informática UCM (20)

¿Por qué debemos seguir trabajando en álgebra lineal?
¿Por qué debemos seguir trabajando en álgebra lineal?¿Por qué debemos seguir trabajando en álgebra lineal?
¿Por qué debemos seguir trabajando en álgebra lineal?
Facultad de Informática UCM
 
TECNOPOLÍTICA Y ACTIVISMO DE DATOS: EL MAPEO COMO FORMA DE RESILIENCIA ANTE L...
TECNOPOLÍTICA Y ACTIVISMO DE DATOS: EL MAPEO COMO FORMA DE RESILIENCIA ANTE L...TECNOPOLÍTICA Y ACTIVISMO DE DATOS: EL MAPEO COMO FORMA DE RESILIENCIA ANTE L...
TECNOPOLÍTICA Y ACTIVISMO DE DATOS: EL MAPEO COMO FORMA DE RESILIENCIA ANTE L...
Facultad de Informática UCM
 
DRAC: Designing RISC-V-based Accelerators for next generation Computers
DRAC: Designing RISC-V-based Accelerators for next generation ComputersDRAC: Designing RISC-V-based Accelerators for next generation Computers
DRAC: Designing RISC-V-based Accelerators for next generation Computers
Facultad de Informática UCM
 
uElectronics ongoing activities at ESA
uElectronics ongoing activities at ESAuElectronics ongoing activities at ESA
uElectronics ongoing activities at ESA
Facultad de Informática UCM
 
Tendencias en el diseño de procesadores con arquitectura Arm
Tendencias en el diseño de procesadores con arquitectura ArmTendencias en el diseño de procesadores con arquitectura Arm
Tendencias en el diseño de procesadores con arquitectura Arm
Facultad de Informática UCM
 
Formalizing Mathematics in Lean
Formalizing Mathematics in LeanFormalizing Mathematics in Lean
Formalizing Mathematics in Lean
Facultad de Informática UCM
 
Introduction to Quantum Computing and Quantum Service Oriented Computing
Introduction to Quantum Computing and Quantum Service Oriented ComputingIntroduction to Quantum Computing and Quantum Service Oriented Computing
Introduction to Quantum Computing and Quantum Service Oriented Computing
Facultad de Informática UCM
 
Computer Design Concepts for Machine Learning
Computer Design Concepts for Machine LearningComputer Design Concepts for Machine Learning
Computer Design Concepts for Machine Learning
Facultad de Informática UCM
 
Inteligencia Artificial en la atención sanitaria del futuro
Inteligencia Artificial en la atención sanitaria del futuroInteligencia Artificial en la atención sanitaria del futuro
Inteligencia Artificial en la atención sanitaria del futuro
Facultad de Informática UCM
 
Design Automation Approaches for Real-Time Edge Computing for Science Applic...
Design Automation Approaches for Real-Time Edge Computing for Science Applic... Design Automation Approaches for Real-Time Edge Computing for Science Applic...
Design Automation Approaches for Real-Time Edge Computing for Science Applic...
Facultad de Informática UCM
 
Estrategias de navegación para robótica móvil de campo: caso de estudio proye...
Estrategias de navegación para robótica móvil de campo: caso de estudio proye...Estrategias de navegación para robótica móvil de campo: caso de estudio proye...
Estrategias de navegación para robótica móvil de campo: caso de estudio proye...
Facultad de Informática UCM
 
Fault-tolerance Quantum computation and Quantum Error Correction
Fault-tolerance Quantum computation and Quantum Error CorrectionFault-tolerance Quantum computation and Quantum Error Correction
Fault-tolerance Quantum computation and Quantum Error Correction
Facultad de Informática UCM
 
Cómo construir un chatbot inteligente sin morir en el intento
Cómo construir un chatbot inteligente sin morir en el intentoCómo construir un chatbot inteligente sin morir en el intento
Cómo construir un chatbot inteligente sin morir en el intento
Facultad de Informática UCM
 
Automatic generation of hardware memory architectures for HPC
Automatic generation of hardware memory architectures for HPCAutomatic generation of hardware memory architectures for HPC
Automatic generation of hardware memory architectures for HPC
Facultad de Informática UCM
 
Type and proof structures for concurrency
Type and proof structures for concurrencyType and proof structures for concurrency
Type and proof structures for concurrency
Facultad de Informática UCM
 
Jose carlossancho slidesLa seguridad en el desarrollo de software implementad...
Jose carlossancho slidesLa seguridad en el desarrollo de software implementad...Jose carlossancho slidesLa seguridad en el desarrollo de software implementad...
Jose carlossancho slidesLa seguridad en el desarrollo de software implementad...
Facultad de Informática UCM
 
Do you trust your artificial intelligence system?
Do you trust your artificial intelligence system?Do you trust your artificial intelligence system?
Do you trust your artificial intelligence system?
Facultad de Informática UCM
 
Redes neuronales y reinforcement learning. Aplicación en energía eólica.
Redes neuronales y reinforcement learning. Aplicación en energía eólica.Redes neuronales y reinforcement learning. Aplicación en energía eólica.
Redes neuronales y reinforcement learning. Aplicación en energía eólica.
Facultad de Informática UCM
 
Challenges and Opportunities for AI and Data analytics in Offshore wind
Challenges and Opportunities for AI and Data analytics in Offshore windChallenges and Opportunities for AI and Data analytics in Offshore wind
Challenges and Opportunities for AI and Data analytics in Offshore wind
Facultad de Informática UCM
 
Evolution and Trends in Edge AI Systems and Architectures for the Internet of...
Evolution and Trends in Edge AI Systems and Architectures for the Internet of...Evolution and Trends in Edge AI Systems and Architectures for the Internet of...
Evolution and Trends in Edge AI Systems and Architectures for the Internet of...
Facultad de Informática UCM
 
¿Por qué debemos seguir trabajando en álgebra lineal?
¿Por qué debemos seguir trabajando en álgebra lineal?¿Por qué debemos seguir trabajando en álgebra lineal?
¿Por qué debemos seguir trabajando en álgebra lineal?
Facultad de Informática UCM
 
TECNOPOLÍTICA Y ACTIVISMO DE DATOS: EL MAPEO COMO FORMA DE RESILIENCIA ANTE L...
TECNOPOLÍTICA Y ACTIVISMO DE DATOS: EL MAPEO COMO FORMA DE RESILIENCIA ANTE L...TECNOPOLÍTICA Y ACTIVISMO DE DATOS: EL MAPEO COMO FORMA DE RESILIENCIA ANTE L...
TECNOPOLÍTICA Y ACTIVISMO DE DATOS: EL MAPEO COMO FORMA DE RESILIENCIA ANTE L...
Facultad de Informática UCM
 
DRAC: Designing RISC-V-based Accelerators for next generation Computers
DRAC: Designing RISC-V-based Accelerators for next generation ComputersDRAC: Designing RISC-V-based Accelerators for next generation Computers
DRAC: Designing RISC-V-based Accelerators for next generation Computers
Facultad de Informática UCM
 
uElectronics ongoing activities at ESA
uElectronics ongoing activities at ESAuElectronics ongoing activities at ESA
uElectronics ongoing activities at ESA
Facultad de Informática UCM
 
Tendencias en el diseño de procesadores con arquitectura Arm
Tendencias en el diseño de procesadores con arquitectura ArmTendencias en el diseño de procesadores con arquitectura Arm
Tendencias en el diseño de procesadores con arquitectura Arm
Facultad de Informática UCM
 
Formalizing Mathematics in Lean
Formalizing Mathematics in LeanFormalizing Mathematics in Lean
Formalizing Mathematics in Lean
Facultad de Informática UCM
 
Introduction to Quantum Computing and Quantum Service Oriented Computing
Introduction to Quantum Computing and Quantum Service Oriented ComputingIntroduction to Quantum Computing and Quantum Service Oriented Computing
Introduction to Quantum Computing and Quantum Service Oriented Computing
Facultad de Informática UCM
 
Computer Design Concepts for Machine Learning
Computer Design Concepts for Machine LearningComputer Design Concepts for Machine Learning
Computer Design Concepts for Machine Learning
Facultad de Informática UCM
 
Inteligencia Artificial en la atención sanitaria del futuro
Inteligencia Artificial en la atención sanitaria del futuroInteligencia Artificial en la atención sanitaria del futuro
Inteligencia Artificial en la atención sanitaria del futuro
Facultad de Informática UCM
 
Design Automation Approaches for Real-Time Edge Computing for Science Applic...
Design Automation Approaches for Real-Time Edge Computing for Science Applic... Design Automation Approaches for Real-Time Edge Computing for Science Applic...
Design Automation Approaches for Real-Time Edge Computing for Science Applic...
Facultad de Informática UCM
 
Estrategias de navegación para robótica móvil de campo: caso de estudio proye...
Estrategias de navegación para robótica móvil de campo: caso de estudio proye...Estrategias de navegación para robótica móvil de campo: caso de estudio proye...
Estrategias de navegación para robótica móvil de campo: caso de estudio proye...
Facultad de Informática UCM
 
Fault-tolerance Quantum computation and Quantum Error Correction
Fault-tolerance Quantum computation and Quantum Error CorrectionFault-tolerance Quantum computation and Quantum Error Correction
Fault-tolerance Quantum computation and Quantum Error Correction
Facultad de Informática UCM
 
Cómo construir un chatbot inteligente sin morir en el intento
Cómo construir un chatbot inteligente sin morir en el intentoCómo construir un chatbot inteligente sin morir en el intento
Cómo construir un chatbot inteligente sin morir en el intento
Facultad de Informática UCM
 
Automatic generation of hardware memory architectures for HPC
Automatic generation of hardware memory architectures for HPCAutomatic generation of hardware memory architectures for HPC
Automatic generation of hardware memory architectures for HPC
Facultad de Informática UCM
 
Type and proof structures for concurrency
Type and proof structures for concurrencyType and proof structures for concurrency
Type and proof structures for concurrency
Facultad de Informática UCM
 
Jose carlossancho slidesLa seguridad en el desarrollo de software implementad...
Jose carlossancho slidesLa seguridad en el desarrollo de software implementad...Jose carlossancho slidesLa seguridad en el desarrollo de software implementad...
Jose carlossancho slidesLa seguridad en el desarrollo de software implementad...
Facultad de Informática UCM
 
Do you trust your artificial intelligence system?
Do you trust your artificial intelligence system?Do you trust your artificial intelligence system?
Do you trust your artificial intelligence system?
Facultad de Informática UCM
 
Redes neuronales y reinforcement learning. Aplicación en energía eólica.
Redes neuronales y reinforcement learning. Aplicación en energía eólica.Redes neuronales y reinforcement learning. Aplicación en energía eólica.
Redes neuronales y reinforcement learning. Aplicación en energía eólica.
Facultad de Informática UCM
 
Challenges and Opportunities for AI and Data analytics in Offshore wind
Challenges and Opportunities for AI and Data analytics in Offshore windChallenges and Opportunities for AI and Data analytics in Offshore wind
Challenges and Opportunities for AI and Data analytics in Offshore wind
Facultad de Informática UCM
 
Evolution and Trends in Edge AI Systems and Architectures for the Internet of...
Evolution and Trends in Edge AI Systems and Architectures for the Internet of...Evolution and Trends in Edge AI Systems and Architectures for the Internet of...
Evolution and Trends in Edge AI Systems and Architectures for the Internet of...
Facultad de Informática UCM
 
Ad

Recently uploaded (20)

Montreal Dreamin' 25 - Introduction to the MuleSoft AI Chain (MAC) Project
Montreal Dreamin' 25 - Introduction to the MuleSoft AI Chain (MAC) ProjectMontreal Dreamin' 25 - Introduction to the MuleSoft AI Chain (MAC) Project
Montreal Dreamin' 25 - Introduction to the MuleSoft AI Chain (MAC) Project
Alexandra N. Martinez
 
Structure of OS ppt Structure of OsS ppt
Structure of OS ppt Structure of OsS pptStructure of OS ppt Structure of OsS ppt
Structure of OS ppt Structure of OsS ppt
Wahajch
 
WIRELESS COMMUNICATION SECURITY AND IT’S PROTECTION METHODS
WIRELESS COMMUNICATION SECURITY AND IT’S PROTECTION METHODSWIRELESS COMMUNICATION SECURITY AND IT’S PROTECTION METHODS
WIRELESS COMMUNICATION SECURITY AND IT’S PROTECTION METHODS
samueljackson3773
 
Third Review PPT that consists of the project d etails like abstract.
Third Review PPT that consists of the project d etails like abstract.Third Review PPT that consists of the project d etails like abstract.
Third Review PPT that consists of the project d etails like abstract.
Sowndarya6
 
Présentation_gestion[1] [Autosaved].pptx
Présentation_gestion[1] [Autosaved].pptxPrésentation_gestion[1] [Autosaved].pptx
Présentation_gestion[1] [Autosaved].pptx
KHADIJAESSAKET
 
Top Cite Articles- International Journal on Soft Computing, Artificial Intell...
Top Cite Articles- International Journal on Soft Computing, Artificial Intell...Top Cite Articles- International Journal on Soft Computing, Artificial Intell...
Top Cite Articles- International Journal on Soft Computing, Artificial Intell...
ijscai
 
22PCOAM16 _ML_Unit 3 Notes & Question bank
22PCOAM16 _ML_Unit 3 Notes & Question bank22PCOAM16 _ML_Unit 3 Notes & Question bank
22PCOAM16 _ML_Unit 3 Notes & Question bank
Guru Nanak Technical Institutions
 
Week 6- PC HARDWARE AND MAINTENANCE-THEORY.pptx
Week 6- PC HARDWARE AND MAINTENANCE-THEORY.pptxWeek 6- PC HARDWARE AND MAINTENANCE-THEORY.pptx
Week 6- PC HARDWARE AND MAINTENANCE-THEORY.pptx
dayananda54
 
社内勉強会資料_Chain of Thought .
社内勉強会資料_Chain of Thought .社内勉強会資料_Chain of Thought .
社内勉強会資料_Chain of Thought .
NABLAS株式会社
 
David Boutry - Mentors Junior Developers
David Boutry - Mentors Junior DevelopersDavid Boutry - Mentors Junior Developers
David Boutry - Mentors Junior Developers
David Boutry
 
Development of Portable Biomass Briquetting Machine (S, A & D)-1.pptx
Development of Portable Biomass Briquetting Machine (S, A & D)-1.pptxDevelopment of Portable Biomass Briquetting Machine (S, A & D)-1.pptx
Development of Portable Biomass Briquetting Machine (S, A & D)-1.pptx
aniket862935
 
Semi-Conductor ppt ShubhamSeSemi-Con.pptx
Semi-Conductor ppt ShubhamSeSemi-Con.pptxSemi-Conductor ppt ShubhamSeSemi-Con.pptx
Semi-Conductor ppt ShubhamSeSemi-Con.pptx
studyshubham18
 
Ppt on the related on the solar power system for electric vehicle engineering
Ppt on the related on the solar power system for electric vehicle engineeringPpt on the related on the solar power system for electric vehicle engineering
Ppt on the related on the solar power system for electric vehicle engineering
ravindrabodke
 
IntroSlides-June-GDG-Cloud-Munich community [email protected]
IntroSlides-June-GDG-Cloud-Munich community gathering@Netlight.pdfIntroSlides-June-GDG-Cloud-Munich community gathering@Netlight.pdf
IntroSlides-June-GDG-Cloud-Munich community [email protected]
Luiz Carneiro
 
A Comprehensive Investigation into the Accuracy of Soft Computing Tools for D...
A Comprehensive Investigation into the Accuracy of Soft Computing Tools for D...A Comprehensive Investigation into the Accuracy of Soft Computing Tools for D...
A Comprehensive Investigation into the Accuracy of Soft Computing Tools for D...
Journal of Soft Computing in Civil Engineering
 
Airport_Substation_With_Diagrams (2).pptx
Airport_Substation_With_Diagrams (2).pptxAirport_Substation_With_Diagrams (2).pptx
Airport_Substation_With_Diagrams (2).pptx
BibekMedhi2
 
The first edition of the AIAG-VDA FMEA.pptx
The first edition of the AIAG-VDA FMEA.pptxThe first edition of the AIAG-VDA FMEA.pptx
The first edition of the AIAG-VDA FMEA.pptx
Mayank Mathur
 
Artificial Power 2025 raport krajobrazowy
Artificial Power 2025 raport krajobrazowyArtificial Power 2025 raport krajobrazowy
Artificial Power 2025 raport krajobrazowy
dominikamizerska1
 
First Review PPT gfinal gyft ftu liu yrfut go
First Review PPT gfinal gyft ftu liu yrfut goFirst Review PPT gfinal gyft ftu liu yrfut go
First Review PPT gfinal gyft ftu liu yrfut go
Sowndarya6
 
IOt Based Research on Challenges and Future
IOt Based Research on Challenges and FutureIOt Based Research on Challenges and Future
IOt Based Research on Challenges and Future
SACHINSAHU821405
 
Montreal Dreamin' 25 - Introduction to the MuleSoft AI Chain (MAC) Project
Montreal Dreamin' 25 - Introduction to the MuleSoft AI Chain (MAC) ProjectMontreal Dreamin' 25 - Introduction to the MuleSoft AI Chain (MAC) Project
Montreal Dreamin' 25 - Introduction to the MuleSoft AI Chain (MAC) Project
Alexandra N. Martinez
 
Structure of OS ppt Structure of OsS ppt
Structure of OS ppt Structure of OsS pptStructure of OS ppt Structure of OsS ppt
Structure of OS ppt Structure of OsS ppt
Wahajch
 
WIRELESS COMMUNICATION SECURITY AND IT’S PROTECTION METHODS
WIRELESS COMMUNICATION SECURITY AND IT’S PROTECTION METHODSWIRELESS COMMUNICATION SECURITY AND IT’S PROTECTION METHODS
WIRELESS COMMUNICATION SECURITY AND IT’S PROTECTION METHODS
samueljackson3773
 
Third Review PPT that consists of the project d etails like abstract.
Third Review PPT that consists of the project d etails like abstract.Third Review PPT that consists of the project d etails like abstract.
Third Review PPT that consists of the project d etails like abstract.
Sowndarya6
 
Présentation_gestion[1] [Autosaved].pptx
Présentation_gestion[1] [Autosaved].pptxPrésentation_gestion[1] [Autosaved].pptx
Présentation_gestion[1] [Autosaved].pptx
KHADIJAESSAKET
 
Top Cite Articles- International Journal on Soft Computing, Artificial Intell...
Top Cite Articles- International Journal on Soft Computing, Artificial Intell...Top Cite Articles- International Journal on Soft Computing, Artificial Intell...
Top Cite Articles- International Journal on Soft Computing, Artificial Intell...
ijscai
 
22PCOAM16 _ML_Unit 3 Notes & Question bank
22PCOAM16 _ML_Unit 3 Notes & Question bank22PCOAM16 _ML_Unit 3 Notes & Question bank
22PCOAM16 _ML_Unit 3 Notes & Question bank
Guru Nanak Technical Institutions
 
Week 6- PC HARDWARE AND MAINTENANCE-THEORY.pptx
Week 6- PC HARDWARE AND MAINTENANCE-THEORY.pptxWeek 6- PC HARDWARE AND MAINTENANCE-THEORY.pptx
Week 6- PC HARDWARE AND MAINTENANCE-THEORY.pptx
dayananda54
 
社内勉強会資料_Chain of Thought .
社内勉強会資料_Chain of Thought .社内勉強会資料_Chain of Thought .
社内勉強会資料_Chain of Thought .
NABLAS株式会社
 
David Boutry - Mentors Junior Developers
David Boutry - Mentors Junior DevelopersDavid Boutry - Mentors Junior Developers
David Boutry - Mentors Junior Developers
David Boutry
 
Development of Portable Biomass Briquetting Machine (S, A & D)-1.pptx
Development of Portable Biomass Briquetting Machine (S, A & D)-1.pptxDevelopment of Portable Biomass Briquetting Machine (S, A & D)-1.pptx
Development of Portable Biomass Briquetting Machine (S, A & D)-1.pptx
aniket862935
 
Semi-Conductor ppt ShubhamSeSemi-Con.pptx
Semi-Conductor ppt ShubhamSeSemi-Con.pptxSemi-Conductor ppt ShubhamSeSemi-Con.pptx
Semi-Conductor ppt ShubhamSeSemi-Con.pptx
studyshubham18
 
Ppt on the related on the solar power system for electric vehicle engineering
Ppt on the related on the solar power system for electric vehicle engineeringPpt on the related on the solar power system for electric vehicle engineering
Ppt on the related on the solar power system for electric vehicle engineering
ravindrabodke
 
IntroSlides-June-GDG-Cloud-Munich community [email protected]
IntroSlides-June-GDG-Cloud-Munich community gathering@Netlight.pdfIntroSlides-June-GDG-Cloud-Munich community gathering@Netlight.pdf
IntroSlides-June-GDG-Cloud-Munich community [email protected]
Luiz Carneiro
 
A Comprehensive Investigation into the Accuracy of Soft Computing Tools for D...
A Comprehensive Investigation into the Accuracy of Soft Computing Tools for D...A Comprehensive Investigation into the Accuracy of Soft Computing Tools for D...
A Comprehensive Investigation into the Accuracy of Soft Computing Tools for D...
Journal of Soft Computing in Civil Engineering
 
Airport_Substation_With_Diagrams (2).pptx
Airport_Substation_With_Diagrams (2).pptxAirport_Substation_With_Diagrams (2).pptx
Airport_Substation_With_Diagrams (2).pptx
BibekMedhi2
 
The first edition of the AIAG-VDA FMEA.pptx
The first edition of the AIAG-VDA FMEA.pptxThe first edition of the AIAG-VDA FMEA.pptx
The first edition of the AIAG-VDA FMEA.pptx
Mayank Mathur
 
Artificial Power 2025 raport krajobrazowy
Artificial Power 2025 raport krajobrazowyArtificial Power 2025 raport krajobrazowy
Artificial Power 2025 raport krajobrazowy
dominikamizerska1
 
First Review PPT gfinal gyft ftu liu yrfut go
First Review PPT gfinal gyft ftu liu yrfut goFirst Review PPT gfinal gyft ftu liu yrfut go
First Review PPT gfinal gyft ftu liu yrfut go
Sowndarya6
 
IOt Based Research on Challenges and Future
IOt Based Research on Challenges and FutureIOt Based Research on Challenges and Future
IOt Based Research on Challenges and Future
SACHINSAHU821405
 
Ad

Hardware/software security contracts: Principled foundations for building secure microarchitectures

  • 1. Hardware-software security contracts Principled foundations for building secure microarchitectures 1 Marco Guarnieri IMDEA Software Institute Contacts: [email protected] 
 @MarcoGuarnier1 Based on joint work with Boris Köpf @ Microsoft Research Jan Reineke @ Saarland University José F. Morales, Pepe Vila, Andrés Sánchez @ IMDEA Software Institute Marco Patrignani @ CISPA
  • 3. Outline • Introduction • Speculative execution attacks • Hardware countermeasures and limitations • Hardware/software security contracts for secure speculation • Next steps & challenges 3
  • 4. 4
  • 5. 4
  • 6. 4 Attacks exploit μarchitectural side-e ff ects 
 invisible at ISA level
  • 8. ISA: Benefits 5 High-level language Microarchitecture Instruction set architecture (ISA) Can program independently of 
 microarchitecture
  • 9. ISA: Benefits 5 High-level language Microarchitecture Instruction set architecture (ISA) Can program independently of 
 microarchitecture Can implement arbitrary 
 optimizations as long as 
 ISA semantics are obeyed
  • 10. ISA: (security) pitfalls 6 High-level language Microarchitecture Instruction set architecture (ISA)
  • 11. ISA: (security) pitfalls 6 High-level language Microarchitecture Instruction set architecture (ISA) No guarantees about timing 
 and side channels
  • 12. ISA: (security) pitfalls 6 High-level language Microarchitecture Instruction set architecture (ISA) Can implement arbitrary insecure 
 optimizations as long as ISA 
 semantics are obeyed No guarantees about timing 
 and side channels
  • 13. ISA: (security) pitfalls 6 High-level language Microarchitecture Instruction set architecture (ISA) Can implement arbitrary insecure 
 optimizations as long as ISA 
 semantics are obeyed No guarantees about timing 
 and side channels
  • 14. ISA: (security) pitfalls 6 High-level language Microarchitecture Instruction set architecture (ISA) Can implement arbitrary insecure 
 optimizations as long as ISA 
 semantics are obeyed No guarantees about timing 
 and side channels Impossible to program securely 
 cryptographic algorithms? sandboxing untrusted code?
  • 15. A Way Forward: HW/SW Security Contracts 7 Succinctly captures possible information leakage Hw-Sw contract = ISA + X
  • 16. A Way Forward: HW/SW Security Contracts 7 Can program securely on top contract 
 independently of microarchitecture Succinctly captures possible information leakage Hw-Sw contract = ISA + X
  • 17. A Way Forward: HW/SW Security Contracts 7 Can program securely on top contract 
 independently of microarchitecture Can implement arbitrary insecure optimizations 
 as long as contract is obeyed Succinctly captures possible information leakage Hw-Sw contract = ISA + X
  • 18. A Way Forward: HW/SW Security Contracts 7 Can program securely on top contract 
 independently of microarchitecture Can implement arbitrary insecure optimizations 
 as long as contract is obeyed Succinctly captures possible information leakage Hw-Sw contract = ISA + X In this talk 
 Proof-of-concept of HW/SW contracts for secure speculation
  • 20. Exploits speculative execution Almost all modern CPUs are affected P. Kocher, J. Horn, A. Fogh, D. Genkin, D. Gruss, W. Haas, M. Hamburg, M. Lipp, S. Mangard, T. Prescher, M. Schwarz, Y. Yarom — Spectre Attacks: Exploiting Speculative Execution — S&P 2019 9
  • 21. if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 10 Size of array A
  • 22. if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 10 Size of array A
  • 23. if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 10 Size of array A Branch predictor
  • 24. if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 10 Size of array A Branch predictor Prediction based on branch history & program structure
  • 25. if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 10 Size of array A Branch predictor Prediction based on branch history & program structure
  • 26. if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 10 Size of array A Branch predictor Prediction based on branch history & program structure Wrong predicton? Rollback changes! Architectural (ISA) state Microarchitectural state
  • 28. Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] 11
  • 29. Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] 11
  • 30. Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] 11
  • 31. Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] 11 What is in A[128]? A_size=16 B[0]B[1] ... B
  • 32. Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 12 A_size=16 B[0]B[1] ... B
  • 33. Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 12 A_size=16 B[0]B[1] ... B
  • 34. Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 12 A_size=16 B[0]B[1] ... B
  • 35. Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 12 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
  • 36. B[A[128]] ] Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 12 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
  • 37. B[A[128]] ] Depends on A[128] Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 12 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
  • 38. B[A[128]] ] Depends on A[128] Persistent across speculations Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 12 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
  • 39. B[A[128]] ] Depends on A[128] Persistent across speculations Spectre 101 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 4) Extract from cache 12 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
  • 47. Hardware countermeasures 4 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end
  • 48. Hardware countermeasures 4 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end
  • 49. Hardware countermeasures 4 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end
  • 50. Hardware countermeasures 4 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end Delay loads until 
 they can be retired 
 [Sakalis et al., ISCA’19] Delay loads until they cannot be squashed 
 [Sakalis et al., ISCA’19]
  • 51. Hardware countermeasures 4 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end Delay loads until 
 they can be retired 
 [Sakalis et al., ISCA’19] Delay loads until they cannot be squashed 
 [Sakalis et al., ISCA’19] Taint speculatively loaded data + delay tainted loads 
 [STT and NDA, MICRO’19]
  • 52. Hardware countermeasures 5 1. y = A[x] 2. if (x < A_size) 3. z = B[y] 4. end
  • 53. Hardware countermeasures 5 1. y = A[x] 2. if (x < A_size) 3. z = B[y] 4. end Delay loads until 
 they can be retired 
 [Sakalis et al., ISCA'19] Delay loads until they cannot be squashed 
 [Sakalis et al., ISCA'19]
  • 54. Hardware countermeasures 5 1. y = A[x] 2. if (x < A_size) 3. z = B[y] 4. end Delay loads until 
 they can be retired 
 [Sakalis et al., ISCA'19] Delay loads until they cannot be squashed 
 [Sakalis et al., ISCA'19] Taint speculatively loaded data + delay tainted loads 
 [STT and NDA, MICRO’19]
  • 57. How can we capture security guarantees? 18 Software Hardware C
 o
 n
 t
 r
 a
 c
 t
  • 58. Hardware/software security contracts 19 Guarnieri, Köpf, Reineke, Vila — Hardware-software contracts for secure speculation — IEEE S&P 2021 
 https://arxiv.org/abs/2006.03841
  • 60. Contracts for side-channel-free systems 20 Contracts specify which program executions a side-channel adversary can distinguish
  • 61. Contracts for side-channel-free systems 20 Contracts specify which program executions a side-channel adversary can distinguish Goals • Capture security guarantees of HW • Basis for secure programming
  • 64. Contract ISA extended with observations Contracts 21 Observations expose security-relevant 
 μarch events
  • 65. Contract ISA extended with observations Contracts 21 Observations expose security-relevant 
 μarch events Contract traces: (p, σ)
  • 66. Contract ISA extended with observations Contracts 21 Observations expose security-relevant 
 μarch events Contract traces: (p, σ) Hardware Formal model of 
 processor
  • 67. Contract ISA extended with observations Contracts 21 Observations expose security-relevant 
 μarch events Contract traces: (p, σ) Hardware Formal model of 
 processor Hardware traces: (p, σ)
  • 68. Contract ISA extended with observations Contracts 21 Observations expose security-relevant 
 μarch events Attacker observes sequences of μarch states Contract traces: (p, σ) Hardware Formal model of 
 processor Hardware traces: (p, σ)
  • 69. Contract ISA extended with observations Contracts 21 Contract satisfaction Hardware satis fi es contract if for all programs and arch. states , : if then p σ σ′  (p, σ)= (p, σ′  ) (p, σ) = (p, σ′  ) Observations expose security-relevant 
 μarch events Attacker observes sequences of μarch states Contract traces: (p, σ) Hardware Formal model of 
 processor Hardware traces: (p, σ)
  • 70. Contract ISA extended with observations Contracts 21 Contract satisfaction Hardware satis fi es contract if for all programs and arch. states , : if then p σ σ′  (p, σ)= (p, σ′  ) (p, σ) = (p, σ′  ) Observations expose security-relevant 
 μarch events Attacker observes sequences of μarch states Contract traces: (p, σ) Hardware Formal model of 
 processor Hardware traces: (p, σ)
  • 71. Contract ISA extended with observations Contracts 21 Contract satisfaction Hardware satis fi es contract if for all programs and arch. states , : if then p σ σ′  (p, σ)= (p, σ′  ) (p, σ) = (p, σ′  ) Observations expose security-relevant 
 μarch events Attacker observes sequences of μarch states Contract traces: (p, σ) Hardware Formal model of 
 processor Hardware traces: (p, σ)
  • 72. Contracts for secure speculation 22
  • 73. Contracts for secure speculation 22 Contract = 
 Execution Mode · Observer Mode
  • 74. Contracts for secure speculation 22 Contract = 
 Execution Mode · Observer Mode How are programs executed?
  • 75. Contracts for secure speculation 22 Contract = 
 Execution Mode · Observer Mode How are programs executed? What is visible about the execution?
  • 76. seq — sequential execution spec — mispredict branch instrs. Contracts for secure speculation 23 Contract = 
 Execution Mode · Observer Mode
  • 77. pc — only program counter ct — pc + addr. of loads and stores 
 arch — ct + loaded values 
 Contracts for secure speculation 24 Contract = 
 Execution Mode · Observer Mode
  • 78. A lattice of contracts 25 Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc ⊤ ⊥
  • 79. A lattice of contracts 25 Leaks “everything” Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc ⊤ ⊥
  • 80. A lattice of contracts 25 Leaks “everything” Leaks “nothing” Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc ⊤ ⊥
  • 81. A lattice of contracts 25 Leaks “everything” Leaks “nothing” Leaks addresses of non-spec. loads/stores/ instruction fetches Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc ⊤ ⊥
  • 82. A lattice of contracts 25 Leaks “everything” Leaks “nothing” Leaks addresses of non-spec. loads/stores/ instruction fetches Leaks all data 
 accessed non- speculatively Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc ⊤ ⊥
  • 83. A lattice of contracts 25 Leaks “everything” Leaks “nothing” Leaks addresses of non-spec. loads/stores/ instruction fetches Leaks all data 
 accessed non- speculatively Leaks addresses of all loads/ stores/instruction fetches Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc ⊤ ⊥
  • 84. Example: seq-ct 26 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end 😈
  • 85. Example: seq-ct 26 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x < A_size 😈
  • 86. Example: seq-ct 26 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x < A_size 😈 pc 2
  • 87. Example: seq-ct 26 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x < A_size 😈 load A+x
  • 88. Example: seq-ct 26 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x < A_size 😈 load B+A[x]
  • 89. Example: seq-arch 27 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end 😈
  • 90. Example: seq-arch 27 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x < A_size 😈
  • 91. Example: seq-arch 27 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x < A_size 😈 pc 2
  • 92. Example: seq-arch 27 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x < A_size 😈 load A+x,A[x]
  • 93. load B+A[x],B[A[x]] Example: seq-arch 27 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x < A_size 😈
  • 94. Example: spec-ct 28 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end 😈
  • 95. Example: spec-ct 28 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
  • 96. Example: spec-ct 28 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
  • 97. Example: spec-ct 28 start pc 2 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
  • 98. Example: spec-ct 28 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
  • 99. Example: spec-ct 28 load A+x 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
  • 100. Example: spec-ct 28 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
  • 101. Example: spec-ct 28 load B+A[x] 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
  • 102. Example: spec-ct 28 rollback pc 4 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
  • 103. Example: spec-ct 28 1. if (x < A_size) 2. y = A[x] 3. z = B[y] 4. end x > A_size 😈
  • 105. A simple processor 30 See paper for: processor operational semantics and security proofs
  • 106. A simple processor Speculative and out-of-order executions 30 See paper for: processor operational semantics and security proofs
  • 107. A simple processor 3-stage pipeline 
 (fetch, execute, retire) Speculative and out-of-order executions 30 See paper for: processor operational semantics and security proofs
  • 108. A simple processor Parametric in branch predictor and memory hierarchy 3-stage pipeline 
 (fetch, execute, retire) Speculative and out-of-order executions 30 See paper for: processor operational semantics and security proofs
  • 109. A simple processor Parametric in branch predictor and memory hierarchy 3-stage pipeline 
 (fetch, execute, retire) Speculative and out-of-order executions 30 See paper for: processor operational semantics and security proofs Modeled as operational semantics describing how processor’s state changes 
 (inspired by [Cauligi et al. 2019]) ⇒
  • 110. No countermeasures [The world before Spectre] 17
  • 111. No countermeasures [The world before Spectre] 17 if (x < A_size) 
 z = A[x] 
 y = B[z]
  • 112. No countermeasures [The world before Spectre] 17 if (x < A_size) 
 z = A[x] 
 y = B[z]
  • 113. No countermeasures [The world before Spectre] 17 if (x < A_size) 
 z = A[x] 
 y = B[z]
  • 114. No countermeasures [The world before Spectre] 17 Satis fi es spec-ct if (x < A_size) 
 z = A[x] 
 y = B[z]
  • 117. Disabling speculative execution 32 Instructions are executed sequentially 🥳 No speculative leaks 🥳
  • 118. Disabling speculative execution 32 Instructions are executed sequentially 🥳 No speculative leaks 🥳 Satis fi es seq-ct
  • 119. Eager load delay [Sakalis et al., ISCA’19] 33
  • 120. Eager load delay [Sakalis et al., ISCA’19] 33 Delaying loads until all sources of speculation are resolved
  • 121. Eager load delay [Sakalis et al., ISCA’19] 33 Delaying loads until all sources of speculation are resolved Security guarantees?
  • 122. Eager load delay [Sakalis et al., ISCA’19] 34 if (x < A_size) 
 z = A[x] 
 y = B[z]
  • 123. Eager load delay [Sakalis et al., ISCA’19] 34 if (x < A_size) 
 z = A[x] 
 y = B[z]
  • 124. Eager load delay [Sakalis et al., ISCA’19] 34 if (x < A_size) 
 z = A[x] 
 y = B[z] A[x]and B[z] delayed until 
 x < A_size is resolved
  • 125. Eager load delay [Sakalis et al., ISCA’19] 34 if (x < A_size) 
 z = A[x] 
 y = B[z] A[x]and B[z] delayed until 
 x < A_size is resolved 🥳 No speculative leaks 🥳
  • 126. Eager load delay [Sakalis et al., ISCA’19] 35 z = A[x] if(x < A_size) 
 if(z==0) 
 skip
  • 127. Eager load delay [Sakalis et al., ISCA’19] 35 z = A[x] if(x < A_size) 
 if(z==0) 
 skip
  • 128. Eager load delay [Sakalis et al., ISCA’19] 35 z = A[x] if(x < A_size) 
 if(z==0) 
 skip if(z==0) is not delayed
  • 129. Eager load delay [Sakalis et al., ISCA’19] 35 z = A[x] if(x < A_size) 
 if(z==0) 
 skip if(z==0) is not delayed Program speculatively 
 leaks A[x] 😞
  • 130. Eager load delay [Sakalis et al., ISCA’19] 36
  • 131. Eager load delay [Sakalis et al., ISCA’19] 36 Satis fi es seq-arch Satis fi es seq/spec-ct/pc
  • 132. Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 37
  • 133. Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 37 Taint speculatively loaded data
  • 134. Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 37 Propagate taint through computation Taint speculatively loaded data
  • 135. Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 37 Propagate taint through computation Delay tainted operations Taint speculatively loaded data
  • 136. Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 37 Propagate taint through computation Delay tainted operations Taint speculatively loaded data Security guarantees?
  • 137. Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 38 if (x < A_size) 
 z = A[x] 
 y = B[z]
  • 138. Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 38 if (x < A_size) 
 z = A[x] 
 y = B[z]
  • 139. Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 38 if (x < A_size) 
 z = A[x] 
 y = B[z] A[x]tainted as unsafe 
 B[z] delayed until 
 A[x] is safe
  • 140. Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 38 if (x < A_size) 
 z = A[x] 
 y = B[z] A[x]tainted as unsafe 
 B[z] delayed until 
 A[x] is safe 🥳 No speculative leaks 🥳
  • 141. Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 39 z = A[x] 
 if (x < A_size) 
 y = B[z]
  • 142. Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 39 z = A[x] 
 if (x < A_size) 
 y = B[z]
  • 143. Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 39 z = A[x] 
 if (x < A_size) 
 y = B[z] A[x]tagged as safe 
 
 B[z] not delayed
  • 144. Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 39 z = A[x] 
 if (x < A_size) 
 y = B[z] A[x]tagged as safe 
 
 B[z] not delayed Program speculatively 
 leaks A[x] 😞
  • 145. Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 40
  • 146. Hardware taint-tracking [Yu et al. 2019, Weisse et al. 2019] 40 Satis fi es seq-arch Satis fi es spec-ct
  • 147. Security guarantees 41 See paper for: models and security proofs Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc OoO NS LD TT Vanilla OoO CPU + 
 spec. exec In-order CPU 
 (no specExec) OoO CPU+load delay OoO CPU+taint tracking
  • 148. Security guarantees 41 See paper for: models and security proofs Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc OoO NS LD TT Vanilla OoO CPU + 
 spec. exec In-order CPU 
 (no specExec) OoO CPU+load delay OoO CPU+taint tracking OoO
  • 149. Security guarantees 41 See paper for: models and security proofs Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc OoO NS LD TT Vanilla OoO CPU + 
 spec. exec In-order CPU 
 (no specExec) OoO CPU+load delay OoO CPU+taint tracking OoO NS
  • 150. Security guarantees 41 See paper for: models and security proofs Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc OoO NS LD TT Vanilla OoO CPU + 
 spec. exec In-order CPU 
 (no specExec) OoO CPU+load delay OoO CPU+taint tracking OoO LD NS LD
  • 151. Security guarantees 41 See paper for: models and security proofs Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc OoO NS LD TT Vanilla OoO CPU + 
 spec. exec In-order CPU 
 (no specExec) OoO CPU+load delay OoO CPU+taint tracking OoO TT LD NS TT LD
  • 153. Two flavors of secure programming 26 Sandboxing Constant-time
  • 154. Two flavors of secure programming 26 Sandboxing Constant-time
  • 155. Two flavors of secure programming 26 Sandboxing Constant-time
  • 156. Constant-time Sandboxing Checking secure programming 27 Seq-ct Seq-arch Spec-ct ❌ ✓ ✓ ✓ ❌ ❌ See paper for: additional security checks, proofs, automation
  • 157. Constant-time Sandboxing Checking secure programming 27 Seq-ct Seq-arch Spec-ct ❌ ✓ ✓ ✓ ❌ ❌ See paper for: additional security checks, proofs, automation
  • 162. Contracts & Modeling 47 So far: toy ISA + observation modes for cache/control- fl ow leaks + execution modes for branch speculation
  • 163. Contracts & Modeling 47 So far: toy ISA + observation modes for cache/control- fl ow leaks + execution modes for branch speculation Challenge: scale to real-world ISAs
  • 164. Contracts & Modeling 47 So far: toy ISA + observation modes for cache/control- fl ow leaks + execution modes for branch speculation Challenge: scale to real-world ISAs What do we need? Formal models of ISAs + adequate extensions to capture leaks
  • 168. Contracts & Hardware 49 So far: manual security proofs on toy CPU/ISA
  • 169. Contracts & Hardware 49 So far: manual security proofs on toy CPU/ISA Challenge: automation for realistic CPUs
  • 170. Contracts & Hardware 49 So far: manual security proofs on toy CPU/ISA Challenge: automation for realistic CPUs What do we need? Automated veri fi cation and testing techniques for contract satisfaction
  • 174. Contracts & Software 51 So far: contracts as secure programming foundations + tools targeting “ fi xed contracts”
  • 175. Contracts & Software 51 So far: contracts as secure programming foundations + tools targeting “ fi xed contracts” Challenge: support for large classes of contracts
  • 176. Contracts & Software 51 So far: contracts as secure programming foundations + tools targeting “ fi xed contracts” Challenge: support for large classes of contracts What do we need? Contract-aware program analyses and secure compilation passes
  • 178. 
 Contract ISA extended with observations Contracts Contract satisfaction Hardware satisfies contract if for all programs and arch. states , : if then p σ σ′ (p, σ)= (p, σ′) (p, σ) = (p, σ′) Contract traces: (p, σ) Hardware Formal model of processor Hardware traces: (p, σ) A lattice of contracts Leaks “everything” Leaks “nothing” Leaks addresses of non-spec. loads/stores/ instruction fetches Leaks all data accessed non- speculatively Leaks addresses of all loads/ stores/instruction fetches Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc ⊤ ⊥ Security guarantees Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc OoO NS LD TT Vanilla OoO CPU + spec. exec In-order CPU (no specExec) OoO CPU+load delay OoO CPU+taint tracking OoO TT LD NS TT LD Two flavors of secure programming Sandboxing Constant-time
  • 179. 
 Contract ISA extended with observations Contracts Contract satisfaction Hardware satisfies contract if for all programs and arch. states , : if then p σ σ′ (p, σ)= (p, σ′) (p, σ) = (p, σ′) Contract traces: (p, σ) Hardware Formal model of processor Hardware traces: (p, σ) A lattice of contracts Leaks “everything” Leaks “nothing” Leaks addresses of non-spec. loads/stores/ instruction fetches Leaks all data accessed non- speculatively Leaks addresses of all loads/ stores/instruction fetches Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc ⊤ ⊥ Security guarantees Seq-ct Spec-ct Spec-arch Seq-arch Seq/spec-ct/pc OoO NS LD TT Vanilla OoO CPU + spec. exec In-order CPU (no specExec) OoO CPU+load delay OoO CPU+taint tracking OoO TT LD NS TT LD Two flavors of secure programming Sandboxing Constant-time [email protected] @MarcoGuarnier1 Find out more in the paper: 
 https://arxiv.org/abs/2006.03841
  • 183. 56 Software Hardware Knows what data is sensitive
  • 185. Contracts as basis for HW/SW co-design 56 Controls microarchitectural state Software Hardware C 
 o 
 n 
 t 
 r 
 a 
 c 
 t Knows what data is sensitive
  • 187. Contracts @ Software 57 Program analysis + Guarnieri et al., Spectector: Principled detection of speculative leaks, S&P 2020 Program analyzers that work for arbitrary contracts
  • 188. Contracts @ Software 57 Secure compilation Compiler Source program Target program Contract Compiler takes contracts as input Ensure security at contract level Patrignani and Guarnieri, Exorcising Spectre with secure compilers, CCS 2021 Program analysis + Guarnieri et al., Spectector: Principled detection of speculative leaks, S&P 2020 Program analyzers that work for arbitrary contracts
  • 190. Contracts @ Hardware 58 Veri fi cation Tools for checking compliance with contracts (Partially) automate contract satisfaction proofs
  • 191. Contracts @ Hardware 58 Veri fi cation Tools for checking compliance with contracts (Partially) automate contract satisfaction proofs Testing/Fuzzing Contracts as test oracles Black box: see Oleksenko et al., Revizor: Fuzzing for Leaks in Black-box CPUs https://arxiv.org/ abs/2105.06872 White box: WIP!
  • 192. A simple processor — Configurations 59
  • 193. A simple processor — Configurations 59 Configurations: State of the processor during computation
  • 194. A simple processor — Configurations 59 Configurations: State of the processor during computation ⟨m, a, buf, cs, bp, sc⟩
  • 195. A simple processor — Configurations 59 Configurations: State of the processor during computation Memory ⟨m, a, buf, cs, bp, sc⟩
  • 196. A simple processor — Configurations 59 Configurations: State of the processor during computation Memory Registers ⟨m, a, buf, cs, bp, sc⟩
  • 197. A simple processor — Configurations 59 Configurations: State of the processor during computation Memory Registers Reorder 
 bu ff er ⟨m, a, buf, cs, bp, sc⟩
  • 198. A simple processor — Configurations 59 Configurations: State of the processor during computation Memory Registers Reorder 
 bu ff er Cache 
 (metadata) ⟨m, a, buf, cs, bp, sc⟩
  • 199. A simple processor — Configurations 59 Configurations: State of the processor during computation Memory Registers Reorder 
 bu ff er Cache 
 (metadata) Branch 
 predictor ⟨m, a, buf, cs, bp, sc⟩
  • 200. A simple processor — Configurations 59 Configurations: State of the processor during computation Memory Registers Reorder 
 bu ff er Cache 
 (metadata) Branch 
 predictor Scheduler ⟨m, a, buf, cs, bp, sc⟩
  • 201. A simple processor — Configurations 59 Configurations: State of the processor during computation Memory Registers Reorder 
 bu ff er Cache 
 (metadata) Branch 
 predictor Scheduler 😈 ⟨m, a, buf, cs, bp, sc⟩
  • 202. A simple processor — Semantics 60
  • 203. A simple processor — Semantics 60 Semantics: Describe how con fi gurations evolve
  • 204. A simple processor — Semantics 60 Semantics: Describe how con fi gurations evolve Hardware semantics We formalize the hardware semantics of a µASM program ng a binary relation ) ✓ HwStates ⇥ HwStates that ma dware states to their successors: STEP hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) hm,a,buf,cs,bp,sci)hm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i e rule captures one execution step at the µarch. level. T
  • 205. A simple processor — Semantics 60 Semantics: Describe how con fi gurations evolve Hardware semantics We formalize the hardware semantics of a µASM program ng a binary relation ) ✓ HwStates ⇥ HwStates that ma dware states to their successors: STEP hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) hm,a,buf,cs,bp,sci)hm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i e rule captures one execution step at the µarch. level. T Current state
  • 206. A simple processor — Semantics 60 Semantics: Describe how con fi gurations evolve Hardware semantics We formalize the hardware semantics of a µASM program ng a binary relation ) ✓ HwStates ⇥ HwStates that ma dware states to their successors: STEP hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) hm,a,buf,cs,bp,sci)hm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i e rule captures one execution step at the µarch. level. T Current state Next state
  • 207. A simple processor — Semantics 60 Semantics: Describe how con fi gurations evolve Hardware semantics We formalize the hardware semantics of a µASM program ng a binary relation ) ✓ HwStates ⇥ HwStates that ma dware states to their successors: STEP hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) hm,a,buf,cs,bp,sci)hm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i e rule captures one execution step at the µarch. level. T Current state Next state Directive from scheduler 
 fetch, execute i, retire
  • 208. A simple processor — Semantics 60 Semantics: Describe how con fi gurations evolve Hardware semantics We formalize the hardware semantics of a µASM program ng a binary relation ) ✓ HwStates ⇥ HwStates that ma dware states to their successors: STEP hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) hm,a,buf,cs,bp,sci)hm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i e rule captures one execution step at the µarch. level. T Current state Next state Directive from scheduler 
 fetch, execute i, retire Semantics for pipeline stages
  • 209. Rules capture effect of directives - Fetch 61 nents reted s) 2 ad- miss state that ocks ction edic- been ictor For each directive, i.e., fetch,execute i, and retire, we sketch below the rules that govern the definition of the auxiliary relations fetch = = ), execute i = = = = = ), and retire = = = ). 1) Fetch: Instructions are fetched in-order. Here we present selected rules modeling instruction fetch: FETCH-BRANCH-HIT a0 = apl(buf,a) |buf| < w a0 (pc) 6= ? p(a0 (pc)) = beqz x,` `0 = predict(bp,a0 (pc)) access(cs,a0 (pc)) = Hit update(cs,a0 (pc)) = cs0 hm,a,buf,cs,bpi fetch = = )hm,a,buf ·pc `0 @a0 (pc),cs0 ,bpi FETCH-MISS |buf| < w a0 = apl(buf,a) a0 (pc) 6= ? access(cs,a0 (pc)) = Miss update(cs,a0 (pc)) = cs0
  • 210. Rules capture effect of directives - Fetch 61 nents reted s) 2 ad- miss state that ocks ction edic- been ictor For each directive, i.e., fetch,execute i, and retire, we sketch below the rules that govern the definition of the auxiliary relations fetch = = ), execute i = = = = = ), and retire = = = ). 1) Fetch: Instructions are fetched in-order. Here we present selected rules modeling instruction fetch: FETCH-BRANCH-HIT a0 = apl(buf,a) |buf| < w a0 (pc) 6= ? p(a0 (pc)) = beqz x,` `0 = predict(bp,a0 (pc)) access(cs,a0 (pc)) = Hit update(cs,a0 (pc)) = cs0 hm,a,buf,cs,bpi fetch = = )hm,a,buf ·pc `0 @a0 (pc),cs0 ,bpi FETCH-MISS |buf| < w a0 = apl(buf,a) a0 (pc) 6= ? access(cs,a0 (pc)) = Miss update(cs,a0 (pc)) = cs0 applying reorder buffer 
 to register state
  • 211. Rules capture effect of directives - Fetch 61 nents reted s) 2 ad- miss state that ocks ction edic- been ictor For each directive, i.e., fetch,execute i, and retire, we sketch below the rules that govern the definition of the auxiliary relations fetch = = ), execute i = = = = = ), and retire = = = ). 1) Fetch: Instructions are fetched in-order. Here we present selected rules modeling instruction fetch: FETCH-BRANCH-HIT a0 = apl(buf,a) |buf| < w a0 (pc) 6= ? p(a0 (pc)) = beqz x,` `0 = predict(bp,a0 (pc)) access(cs,a0 (pc)) = Hit update(cs,a0 (pc)) = cs0 hm,a,buf,cs,bpi fetch = = )hm,a,buf ·pc `0 @a0 (pc),cs0 ,bpi FETCH-MISS |buf| < w a0 = apl(buf,a) a0 (pc) 6= ? access(cs,a0 (pc)) = Miss update(cs,a0 (pc)) = cs0 applying reorder buffer 
 to register state reorder buffer 
 is not full
  • 212. Rules capture effect of directives - Fetch 61 nents reted s) 2 ad- miss state that ocks ction edic- been ictor For each directive, i.e., fetch,execute i, and retire, we sketch below the rules that govern the definition of the auxiliary relations fetch = = ), execute i = = = = = ), and retire = = = ). 1) Fetch: Instructions are fetched in-order. Here we present selected rules modeling instruction fetch: FETCH-BRANCH-HIT a0 = apl(buf,a) |buf| < w a0 (pc) 6= ? p(a0 (pc)) = beqz x,` `0 = predict(bp,a0 (pc)) access(cs,a0 (pc)) = Hit update(cs,a0 (pc)) = cs0 hm,a,buf,cs,bpi fetch = = )hm,a,buf ·pc `0 @a0 (pc),cs0 ,bpi FETCH-MISS |buf| < w a0 = apl(buf,a) a0 (pc) 6= ? access(cs,a0 (pc)) = Miss update(cs,a0 (pc)) = cs0 instruction is a 
 branch instruction is a 
 branch applying reorder buffer 
 to register state reorder buffer 
 is not full
  • 213. Rules capture effect of directives - Fetch 61 nents reted s) 2 ad- miss state that ocks ction edic- been ictor For each directive, i.e., fetch,execute i, and retire, we sketch below the rules that govern the definition of the auxiliary relations fetch = = ), execute i = = = = = ), and retire = = = ). 1) Fetch: Instructions are fetched in-order. Here we present selected rules modeling instruction fetch: FETCH-BRANCH-HIT a0 = apl(buf,a) |buf| < w a0 (pc) 6= ? p(a0 (pc)) = beqz x,` `0 = predict(bp,a0 (pc)) access(cs,a0 (pc)) = Hit update(cs,a0 (pc)) = cs0 hm,a,buf,cs,bpi fetch = = )hm,a,buf ·pc `0 @a0 (pc),cs0 ,bpi FETCH-MISS |buf| < w a0 = apl(buf,a) a0 (pc) 6= ? access(cs,a0 (pc)) = Miss update(cs,a0 (pc)) = cs0 instruction is a 
 branch instruction is a 
 branch applying reorder buffer 
 to register state reorder buffer 
 is not full branch predictor 
 says is next ℓ′ 
  • 214. Rules capture effect of directives - Fetch 61 nents reted s) 2 ad- miss state that ocks ction edic- been ictor For each directive, i.e., fetch,execute i, and retire, we sketch below the rules that govern the definition of the auxiliary relations fetch = = ), execute i = = = = = ), and retire = = = ). 1) Fetch: Instructions are fetched in-order. Here we present selected rules modeling instruction fetch: FETCH-BRANCH-HIT a0 = apl(buf,a) |buf| < w a0 (pc) 6= ? p(a0 (pc)) = beqz x,` `0 = predict(bp,a0 (pc)) access(cs,a0 (pc)) = Hit update(cs,a0 (pc)) = cs0 hm,a,buf,cs,bpi fetch = = )hm,a,buf ·pc `0 @a0 (pc),cs0 ,bpi FETCH-MISS |buf| < w a0 = apl(buf,a) a0 (pc) 6= ? access(cs,a0 (pc)) = Miss update(cs,a0 (pc)) = cs0 instruction is a 
 branch instruction is a 
 branch applying reorder buffer 
 to register state reorder buffer 
 is not full branch predictor 
 says is next ℓ′  Cache hit 
 + updating 
 cache state
  • 215. Rules capture effect of directives - Fetch 61 nents reted s) 2 ad- miss state that ocks ction edic- been ictor For each directive, i.e., fetch,execute i, and retire, we sketch below the rules that govern the definition of the auxiliary relations fetch = = ), execute i = = = = = ), and retire = = = ). 1) Fetch: Instructions are fetched in-order. Here we present selected rules modeling instruction fetch: FETCH-BRANCH-HIT a0 = apl(buf,a) |buf| < w a0 (pc) 6= ? p(a0 (pc)) = beqz x,` `0 = predict(bp,a0 (pc)) access(cs,a0 (pc)) = Hit update(cs,a0 (pc)) = cs0 hm,a,buf,cs,bpi fetch = = )hm,a,buf ·pc `0 @a0 (pc),cs0 ,bpi FETCH-MISS |buf| < w a0 = apl(buf,a) a0 (pc) 6= ? access(cs,a0 (pc)) = Miss update(cs,a0 (pc)) = cs0 instruction is a 
 branch instruction is a 
 branch applying reorder buffer 
 to register state reorder buffer 
 is not full branch predictor 
 says is next ℓ′  Cache hit 
 + updating 
 cache state add change of pc to reorder buffer
  • 216. Rules capture effect of directive - Retire 62 retiring only commands i@T at the head of the reorder buffer where the instruction i has been resolved, and the tag T is e indicating that there are no unresolved predictions. Selected rules for the retire directive are given below: RETIRE-ASSIGNMENT buf = x v@e ·buf0 v 2 Vals hm,a,buf,cs,bpi retire = = = )hm,a[x 7! v],buf0 ,cs,bpi RETIRE-STORE buf = store v,n@e ·buf0 v,n 2 Vals update(cs,n) = cs0 retire 0 0
  • 217. Rules capture effect of directive - Retire 62 retiring only commands i@T at the head of the reorder buffer where the instruction i has been resolved, and the tag T is e indicating that there are no unresolved predictions. Selected rules for the retire directive are given below: RETIRE-ASSIGNMENT buf = x v@e ·buf0 v 2 Vals hm,a,buf,cs,bpi retire = = = )hm,a[x 7! v],buf0 ,cs,bpi RETIRE-STORE buf = store v,n@e ·buf0 v,n 2 Vals update(cs,n) = cs0 retire 0 0 result of instruction at head of 
 reorder buffer is resolved
  • 218. Rules capture effect of directive - Retire 62 retiring only commands i@T at the head of the reorder buffer where the instruction i has been resolved, and the tag T is e indicating that there are no unresolved predictions. Selected rules for the retire directive are given below: RETIRE-ASSIGNMENT buf = x v@e ·buf0 v 2 Vals hm,a,buf,cs,bpi retire = = = )hm,a[x 7! v],buf0 ,cs,bpi RETIRE-STORE buf = store v,n@e ·buf0 v,n 2 Vals update(cs,n) = cs0 retire 0 0 result of instruction at head of 
 reorder buffer is resolved apply change to registers 
 and remove entry from reorder buffer
  • 219. Eager load delay [Sakalis et al. 2019] 63 hm,a,buf,cs,bpi= )hm ,a ,buf ,cs ,bp i d = next(sc) sc0 = update(sc,buf0 #) d 2 {fetch,retire}_(d = execute i^buf|i 6= load x,e) hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i STEP-EAGER-DELAY hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) d = execute i buf|i = load x,e 8pc `@`0 2 buf[0..i 1]. `0 = e hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i and to selectively delay instruction tion. While these proposals slight are labelled and on the effects of the same building blocks and pro For this reason, we start by the Speculative Taint Tracking (S Data Access (NDA) [4] counterm a general extension to the hardwa for supporting taint-tracking schem izing a countermeasure inspired security guarantees, and we conc sure. This countermeasure consists in delaying loads until all sources of mis-speculation have been resolved. We remark that the hardware semantics of Section V supports speculation only over branch instructions. Therefore, we model the loadDelay countermeasure by preventing loads whenever there are pre- ceding, unresolved branch instructions in the reorder buffer. Using the terminology of [3], loads are delayed as long as they are under a so-called control-shadow. We formalize the loadDelay countermeasure by modifying the STEP rule of the hardware semantics as follows (changes are highlighted in blue): STEP-OTHERS hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) d 2 {fetch,retire}_(d = execute i^buf|i 6= load x,e) hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i STEP-EAGER-DELAY cution, and in addition, the progr speculative execution. This new countermeasure, leading to Theor Theorem 3. { |·| }loadDelay ` J·Kseq ct-p As the control flow during spe depend upon data previously lo security of the countermeasure can Theorem 4. { |·| }loadDelay ` J·K seq arc C. tt: Taint tracking of speculativ Recent work [4], [5] propose to and to selectively delay instruction tion. While these proposals slight are labelled and on the effects of the same building blocks and pro For this reason, we start by the Speculative Taint Tracking (S
  • 220. Eager load delay [Sakalis et al. 2019] 63 hm,a,buf,cs,bpi= )hm ,a ,buf ,cs ,bp i d = next(sc) sc0 = update(sc,buf0 #) d 2 {fetch,retire}_(d = execute i^buf|i 6= load x,e) hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i STEP-EAGER-DELAY hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) d = execute i buf|i = load x,e 8pc `@`0 2 buf[0..i 1]. `0 = e hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i and to selectively delay instruction tion. While these proposals slight are labelled and on the effects of the same building blocks and pro For this reason, we start by the Speculative Taint Tracking (S Data Access (NDA) [4] counterm a general extension to the hardwa for supporting taint-tracking schem izing a countermeasure inspired security guarantees, and we conc Loads are executed only if prior branch instructions are resolved sure. This countermeasure consists in delaying loads until all sources of mis-speculation have been resolved. We remark that the hardware semantics of Section V supports speculation only over branch instructions. Therefore, we model the loadDelay countermeasure by preventing loads whenever there are pre- ceding, unresolved branch instructions in the reorder buffer. Using the terminology of [3], loads are delayed as long as they are under a so-called control-shadow. We formalize the loadDelay countermeasure by modifying the STEP rule of the hardware semantics as follows (changes are highlighted in blue): STEP-OTHERS hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) d 2 {fetch,retire}_(d = execute i^buf|i 6= load x,e) hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i STEP-EAGER-DELAY cution, and in addition, the progr speculative execution. This new countermeasure, leading to Theor Theorem 3. { |·| }loadDelay ` J·Kseq ct-p As the control flow during spe depend upon data previously lo security of the countermeasure can Theorem 4. { |·| }loadDelay ` J·K seq arc C. tt: Taint tracking of speculativ Recent work [4], [5] propose to and to selectively delay instruction tion. While these proposals slight are labelled and on the effects of the same building blocks and pro For this reason, we start by the Speculative Taint Tracking (S
  • 221. Eager load delay [Sakalis et al. 2019] 63 hm,a,buf,cs,bpi= )hm ,a ,buf ,cs ,bp i d = next(sc) sc0 = update(sc,buf0 #) d 2 {fetch,retire}_(d = execute i^buf|i 6= load x,e) hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i STEP-EAGER-DELAY hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) d = execute i buf|i = load x,e 8pc `@`0 2 buf[0..i 1]. `0 = e hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i and to selectively delay instruction tion. While these proposals slight are labelled and on the effects of the same building blocks and pro For this reason, we start by the Speculative Taint Tracking (S Data Access (NDA) [4] counterm a general extension to the hardwa for supporting taint-tracking schem izing a countermeasure inspired security guarantees, and we conc Loads are executed only if prior branch instructions are resolved sure. This countermeasure consists in delaying loads until all sources of mis-speculation have been resolved. We remark that the hardware semantics of Section V supports speculation only over branch instructions. Therefore, we model the loadDelay countermeasure by preventing loads whenever there are pre- ceding, unresolved branch instructions in the reorder buffer. Using the terminology of [3], loads are delayed as long as they are under a so-called control-shadow. We formalize the loadDelay countermeasure by modifying the STEP rule of the hardware semantics as follows (changes are highlighted in blue): STEP-OTHERS hm,a,buf,cs,bpi d = )hm0 ,a0 ,buf0 ,cs0 ,bp0 i d = next(sc) sc0 = update(sc,buf0 #) d 2 {fetch,retire}_(d = execute i^buf|i 6= load x,e) hm,a,buf,cs,bp,sci)loadDelayhm0 ,a0 ,buf0 ,cs0 ,bp0 ,sc0 i STEP-EAGER-DELAY cution, and in addition, the progr speculative execution. This new countermeasure, leading to Theor Theorem 3. { |·| }loadDelay ` J·Kseq ct-p As the control flow during spe depend upon data previously lo security of the countermeasure can Theorem 4. { |·| }loadDelay ` J·K seq arc C. tt: Taint tracking of speculativ Recent work [4], [5] propose to and to selectively delay instruction tion. While these proposals slight are labelled and on the effects of the same building blocks and pro For this reason, we start by the Speculative Taint Tracking (S Everything else works as before
  • 222. Hw-level taint-tracking [Yu et al. 2019, Weisse et al. 2019] 64 modeled by d). We describe later how these functions can be instantiated to model STT and NDA. We formalize the tt countermeasure by modifying the STEP rule as follows (changes are highlighted in blue): STEP d = next(sc) buful = unlbl(buf,d) hm,a, buful ,cs,bpi d = )hm0 ,a0 , buf0 ul ,cs0 ,bp0 i sc0 = update(sc,buf0 #) buf0 = lbl(buf0 ul,buf,d) hm,a,buf,cs,bp,sci)tthm0 ,a0 buf0 ,cs0 ,bp0 ,sc0 i The rule differs from the standard STEP rule in three ways: • Entries in the reorder buffer are labelled. • Before activating a step in the pipeline, i.e., before apply- ing one step of d = ), we use the unlabeling function to derive an a transmit execute no • The la fies how ne labels are u – Newly f there is no they are la assignment unsafe dat labelled as All other n – Whenev labels are p – When w eliminating
  • 223. Hw-level taint-tracking [Yu et al. 2019, Weisse et al. 2019] 64 modeled by d). We describe later how these functions can be instantiated to model STT and NDA. We formalize the tt countermeasure by modifying the STEP rule as follows (changes are highlighted in blue): STEP d = next(sc) buful = unlbl(buf,d) hm,a, buful ,cs,bpi d = )hm0 ,a0 , buf0 ul ,cs0 ,bp0 i sc0 = update(sc,buf0 #) buf0 = lbl(buf0 ul,buf,d) hm,a,buf,cs,bp,sci)tthm0 ,a0 buf0 ,cs0 ,bp0 ,sc0 i The rule differs from the standard STEP rule in three ways: • Entries in the reorder buffer are labelled. • Before activating a step in the pipeline, i.e., before apply- ing one step of d = ), we use the unlabeling function to derive an a transmit execute no • The la fies how ne labels are u – Newly f there is no they are la assignment unsafe dat labelled as All other n – Whenev labels are p – When w eliminating Entries in the reorder buffer are labelled as safe/unsafe
  • 224. Hw-level taint-tracking [Yu et al. 2019, Weisse et al. 2019] 64 modeled by d). We describe later how these functions can be instantiated to model STT and NDA. We formalize the tt countermeasure by modifying the STEP rule as follows (changes are highlighted in blue): STEP d = next(sc) buful = unlbl(buf,d) hm,a, buful ,cs,bpi d = )hm0 ,a0 , buf0 ul ,cs0 ,bp0 i sc0 = update(sc,buf0 #) buf0 = lbl(buf0 ul,buf,d) hm,a,buf,cs,bp,sci)tthm0 ,a0 buf0 ,cs0 ,bp0 ,sc0 i The rule differs from the standard STEP rule in three ways: • Entries in the reorder buffer are labelled. • Before activating a step in the pipeline, i.e., before apply- ing one step of d = ), we use the unlabeling function to derive an a transmit execute no • The la fies how ne labels are u – Newly f there is no they are la assignment unsafe dat labelled as All other n – Whenev labels are p – When w eliminating Entries in the reorder buffer are labelled as safe/unsafe Derive unlabeled buffer 
 (hides information tagged 
 as unsafe)
  • 225. Hw-level taint-tracking [Yu et al. 2019, Weisse et al. 2019] 64 modeled by d). We describe later how these functions can be instantiated to model STT and NDA. We formalize the tt countermeasure by modifying the STEP rule as follows (changes are highlighted in blue): STEP d = next(sc) buful = unlbl(buf,d) hm,a, buful ,cs,bpi d = )hm0 ,a0 , buf0 ul ,cs0 ,bp0 i sc0 = update(sc,buf0 #) buf0 = lbl(buf0 ul,buf,d) hm,a,buf,cs,bp,sci)tthm0 ,a0 buf0 ,cs0 ,bp0 ,sc0 i The rule differs from the standard STEP rule in three ways: • Entries in the reorder buffer are labelled. • Before activating a step in the pipeline, i.e., before apply- ing one step of d = ), we use the unlabeling function to derive an a transmit execute no • The la fies how ne labels are u – Newly f there is no they are la assignment unsafe dat labelled as All other n – Whenev labels are p – When w eliminating Entries in the reorder buffer are labelled as safe/unsafe Derive unlabeled buffer 
 (hides information tagged 
 as unsafe) Computation on unlabeled buffer
  • 226. Hw-level taint-tracking [Yu et al. 2019, Weisse et al. 2019] 64 modeled by d). We describe later how these functions can be instantiated to model STT and NDA. We formalize the tt countermeasure by modifying the STEP rule as follows (changes are highlighted in blue): STEP d = next(sc) buful = unlbl(buf,d) hm,a, buful ,cs,bpi d = )hm0 ,a0 , buf0 ul ,cs0 ,bp0 i sc0 = update(sc,buf0 #) buf0 = lbl(buf0 ul,buf,d) hm,a,buf,cs,bp,sci)tthm0 ,a0 buf0 ,cs0 ,bp0 ,sc0 i The rule differs from the standard STEP rule in three ways: • Entries in the reorder buffer are labelled. • Before activating a step in the pipeline, i.e., before apply- ing one step of d = ), we use the unlabeling function to derive an a transmit execute no • The la fies how ne labels are u – Newly f there is no they are la assignment unsafe dat labelled as All other n – Whenev labels are p – When w eliminating Entries in the reorder buffer are labelled as safe/unsafe Update labels Derive unlabeled buffer 
 (hides information tagged 
 as unsafe) Computation on unlabeled buffer
  • 227. Constant-time Sandboxing Checking secure programming 27 [[⋅]]seq ct [[⋅]]seq arch [[⋅]]spec ct ✓ ✓ ✓ See paper for: security de fi nitions .. + NI wrt [[⋅]]seq arch .. + Speculative NI 
 [Guarnieri et al., S&P’20] .. + weak spec. NI
  • 228. Constant-time Sandboxing Checking secure programming 27 [[⋅]]seq ct [[⋅]]seq arch [[⋅]]spec ct ✓ ✓ ✓ See paper for: security de fi nitions .. + NI wrt [[⋅]]seq arch .. + Speculative NI 
 [Guarnieri et al., S&P’20] .. + weak spec. NI
  • 230. Background: Reorder buffer • Key hardware data structure for 
 out-of-order and speculative execution 66
  • 231. Background: Reorder buffer • Key hardware data structure for 
 out-of-order and speculative execution • Keeps track of “in- fl ight instructions” 66
  • 232. Background: Reorder buffer • Key hardware data structure for 
 out-of-order and speculative execution • Keeps track of “in- fl ight instructions” • Example: 66 Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: - - 3: - - … … … c ⟵ x < A_size beqz c, END L1: load t, A + x 
 load y, B + t END:
  • 233. Background: Reorder buffer • Key hardware data structure for 
 out-of-order and speculative execution • Keeps track of “in- fl ight instructions” • Example: 66 Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: - - 3: - - … … … c ⟵ x < A_size beqz c, END L1: load t, A + x 
 load y, B + t END: Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 1 3: - - … … … Speculative 
 Instruction Fetch
  • 234. Background: Reorder buffer • Key hardware data structure for 
 out-of-order and speculative execution • Keeps track of “in- fl ight instructions” • Example: 67 Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: - - 3: - - … … … c ⟵ x < A_size beqz c, END L1: load t, A + x 
 load y, B + t END: Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 1 3: load y, B + t 1 … … … Speculative 
 Instruction Fetch Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 1 3: - - … … …
  • 235. Background: Reorder buffer • Key hardware data structure for 
 out-of-order and speculative execution • Keeps track of “in- fl ight instructions” • Example: 68 Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: - - 3: - - … … … c ⟵ x < A_size beqz c, END L1: load t, A + x 
 load y, B + t END: Entry Instruction Control Dep. 0: c ⟵ 0 - 1: beqz c, END - 2: load t, A + x 1 3: load y, B + t 1 … … … Evaluate x < A_size Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 2 3: - - … … … Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 1 3: load y, B + t 1 … … …
  • 236. Background: Reorder buffer • Key hardware data structure for 
 out-of-order and speculative execution • Keeps track of “in- fl ight instructions” • Example: 69 Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: - - 3: - - … … … c ⟵ x < A_size beqz c, END L1: load t, A + x 
 load y, B + t END: Entry Instruction Control Dep. 0: c ⟵ 0 - 1: beqz c, END - 2: - - 3: - - … … … Rollback 
 mis-speculation Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 2 3: - - … … … Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 2 3: load y, B + t 2 … … … Entry Instruction Control Dep. 0: c ⟵ 0 - 1: beqz c, END - 2: load t, A + x 1 3: load y, B + t 1 … … …
  • 237. Background: Reorder buffer • Key hardware data structure for 
 out-of-order and speculative execution • Keeps track of “in- fl ight instructions” • Example: 70 Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: - - 3: - - … … … c ⟵ x < A_size beqz c, END L1: load t, A + x 
 load y, B + t END: Entry Instruction Control Dep. 0: beqz c, END - 1: - - 2: - - 3: - - … … … Retire Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 2 3: - - … … … Entry Instruction Control Dep. 0: c ⟵ x < A_size - 1: beqz c, END - 2: load t, A + x 2 3: load y, B + t 2 … … … Entry Instruction Control Dep. 0: c ⟵ 0 - 1: beqz c, END - 2: - - 3: - - … … …
  • 239. if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 72 Size of array A
  • 240. if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 72 Size of array A
  • 241. if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 72 Size of array A Branch predictor
  • 242. if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 72 Size of array A Branch predictor Prediction based on branch history & program structure
  • 243. if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 72 Size of array A Branch predictor Prediction based on branch history & program structure
  • 244. if (x < A_size) y = B[A[x]] Speculative execution + branch prediction 72 Size of array A Branch predictor Prediction based on branch history & program structure Wrong predicton? Rollback changes! Architectural (ISA) state Microarchitectural state
  • 246. Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] 73
  • 247. Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] 73
  • 248. Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] 73
  • 249. Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] 73 What is in A[128]? A_size=16 B[0]B[1] ... B
  • 250. Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 74 A_size=16 B[0]B[1] ... B
  • 251. Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 74 A_size=16 B[0]B[1] ... B
  • 252. Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 74 A_size=16 B[0]B[1] ... B
  • 253. Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 74 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
  • 254. B[A[128]] ] Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 74 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
  • 255. B[A[128]] ] Depends on A[128] Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 74 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
  • 256. B[A[128]] ] Depends on A[128] Persistent across speculations Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 74 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
  • 257. B[A[128]] ] Depends on A[128] Persistent across speculations Spectre V1 void f(int x) if (x < A_size) y = B[A[x]] What is in A[128]? 1) Train branch predicto r 2) Prepare cache 3) Run with x = 128 4) Extract from cache 74 B[A[128]] A_size=16 B[0]B[1] ... B B[A[128]]
  • 258. Secure programming — foundations 75
  • 259. Secure programming — foundations 75 Program is non-interferent wrt contract and policy 
 if for all arch. states , : if then p π σ σ′  σ ≈π σ′  (p, σ) = (p, σ′  )
  • 260. Secure programming — foundations 75 Program is non-interferent wrt contract and policy 
 if for all arch. states , : if then p π σ σ′  σ ≈π σ′  (p, σ) = (p, σ′  ) Specify secret data
  • 261. Secure programming — foundations 75 Program is non-interferent wrt contract and policy 
 if for all arch. states , : if then p π σ σ′  σ ≈π σ′  (p, σ) = (p, σ′  ) Specify secret data
  • 262. Secure programming — foundations 75 Program is non-interferent wrt contract and policy 
 if for all arch. states , : if then p π σ σ′  σ ≈π σ′  (p, σ) = (p, σ′  ) Specify secret data
  • 263. Secure programming — foundations 75 Program is non-interferent wrt contract and policy 
 if for all arch. states , : if then p π σ σ′  σ ≈π σ′  (p, σ) = (p, σ′  ) If is non-interferent wrt contract and policy , and hardware satis fi es , then 
 is non-interferent wrt hardware and policy 
 p π p π Specify secret data
  • 264. Secure programming — foundations 75 Program is non-interferent wrt contract and policy 
 if for all arch. states , : if then p π σ σ′  σ ≈π σ′  (p, σ) = (p, σ′  ) If is non-interferent wrt contract and policy , and hardware satis fi es , then 
 is non-interferent wrt hardware and policy 
 p π p π Specify secret data
  • 265. Secure programming — foundations 75 Program is non-interferent wrt contract and policy 
 if for all arch. states , : if then p π σ σ′  σ ≈π σ′  (p, σ) = (p, σ′  ) If is non-interferent wrt contract and policy , and hardware satis fi es , then 
 is non-interferent wrt hardware and policy 
 p π p π Specify secret data
  • 266. Secure programming — foundations 75 Program is non-interferent wrt contract and policy 
 if for all arch. states , : if then p π σ σ′  σ ≈π σ′  (p, σ) = (p, σ′  ) If is non-interferent wrt contract and policy , and hardware satis fi es , then 
 is non-interferent wrt hardware and policy 
 p π p π Specify secret data
  • 268. Constant-time 76 Traditional CT wrt policy non-interference wrt seq-ct and π ≡ π
  • 269. Constant-time 76 Traditional CT wrt policy non-interference wrt seq-ct and π ≡ π Control- fl ow and memory accesses 
 do not depend on secrets
  • 270. Constant-time 76 Traditional CT wrt policy non-interference wrt seq-ct and π ≡ π General CT wrt and non-interference wrt and π ≡ π Control- fl ow and memory accesses 
 do not depend on secrets
  • 272. Sandboxing 77 Traditional SB wrt policy non-interference wrt seq-arch and π ≡ π
  • 273. Sandboxing 77 Traditional SB wrt policy non-interference wrt seq-arch and π ≡ π Programs never access high memory locations (out-of-sandbox)
  • 274. Sandboxing 77 Traditional SB wrt policy non-interference wrt seq-arch and π ≡ π General SB wrt and 
 Traditional SB wrt + non-interference wrt and π ≡ π π Programs never access high memory locations (out-of-sandbox)
  • 275. Constant-time Sandboxing Checking secure programming 78 [[⋅]]seq ct [[⋅]]seq arch [[⋅]]spec ct Traditional CT .. + NI wrt [[⋅]]seq arch .. + speculative NI 
 [Guarnieri et al., S&P’20] Traditional SB Traditional SB .. + weak spec. NI
  • 276. Constant-time Sandboxing Checking secure programming 78 [[⋅]]seq ct [[⋅]]seq arch [[⋅]]spec ct Traditional CT .. + NI wrt [[⋅]]seq arch .. + speculative NI 
 [Guarnieri et al., S&P’20] Traditional SB Traditional SB .. + weak spec. NI