1 .. SPDX-License-Identifier: GPL-2.0
2
3 Speculative Return Stack Overflow (SRSO)
4 ========================================
5
6 This is a mitigation for the speculative retur
7 vulnerability found on AMD processors. The mec
8 known scenario of poisoning CPU functional uni
9 Buffer (BTB) and Return Address Predictor (RAP
10 tricking the elevated privilege domain (the ke
11 sensitive data.
12
13 AMD CPUs predict RET instructions using a Retu
14 Return Address Stack/Return Stack Buffer). In
15 CALL instruction (i.e., an instruction predict
16 not actually a CALL) can create an entry in th
17 to predict the target of a subsequent RET inst
18
19 The specific circumstances that lead to this v
20 but the concern is that an attacker can mis-tr
21 non-architectural CALL instructions in kernel
22 control the speculative target of a subsequent
23 leading to information disclosure via a specul
24
25 The issue is tracked under CVE-2023-20569.
26
27 Affected processors
28 -------------------
29
30 AMD Zen, generations 1-4. That is, all familie
31 processors have not been investigated.
32
33 System information and options
34 ------------------------------
35
36 First of all, it is required that the latest m
37 mitigations to be effective.
38
39 The sysfs file showing SRSO mitigation status
40
41 /sys/devices/system/cpu/vulnerabilities/spec
42
43 The possible values in this file are:
44
45 * 'Not affected':
46
47 The processor is not vulnerable
48
49 * 'Vulnerable':
50
51 The processor is vulnerable and no mitigati
52
53 * 'Vulnerable: No microcode':
54
55 The processor is vulnerable, no microcode e
56 functionality to address the vulnerability
57
58 * 'Vulnerable: Safe RET, no microcode':
59
60 The "Safe RET" mitigation (see below) has b
61 kernel, but the IBPB-extending microcode ha
62 space tasks may still be vulnerable.
63
64 * 'Vulnerable: Microcode, no safe RET':
65
66 Extended IBPB functionality microcode patch
67 not address User->Kernel and Guest->Host tr
68 does address User->User and VM->VM attack v
69
70 Note that User->User mitigation is controll
71 the Spectre v2 mitigation is selected:
72
73 * conditional IBPB:
74
75 where each process can select whether it
76 around it PR_SPEC_DISABLE/_ENABLE etc, s
77
78 * strict:
79
80 i.e., always on - by supplying spectre_v
81 command line
82
83 (spec_rstack_overflow=microcode)
84
85 * 'Mitigation: Safe RET':
86
87 Combined microcode/software mitigation. It
88 extended IBPB microcode patch functionality
89 User->Kernel and Guest->Host transitions pr
90
91 Selected by default or by spec_rstack_overf
92
93 * 'Mitigation: IBPB':
94
95 Similar protection as "safe RET" above but
96 privilege domain crossings (User->Kernel, G
97
98 (spec_rstack_overflow=ibpb)
99
100 * 'Mitigation: IBPB on VMEXIT':
101
102 Mitigation addressing the cloud provider sc
103 transitions only.
104
105 (spec_rstack_overflow=ibpb-vmexit)
106
107
108
109 In order to exploit vulnerability, an attacker
110
111 - gain local access on the machine
112
113 - break kASLR
114
115 - find gadgets in the running kernel in order
116
117 - potentially create and pin an additional wo
118 thread, depending on the microarchitecture
119
120 - run the exploit
121
122 Considering the performance implications of ea
123 default one is 'Mitigation: safe RET' which sh
124 attack vectors, including the local User->Kern
125
126 As always, the user is advised to keep her/his
127 applying software updates regularly.
128
129 The default setting will be reevaluated when n
130 new attack vectors appear.
131
132 As one can surmise, 'Mitigation: safe RET' doe
133 performance depending on the workload. If one
134 and does not want to suffer the performance im
135 disable the mitigation with spec_rstack_overfl
136
137 Similarly, 'Mitigation: IBPB' is another full
138 an indirect branch prediction barrier after ha
139 microcode patch for one's system. This mitigat
140 a performance cost.
141
142 Mitigation: Safe RET
143 --------------------
144
145 The mitigation works by ensuring all RET instr
146 a controlled location, similar to how speculat
147 retpoline sequence. To accomplish this, the _
148 the CPU to mispredict every function return us
149 sequence.
150
151 To ensure the safety of this mitigation, the k
152 safe return sequence is itself free from attac
153 and Zen4, this is accomplished by creating a B
154 untraining function srso_alias_untrain_ret() a
155 function srso_alias_safe_ret() which results i
156 poisoned BTB entry and using that safe one for
157
158 In older Zen1 and Zen2, this is accomplished u
159 technique similar to Retbleed one: srso_untrai
160 srso_safe_ret().
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.