Commit 4c920576 authored by Josh Poimboeuf's avatar Josh Poimboeuf Committed by Thomas Gleixner

Documentation: Add swapgs description to the Spectre v1 documentation

Add documentation to the Spectre document about the new swapgs variant of
Spectre v1.
Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
parent 7a30bdd9
...@@ -41,10 +41,11 @@ Related CVEs ...@@ -41,10 +41,11 @@ Related CVEs
The following CVE entries describe Spectre variants: The following CVE entries describe Spectre variants:
============= ======================= ================= ============= ======================= ==========================
CVE-2017-5753 Bounds check bypass Spectre variant 1 CVE-2017-5753 Bounds check bypass Spectre variant 1
CVE-2017-5715 Branch target injection Spectre variant 2 CVE-2017-5715 Branch target injection Spectre variant 2
============= ======================= ================= CVE-2019-1125 Spectre v1 swapgs Spectre variant 1 (swapgs)
============= ======================= ==========================
Problem Problem
------- -------
...@@ -78,6 +79,13 @@ There are some extensions of Spectre variant 1 attacks for reading data ...@@ -78,6 +79,13 @@ There are some extensions of Spectre variant 1 attacks for reading data
over the network, see :ref:`[12] <spec_ref12>`. However such attacks over the network, see :ref:`[12] <spec_ref12>`. However such attacks
are difficult, low bandwidth, fragile, and are considered low risk. are difficult, low bandwidth, fragile, and are considered low risk.
Note that, despite "Bounds Check Bypass" name, Spectre variant 1 is not
only about user-controlled array bounds checks. It can affect any
conditional checks. The kernel entry code interrupt, exception, and NMI
handlers all have conditional swapgs checks. Those may be problematic
in the context of Spectre v1, as kernel code can speculatively run with
a user GS.
Spectre variant 2 (Branch Target Injection) Spectre variant 2 (Branch Target Injection)
------------------------------------------- -------------------------------------------
...@@ -132,6 +140,9 @@ not cover all possible attack vectors. ...@@ -132,6 +140,9 @@ not cover all possible attack vectors.
1. A user process attacking the kernel 1. A user process attacking the kernel
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Spectre variant 1
~~~~~~~~~~~~~~~~~
The attacker passes a parameter to the kernel via a register or The attacker passes a parameter to the kernel via a register or
via a known address in memory during a syscall. Such parameter may via a known address in memory during a syscall. Such parameter may
be used later by the kernel as an index to an array or to derive be used later by the kernel as an index to an array or to derive
...@@ -144,7 +155,40 @@ not cover all possible attack vectors. ...@@ -144,7 +155,40 @@ not cover all possible attack vectors.
potentially be influenced for Spectre attacks, new "nospec" accessor potentially be influenced for Spectre attacks, new "nospec" accessor
macros are used to prevent speculative loading of data. macros are used to prevent speculative loading of data.
Spectre variant 2 attacker can :ref:`poison <poison_btb>` the branch Spectre variant 1 (swapgs)
~~~~~~~~~~~~~~~~~~~~~~~~~~
An attacker can train the branch predictor to speculatively skip the
swapgs path for an interrupt or exception. If they initialize
the GS register to a user-space value, if the swapgs is speculatively
skipped, subsequent GS-related percpu accesses in the speculation
window will be done with the attacker-controlled GS value. This
could cause privileged memory to be accessed and leaked.
For example:
::
if (coming from user space)
swapgs
mov %gs:<percpu_offset>, %reg
mov (%reg), %reg1
When coming from user space, the CPU can speculatively skip the
swapgs, and then do a speculative percpu load using the user GS
value. So the user can speculatively force a read of any kernel
value. If a gadget exists which uses the percpu value as an address
in another load/store, then the contents of the kernel value may
become visible via an L1 side channel attack.
A similar attack exists when coming from kernel space. The CPU can
speculatively do the swapgs, causing the user GS to get used for the
rest of the speculative window.
Spectre variant 2
~~~~~~~~~~~~~~~~~
A spectre variant 2 attacker can :ref:`poison <poison_btb>` the branch
target buffer (BTB) before issuing syscall to launch an attack. target buffer (BTB) before issuing syscall to launch an attack.
After entering the kernel, the kernel could use the poisoned branch After entering the kernel, the kernel could use the poisoned branch
target buffer on indirect jump and jump to gadget code in speculative target buffer on indirect jump and jump to gadget code in speculative
...@@ -280,11 +324,18 @@ The sysfs file showing Spectre variant 1 mitigation status is: ...@@ -280,11 +324,18 @@ The sysfs file showing Spectre variant 1 mitigation status is:
The possible values in this file are: The possible values in this file are:
======================================= ================================= .. list-table::
'Mitigation: __user pointer sanitation' Protection in kernel on a case by
case base with explicit pointer * - 'Not affected'
sanitation. - The processor is not vulnerable.
======================================= ================================= * - 'Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers'
- The swapgs protections are disabled; otherwise it has
protection in the kernel on a case by case base with explicit
pointer sanitation and usercopy LFENCE barriers.
* - 'Mitigation: usercopy/swapgs barriers and __user pointer sanitization'
- Protection in the kernel on a case by case base with explicit
pointer sanitation, usercopy LFENCE barriers, and swapgs LFENCE
barriers.
However, the protections are put in place on a case by case basis, However, the protections are put in place on a case by case basis,
and there is no guarantee that all possible attack vectors for Spectre and there is no guarantee that all possible attack vectors for Spectre
...@@ -366,12 +417,27 @@ Turning on mitigation for Spectre variant 1 and Spectre variant 2 ...@@ -366,12 +417,27 @@ Turning on mitigation for Spectre variant 1 and Spectre variant 2
1. Kernel mitigation 1. Kernel mitigation
^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^
Spectre variant 1
~~~~~~~~~~~~~~~~~
For the Spectre variant 1, vulnerable kernel code (as determined For the Spectre variant 1, vulnerable kernel code (as determined
by code audit or scanning tools) is annotated on a case by case by code audit or scanning tools) is annotated on a case by case
basis to use nospec accessor macros for bounds clipping :ref:`[2] basis to use nospec accessor macros for bounds clipping :ref:`[2]
<spec_ref2>` to avoid any usable disclosure gadgets. However, it may <spec_ref2>` to avoid any usable disclosure gadgets. However, it may
not cover all attack vectors for Spectre variant 1. not cover all attack vectors for Spectre variant 1.
Copy-from-user code has an LFENCE barrier to prevent the access_ok()
check from being mis-speculated. The barrier is done by the
barrier_nospec() macro.
For the swapgs variant of Spectre variant 1, LFENCE barriers are
added to interrupt, exception and NMI entry where needed. These
barriers are done by the FENCE_SWAPGS_KERNEL_ENTRY and
FENCE_SWAPGS_USER_ENTRY macros.
Spectre variant 2
~~~~~~~~~~~~~~~~~
For Spectre variant 2 mitigation, the compiler turns indirect calls or For Spectre variant 2 mitigation, the compiler turns indirect calls or
jumps in the kernel into equivalent return trampolines (retpolines) jumps in the kernel into equivalent return trampolines (retpolines)
:ref:`[3] <spec_ref3>` :ref:`[9] <spec_ref9>` to go to the target :ref:`[3] <spec_ref3>` :ref:`[9] <spec_ref9>` to go to the target
...@@ -473,6 +539,12 @@ Mitigation control on the kernel command line ...@@ -473,6 +539,12 @@ Mitigation control on the kernel command line
Spectre variant 2 mitigation can be disabled or force enabled at the Spectre variant 2 mitigation can be disabled or force enabled at the
kernel command line. kernel command line.
nospectre_v1
[X86,PPC] Disable mitigations for Spectre Variant 1
(bounds check bypass). With this option data leaks are
possible in the system.
nospectre_v2 nospectre_v2
[X86] Disable all mitigations for the Spectre variant 2 [X86] Disable all mitigations for the Spectre variant 2
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment