diff --git a/debian/changelog b/debian/changelog index e779672d2..44f396424 100644 --- a/debian/changelog +++ b/debian/changelog @@ -14,6 +14,17 @@ linux (4.19.37-5+deb10u2) UNRELEASED; urgency=medium * Bluetooth: hci_uart: check for missing tty operations (CVE-2019-10207) * [powerpc/tm] Fix oops on sigreturn on systems without TM (CVE-2019-13648) + [ Salvatore Bonaccorso ] + * [x86] cpufeatures: Carve out CQM features retrieval + * [x86] cpufeatures: Combine word 11 and 12 into a new scattered features + word + * [x86] speculation: Prepare entry code for Spectre v1 swapgs mitigations + * [x86] speculation: Enable Spectre v1 swapgs mitigations (CVE-2019-1125) + * [amd64] entry: Use JMP instead of JMPQ + * [x86] speculation/swapgs: Exclude ATOMs from speculation through SWAPGS + * Documentation: Add section about CPU vulnerabilities for Spectre + * Documentation: Add swapgs description to the Spectre v1 documentation + -- Romain Perier Mon, 22 Jul 2019 14:00:00 +0200 linux (4.19.37-5+deb10u1) buster-security; urgency=high diff --git a/debian/patches/bugfix/all/Documentation-Add-section-about-CPU-vulnerabilities-.patch b/debian/patches/bugfix/all/Documentation-Add-section-about-CPU-vulnerabilities-.patch new file mode 100644 index 000000000..9fe5341ef --- /dev/null +++ b/debian/patches/bugfix/all/Documentation-Add-section-about-CPU-vulnerabilities-.patch @@ -0,0 +1,760 @@ +From: Tim Chen +Date: Thu, 20 Jun 2019 16:10:50 -0700 +Subject: Documentation: Add section about CPU vulnerabilities for Spectre +Origin: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8a815007f5fe292fa8ef082663e1259b9ae0571b + +commit 6e88559470f581741bcd0f2794f9054814ac9740 upstream. + +Add documentation for Spectre vulnerability and the mitigation mechanisms: + +- Explain the problem and risks +- Document the mitigation mechanisms +- Document the command line controls +- Document the sysfs files + +Co-developed-by: Andi Kleen +Signed-off-by: Andi Kleen +Co-developed-by: Tim Chen +Signed-off-by: Tim Chen +Reviewed-by: Randy Dunlap +Reviewed-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Signed-off-by: Jonathan Corbet +Signed-off-by: Greg Kroah-Hartman +--- + Documentation/admin-guide/hw-vuln/index.rst | 1 + + Documentation/admin-guide/hw-vuln/spectre.rst | 697 ++++++++++++++++++ + Documentation/userspace-api/spec_ctrl.rst | 2 + + 3 files changed, 700 insertions(+) + create mode 100644 Documentation/admin-guide/hw-vuln/spectre.rst + +diff --git a/Documentation/admin-guide/hw-vuln/index.rst b/Documentation/admin-guide/hw-vuln/index.rst +index ffc064c1ec68..49311f3da6f2 100644 +--- a/Documentation/admin-guide/hw-vuln/index.rst ++++ b/Documentation/admin-guide/hw-vuln/index.rst +@@ -9,5 +9,6 @@ are configurable at compile, boot or run time. + .. toctree:: + :maxdepth: 1 + ++ spectre + l1tf + mds +diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst b/Documentation/admin-guide/hw-vuln/spectre.rst +new file mode 100644 +index 000000000000..25f3b2532198 +--- /dev/null ++++ b/Documentation/admin-guide/hw-vuln/spectre.rst +@@ -0,0 +1,697 @@ ++.. SPDX-License-Identifier: GPL-2.0 ++ ++Spectre Side Channels ++===================== ++ ++Spectre is a class of side channel attacks that exploit branch prediction ++and speculative execution on modern CPUs to read memory, possibly ++bypassing access controls. Speculative execution side channel exploits ++do not modify memory but attempt to infer privileged data in the memory. ++ ++This document covers Spectre variant 1 and Spectre variant 2. ++ ++Affected processors ++------------------- ++ ++Speculative execution side channel methods affect a wide range of modern ++high performance processors, since most modern high speed processors ++use branch prediction and speculative execution. ++ ++The following CPUs are vulnerable: ++ ++ - Intel Core, Atom, Pentium, and Xeon processors ++ ++ - AMD Phenom, EPYC, and Zen processors ++ ++ - IBM POWER and zSeries processors ++ ++ - Higher end ARM processors ++ ++ - Apple CPUs ++ ++ - Higher end MIPS CPUs ++ ++ - Likely most other high performance CPUs. Contact your CPU vendor for details. ++ ++Whether a processor is affected or not can be read out from the Spectre ++vulnerability files in sysfs. See :ref:`spectre_sys_info`. ++ ++Related CVEs ++------------ ++ ++The following CVE entries describe Spectre variants: ++ ++ ============= ======================= ================= ++ CVE-2017-5753 Bounds check bypass Spectre variant 1 ++ CVE-2017-5715 Branch target injection Spectre variant 2 ++ ============= ======================= ================= ++ ++Problem ++------- ++ ++CPUs use speculative operations to improve performance. That may leave ++traces of memory accesses or computations in the processor's caches, ++buffers, and branch predictors. Malicious software may be able to ++influence the speculative execution paths, and then use the side effects ++of the speculative execution in the CPUs' caches and buffers to infer ++privileged data touched during the speculative execution. ++ ++Spectre variant 1 attacks take advantage of speculative execution of ++conditional branches, while Spectre variant 2 attacks use speculative ++execution of indirect branches to leak privileged memory. ++See :ref:`[1] ` :ref:`[5] ` :ref:`[7] ` ++:ref:`[10] ` :ref:`[11] `. ++ ++Spectre variant 1 (Bounds Check Bypass) ++--------------------------------------- ++ ++The bounds check bypass attack :ref:`[2] ` takes advantage ++of speculative execution that bypasses conditional branch instructions ++used for memory access bounds check (e.g. checking if the index of an ++array results in memory access within a valid range). This results in ++memory accesses to invalid memory (with out-of-bound index) that are ++done speculatively before validation checks resolve. Such speculative ++memory accesses can leave side effects, creating side channels which ++leak information to the attacker. ++ ++There are some extensions of Spectre variant 1 attacks for reading data ++over the network, see :ref:`[12] `. However such attacks ++are difficult, low bandwidth, fragile, and are considered low risk. ++ ++Spectre variant 2 (Branch Target Injection) ++------------------------------------------- ++ ++The branch target injection attack takes advantage of speculative ++execution of indirect branches :ref:`[3] `. The indirect ++branch predictors inside the processor used to guess the target of ++indirect branches can be influenced by an attacker, causing gadget code ++to be speculatively executed, thus exposing sensitive data touched by ++the victim. The side effects left in the CPU's caches during speculative ++execution can be measured to infer data values. ++ ++.. _poison_btb: ++ ++In Spectre variant 2 attacks, the attacker can steer speculative indirect ++branches in the victim to gadget code by poisoning the branch target ++buffer of a CPU used for predicting indirect branch addresses. Such ++poisoning could be done by indirect branching into existing code, ++with the address offset of the indirect branch under the attacker's ++control. Since the branch prediction on impacted hardware does not ++fully disambiguate branch address and uses the offset for prediction, ++this could cause privileged code's indirect branch to jump to a gadget ++code with the same offset. ++ ++The most useful gadgets take an attacker-controlled input parameter (such ++as a register value) so that the memory read can be controlled. Gadgets ++without input parameters might be possible, but the attacker would have ++very little control over what memory can be read, reducing the risk of ++the attack revealing useful data. ++ ++One other variant 2 attack vector is for the attacker to poison the ++return stack buffer (RSB) :ref:`[13] ` to cause speculative ++subroutine return instruction execution to go to a gadget. An attacker's ++imbalanced subroutine call instructions might "poison" entries in the ++return stack buffer which are later consumed by a victim's subroutine ++return instructions. This attack can be mitigated by flushing the return ++stack buffer on context switch, or virtual machine (VM) exit. ++ ++On systems with simultaneous multi-threading (SMT), attacks are possible ++from the sibling thread, as level 1 cache and branch target buffer ++(BTB) may be shared between hardware threads in a CPU core. A malicious ++program running on the sibling thread may influence its peer's BTB to ++steer its indirect branch speculations to gadget code, and measure the ++speculative execution's side effects left in level 1 cache to infer the ++victim's data. ++ ++Attack scenarios ++---------------- ++ ++The following list of attack scenarios have been anticipated, but may ++not cover all possible attack vectors. ++ ++1. A user process attacking the kernel ++^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ++ ++ The attacker passes a parameter to the kernel via a register or ++ 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 ++ a pointer for a Spectre variant 1 attack. The index or pointer ++ is invalid, but bound checks are bypassed in the code branch taken ++ for speculative execution. This could cause privileged memory to be ++ accessed and leaked. ++ ++ For kernel code that has been identified where data pointers could ++ potentially be influenced for Spectre attacks, new "nospec" accessor ++ macros are used to prevent speculative loading of data. ++ ++ Spectre variant 2 attacker can :ref:`poison ` the branch ++ target buffer (BTB) before issuing syscall to launch an attack. ++ After entering the kernel, the kernel could use the poisoned branch ++ target buffer on indirect jump and jump to gadget code in speculative ++ execution. ++ ++ If an attacker tries to control the memory addresses leaked during ++ speculative execution, he would also need to pass a parameter to the ++ gadget, either through a register or a known address in memory. After ++ the gadget has executed, he can measure the side effect. ++ ++ The kernel can protect itself against consuming poisoned branch ++ target buffer entries by using return trampolines (also known as ++ "retpoline") :ref:`[3] ` :ref:`[9] ` for all ++ indirect branches. Return trampolines trap speculative execution paths ++ to prevent jumping to gadget code during speculative execution. ++ x86 CPUs with Enhanced Indirect Branch Restricted Speculation ++ (Enhanced IBRS) available in hardware should use the feature to ++ mitigate Spectre variant 2 instead of retpoline. Enhanced IBRS is ++ more efficient than retpoline. ++ ++ There may be gadget code in firmware which could be exploited with ++ Spectre variant 2 attack by a rogue user process. To mitigate such ++ attacks on x86, Indirect Branch Restricted Speculation (IBRS) feature ++ is turned on before the kernel invokes any firmware code. ++ ++2. A user process attacking another user process ++^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ++ ++ A malicious user process can try to attack another user process, ++ either via a context switch on the same hardware thread, or from the ++ sibling hyperthread sharing a physical processor core on simultaneous ++ multi-threading (SMT) system. ++ ++ Spectre variant 1 attacks generally require passing parameters ++ between the processes, which needs a data passing relationship, such ++ as remote procedure calls (RPC). Those parameters are used in gadget ++ code to derive invalid data pointers accessing privileged memory in ++ the attacked process. ++ ++ Spectre variant 2 attacks can be launched from a rogue process by ++ :ref:`poisoning ` the branch target buffer. This can ++ influence the indirect branch targets for a victim process that either ++ runs later on the same hardware thread, or running concurrently on ++ a sibling hardware thread sharing the same physical core. ++ ++ A user process can protect itself against Spectre variant 2 attacks ++ by using the prctl() syscall to disable indirect branch speculation ++ for itself. An administrator can also cordon off an unsafe process ++ from polluting the branch target buffer by disabling the process's ++ indirect branch speculation. This comes with a performance cost ++ from not using indirect branch speculation and clearing the branch ++ target buffer. When SMT is enabled on x86, for a process that has ++ indirect branch speculation disabled, Single Threaded Indirect Branch ++ Predictors (STIBP) :ref:`[4] ` are turned on to prevent the ++ sibling thread from controlling branch target buffer. In addition, ++ the Indirect Branch Prediction Barrier (IBPB) is issued to clear the ++ branch target buffer when context switching to and from such process. ++ ++ On x86, the return stack buffer is stuffed on context switch. ++ This prevents the branch target buffer from being used for branch ++ prediction when the return stack buffer underflows while switching to ++ a deeper call stack. Any poisoned entries in the return stack buffer ++ left by the previous process will also be cleared. ++ ++ User programs should use address space randomization to make attacks ++ more difficult (Set /proc/sys/kernel/randomize_va_space = 1 or 2). ++ ++3. A virtualized guest attacking the host ++^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ++ ++ The attack mechanism is similar to how user processes attack the ++ kernel. The kernel is entered via hyper-calls or other virtualization ++ exit paths. ++ ++ For Spectre variant 1 attacks, rogue guests can pass parameters ++ (e.g. in registers) via hyper-calls to derive invalid pointers to ++ speculate into privileged memory after entering the kernel. For places ++ where such kernel code has been identified, nospec accessor macros ++ are used to stop speculative memory access. ++ ++ For Spectre variant 2 attacks, rogue guests can :ref:`poison ++ ` the branch target buffer or return stack buffer, causing ++ the kernel to jump to gadget code in the speculative execution paths. ++ ++ To mitigate variant 2, the host kernel can use return trampolines ++ for indirect branches to bypass the poisoned branch target buffer, ++ and flushing the return stack buffer on VM exit. This prevents rogue ++ guests from affecting indirect branching in the host kernel. ++ ++ To protect host processes from rogue guests, host processes can have ++ indirect branch speculation disabled via prctl(). The branch target ++ buffer is cleared before context switching to such processes. ++ ++4. A virtualized guest attacking other guest ++^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ++ ++ A rogue guest may attack another guest to get data accessible by the ++ other guest. ++ ++ Spectre variant 1 attacks are possible if parameters can be passed ++ between guests. This may be done via mechanisms such as shared memory ++ or message passing. Such parameters could be used to derive data ++ pointers to privileged data in guest. The privileged data could be ++ accessed by gadget code in the victim's speculation paths. ++ ++ Spectre variant 2 attacks can be launched from a rogue guest by ++ :ref:`poisoning ` the branch target buffer or the return ++ stack buffer. Such poisoned entries could be used to influence ++ speculation execution paths in the victim guest. ++ ++ Linux kernel mitigates attacks to other guests running in the same ++ CPU hardware thread by flushing the return stack buffer on VM exit, ++ and clearing the branch target buffer before switching to a new guest. ++ ++ If SMT is used, Spectre variant 2 attacks from an untrusted guest ++ in the sibling hyperthread can be mitigated by the administrator, ++ by turning off the unsafe guest's indirect branch speculation via ++ prctl(). A guest can also protect itself by turning on microcode ++ based mitigations (such as IBPB or STIBP on x86) within the guest. ++ ++.. _spectre_sys_info: ++ ++Spectre system information ++-------------------------- ++ ++The Linux kernel provides a sysfs interface to enumerate the current ++mitigation status of the system for Spectre: whether the system is ++vulnerable, and which mitigations are active. ++ ++The sysfs file showing Spectre variant 1 mitigation status is: ++ ++ /sys/devices/system/cpu/vulnerabilities/spectre_v1 ++ ++The possible values in this file are: ++ ++ ======================================= ================================= ++ 'Mitigation: __user pointer sanitation' Protection in kernel on a case by ++ case base with explicit pointer ++ sanitation. ++ ======================================= ================================= ++ ++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 ++variant 1 are covered. ++ ++The spectre_v2 kernel file reports if the kernel has been compiled with ++retpoline mitigation or if the CPU has hardware mitigation, and if the ++CPU has support for additional process-specific mitigation. ++ ++This file also reports CPU features enabled by microcode to mitigate ++attack between user processes: ++ ++1. Indirect Branch Prediction Barrier (IBPB) to add additional ++ isolation between processes of different users. ++2. Single Thread Indirect Branch Predictors (STIBP) to add additional ++ isolation between CPU threads running on the same core. ++ ++These CPU features may impact performance when used and can be enabled ++per process on a case-by-case base. ++ ++The sysfs file showing Spectre variant 2 mitigation status is: ++ ++ /sys/devices/system/cpu/vulnerabilities/spectre_v2 ++ ++The possible values in this file are: ++ ++ - Kernel status: ++ ++ ==================================== ================================= ++ 'Not affected' The processor is not vulnerable ++ 'Vulnerable' Vulnerable, no mitigation ++ 'Mitigation: Full generic retpoline' Software-focused mitigation ++ 'Mitigation: Full AMD retpoline' AMD-specific software mitigation ++ 'Mitigation: Enhanced IBRS' Hardware-focused mitigation ++ ==================================== ================================= ++ ++ - Firmware status: Show if Indirect Branch Restricted Speculation (IBRS) is ++ used to protect against Spectre variant 2 attacks when calling firmware (x86 only). ++ ++ ========== ============================================================= ++ 'IBRS_FW' Protection against user program attacks when calling firmware ++ ========== ============================================================= ++ ++ - Indirect branch prediction barrier (IBPB) status for protection between ++ processes of different users. This feature can be controlled through ++ prctl() per process, or through kernel command line options. This is ++ an x86 only feature. For more details see below. ++ ++ =================== ======================================================== ++ 'IBPB: disabled' IBPB unused ++ 'IBPB: always-on' Use IBPB on all tasks ++ 'IBPB: conditional' Use IBPB on SECCOMP or indirect branch restricted tasks ++ =================== ======================================================== ++ ++ - Single threaded indirect branch prediction (STIBP) status for protection ++ between different hyper threads. This feature can be controlled through ++ prctl per process, or through kernel command line options. This is x86 ++ only feature. For more details see below. ++ ++ ==================== ======================================================== ++ 'STIBP: disabled' STIBP unused ++ 'STIBP: forced' Use STIBP on all tasks ++ 'STIBP: conditional' Use STIBP on SECCOMP or indirect branch restricted tasks ++ ==================== ======================================================== ++ ++ - Return stack buffer (RSB) protection status: ++ ++ ============= =========================================== ++ 'RSB filling' Protection of RSB on context switch enabled ++ ============= =========================================== ++ ++Full mitigation might require a microcode update from the CPU ++vendor. When the necessary microcode is not available, the kernel will ++report vulnerability. ++ ++Turning on mitigation for Spectre variant 1 and Spectre variant 2 ++----------------------------------------------------------------- ++ ++1. Kernel mitigation ++^^^^^^^^^^^^^^^^^^^^ ++ ++ For the Spectre variant 1, vulnerable kernel code (as determined ++ by code audit or scanning tools) is annotated on a case by case ++ basis to use nospec accessor macros for bounds clipping :ref:`[2] ++ ` to avoid any usable disclosure gadgets. However, it may ++ not cover all attack vectors for Spectre variant 1. ++ ++ For Spectre variant 2 mitigation, the compiler turns indirect calls or ++ jumps in the kernel into equivalent return trampolines (retpolines) ++ :ref:`[3] ` :ref:`[9] ` to go to the target ++ addresses. Speculative execution paths under retpolines are trapped ++ in an infinite loop to prevent any speculative execution jumping to ++ a gadget. ++ ++ To turn on retpoline mitigation on a vulnerable CPU, the kernel ++ needs to be compiled with a gcc compiler that supports the ++ -mindirect-branch=thunk-extern -mindirect-branch-register options. ++ If the kernel is compiled with a Clang compiler, the compiler needs ++ to support -mretpoline-external-thunk option. The kernel config ++ CONFIG_RETPOLINE needs to be turned on, and the CPU needs to run with ++ the latest updated microcode. ++ ++ On Intel Skylake-era systems the mitigation covers most, but not all, ++ cases. See :ref:`[3] ` for more details. ++ ++ On CPUs with hardware mitigation for Spectre variant 2 (e.g. Enhanced ++ IBRS on x86), retpoline is automatically disabled at run time. ++ ++ The retpoline mitigation is turned on by default on vulnerable ++ CPUs. It can be forced on or off by the administrator ++ via the kernel command line and sysfs control files. See ++ :ref:`spectre_mitigation_control_command_line`. ++ ++ On x86, indirect branch restricted speculation is turned on by default ++ before invoking any firmware code to prevent Spectre variant 2 exploits ++ using the firmware. ++ ++ Using kernel address space randomization (CONFIG_RANDOMIZE_SLAB=y ++ and CONFIG_SLAB_FREELIST_RANDOM=y in the kernel configuration) makes ++ attacks on the kernel generally more difficult. ++ ++2. User program mitigation ++^^^^^^^^^^^^^^^^^^^^^^^^^^ ++ ++ User programs can mitigate Spectre variant 1 using LFENCE or "bounds ++ clipping". For more details see :ref:`[2] `. ++ ++ For Spectre variant 2 mitigation, individual user programs ++ can be compiled with return trampolines for indirect branches. ++ This protects them from consuming poisoned entries in the branch ++ target buffer left by malicious software. Alternatively, the ++ programs can disable their indirect branch speculation via prctl() ++ (See :ref:`Documentation/userspace-api/spec_ctrl.rst `). ++ On x86, this will turn on STIBP to guard against attacks from the ++ sibling thread when the user program is running, and use IBPB to ++ flush the branch target buffer when switching to/from the program. ++ ++ Restricting indirect branch speculation on a user program will ++ also prevent the program from launching a variant 2 attack ++ on x86. All sand-boxed SECCOMP programs have indirect branch ++ speculation restricted by default. Administrators can change ++ that behavior via the kernel command line and sysfs control files. ++ See :ref:`spectre_mitigation_control_command_line`. ++ ++ Programs that disable their indirect branch speculation will have ++ more overhead and run slower. ++ ++ User programs should use address space randomization ++ (/proc/sys/kernel/randomize_va_space = 1 or 2) to make attacks more ++ difficult. ++ ++3. VM mitigation ++^^^^^^^^^^^^^^^^ ++ ++ Within the kernel, Spectre variant 1 attacks from rogue guests are ++ mitigated on a case by case basis in VM exit paths. Vulnerable code ++ uses nospec accessor macros for "bounds clipping", to avoid any ++ usable disclosure gadgets. However, this may not cover all variant ++ 1 attack vectors. ++ ++ For Spectre variant 2 attacks from rogue guests to the kernel, the ++ Linux kernel uses retpoline or Enhanced IBRS to prevent consumption of ++ poisoned entries in branch target buffer left by rogue guests. It also ++ flushes the return stack buffer on every VM exit to prevent a return ++ stack buffer underflow so poisoned branch target buffer could be used, ++ or attacker guests leaving poisoned entries in the return stack buffer. ++ ++ To mitigate guest-to-guest attacks in the same CPU hardware thread, ++ the branch target buffer is sanitized by flushing before switching ++ to a new guest on a CPU. ++ ++ The above mitigations are turned on by default on vulnerable CPUs. ++ ++ To mitigate guest-to-guest attacks from sibling thread when SMT is ++ in use, an untrusted guest running in the sibling thread can have ++ its indirect branch speculation disabled by administrator via prctl(). ++ ++ The kernel also allows guests to use any microcode based mitigation ++ they choose to use (such as IBPB or STIBP on x86) to protect themselves. ++ ++.. _spectre_mitigation_control_command_line: ++ ++Mitigation control on the kernel command line ++--------------------------------------------- ++ ++Spectre variant 2 mitigation can be disabled or force enabled at the ++kernel command line. ++ ++ nospectre_v2 ++ ++ [X86] Disable all mitigations for the Spectre variant 2 ++ (indirect branch prediction) vulnerability. System may ++ allow data leaks with this option, which is equivalent ++ to spectre_v2=off. ++ ++ ++ spectre_v2= ++ ++ [X86] Control mitigation of Spectre variant 2 ++ (indirect branch speculation) vulnerability. ++ The default operation protects the kernel from ++ user space attacks. ++ ++ on ++ unconditionally enable, implies ++ spectre_v2_user=on ++ off ++ unconditionally disable, implies ++ spectre_v2_user=off ++ auto ++ kernel detects whether your CPU model is ++ vulnerable ++ ++ Selecting 'on' will, and 'auto' may, choose a ++ mitigation method at run time according to the ++ CPU, the available microcode, the setting of the ++ CONFIG_RETPOLINE configuration option, and the ++ compiler with which the kernel was built. ++ ++ Selecting 'on' will also enable the mitigation ++ against user space to user space task attacks. ++ ++ Selecting 'off' will disable both the kernel and ++ the user space protections. ++ ++ Specific mitigations can also be selected manually: ++ ++ retpoline ++ replace indirect branches ++ retpoline,generic ++ google's original retpoline ++ retpoline,amd ++ AMD-specific minimal thunk ++ ++ Not specifying this option is equivalent to ++ spectre_v2=auto. ++ ++For user space mitigation: ++ ++ spectre_v2_user= ++ ++ [X86] Control mitigation of Spectre variant 2 ++ (indirect branch speculation) vulnerability between ++ user space tasks ++ ++ on ++ Unconditionally enable mitigations. Is ++ enforced by spectre_v2=on ++ ++ off ++ Unconditionally disable mitigations. Is ++ enforced by spectre_v2=off ++ ++ prctl ++ Indirect branch speculation is enabled, ++ but mitigation can be enabled via prctl ++ per thread. The mitigation control state ++ is inherited on fork. ++ ++ prctl,ibpb ++ Like "prctl" above, but only STIBP is ++ controlled per thread. IBPB is issued ++ always when switching between different user ++ space processes. ++ ++ seccomp ++ Same as "prctl" above, but all seccomp ++ threads will enable the mitigation unless ++ they explicitly opt out. ++ ++ seccomp,ibpb ++ Like "seccomp" above, but only STIBP is ++ controlled per thread. IBPB is issued ++ always when switching between different ++ user space processes. ++ ++ auto ++ Kernel selects the mitigation depending on ++ the available CPU features and vulnerability. ++ ++ Default mitigation: ++ If CONFIG_SECCOMP=y then "seccomp", otherwise "prctl" ++ ++ Not specifying this option is equivalent to ++ spectre_v2_user=auto. ++ ++ In general the kernel by default selects ++ reasonable mitigations for the current CPU. To ++ disable Spectre variant 2 mitigations, boot with ++ spectre_v2=off. Spectre variant 1 mitigations ++ cannot be disabled. ++ ++Mitigation selection guide ++-------------------------- ++ ++1. Trusted userspace ++^^^^^^^^^^^^^^^^^^^^ ++ ++ If all userspace applications are from trusted sources and do not ++ execute externally supplied untrusted code, then the mitigations can ++ be disabled. ++ ++2. Protect sensitive programs ++^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ++ ++ For security-sensitive programs that have secrets (e.g. crypto ++ keys), protection against Spectre variant 2 can be put in place by ++ disabling indirect branch speculation when the program is running ++ (See :ref:`Documentation/userspace-api/spec_ctrl.rst `). ++ ++3. Sandbox untrusted programs ++^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ++ ++ Untrusted programs that could be a source of attacks can be cordoned ++ off by disabling their indirect branch speculation when they are run ++ (See :ref:`Documentation/userspace-api/spec_ctrl.rst `). ++ This prevents untrusted programs from polluting the branch target ++ buffer. All programs running in SECCOMP sandboxes have indirect ++ branch speculation restricted by default. This behavior can be ++ changed via the kernel command line and sysfs control files. See ++ :ref:`spectre_mitigation_control_command_line`. ++ ++3. High security mode ++^^^^^^^^^^^^^^^^^^^^^ ++ ++ All Spectre variant 2 mitigations can be forced on ++ at boot time for all programs (See the "on" option in ++ :ref:`spectre_mitigation_control_command_line`). This will add ++ overhead as indirect branch speculations for all programs will be ++ restricted. ++ ++ On x86, branch target buffer will be flushed with IBPB when switching ++ to a new program. STIBP is left on all the time to protect programs ++ against variant 2 attacks originating from programs running on ++ sibling threads. ++ ++ Alternatively, STIBP can be used only when running programs ++ whose indirect branch speculation is explicitly disabled, ++ while IBPB is still used all the time when switching to a new ++ program to clear the branch target buffer (See "ibpb" option in ++ :ref:`spectre_mitigation_control_command_line`). This "ibpb" option ++ has less performance cost than the "on" option, which leaves STIBP ++ on all the time. ++ ++References on Spectre ++--------------------- ++ ++Intel white papers: ++ ++.. _spec_ref1: ++ ++[1] `Intel analysis of speculative execution side channels `_. ++ ++.. _spec_ref2: ++ ++[2] `Bounds check bypass `_. ++ ++.. _spec_ref3: ++ ++[3] `Deep dive: Retpoline: A branch target injection mitigation `_. ++ ++.. _spec_ref4: ++ ++[4] `Deep Dive: Single Thread Indirect Branch Predictors `_. ++ ++AMD white papers: ++ ++.. _spec_ref5: ++ ++[5] `AMD64 technology indirect branch control extension `_. ++ ++.. _spec_ref6: ++ ++[6] `Software techniques for managing speculation on AMD processors `_. ++ ++ARM white papers: ++ ++.. _spec_ref7: ++ ++[7] `Cache speculation side-channels `_. ++ ++.. _spec_ref8: ++ ++[8] `Cache speculation issues update `_. ++ ++Google white paper: ++ ++.. _spec_ref9: ++ ++[9] `Retpoline: a software construct for preventing branch-target-injection `_. ++ ++MIPS white paper: ++ ++.. _spec_ref10: ++ ++[10] `MIPS: response on speculative execution and side channel vulnerabilities `_. ++ ++Academic papers: ++ ++.. _spec_ref11: ++ ++[11] `Spectre Attacks: Exploiting Speculative Execution `_. ++ ++.. _spec_ref12: ++ ++[12] `NetSpectre: Read Arbitrary Memory over Network `_. ++ ++.. _spec_ref13: ++ ++[13] `Spectre Returns! Speculation Attacks using the Return Stack Buffer `_. +diff --git a/Documentation/userspace-api/spec_ctrl.rst b/Documentation/userspace-api/spec_ctrl.rst +index c4dbe6f7cdae..0fda8f614110 100644 +--- a/Documentation/userspace-api/spec_ctrl.rst ++++ b/Documentation/userspace-api/spec_ctrl.rst +@@ -47,6 +47,8 @@ If PR_SPEC_PRCTL is set, then the per-task control of the mitigation is + available. If not set, prctl(PR_SET_SPECULATION_CTRL) for the speculation + misfeature will fail. + ++.. _set_spec_ctrl: ++ + PR_SET_SPECULATION_CTRL + ----------------------- + +-- +2.20.1 + diff --git a/debian/patches/bugfix/all/Documentation-Add-swapgs-description-to-the-Spectre-.patch b/debian/patches/bugfix/all/Documentation-Add-swapgs-description-to-the-Spectre-.patch new file mode 100644 index 000000000..4513a1dca --- /dev/null +++ b/debian/patches/bugfix/all/Documentation-Add-swapgs-description-to-the-Spectre-.patch @@ -0,0 +1,170 @@ +From: Josh Poimboeuf +Date: Sat, 3 Aug 2019 21:21:54 +0200 +Subject: Documentation: Add swapgs description to the Spectre v1 documentation +Origin: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7634b9cd27e8f867dd3438d262c78d4b9262497f +Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2019-1125 + +commit 4c92057661a3412f547ede95715641d7ee16ddac upstream + +Add documentation to the Spectre document about the new swapgs variant of +Spectre v1. + +Signed-off-by: Josh Poimboeuf +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman +--- + Documentation/admin-guide/hw-vuln/spectre.rst | 88 +++++++++++++++++-- + 1 file changed, 80 insertions(+), 8 deletions(-) + +diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst b/Documentation/admin-guide/hw-vuln/spectre.rst +index 25f3b2532198..e05e581af5cf 100644 +--- a/Documentation/admin-guide/hw-vuln/spectre.rst ++++ b/Documentation/admin-guide/hw-vuln/spectre.rst +@@ -41,10 +41,11 @@ Related CVEs + + The following CVE entries describe Spectre variants: + +- ============= ======================= ================= ++ ============= ======================= ========================== + CVE-2017-5753 Bounds check bypass Spectre variant 1 + CVE-2017-5715 Branch target injection Spectre variant 2 +- ============= ======================= ================= ++ CVE-2019-1125 Spectre v1 swapgs Spectre variant 1 (swapgs) ++ ============= ======================= ========================== + + Problem + ------- +@@ -78,6 +79,13 @@ There are some extensions of Spectre variant 1 attacks for reading data + over the network, see :ref:`[12] `. However such attacks + 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) + ------------------------------------------- + +@@ -132,6 +140,9 @@ not cover all possible attack vectors. + 1. A user process attacking the kernel + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + ++Spectre variant 1 ++~~~~~~~~~~~~~~~~~ ++ + The attacker passes a parameter to the kernel via a register or + 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 +@@ -144,7 +155,40 @@ not cover all possible attack vectors. + potentially be influenced for Spectre attacks, new "nospec" accessor + macros are used to prevent speculative loading of data. + +- Spectre variant 2 attacker can :ref:`poison ` 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:, %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 ` the branch + target buffer (BTB) before issuing syscall to launch an attack. + After entering the kernel, the kernel could use the poisoned branch + 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: + + The possible values in this file are: + +- ======================================= ================================= +- 'Mitigation: __user pointer sanitation' Protection in kernel on a case by +- case base with explicit pointer +- sanitation. +- ======================================= ================================= ++ .. list-table:: ++ ++ * - 'Not affected' ++ - 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, + 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 + 1. Kernel mitigation + ^^^^^^^^^^^^^^^^^^^^ + ++Spectre variant 1 ++~~~~~~~~~~~~~~~~~ ++ + For the Spectre variant 1, vulnerable kernel code (as determined + by code audit or scanning tools) is annotated on a case by case + basis to use nospec accessor macros for bounds clipping :ref:`[2] + ` to avoid any usable disclosure gadgets. However, it may + 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 + jumps in the kernel into equivalent return trampolines (retpolines) + :ref:`[3] ` :ref:`[9] ` to go to the target +@@ -473,6 +539,12 @@ Mitigation control on the kernel command line + Spectre variant 2 mitigation can be disabled or force enabled at the + 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 + + [X86] Disable all mitigations for the Spectre variant 2 +-- +2.20.1 + diff --git a/debian/patches/bugfix/x86/x86-cpufeatures-Carve-out-CQM-features-retrieval.patch b/debian/patches/bugfix/x86/x86-cpufeatures-Carve-out-CQM-features-retrieval.patch new file mode 100644 index 000000000..68958e089 --- /dev/null +++ b/debian/patches/bugfix/x86/x86-cpufeatures-Carve-out-CQM-features-retrieval.patch @@ -0,0 +1,110 @@ +From: Borislav Petkov +Date: Wed, 19 Jun 2019 17:24:34 +0200 +Subject: x86/cpufeatures: Carve out CQM features retrieval +Origin: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=16ad0b63f382a16454cb927f2eb45b32dbb71b94 + +commit 45fc56e629caa451467e7664fbd4c797c434a6c4 upstream + +... into a separate function for better readability. Split out from a +patch from Fenghua Yu to keep the mechanical, +sole code movement separate for easy review. + +No functional changes. + +Signed-off-by: Borislav Petkov +Signed-off-by: Thomas Gleixner +Cc: Fenghua Yu +Cc: x86@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/cpu/common.c | 60 ++++++++++++++++++++---------------- + 1 file changed, 33 insertions(+), 27 deletions(-) + +diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c +index 1073118b9bf0..a315e475e484 100644 +--- a/arch/x86/kernel/cpu/common.c ++++ b/arch/x86/kernel/cpu/common.c +@@ -808,6 +808,38 @@ static void init_speculation_control(struct cpuinfo_x86 *c) + } + } + ++static void init_cqm(struct cpuinfo_x86 *c) ++{ ++ u32 eax, ebx, ecx, edx; ++ ++ /* Additional Intel-defined flags: level 0x0000000F */ ++ if (c->cpuid_level >= 0x0000000F) { ++ ++ /* QoS sub-leaf, EAX=0Fh, ECX=0 */ ++ cpuid_count(0x0000000F, 0, &eax, &ebx, &ecx, &edx); ++ c->x86_capability[CPUID_F_0_EDX] = edx; ++ ++ if (cpu_has(c, X86_FEATURE_CQM_LLC)) { ++ /* will be overridden if occupancy monitoring exists */ ++ c->x86_cache_max_rmid = ebx; ++ ++ /* QoS sub-leaf, EAX=0Fh, ECX=1 */ ++ cpuid_count(0x0000000F, 1, &eax, &ebx, &ecx, &edx); ++ c->x86_capability[CPUID_F_1_EDX] = edx; ++ ++ if ((cpu_has(c, X86_FEATURE_CQM_OCCUP_LLC)) || ++ ((cpu_has(c, X86_FEATURE_CQM_MBM_TOTAL)) || ++ (cpu_has(c, X86_FEATURE_CQM_MBM_LOCAL)))) { ++ c->x86_cache_max_rmid = ecx; ++ c->x86_cache_occ_scale = ebx; ++ } ++ } else { ++ c->x86_cache_max_rmid = -1; ++ c->x86_cache_occ_scale = -1; ++ } ++ } ++} ++ + void get_cpu_cap(struct cpuinfo_x86 *c) + { + u32 eax, ebx, ecx, edx; +@@ -839,33 +871,6 @@ void get_cpu_cap(struct cpuinfo_x86 *c) + c->x86_capability[CPUID_D_1_EAX] = eax; + } + +- /* Additional Intel-defined flags: level 0x0000000F */ +- if (c->cpuid_level >= 0x0000000F) { +- +- /* QoS sub-leaf, EAX=0Fh, ECX=0 */ +- cpuid_count(0x0000000F, 0, &eax, &ebx, &ecx, &edx); +- c->x86_capability[CPUID_F_0_EDX] = edx; +- +- if (cpu_has(c, X86_FEATURE_CQM_LLC)) { +- /* will be overridden if occupancy monitoring exists */ +- c->x86_cache_max_rmid = ebx; +- +- /* QoS sub-leaf, EAX=0Fh, ECX=1 */ +- cpuid_count(0x0000000F, 1, &eax, &ebx, &ecx, &edx); +- c->x86_capability[CPUID_F_1_EDX] = edx; +- +- if ((cpu_has(c, X86_FEATURE_CQM_OCCUP_LLC)) || +- ((cpu_has(c, X86_FEATURE_CQM_MBM_TOTAL)) || +- (cpu_has(c, X86_FEATURE_CQM_MBM_LOCAL)))) { +- c->x86_cache_max_rmid = ecx; +- c->x86_cache_occ_scale = ebx; +- } +- } else { +- c->x86_cache_max_rmid = -1; +- c->x86_cache_occ_scale = -1; +- } +- } +- + /* AMD-defined flags: level 0x80000001 */ + eax = cpuid_eax(0x80000000); + c->extended_cpuid_level = eax; +@@ -896,6 +901,7 @@ void get_cpu_cap(struct cpuinfo_x86 *c) + + init_scattered_cpuid_features(c); + init_speculation_control(c); ++ init_cqm(c); + + /* + * Clear/Set all flags overridden by options, after probe. +-- +2.20.1 + diff --git a/debian/patches/bugfix/x86/x86-cpufeatures-Combine-word-11-and-12-into-a-new-sc.patch b/debian/patches/bugfix/x86/x86-cpufeatures-Combine-word-11-and-12-into-a-new-sc.patch new file mode 100644 index 000000000..3d78de3ef --- /dev/null +++ b/debian/patches/bugfix/x86/x86-cpufeatures-Combine-word-11-and-12-into-a-new-sc.patch @@ -0,0 +1,211 @@ +From: Fenghua Yu +Date: Wed, 19 Jun 2019 18:51:09 +0200 +Subject: x86/cpufeatures: Combine word 11 and 12 into a new scattered features + word +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit +Origin: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b5dd7f61fce44a1d5df5c63ce7bcb9e0a05ce2f7 + +commit acec0ce081de0c36459eea91647faf99296445a3 upstream + +It's a waste for the four X86_FEATURE_CQM_* feature bits to occupy two +whole feature bits words. To better utilize feature words, re-define +word 11 to host scattered features and move the four X86_FEATURE_CQM_* +features into Linux defined word 11. More scattered features can be +added in word 11 in the future. + +Rename leaf 11 in cpuid_leafs to CPUID_LNX_4 to reflect it's a +Linux-defined leaf. + +Rename leaf 12 as CPUID_DUMMY which will be replaced by a meaningful +name in the next patch when CPUID.7.1:EAX occupies world 12. + +Maximum number of RMID and cache occupancy scale are retrieved from +CPUID.0xf.1 after scattered CQM features are enumerated. Carve out the +code into a separate function. + +KVM doesn't support resctrl now. So it's safe to move the +X86_FEATURE_CQM_* features to scattered features word 11 for KVM. + +Signed-off-by: Fenghua Yu +Signed-off-by: Borislav Petkov +Signed-off-by: Thomas Gleixner +Cc: Aaron Lewis +Cc: Andy Lutomirski +Cc: Babu Moger +Cc: "Chang S. Bae" +Cc: "Sean J Christopherson" +Cc: Frederic Weisbecker +Cc: "H. Peter Anvin" +Cc: Ingo Molnar +Cc: Jann Horn +Cc: Juergen Gross +Cc: Konrad Rzeszutek Wilk +Cc: kvm ML +Cc: Masahiro Yamada +Cc: Masami Hiramatsu +Cc: Nadav Amit +Cc: Paolo Bonzini +Cc: Pavel Tatashin +Cc: Peter Feiner +Cc: "Peter Zijlstra (Intel)" +Cc: "Radim Krčmář" +Cc: "Rafael J. Wysocki" +Cc: Ravi V Shankar +Cc: Sherry Hurwitz +Cc: Thomas Gleixner +Cc: Thomas Lendacky +Cc: x86 +Link: https://lkml.kernel.org/r/1560794416-217638-2-git-send-email-fenghua.yu@intel.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/include/asm/cpufeature.h | 4 ++-- + arch/x86/include/asm/cpufeatures.h | 17 +++++++------ + arch/x86/kernel/cpu/common.c | 38 ++++++++++++------------------ + arch/x86/kernel/cpu/cpuid-deps.c | 3 +++ + arch/x86/kernel/cpu/scattered.c | 4 ++++ + arch/x86/kvm/cpuid.h | 2 -- + 6 files changed, 34 insertions(+), 34 deletions(-) + +diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h +index ce95b8cbd229..68889ace9c4c 100644 +--- a/arch/x86/include/asm/cpufeature.h ++++ b/arch/x86/include/asm/cpufeature.h +@@ -22,8 +22,8 @@ enum cpuid_leafs + CPUID_LNX_3, + CPUID_7_0_EBX, + CPUID_D_1_EAX, +- CPUID_F_0_EDX, +- CPUID_F_1_EDX, ++ CPUID_LNX_4, ++ CPUID_DUMMY, + CPUID_8000_0008_EBX, + CPUID_6_EAX, + CPUID_8000_000A_EDX, +diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h +index 0cf704933f23..5041f19918f2 100644 +--- a/arch/x86/include/asm/cpufeatures.h ++++ b/arch/x86/include/asm/cpufeatures.h +@@ -271,13 +271,16 @@ + #define X86_FEATURE_XGETBV1 (10*32+ 2) /* XGETBV with ECX = 1 instruction */ + #define X86_FEATURE_XSAVES (10*32+ 3) /* XSAVES/XRSTORS instructions */ + +-/* Intel-defined CPU QoS Sub-leaf, CPUID level 0x0000000F:0 (EDX), word 11 */ +-#define X86_FEATURE_CQM_LLC (11*32+ 1) /* LLC QoS if 1 */ +- +-/* Intel-defined CPU QoS Sub-leaf, CPUID level 0x0000000F:1 (EDX), word 12 */ +-#define X86_FEATURE_CQM_OCCUP_LLC (12*32+ 0) /* LLC occupancy monitoring */ +-#define X86_FEATURE_CQM_MBM_TOTAL (12*32+ 1) /* LLC Total MBM monitoring */ +-#define X86_FEATURE_CQM_MBM_LOCAL (12*32+ 2) /* LLC Local MBM monitoring */ ++/* ++ * Extended auxiliary flags: Linux defined - for features scattered in various ++ * CPUID levels like 0xf, etc. ++ * ++ * Reuse free bits when adding new feature flags! ++ */ ++#define X86_FEATURE_CQM_LLC (11*32+ 0) /* LLC QoS if 1 */ ++#define X86_FEATURE_CQM_OCCUP_LLC (11*32+ 1) /* LLC occupancy monitoring */ ++#define X86_FEATURE_CQM_MBM_TOTAL (11*32+ 2) /* LLC Total MBM monitoring */ ++#define X86_FEATURE_CQM_MBM_LOCAL (11*32+ 3) /* LLC Local MBM monitoring */ + + /* AMD-defined CPU features, CPUID level 0x80000008 (EBX), word 13 */ + #define X86_FEATURE_CLZERO (13*32+ 0) /* CLZERO instruction */ +diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c +index a315e475e484..417d09f2bcaf 100644 +--- a/arch/x86/kernel/cpu/common.c ++++ b/arch/x86/kernel/cpu/common.c +@@ -810,33 +810,25 @@ static void init_speculation_control(struct cpuinfo_x86 *c) + + static void init_cqm(struct cpuinfo_x86 *c) + { +- u32 eax, ebx, ecx, edx; +- +- /* Additional Intel-defined flags: level 0x0000000F */ +- if (c->cpuid_level >= 0x0000000F) { ++ if (!cpu_has(c, X86_FEATURE_CQM_LLC)) { ++ c->x86_cache_max_rmid = -1; ++ c->x86_cache_occ_scale = -1; ++ return; ++ } + +- /* QoS sub-leaf, EAX=0Fh, ECX=0 */ +- cpuid_count(0x0000000F, 0, &eax, &ebx, &ecx, &edx); +- c->x86_capability[CPUID_F_0_EDX] = edx; ++ /* will be overridden if occupancy monitoring exists */ ++ c->x86_cache_max_rmid = cpuid_ebx(0xf); + +- if (cpu_has(c, X86_FEATURE_CQM_LLC)) { +- /* will be overridden if occupancy monitoring exists */ +- c->x86_cache_max_rmid = ebx; ++ if (cpu_has(c, X86_FEATURE_CQM_OCCUP_LLC) || ++ cpu_has(c, X86_FEATURE_CQM_MBM_TOTAL) || ++ cpu_has(c, X86_FEATURE_CQM_MBM_LOCAL)) { ++ u32 eax, ebx, ecx, edx; + +- /* QoS sub-leaf, EAX=0Fh, ECX=1 */ +- cpuid_count(0x0000000F, 1, &eax, &ebx, &ecx, &edx); +- c->x86_capability[CPUID_F_1_EDX] = edx; ++ /* QoS sub-leaf, EAX=0Fh, ECX=1 */ ++ cpuid_count(0xf, 1, &eax, &ebx, &ecx, &edx); + +- if ((cpu_has(c, X86_FEATURE_CQM_OCCUP_LLC)) || +- ((cpu_has(c, X86_FEATURE_CQM_MBM_TOTAL)) || +- (cpu_has(c, X86_FEATURE_CQM_MBM_LOCAL)))) { +- c->x86_cache_max_rmid = ecx; +- c->x86_cache_occ_scale = ebx; +- } +- } else { +- c->x86_cache_max_rmid = -1; +- c->x86_cache_occ_scale = -1; +- } ++ c->x86_cache_max_rmid = ecx; ++ c->x86_cache_occ_scale = ebx; + } + } + +diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c +index 2c0bd38a44ab..fa07a224e7b9 100644 +--- a/arch/x86/kernel/cpu/cpuid-deps.c ++++ b/arch/x86/kernel/cpu/cpuid-deps.c +@@ -59,6 +59,9 @@ static const struct cpuid_dep cpuid_deps[] = { + { X86_FEATURE_AVX512_4VNNIW, X86_FEATURE_AVX512F }, + { X86_FEATURE_AVX512_4FMAPS, X86_FEATURE_AVX512F }, + { X86_FEATURE_AVX512_VPOPCNTDQ, X86_FEATURE_AVX512F }, ++ { X86_FEATURE_CQM_OCCUP_LLC, X86_FEATURE_CQM_LLC }, ++ { X86_FEATURE_CQM_MBM_TOTAL, X86_FEATURE_CQM_LLC }, ++ { X86_FEATURE_CQM_MBM_LOCAL, X86_FEATURE_CQM_LLC }, + {} + }; + +diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c +index 772c219b6889..5a52672e3f8b 100644 +--- a/arch/x86/kernel/cpu/scattered.c ++++ b/arch/x86/kernel/cpu/scattered.c +@@ -21,6 +21,10 @@ struct cpuid_bit { + static const struct cpuid_bit cpuid_bits[] = { + { X86_FEATURE_APERFMPERF, CPUID_ECX, 0, 0x00000006, 0 }, + { X86_FEATURE_EPB, CPUID_ECX, 3, 0x00000006, 0 }, ++ { X86_FEATURE_CQM_LLC, CPUID_EDX, 1, 0x0000000f, 0 }, ++ { X86_FEATURE_CQM_OCCUP_LLC, CPUID_EDX, 0, 0x0000000f, 1 }, ++ { X86_FEATURE_CQM_MBM_TOTAL, CPUID_EDX, 1, 0x0000000f, 1 }, ++ { X86_FEATURE_CQM_MBM_LOCAL, CPUID_EDX, 2, 0x0000000f, 1 }, + { X86_FEATURE_CAT_L3, CPUID_EBX, 1, 0x00000010, 0 }, + { X86_FEATURE_CAT_L2, CPUID_EBX, 2, 0x00000010, 0 }, + { X86_FEATURE_CDP_L3, CPUID_ECX, 2, 0x00000010, 1 }, +diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h +index 9a327d5b6d1f..d78a61408243 100644 +--- a/arch/x86/kvm/cpuid.h ++++ b/arch/x86/kvm/cpuid.h +@@ -47,8 +47,6 @@ static const struct cpuid_reg reverse_cpuid[] = { + [CPUID_8000_0001_ECX] = {0x80000001, 0, CPUID_ECX}, + [CPUID_7_0_EBX] = { 7, 0, CPUID_EBX}, + [CPUID_D_1_EAX] = { 0xd, 1, CPUID_EAX}, +- [CPUID_F_0_EDX] = { 0xf, 0, CPUID_EDX}, +- [CPUID_F_1_EDX] = { 0xf, 1, CPUID_EDX}, + [CPUID_8000_0008_EBX] = {0x80000008, 0, CPUID_EBX}, + [CPUID_6_EAX] = { 6, 0, CPUID_EAX}, + [CPUID_8000_000A_EDX] = {0x8000000a, 0, CPUID_EDX}, +-- +2.20.1 + diff --git a/debian/patches/bugfix/x86/x86-entry-64-Use-JMP-instead-of-JMPQ.patch b/debian/patches/bugfix/x86/x86-entry-64-Use-JMP-instead-of-JMPQ.patch new file mode 100644 index 000000000..8a65f2aee --- /dev/null +++ b/debian/patches/bugfix/x86/x86-entry-64-Use-JMP-instead-of-JMPQ.patch @@ -0,0 +1,40 @@ +From: Josh Poimboeuf +Date: Mon, 15 Jul 2019 11:51:39 -0500 +Subject: x86/entry/64: Use JMP instead of JMPQ +Origin: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=931b6bfe8af1069fd1a494ef6ab14509ffeacdc3 +Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2019-1125 + +commit 64dbc122b20f75183d8822618c24f85144a5a94d upstream + +Somehow the swapgs mitigation entry code patch ended up with a JMPQ +instruction instead of JMP, where only the short jump is needed. Some +assembler versions apparently fail to optimize JMPQ into a two-byte JMP +when possible, instead always using a 7-byte JMP with relocation. For +some reason that makes the entry code explode with a #GP during boot. + +Change it back to "JMP" as originally intended. + +Fixes: 18ec54fdd6d1 ("x86/speculation: Prepare entry code for Spectre v1 swapgs mitigations") +Signed-off-by: Josh Poimboeuf +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/entry/entry_64.S | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S +index 7d8da285e185..ccb5e3486aee 100644 +--- a/arch/x86/entry/entry_64.S ++++ b/arch/x86/entry/entry_64.S +@@ -612,7 +612,7 @@ ENTRY(interrupt_entry) + UNWIND_HINT_FUNC + + movq (%rdi), %rdi +- jmpq 2f ++ jmp 2f + 1: + FENCE_SWAPGS_KERNEL_ENTRY + 2: +-- +2.20.1 + diff --git a/debian/patches/bugfix/x86/x86-speculation-Enable-Spectre-v1-swapgs-mitigations.patch b/debian/patches/bugfix/x86/x86-speculation-Enable-Spectre-v1-swapgs-mitigations.patch new file mode 100644 index 000000000..919586a4f --- /dev/null +++ b/debian/patches/bugfix/x86/x86-speculation-Enable-Spectre-v1-swapgs-mitigations.patch @@ -0,0 +1,261 @@ +From: Josh Poimboeuf +Date: Mon, 8 Jul 2019 11:52:26 -0500 +Subject: x86/speculation: Enable Spectre v1 swapgs mitigations +Origin: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=23e7a7b3a75f6dd24c161bf7d1399f251bf5c109 +Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2019-1125 + +commit a2059825986a1c8143fd6698774fa9d83733bb11 upstream + +The previous commit added macro calls in the entry code which mitigate the +Spectre v1 swapgs issue if the X86_FEATURE_FENCE_SWAPGS_* features are +enabled. Enable those features where applicable. + +The mitigations may be disabled with "nospectre_v1" or "mitigations=off". + +There are different features which can affect the risk of attack: + +- When FSGSBASE is enabled, unprivileged users are able to place any + value in GS, using the wrgsbase instruction. This means they can + write a GS value which points to any value in kernel space, which can + be useful with the following gadget in an interrupt/exception/NMI + handler: + + if (coming from user space) + swapgs + mov %gs:, %reg1 + // dependent load or store based on the value of %reg + // for example: mov %(reg1), %reg2 + + If an interrupt is coming from user space, and the entry code + speculatively skips the swapgs (due to user branch mistraining), it + may speculatively execute the GS-based load and a subsequent dependent + load or store, exposing the kernel data to an L1 side channel leak. + + Note that, on Intel, a similar attack exists in the above gadget when + coming from kernel space, if the swapgs gets speculatively executed to + switch back to the user GS. On AMD, this variant isn't possible + because swapgs is serializing with respect to future GS-based + accesses. + + NOTE: The FSGSBASE patch set hasn't been merged yet, so the above case + doesn't exist quite yet. + +- When FSGSBASE is disabled, the issue is mitigated somewhat because + unprivileged users must use prctl(ARCH_SET_GS) to set GS, which + restricts GS values to user space addresses only. That means the + gadget would need an additional step, since the target kernel address + needs to be read from user space first. Something like: + + if (coming from user space) + swapgs + mov %gs:, %reg1 + mov (%reg1), %reg2 + // dependent load or store based on the value of %reg2 + // for example: mov %(reg2), %reg3 + + It's difficult to audit for this gadget in all the handlers, so while + there are no known instances of it, it's entirely possible that it + exists somewhere (or could be introduced in the future). Without + tooling to analyze all such code paths, consider it vulnerable. + + Effects of SMAP on the !FSGSBASE case: + + - If SMAP is enabled, and the CPU reports RDCL_NO (i.e., not + susceptible to Meltdown), the kernel is prevented from speculatively + reading user space memory, even L1 cached values. This effectively + disables the !FSGSBASE attack vector. + + - If SMAP is enabled, but the CPU *is* susceptible to Meltdown, SMAP + still prevents the kernel from speculatively reading user space + memory. But it does *not* prevent the kernel from reading the + user value from L1, if it has already been cached. This is probably + only a small hurdle for an attacker to overcome. + +Thanks to Dave Hansen for contributing the speculative_smap() function. + +Thanks to Andrew Cooper for providing the inside scoop on whether swapgs +is serializing on AMD. + +[ tglx: Fixed the USER fence decision and polished the comment as suggested + by Dave Hansen ] + +Signed-off-by: Josh Poimboeuf +Signed-off-by: Thomas Gleixner +Reviewed-by: Dave Hansen +Signed-off-by: Greg Kroah-Hartman +--- + .../admin-guide/kernel-parameters.txt | 7 +- + arch/x86/kernel/cpu/bugs.c | 115 ++++++++++++++++-- + 2 files changed, 110 insertions(+), 12 deletions(-) + +--- a/Documentation/admin-guide/kernel-parameters.txt ++++ b/Documentation/admin-guide/kernel-parameters.txt +@@ -2515,6 +2515,7 @@ + Equivalent to: nopti [X86,PPC] + nospectre_v1 [PPC] + nobp=0 [S390] ++ nospectre_v1 [X86] + nospectre_v2 [X86,PPC,S390] + spectre_v2_user=off [X86] + spec_store_bypass_disable=off [X86,PPC] +@@ -2861,9 +2862,9 @@ + nosmt=force: Force disable SMT, cannot be undone + via the sysfs control file. + +- nospectre_v1 [PPC] Disable mitigations for Spectre Variant 1 (bounds +- check bypass). With this option data leaks are possible +- in the system. ++ nospectre_v1 [X66, PPC] Disable mitigations for Spectre Variant 1 ++ (bounds check bypass). With this option data leaks ++ are possible in the system. + + nospectre_v2 [X86] Disable all mitigations for the Spectre variant 2 + (indirect branch prediction) vulnerability. System may +--- a/arch/x86/kernel/cpu/bugs.c ++++ b/arch/x86/kernel/cpu/bugs.c +@@ -32,6 +32,7 @@ + #include + #include + ++static void __init spectre_v1_select_mitigation(void); + static void __init spectre_v2_select_mitigation(void); + static void __init ssb_select_mitigation(void); + static void __init l1tf_select_mitigation(void); +@@ -96,17 +97,11 @@ void __init check_bugs(void) + if (boot_cpu_has(X86_FEATURE_STIBP)) + x86_spec_ctrl_mask |= SPEC_CTRL_STIBP; + +- /* Select the proper spectre mitigation before patching alternatives */ ++ /* Select the proper CPU mitigations before patching alternatives: */ ++ spectre_v1_select_mitigation(); + spectre_v2_select_mitigation(); +- +- /* +- * Select proper mitigation for any exposure to the Speculative Store +- * Bypass vulnerability. +- */ + ssb_select_mitigation(); +- + l1tf_select_mitigation(); +- + mds_select_mitigation(); + + arch_smt_update(); +@@ -272,6 +267,108 @@ static int __init mds_cmdline(char *str) + early_param("mds", mds_cmdline); + + #undef pr_fmt ++#define pr_fmt(fmt) "Spectre V1 : " fmt ++ ++enum spectre_v1_mitigation { ++ SPECTRE_V1_MITIGATION_NONE, ++ SPECTRE_V1_MITIGATION_AUTO, ++}; ++ ++static enum spectre_v1_mitigation spectre_v1_mitigation __ro_after_init = ++ SPECTRE_V1_MITIGATION_AUTO; ++ ++static const char * const spectre_v1_strings[] = { ++ [SPECTRE_V1_MITIGATION_NONE] = "Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers", ++ [SPECTRE_V1_MITIGATION_AUTO] = "Mitigation: usercopy/swapgs barriers and __user pointer sanitization", ++}; ++ ++static bool is_swapgs_serializing(void) ++{ ++ /* ++ * Technically, swapgs isn't serializing on AMD (despite it previously ++ * being documented as such in the APM). But according to AMD, %gs is ++ * updated non-speculatively, and the issuing of %gs-relative memory ++ * operands will be blocked until the %gs update completes, which is ++ * good enough for our purposes. ++ */ ++ return boot_cpu_data.x86_vendor == X86_VENDOR_AMD; ++} ++ ++/* ++ * Does SMAP provide full mitigation against speculative kernel access to ++ * userspace? ++ */ ++static bool smap_works_speculatively(void) ++{ ++ if (!boot_cpu_has(X86_FEATURE_SMAP)) ++ return false; ++ ++ /* ++ * On CPUs which are vulnerable to Meltdown, SMAP does not ++ * prevent speculative access to user data in the L1 cache. ++ * Consider SMAP to be non-functional as a mitigation on these ++ * CPUs. ++ */ ++ if (boot_cpu_has(X86_BUG_CPU_MELTDOWN)) ++ return false; ++ ++ return true; ++} ++ ++static void __init spectre_v1_select_mitigation(void) ++{ ++ if (!boot_cpu_has_bug(X86_BUG_SPECTRE_V1) || cpu_mitigations_off()) { ++ spectre_v1_mitigation = SPECTRE_V1_MITIGATION_NONE; ++ return; ++ } ++ ++ if (spectre_v1_mitigation == SPECTRE_V1_MITIGATION_AUTO) { ++ /* ++ * With Spectre v1, a user can speculatively control either ++ * path of a conditional swapgs with a user-controlled GS ++ * value. The mitigation is to add lfences to both code paths. ++ * ++ * If FSGSBASE is enabled, the user can put a kernel address in ++ * GS, in which case SMAP provides no protection. ++ * ++ * [ NOTE: Don't check for X86_FEATURE_FSGSBASE until the ++ * FSGSBASE enablement patches have been merged. ] ++ * ++ * If FSGSBASE is disabled, the user can only put a user space ++ * address in GS. That makes an attack harder, but still ++ * possible if there's no SMAP protection. ++ */ ++ if (!smap_works_speculatively()) { ++ /* ++ * Mitigation can be provided from SWAPGS itself or ++ * PTI as the CR3 write in the Meltdown mitigation ++ * is serializing. ++ * ++ * If neither is there, mitigate with an LFENCE. ++ */ ++ if (!is_swapgs_serializing() && !boot_cpu_has(X86_FEATURE_PTI)) ++ setup_force_cpu_cap(X86_FEATURE_FENCE_SWAPGS_USER); ++ ++ /* ++ * Enable lfences in the kernel entry (non-swapgs) ++ * paths, to prevent user entry from speculatively ++ * skipping swapgs. ++ */ ++ setup_force_cpu_cap(X86_FEATURE_FENCE_SWAPGS_KERNEL); ++ } ++ } ++ ++ pr_info("%s\n", spectre_v1_strings[spectre_v1_mitigation]); ++} ++ ++static int __init nospectre_v1_cmdline(char *str) ++{ ++ spectre_v1_mitigation = SPECTRE_V1_MITIGATION_NONE; ++ return 0; ++} ++early_param("nospectre_v1", nospectre_v1_cmdline); ++ ++#undef pr_fmt + #define pr_fmt(fmt) "Spectre V2 : " fmt + + static enum spectre_v2_mitigation spectre_v2_enabled __ro_after_init = +@@ -1249,7 +1346,7 @@ static ssize_t cpu_show_common(struct de + break; + + case X86_BUG_SPECTRE_V1: +- return sprintf(buf, "Mitigation: __user pointer sanitization\n"); ++ return sprintf(buf, "%s\n", spectre_v1_strings[spectre_v1_mitigation]); + + case X86_BUG_SPECTRE_V2: + return sprintf(buf, "%s%s%s%s%s%s\n", spectre_v2_strings[spectre_v2_enabled], diff --git a/debian/patches/bugfix/x86/x86-speculation-Prepare-entry-code-for-Spectre-v1-sw.patch b/debian/patches/bugfix/x86/x86-speculation-Prepare-entry-code-for-Spectre-v1-sw.patch new file mode 100644 index 000000000..f47559b40 --- /dev/null +++ b/debian/patches/bugfix/x86/x86-speculation-Prepare-entry-code-for-Spectre-v1-sw.patch @@ -0,0 +1,200 @@ +From: Josh Poimboeuf +Date: Mon, 8 Jul 2019 11:52:25 -0500 +Subject: x86/speculation: Prepare entry code for Spectre v1 swapgs mitigations +Origin: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=befb822c062b4c3d93380a58d5fd479395e8b267 +Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2019-1125 + +commit 18ec54fdd6d18d92025af097cd042a75cf0ea24c upstream + +Spectre v1 isn't only about 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. + +For example: + + if (coming from user space) + swapgs + mov %gs:, %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. + +The mitigation is similar to a traditional Spectre v1 mitigation, except: + + a) index masking isn't possible; because the index (percpu offset) + isn't user-controlled; and + + b) an lfence is needed in both the "from user" swapgs path and the + "from kernel" non-swapgs path (because of the two attacks described + above). + +The user entry swapgs paths already have SWITCH_TO_KERNEL_CR3, which has a +CR3 write when PTI is enabled. Since CR3 writes are serializing, the +lfences can be skipped in those cases. + +On the other hand, the kernel entry swapgs paths don't depend on PTI. + +To avoid unnecessary lfences for the user entry case, create two separate +features for alternative patching: + + X86_FEATURE_FENCE_SWAPGS_USER + X86_FEATURE_FENCE_SWAPGS_KERNEL + +Use these features in entry code to patch in lfences where needed. + +The features aren't enabled yet, so there's no functional change. + +Signed-off-by: Josh Poimboeuf +Signed-off-by: Thomas Gleixner +Reviewed-by: Dave Hansen +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/entry/calling.h | 17 +++++++++++++++++ + arch/x86/entry/entry_64.S | 21 ++++++++++++++++++--- + arch/x86/include/asm/cpufeatures.h | 2 ++ + 3 files changed, 37 insertions(+), 3 deletions(-) + +diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h +index e699b2041665..578b5455334f 100644 +--- a/arch/x86/entry/calling.h ++++ b/arch/x86/entry/calling.h +@@ -329,6 +329,23 @@ For 32-bit we have the following conventions - kernel is built with + + #endif + ++/* ++ * Mitigate Spectre v1 for conditional swapgs code paths. ++ * ++ * FENCE_SWAPGS_USER_ENTRY is used in the user entry swapgs code path, to ++ * prevent a speculative swapgs when coming from kernel space. ++ * ++ * FENCE_SWAPGS_KERNEL_ENTRY is used in the kernel entry non-swapgs code path, ++ * to prevent the swapgs from getting speculatively skipped when coming from ++ * user space. ++ */ ++.macro FENCE_SWAPGS_USER_ENTRY ++ ALTERNATIVE "", "lfence", X86_FEATURE_FENCE_SWAPGS_USER ++.endm ++.macro FENCE_SWAPGS_KERNEL_ENTRY ++ ALTERNATIVE "", "lfence", X86_FEATURE_FENCE_SWAPGS_KERNEL ++.endm ++ + #endif /* CONFIG_X86_64 */ + + /* +diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S +index e7572a209fbe..7d8da285e185 100644 +--- a/arch/x86/entry/entry_64.S ++++ b/arch/x86/entry/entry_64.S +@@ -582,7 +582,7 @@ ENTRY(interrupt_entry) + testb $3, CS-ORIG_RAX+8(%rsp) + jz 1f + SWAPGS +- ++ FENCE_SWAPGS_USER_ENTRY + /* + * Switch to the thread stack. The IRET frame and orig_ax are + * on the stack, as well as the return address. RDI..R12 are +@@ -612,8 +612,10 @@ ENTRY(interrupt_entry) + UNWIND_HINT_FUNC + + movq (%rdi), %rdi ++ jmpq 2f + 1: +- ++ FENCE_SWAPGS_KERNEL_ENTRY ++2: + PUSH_AND_CLEAR_REGS save_ret=1 + ENCODE_FRAME_POINTER 8 + +@@ -1240,6 +1242,13 @@ ENTRY(paranoid_entry) + */ + SAVE_AND_SWITCH_TO_KERNEL_CR3 scratch_reg=%rax save_reg=%r14 + ++ /* ++ * The above SAVE_AND_SWITCH_TO_KERNEL_CR3 macro doesn't do an ++ * unconditional CR3 write, even in the PTI case. So do an lfence ++ * to prevent GS speculation, regardless of whether PTI is enabled. ++ */ ++ FENCE_SWAPGS_KERNEL_ENTRY ++ + ret + END(paranoid_entry) + +@@ -1290,6 +1299,7 @@ ENTRY(error_entry) + * from user mode due to an IRET fault. + */ + SWAPGS ++ FENCE_SWAPGS_USER_ENTRY + /* We have user CR3. Change to kernel CR3. */ + SWITCH_TO_KERNEL_CR3 scratch_reg=%rax + +@@ -1311,6 +1321,8 @@ ENTRY(error_entry) + CALL_enter_from_user_mode + ret + ++.Lerror_entry_done_lfence: ++ FENCE_SWAPGS_KERNEL_ENTRY + .Lerror_entry_done: + TRACE_IRQS_OFF + ret +@@ -1329,7 +1341,7 @@ ENTRY(error_entry) + cmpq %rax, RIP+8(%rsp) + je .Lbstep_iret + cmpq $.Lgs_change, RIP+8(%rsp) +- jne .Lerror_entry_done ++ jne .Lerror_entry_done_lfence + + /* + * hack: .Lgs_change can fail with user gsbase. If this happens, fix up +@@ -1337,6 +1349,7 @@ ENTRY(error_entry) + * .Lgs_change's error handler with kernel gsbase. + */ + SWAPGS ++ FENCE_SWAPGS_USER_ENTRY + SWITCH_TO_KERNEL_CR3 scratch_reg=%rax + jmp .Lerror_entry_done + +@@ -1351,6 +1364,7 @@ ENTRY(error_entry) + * gsbase and CR3. Switch to kernel gsbase and CR3: + */ + SWAPGS ++ FENCE_SWAPGS_USER_ENTRY + SWITCH_TO_KERNEL_CR3 scratch_reg=%rax + + /* +@@ -1442,6 +1456,7 @@ ENTRY(nmi) + + swapgs + cld ++ FENCE_SWAPGS_USER_ENTRY + SWITCH_TO_KERNEL_CR3 scratch_reg=%rdx + movq %rsp, %rdx + movq PER_CPU_VAR(cpu_current_top_of_stack), %rsp +diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h +index 5041f19918f2..e0f47f6a1017 100644 +--- a/arch/x86/include/asm/cpufeatures.h ++++ b/arch/x86/include/asm/cpufeatures.h +@@ -281,6 +281,8 @@ + #define X86_FEATURE_CQM_OCCUP_LLC (11*32+ 1) /* LLC occupancy monitoring */ + #define X86_FEATURE_CQM_MBM_TOTAL (11*32+ 2) /* LLC Total MBM monitoring */ + #define X86_FEATURE_CQM_MBM_LOCAL (11*32+ 3) /* LLC Local MBM monitoring */ ++#define X86_FEATURE_FENCE_SWAPGS_USER (11*32+ 4) /* "" LFENCE in user entry SWAPGS path */ ++#define X86_FEATURE_FENCE_SWAPGS_KERNEL (11*32+ 5) /* "" LFENCE in kernel entry SWAPGS path */ + + /* AMD-defined CPU features, CPUID level 0x80000008 (EBX), word 13 */ + #define X86_FEATURE_CLZERO (13*32+ 0) /* CLZERO instruction */ +-- +2.20.1 + diff --git a/debian/patches/bugfix/x86/x86-speculation-swapgs-Exclude-ATOMs-from-speculatio.patch b/debian/patches/bugfix/x86/x86-speculation-swapgs-Exclude-ATOMs-from-speculatio.patch new file mode 100644 index 000000000..d466887ba --- /dev/null +++ b/debian/patches/bugfix/x86/x86-speculation-swapgs-Exclude-ATOMs-from-speculatio.patch @@ -0,0 +1,159 @@ +From: Thomas Gleixner +Date: Wed, 17 Jul 2019 21:18:59 +0200 +Subject: x86/speculation/swapgs: Exclude ATOMs from speculation through SWAPGS +Origin: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b88241aef6f1654417bb281546da316ffab57807 +Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2019-1125 + +commit f36cf386e3fec258a341d446915862eded3e13d8 upstream + +Intel provided the following information: + + On all current Atom processors, instructions that use a segment register + value (e.g. a load or store) will not speculatively execute before the + last writer of that segment retires. Thus they will not use a + speculatively written segment value. + +That means on ATOMs there is no speculation through SWAPGS, so the SWAPGS +entry paths can be excluded from the extra LFENCE if PTI is disabled. + +Create a separate bug flag for the through SWAPGS speculation and mark all +out-of-order ATOMs and AMD/HYGON CPUs as not affected. The in-order ATOMs +are excluded from the whole mitigation mess anyway. + +Reported-by: Andrew Cooper +Signed-off-by: Thomas Gleixner +Reviewed-by: Tyler Hicks +Reviewed-by: Josh Poimboeuf +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/include/asm/cpufeatures.h | 1 + + arch/x86/kernel/cpu/bugs.c | 18 +++---------- + arch/x86/kernel/cpu/common.c | 42 +++++++++++++++++++----------- + 3 files changed, 32 insertions(+), 29 deletions(-) + +diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h +index e0f47f6a1017..759f0a176612 100644 +--- a/arch/x86/include/asm/cpufeatures.h ++++ b/arch/x86/include/asm/cpufeatures.h +@@ -388,5 +388,6 @@ + #define X86_BUG_L1TF X86_BUG(18) /* CPU is affected by L1 Terminal Fault */ + #define X86_BUG_MDS X86_BUG(19) /* CPU is affected by Microarchitectural data sampling */ + #define X86_BUG_MSBDS_ONLY X86_BUG(20) /* CPU is only affected by the MSDBS variant of BUG_MDS */ ++#define X86_BUG_SWAPGS X86_BUG(21) /* CPU is affected by speculation through SWAPGS */ + + #endif /* _ASM_X86_CPUFEATURES_H */ +diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c +index 844ad5d3ef51..ee7d17611ead 100644 +--- a/arch/x86/kernel/cpu/bugs.c ++++ b/arch/x86/kernel/cpu/bugs.c +@@ -282,18 +282,6 @@ static const char * const spectre_v1_strings[] = { + [SPECTRE_V1_MITIGATION_AUTO] = "Mitigation: usercopy/swapgs barriers and __user pointer sanitization", + }; + +-static bool is_swapgs_serializing(void) +-{ +- /* +- * Technically, swapgs isn't serializing on AMD (despite it previously +- * being documented as such in the APM). But according to AMD, %gs is +- * updated non-speculatively, and the issuing of %gs-relative memory +- * operands will be blocked until the %gs update completes, which is +- * good enough for our purposes. +- */ +- return boot_cpu_data.x86_vendor == X86_VENDOR_AMD; +-} +- + /* + * Does SMAP provide full mitigation against speculative kernel access to + * userspace? +@@ -344,9 +332,11 @@ static void __init spectre_v1_select_mitigation(void) + * PTI as the CR3 write in the Meltdown mitigation + * is serializing. + * +- * If neither is there, mitigate with an LFENCE. ++ * If neither is there, mitigate with an LFENCE to ++ * stop speculation through swapgs. + */ +- if (!is_swapgs_serializing() && !boot_cpu_has(X86_FEATURE_PTI)) ++ if (boot_cpu_has_bug(X86_BUG_SWAPGS) && ++ !boot_cpu_has(X86_FEATURE_PTI)) + setup_force_cpu_cap(X86_FEATURE_FENCE_SWAPGS_USER); + + /* +diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c +index 417d09f2bcaf..b33fdfa0ff49 100644 +--- a/arch/x86/kernel/cpu/common.c ++++ b/arch/x86/kernel/cpu/common.c +@@ -952,6 +952,7 @@ static void identify_cpu_without_cpuid(struct cpuinfo_x86 *c) + #define NO_L1TF BIT(3) + #define NO_MDS BIT(4) + #define MSBDS_ONLY BIT(5) ++#define NO_SWAPGS BIT(6) + + #define VULNWL(_vendor, _family, _model, _whitelist) \ + { X86_VENDOR_##_vendor, _family, _model, X86_FEATURE_ANY, _whitelist } +@@ -975,29 +976,37 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = { + VULNWL_INTEL(ATOM_BONNELL, NO_SPECULATION), + VULNWL_INTEL(ATOM_BONNELL_MID, NO_SPECULATION), + +- VULNWL_INTEL(ATOM_SILVERMONT, NO_SSB | NO_L1TF | MSBDS_ONLY), +- VULNWL_INTEL(ATOM_SILVERMONT_X, NO_SSB | NO_L1TF | MSBDS_ONLY), +- VULNWL_INTEL(ATOM_SILVERMONT_MID, NO_SSB | NO_L1TF | MSBDS_ONLY), +- VULNWL_INTEL(ATOM_AIRMONT, NO_SSB | NO_L1TF | MSBDS_ONLY), +- VULNWL_INTEL(XEON_PHI_KNL, NO_SSB | NO_L1TF | MSBDS_ONLY), +- VULNWL_INTEL(XEON_PHI_KNM, NO_SSB | NO_L1TF | MSBDS_ONLY), ++ VULNWL_INTEL(ATOM_SILVERMONT, NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS), ++ VULNWL_INTEL(ATOM_SILVERMONT_X, NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS), ++ VULNWL_INTEL(ATOM_SILVERMONT_MID, NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS), ++ VULNWL_INTEL(ATOM_AIRMONT, NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS), ++ VULNWL_INTEL(XEON_PHI_KNL, NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS), ++ VULNWL_INTEL(XEON_PHI_KNM, NO_SSB | NO_L1TF | MSBDS_ONLY | NO_SWAPGS), + + VULNWL_INTEL(CORE_YONAH, NO_SSB), + +- VULNWL_INTEL(ATOM_AIRMONT_MID, NO_L1TF | MSBDS_ONLY), ++ VULNWL_INTEL(ATOM_AIRMONT_MID, NO_L1TF | MSBDS_ONLY | NO_SWAPGS), + +- VULNWL_INTEL(ATOM_GOLDMONT, NO_MDS | NO_L1TF), +- VULNWL_INTEL(ATOM_GOLDMONT_X, NO_MDS | NO_L1TF), +- VULNWL_INTEL(ATOM_GOLDMONT_PLUS, NO_MDS | NO_L1TF), ++ VULNWL_INTEL(ATOM_GOLDMONT, NO_MDS | NO_L1TF | NO_SWAPGS), ++ VULNWL_INTEL(ATOM_GOLDMONT_X, NO_MDS | NO_L1TF | NO_SWAPGS), ++ VULNWL_INTEL(ATOM_GOLDMONT_PLUS, NO_MDS | NO_L1TF | NO_SWAPGS), ++ ++ /* ++ * Technically, swapgs isn't serializing on AMD (despite it previously ++ * being documented as such in the APM). But according to AMD, %gs is ++ * updated non-speculatively, and the issuing of %gs-relative memory ++ * operands will be blocked until the %gs update completes, which is ++ * good enough for our purposes. ++ */ + + /* AMD Family 0xf - 0x12 */ +- VULNWL_AMD(0x0f, NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS), +- VULNWL_AMD(0x10, NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS), +- VULNWL_AMD(0x11, NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS), +- VULNWL_AMD(0x12, NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS), ++ VULNWL_AMD(0x0f, NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS | NO_SWAPGS), ++ VULNWL_AMD(0x10, NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS | NO_SWAPGS), ++ VULNWL_AMD(0x11, NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS | NO_SWAPGS), ++ VULNWL_AMD(0x12, NO_MELTDOWN | NO_SSB | NO_L1TF | NO_MDS | NO_SWAPGS), + + /* FAMILY_ANY must be last, otherwise 0x0f - 0x12 matches won't work */ +- VULNWL_AMD(X86_FAMILY_ANY, NO_MELTDOWN | NO_L1TF | NO_MDS), ++ VULNWL_AMD(X86_FAMILY_ANY, NO_MELTDOWN | NO_L1TF | NO_MDS | NO_SWAPGS), + {} + }; + +@@ -1034,6 +1043,9 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c) + setup_force_cpu_bug(X86_BUG_MSBDS_ONLY); + } + ++ if (!cpu_matches(NO_SWAPGS)) ++ setup_force_cpu_bug(X86_BUG_SWAPGS); ++ + if (cpu_matches(NO_MELTDOWN)) + return; + +-- +2.20.1 + diff --git a/debian/patches/series b/debian/patches/series index f4e381744..37da9881b 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -240,6 +240,14 @@ bugfix/all/floppy-fix-div-by-zero-in-setup_format_params.patch bugfix/all/floppy-fix-out-of-bounds-read-in-copy_buffer.patch bugfix/all/Bluetooth-hci_uart-check-for-missing-tty-operations.patch bugfix/powerpc/powerpc-tm-Fix-oops-on-sigreturn-on-systems-without-TM.patch +bugfix/x86/x86-cpufeatures-Carve-out-CQM-features-retrieval.patch +bugfix/x86/x86-cpufeatures-Combine-word-11-and-12-into-a-new-sc.patch +bugfix/x86/x86-speculation-Prepare-entry-code-for-Spectre-v1-sw.patch +bugfix/x86/x86-speculation-Enable-Spectre-v1-swapgs-mitigations.patch +bugfix/x86/x86-entry-64-Use-JMP-instead-of-JMPQ.patch +bugfix/x86/x86-speculation-swapgs-Exclude-ATOMs-from-speculatio.patch +bugfix/all/Documentation-Add-section-about-CPU-vulnerabilities-.patch +bugfix/all/Documentation-Add-swapgs-description-to-the-Spectre-.patch # Fix exported symbol versions bugfix/all/module-disable-matching-missing-version-crc.patch