1.. SPDX-License-Identifier: GPL-2.0
2
3Speculative Return Stack Overflow (SRSO)
4========================================
5
6This is a mitigation for the speculative return stack overflow (SRSO)
7vulnerability found on AMD processors. The mechanism is by now the well
8known scenario of poisoning CPU functional units - the Branch Target
9Buffer (BTB) and Return Address Predictor (RAP) in this case - and then
10tricking the elevated privilege domain (the kernel) into leaking
11sensitive data.
12
13AMD CPUs predict RET instructions using a Return Address Predictor (aka
14Return Address Stack/Return Stack Buffer). In some cases, a non-architectural
15CALL instruction (i.e., an instruction predicted to be a CALL but is
16not actually a CALL) can create an entry in the RAP which may be used
17to predict the target of a subsequent RET instruction.
18
19The specific circumstances that lead to this varies by microarchitecture
20but the concern is that an attacker can mis-train the CPU BTB to predict
21non-architectural CALL instructions in kernel space and use this to
22control the speculative target of a subsequent kernel RET, potentially
23leading to information disclosure via a speculative side-channel.
24
25The issue is tracked under CVE-2023-20569.
26
27Affected processors
28-------------------
29
30AMD Zen, generations 1-4. That is, all families 0x17 and 0x19. Older
31processors have not been investigated.
32
33System information and options
34------------------------------
35
36First of all, it is required that the latest microcode be loaded for
37mitigations to be effective.
38
39The sysfs file showing SRSO mitigation status is:
40
41  /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow
42
43The possible values in this file are:
44
45 * 'Not affected':
46
47   The processor is not vulnerable
48
49 * 'Vulnerable: no microcode':
50
51   The processor is vulnerable, no microcode extending IBPB
52   functionality to address the vulnerability has been applied.
53
54 * 'Mitigation: microcode':
55
56   Extended IBPB functionality microcode patch has been applied. It does
57   not address User->Kernel and Guest->Host transitions protection but it
58   does address User->User and VM->VM attack vectors.
59
60   Note that User->User mitigation is controlled by how the IBPB aspect in
61   the Spectre v2 mitigation is selected:
62
63    * conditional IBPB:
64
65      where each process can select whether it needs an IBPB issued
66      around it PR_SPEC_DISABLE/_ENABLE etc, see :doc:`spectre`
67
68    * strict:
69
70      i.e., always on - by supplying spectre_v2_user=on on the kernel
71      command line
72
73   (spec_rstack_overflow=microcode)
74
75 * 'Mitigation: safe RET':
76
77   Software-only mitigation. It complements the extended IBPB microcode
78   patch functionality by addressing User->Kernel and Guest->Host
79   transitions protection.
80
81   Selected by default or by spec_rstack_overflow=safe-ret
82
83 * 'Mitigation: IBPB':
84
85   Similar protection as "safe RET" above but employs an IBPB barrier on
86   privilege domain crossings (User->Kernel, Guest->Host).
87
88  (spec_rstack_overflow=ibpb)
89
90 * 'Mitigation: IBPB on VMEXIT':
91
92   Mitigation addressing the cloud provider scenario - the Guest->Host
93   transitions only.
94
95   (spec_rstack_overflow=ibpb-vmexit)
96
97
98
99In order to exploit vulnerability, an attacker needs to:
100
101 - gain local access on the machine
102
103 - break kASLR
104
105 - find gadgets in the running kernel in order to use them in the exploit
106
107 - potentially create and pin an additional workload on the sibling
108   thread, depending on the microarchitecture (not necessary on fam 0x19)
109
110 - run the exploit
111
112Considering the performance implications of each mitigation type, the
113default one is 'Mitigation: safe RET' which should take care of most
114attack vectors, including the local User->Kernel one.
115
116As always, the user is advised to keep her/his system up-to-date by
117applying software updates regularly.
118
119The default setting will be reevaluated when needed and especially when
120new attack vectors appear.
121
122As one can surmise, 'Mitigation: safe RET' does come at the cost of some
123performance depending on the workload. If one trusts her/his userspace
124and does not want to suffer the performance impact, one can always
125disable the mitigation with spec_rstack_overflow=off.
126
127Similarly, 'Mitigation: IBPB' is another full mitigation type employing
128an indrect branch prediction barrier after having applied the required
129microcode patch for one's system. This mitigation comes also at
130a performance cost.
131
132Mitigation: safe RET
133--------------------
134
135The mitigation works by ensuring all RET instructions speculate to
136a controlled location, similar to how speculation is controlled in the
137retpoline sequence.  To accomplish this, the __x86_return_thunk forces
138the CPU to mispredict every function return using a 'safe return'
139sequence.
140
141To ensure the safety of this mitigation, the kernel must ensure that the
142safe return sequence is itself free from attacker interference.  In Zen3
143and Zen4, this is accomplished by creating a BTB alias between the
144untraining function srso_untrain_ret_alias() and the safe return
145function srso_safe_ret_alias() which results in evicting a potentially
146poisoned BTB entry and using that safe one for all function returns.
147
148In older Zen1 and Zen2, this is accomplished using a reinterpretation
149technique similar to Retbleed one: srso_untrain_ret() and
150srso_safe_ret().
151