Skip to content

Commit 45eb291

Browse files
bonzinibonzini
committed
Merge branch 'kvm-fixes-6.15-rc4' into HEAD
* Single fix for broken usage of 'multi-MIDR' infrastructure in PI code, adding an open-coded erratum check for Cavium ThunderX * Bugfixes from a planned posted interrupt rework * Do not use kvm_rip_read() unconditionally to cater for guests with inaccessible register state.
2 parents fd02aa4 + 2d71249 commit 45eb291

File tree

411 files changed

+4710
-2295
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

411 files changed

+4710
-2295
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>`_

‎Documentation/admin-guide/kernel-parameters.txt

Lines changed: 1 addition & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1407,18 +1407,15 @@
14071407
earlyprintk=serial[,0x...[,baudrate]]
14081408
earlyprintk=ttySn[,baudrate]
14091409
earlyprintk=dbgp[debugController#]
1410+
earlyprintk=mmio32,membase[,{nocfg|baudrate}]
14101411
earlyprintk=pciserial[,force],bus:device.function[,{nocfg|baudrate}]
14111412
earlyprintk=xdbc[xhciController#]
14121413
earlyprintk=bios
1413-
earlyprintk=mmio,membase[,{nocfg|baudrate}]
14141414

14151415
earlyprintk is useful when the kernel crashes before
14161416
the normal console is initialized. It is not enabled by
14171417
default because it has some cosmetic problems.
14181418

1419-
Only 32-bit memory addresses are supported for "mmio"
1420-
and "pciserial" devices.
1421-
14221419
Use "nocfg" to skip UART configuration, assume
14231420
BIOS/firmware has configured UART correctly.
14241421

0 commit comments

Comments
 (0)