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. 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