Skip to content

Commit 83f6665

Browse files
jpoimboeIngo Molnar
jpoimboe
authored and
Ingo Molnar
committed
x86/bugs: Add RSB mitigation document
Create a document to summarize hard-earned knowledge about RSB-related mitigations, with references, and replace the overly verbose yet incomplete comments with a reference to the document. Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/ab73f4659ba697a974759f07befd41ae605e33dd.1744148254.git.jpoimboe@kernel.org
1 parent 27ce829 commit 83f6665

File tree

3 files changed

+282
-51
lines changed

3 files changed

+282
-51
lines changed

‎Documentation/admin-guide/hw-vuln/index.rst

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -22,3 +22,4 @@ are configurable at compile, boot or run time.
2222
srso
2323
gather_data_sampling
2424
reg-file-data-sampling
25+
rsb

‎Documentation/admin-guide/hw-vuln/rsb.rst

Lines changed: 268 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,268 @@
1+
.. SPDX-License-Identifier: GPL-2.0
2+
3+
=======================
4+
RSB-related mitigations
5+
=======================
6+
7+
.. warning::
8+
Please keep this document up-to-date, otherwise you will be
9+
volunteered to update it and convert it to a very long comment in
10+
bugs.c!
11+
12+
Since 2018 there have been many Spectre CVEs related to the Return Stack
13+
Buffer (RSB) (sometimes referred to as the Return Address Stack (RAS) or
14+
Return Address Predictor (RAP) on AMD).
15+
16+
Information about these CVEs and how to mitigate them is scattered
17+
amongst a myriad of microarchitecture-specific documents.
18+
19+
This document attempts to consolidate all the relevant information in
20+
once place and clarify the reasoning behind the current RSB-related
21+
mitigations. It's meant to be as concise as possible, focused only on
22+
the current kernel mitigations: what are the RSB-related attack vectors
23+
and how are they currently being mitigated?
24+
25+
It's *not* meant to describe how the RSB mechanism operates or how the
26+
exploits work. More details about those can be found in the references
27+
below.
28+
29+
Rather, this is basically a glorified comment, but too long to actually
30+
be one. So when the next CVE comes along, a kernel developer can
31+
quickly refer to this as a refresher to see what we're actually doing
32+
and why.
33+
34+
At a high level, there are two classes of RSB attacks: RSB poisoning
35+
(Intel and AMD) and RSB underflow (Intel only). They must each be
36+
considered individually for each attack vector (and microarchitecture
37+
where applicable).
38+
39+
----
40+
41+
RSB poisoning (Intel and AMD)
42+
=============================
43+
44+
SpectreRSB
45+
~~~~~~~~~~
46+
47+
RSB poisoning is a technique used by SpectreRSB [#spectre-rsb]_ where
48+
an attacker poisons an RSB entry to cause a victim's return instruction
49+
to speculate to an attacker-controlled address. This can happen when
50+
there are unbalanced CALLs/RETs after a context switch or VMEXIT.
51+
52+
* All attack vectors can potentially be mitigated by flushing out any
53+
poisoned RSB entries using an RSB filling sequence
54+
[#intel-rsb-filling]_ [#amd-rsb-filling]_ when transitioning between
55+
untrusted and trusted domains. But this has a performance impact and
56+
should be avoided whenever possible.
57+
58+
.. DANGER::
59+
**FIXME**: Currently we're flushing 32 entries. However, some CPU
60+
models have more than 32 entries. The loop count needs to be
61+
increased for those. More detailed information is needed about RSB
62+
sizes.
63+
64+
* On context switch, the user->user mitigation requires ensuring the
65+
RSB gets filled or cleared whenever IBPB gets written [#cond-ibpb]_
66+
during a context switch:
67+
68+
* AMD:
69+
On Zen 4+, IBPB (or SBPB [#amd-sbpb]_ if used) clears the RSB.
70+
This is indicated by IBPB_RET in CPUID [#amd-ibpb-rsb]_.
71+
72+
On Zen < 4, the RSB filling sequence [#amd-rsb-filling]_ must be
73+
always be done in addition to IBPB [#amd-ibpb-no-rsb]_. This is
74+
indicated by X86_BUG_IBPB_NO_RET.
75+
76+
* Intel:
77+
IBPB always clears the RSB:
78+
79+
"Software that executed before the IBPB command cannot control
80+
the predicted targets of indirect branches executed after the
81+
command on the same logical processor. The term indirect branch
82+
in this context includes near return instructions, so these
83+
predicted targets may come from the RSB." [#intel-ibpb-rsb]_
84+
85+
* On context switch, user->kernel attacks are prevented by SMEP. User
86+
space can only insert user space addresses into the RSB. Even
87+
non-canonical addresses can't be inserted due to the page gap at the
88+
end of the user canonical address space reserved by TASK_SIZE_MAX.
89+
A SMEP #PF at instruction fetch prevents the kernel from speculatively
90+
executing user space.
91+
92+
* AMD:
93+
"Finally, branches that are predicted as 'ret' instructions get
94+
their predicted targets from the Return Address Predictor (RAP).
95+
AMD recommends software use a RAP stuffing sequence (mitigation
96+
V2-3 in [2]) and/or Supervisor Mode Execution Protection (SMEP)
97+
to ensure that the addresses in the RAP are safe for
98+
speculation. Collectively, we refer to these mitigations as "RAP
99+
Protection"." [#amd-smep-rsb]_
100+
101+
* Intel:
102+
"On processors with enhanced IBRS, an RSB overwrite sequence may
103+
not suffice to prevent the predicted target of a near return
104+
from using an RSB entry created in a less privileged predictor
105+
mode. Software can prevent this by enabling SMEP (for
106+
transitions from user mode to supervisor mode) and by having
107+
IA32_SPEC_CTRL.IBRS set during VM exits." [#intel-smep-rsb]_
108+
109+
* On VMEXIT, guest->host attacks are mitigated by eIBRS (and PBRSB
110+
mitigation if needed):
111+
112+
* AMD:
113+
"When Automatic IBRS is enabled, the internal return address
114+
stack used for return address predictions is cleared on VMEXIT."
115+
[#amd-eibrs-vmexit]_
116+
117+
* Intel:
118+
"On processors with enhanced IBRS, an RSB overwrite sequence may
119+
not suffice to prevent the predicted target of a near return
120+
from using an RSB entry created in a less privileged predictor
121+
mode. Software can prevent this by enabling SMEP (for
122+
transitions from user mode to supervisor mode) and by having
123+
IA32_SPEC_CTRL.IBRS set during VM exits. Processors with
124+
enhanced IBRS still support the usage model where IBRS is set
125+
only in the OS/VMM for OSes that enable SMEP. To do this, such
126+
processors will ensure that guest behavior cannot control the
127+
RSB after a VM exit once IBRS is set, even if IBRS was not set
128+
at the time of the VM exit." [#intel-eibrs-vmexit]_
129+
130+
Note that some Intel CPUs are susceptible to Post-barrier Return
131+
Stack Buffer Predictions (PBRSB) [#intel-pbrsb]_, where the last
132+
CALL from the guest can be used to predict the first unbalanced RET.
133+
In this case the PBRSB mitigation is needed in addition to eIBRS.
134+
135+
AMD RETBleed / SRSO / Branch Type Confusion
136+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
137+
138+
On AMD, poisoned RSB entries can also be created by the AMD RETBleed
139+
variant [#retbleed-paper]_ [#amd-btc]_ or by Speculative Return Stack
140+
Overflow [#amd-srso]_ (Inception [#inception-paper]_). The kernel
141+
protects itself by replacing every RET in the kernel with a branch to a
142+
single safe RET.
143+
144+
----
145+
146+
RSB underflow (Intel only)
147+
==========================
148+
149+
RSB Alternate (RSBA) ("Intel Retbleed")
150+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
151+
152+
Some Intel Skylake-generation CPUs are susceptible to the Intel variant
153+
of RETBleed [#retbleed-paper]_ (Return Stack Buffer Underflow
154+
[#intel-rsbu]_). If a RET is executed when the RSB buffer is empty due
155+
to mismatched CALLs/RETs or returning from a deep call stack, the branch
156+
predictor can fall back to using the Branch Target Buffer (BTB). If a
157+
user forces a BTB collision then the RET can speculatively branch to a
158+
user-controlled address.
159+
160+
* Note that RSB filling doesn't fully mitigate this issue. If there
161+
are enough unbalanced RETs, the RSB may still underflow and fall back
162+
to using a poisoned BTB entry.
163+
164+
* On context switch, user->user underflow attacks are mitigated by the
165+
conditional IBPB [#cond-ibpb]_ on context switch which effectively
166+
clears the BTB:
167+
168+
* "The indirect branch predictor barrier (IBPB) is an indirect branch
169+
control mechanism that establishes a barrier, preventing software
170+
that executed before the barrier from controlling the predicted
171+
targets of indirect branches executed after the barrier on the same
172+
logical processor." [#intel-ibpb-btb]_
173+
174+
* On context switch and VMEXIT, user->kernel and guest->host RSB
175+
underflows are mitigated by IBRS or eIBRS:
176+
177+
* "Enabling IBRS (including enhanced IBRS) will mitigate the "RSBU"
178+
attack demonstrated by the researchers. As previously documented,
179+
Intel recommends the use of enhanced IBRS, where supported. This
180+
includes any processor that enumerates RRSBA but not RRSBA_DIS_S."
181+
[#intel-rsbu]_
182+
183+
However, note that eIBRS and IBRS do not mitigate intra-mode attacks.
184+
Like RRSBA below, this is mitigated by clearing the BHB on kernel
185+
entry.
186+
187+
As an alternative to classic IBRS, call depth tracking (combined with
188+
retpolines) can be used to track kernel returns and fill the RSB when
189+
it gets close to being empty.
190+
191+
Restricted RSB Alternate (RRSBA)
192+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
193+
194+
Some newer Intel CPUs have Restricted RSB Alternate (RRSBA) behavior,
195+
which, similar to RSBA described above, also falls back to using the BTB
196+
on RSB underflow. The only difference is that the predicted targets are
197+
restricted to the current domain when eIBRS is enabled:
198+
199+
* "Restricted RSB Alternate (RRSBA) behavior allows alternate branch
200+
predictors to be used by near RET instructions when the RSB is
201+
empty. When eIBRS is enabled, the predicted targets of these
202+
alternate predictors are restricted to those belonging to the
203+
indirect branch predictor entries of the current prediction domain.
204+
[#intel-eibrs-rrsba]_
205+
206+
When a CPU with RRSBA is vulnerable to Branch History Injection
207+
[#bhi-paper]_ [#intel-bhi]_, an RSB underflow could be used for an
208+
intra-mode BTI attack. This is mitigated by clearing the BHB on
209+
kernel entry.
210+
211+
However if the kernel uses retpolines instead of eIBRS, it needs to
212+
disable RRSBA:
213+
214+
* "Where software is using retpoline as a mitigation for BHI or
215+
intra-mode BTI, and the processor both enumerates RRSBA and
216+
enumerates RRSBA_DIS controls, it should disable this behavior."
217+
[#intel-retpoline-rrsba]_
218+
219+
----
220+
221+
References
222+
==========
223+
224+
.. [#spectre-rsb] `Spectre Returns! Speculation Attacks using the Return Stack Buffer <https://arxiv.org/pdf/1807.07940.pdf>`_
225+
226+
.. [#intel-rsb-filling] "Empty RSB Mitigation on Skylake-generation" in `Retpoline: A Branch Target Injection Mitigation <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/retpoline-branch-target-injection-mitigation.html#inpage-nav-5-1>`_
227+
228+
.. [#amd-rsb-filling] "Mitigation V2-3" in `Software Techniques for Managing Speculation <https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/software-techniques-for-managing-speculation.pdf>`_
229+
230+
.. [#cond-ibpb] Whether IBPB is written depends on whether the prev and/or next task is protected from Spectre attacks. It typically requires opting in per task or system-wide. For more details see the documentation for the ``spectre_v2_user`` cmdline option in Documentation/admin-guide/kernel-parameters.txt.
231+
232+
.. [#amd-sbpb] IBPB without flushing of branch type predictions. Only exists for AMD.
233+
234+
.. [#amd-ibpb-rsb] "Function 8000_0008h -- Processor Capacity Parameters and Extended Feature Identification" in `AMD64 Architecture Programmer's Manual Volume 3: General-Purpose and System Instructions <https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24594.pdf>`_. SBPB behaves the same way according to `this email <https://lore.kernel.org/5175b163a3736ca5fd01cedf406735636c99a>`_.
235+
236+
.. [#amd-ibpb-no-rsb] `Spectre Attacks: Exploiting Speculative Execution <https://comsec.ethz.ch/wp-content/files/ibpb_sp25.pdf>`_
237+
238+
.. [#intel-ibpb-rsb] "Introduction" in `Post-barrier Return Stack Buffer Predictions / CVE-2022-26373 / INTEL-SA-00706 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/post-barrier-return-stack-buffer-predictions.html>`_
239+
240+
.. [#amd-smep-rsb] "Existing Mitigations" in `Technical Guidance for Mitigating Branch Type Confusion <https://www.amd.com/content/dam/amd/en/documents/resources/technical-guidance-for-mitigating-branch-type-confusion.pdf>`_
241+
242+
.. [#intel-smep-rsb] "Enhanced IBRS" in `Indirect Branch Restricted Speculation <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/indirect-branch-restricted-speculation.html>`_
243+
244+
.. [#amd-eibrs-vmexit] "Extended Feature Enable Register (EFER)" in `AMD64 Architecture Programmer's Manual Volume 2: System Programming <https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24593.pdf>`_
245+
246+
.. [#intel-eibrs-vmexit] "Enhanced IBRS" in `Indirect Branch Restricted Speculation <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/indirect-branch-restricted-speculation.html>`_
247+
248+
.. [#intel-pbrsb] `Post-barrier Return Stack Buffer Predictions / CVE-2022-26373 / INTEL-SA-00706 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/post-barrier-return-stack-buffer-predictions.html>`_
249+
250+
.. [#retbleed-paper] `RETBleed: Arbitrary Speculative Code Execution with Return Instruction <https://comsec.ethz.ch/wp-content/files/retbleed_sec22.pdf>`_
251+
252+
.. [#amd-btc] `Technical Guidance for Mitigating Branch Type Confusion <https://www.amd.com/content/dam/amd/en/documents/resources/technical-guidance-for-mitigating-branch-type-confusion.pdf>`_
253+
254+
.. [#amd-srso] `Technical Update Regarding Speculative Return Stack Overflow <https://www.amd.com/content/dam/amd/en/documents/corporate/cr/speculative-return-stack-overflow-whitepaper.pdf>`_
255+
256+
.. [#inception-paper] `Inception: Exposing New Attack Surfaces with Training in Transient Execution <https://comsec.ethz.ch/wp-content/files/inception_sec23.pdf>`_
257+
258+
.. [#intel-rsbu] `Return Stack Buffer Underflow / Return Stack Buffer Underflow / CVE-2022-29901, CVE-2022-28693 / INTEL-SA-00702 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/return-stack-buffer-underflow.html>`_
259+
260+
.. [#intel-ibpb-btb] `Indirect Branch Predictor Barrier' <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/indirect-branch-predictor-barrier.html>`_
261+
262+
.. [#intel-eibrs-rrsba] "Guidance for RSBU" in `Return Stack Buffer Underflow / Return Stack Buffer Underflow / CVE-2022-29901, CVE-2022-28693 / INTEL-SA-00702 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/return-stack-buffer-underflow.html>`_
263+
264+
.. [#bhi-paper] `Branch History Injection: On the Effectiveness of Hardware Mitigations Against Cross-Privilege Spectre-v2 Attacks <http://download.vusec.net/papers/bhi-spectre-bhb_sec22.pdf>`_
265+
266+
.. [#intel-bhi] `Branch History Injection and Intra-mode Branch Target Injection / CVE-2022-0001, CVE-2022-0002 / INTEL-SA-00598 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html>`_
267+
268+
.. [#intel-retpoline-rrsba] "Retpoline" in `Branch History Injection and Intra-mode Branch Target Injection / CVE-2022-0001, CVE-2022-0002 / INTEL-SA-00598 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html>`_

‎arch/x86/kernel/cpu/bugs.c

Lines changed: 13 additions & 51 deletions
Original file line numberDiff line numberDiff line change
@@ -1594,25 +1594,25 @@ static void __init spec_ctrl_disable_kernel_rrsba(void)
15941594
static void __init spectre_v2_select_rsb_mitigation(enum spectre_v2_mitigation mode)
15951595
{
15961596
/*
1597-
* Similar to context switches, there are two types of RSB attacks
1598-
* after VM exit:
1597+
* WARNING! There are many subtleties to consider when changing *any*
1598+
* code related to RSB-related mitigations. Before doing so, carefully
1599+
* read the following document, and update if necessary:
15991600
*
1600-
* 1) RSB underflow
1601+
* Documentation/admin-guide/hw-vuln/rsb.rst
16011602
*
1602-
* 2) Poisoned RSB entry
1603+
* In an overly simplified nutshell:
16031604
*
1604-
* When retpoline is enabled, both are mitigated by filling/clearing
1605-
* the RSB.
1605+
* - User->user RSB attacks are conditionally mitigated during
1606+
* context switches by cond_mitigation -> write_ibpb().
16061607
*
1607-
* When IBRS is enabled, while #1 would be mitigated by the IBRS branch
1608-
* prediction isolation protections, RSB still needs to be cleared
1609-
* because of #2. Note that SMEP provides no protection here, unlike
1610-
* user-space-poisoned RSB entries.
1608+
* - User->kernel and guest->host attacks are mitigated by eIBRS or
1609+
* RSB filling.
16111610
*
1612-
* eIBRS should protect against RSB poisoning, but if the EIBRS_PBRSB
1613-
* bug is present then a LITE version of RSB protection is required,
1614-
* just a single call needs to retire before a RET is executed.
1611+
* Though, depending on config, note that other alternative
1612+
* mitigations may end up getting used instead, e.g., IBPB on
1613+
* entry/vmexit, call depth tracking, or return thunks.
16151614
*/
1615+
16161616
switch (mode) {
16171617
case SPECTRE_V2_NONE:
16181618
break;
@@ -1832,44 +1832,6 @@ static void __init spectre_v2_select_mitigation(void)
18321832
spectre_v2_enabled = mode;
18331833
pr_info("%s\n", spectre_v2_strings[mode]);
18341834

1835-
/*
1836-
* If Spectre v2 protection has been enabled, fill the RSB during a
1837-
* context switch. In general there are two types of RSB attacks
1838-
* across context switches, for which the CALLs/RETs may be unbalanced.
1839-
*
1840-
* 1) RSB underflow
1841-
*
1842-
* Some Intel parts have "bottomless RSB". When the RSB is empty,
1843-
* speculated return targets may come from the branch predictor,
1844-
* which could have a user-poisoned BTB or BHB entry.
1845-
*
1846-
* AMD has it even worse: *all* returns are speculated from the BTB,
1847-
* regardless of the state of the RSB.
1848-
*
1849-
* When IBRS or eIBRS is enabled, the "user -> kernel" attack
1850-
* scenario is mitigated by the IBRS branch prediction isolation
1851-
* properties, so the RSB buffer filling wouldn't be necessary to
1852-
* protect against this type of attack.
1853-
*
1854-
* The "user -> user" attack scenario is mitigated by RSB filling.
1855-
*
1856-
* 2) Poisoned RSB entry
1857-
*
1858-
* If the 'next' in-kernel return stack is shorter than 'prev',
1859-
* 'next' could be tricked into speculating with a user-poisoned RSB
1860-
* entry.
1861-
*
1862-
* The "user -> kernel" attack scenario is mitigated by SMEP and
1863-
* eIBRS.
1864-
*
1865-
* The "user -> user" scenario, also known as SpectreBHB, requires
1866-
* RSB clearing.
1867-
*
1868-
* So to mitigate all cases, unconditionally fill RSB on context
1869-
* switches.
1870-
*
1871-
* FIXME: Is this pointless for retbleed-affected AMD?
1872-
*/
18731835
spectre_v2_select_rsb_mitigation(mode);
18741836

18751837
/*

0 commit comments

Comments
 (0)