Merge branch 'buster-security' into buster
* Accept revert of "[sh4]: Check for kprobe trap number before trying to handle a kprobe trap" and update debian/changelog accordingly, as sh4 is not a release architecture * Keep "[arm64] Improve support for the Huawei TaiShan server platform" which was reverted on the buster-security branch
This commit is contained in:
commit
64c3754b90
|
@ -1,8 +1,5 @@
|
|||
linux (4.19.37-6) UNRELEASED; urgency=medium
|
||||
|
||||
[ John Paul Adrian Glaubitz ]
|
||||
* [sh4]: Check for kprobe trap number before trying to handle a kprobe trap
|
||||
|
||||
[ Steve McIntyre ]
|
||||
* [arm64] Improve support for the Huawei TaiShan server platform
|
||||
(Closes: #930554):
|
||||
|
@ -22,6 +19,42 @@ linux (4.19.37-6) UNRELEASED; urgency=medium
|
|||
|
||||
-- Salvatore Bonaccorso <carnil@debian.org> Sun, 23 Jun 2019 16:15:17 +0200
|
||||
|
||||
linux (4.19.37-5+deb10u2) buster-security; urgency=high
|
||||
|
||||
[ Romain Perier ]
|
||||
* [x86] x86/insn-eval: Fix use-after-free access to LDT entry (CVE-2019-13233)
|
||||
* [powerpc*] mm/64s/hash: Reallocate context ids on fork (CVE-2019-12817)
|
||||
* nfc: Ensure presence of required attributes in the deactivate_target handler
|
||||
(CVE-2019-12984)
|
||||
* binder: fix race between munmap() and direct reclaim (CVE-2019-1999)
|
||||
* scsi: libsas: fix a race condition when smp task timeout (CVE-2018-20836)
|
||||
* Input: gtco - bounds check collection indent level (CVE-2019-13631)
|
||||
* floppy: fix out-of-bounds read in copy_buffer (CVE-2019-14283)
|
||||
* inet: switch IP ID generator to siphash (CVE-2019-10638)
|
||||
* floppy: fix div-by-zero in setup_format_params (CVE-2019-14284)
|
||||
* 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
|
||||
|
||||
[ Ben Hutchings ]
|
||||
* [x86] cpufeatures: Avoid ABI change for swapgs mitigations:
|
||||
- Move swapgs feature bits to existing scattered words
|
||||
- Revert "x86/cpufeatures: Combine word 11 and 12 into a new scattered
|
||||
features word"
|
||||
* inet: Avoid ABI change for IP ID hash change
|
||||
|
||||
-- Ben Hutchings <ben@decadent.org.uk> Thu, 08 Aug 2019 03:02:38 +0100
|
||||
|
||||
linux (4.19.37-5+deb10u1) buster-security; urgency=high
|
||||
|
||||
* tcp: refine memory limit test in tcp_fragment() (Closes: #930904)
|
||||
|
|
152
debian/patches/bugfix/all/Bluetooth-hci_uart-check-for-missing-tty-operations.patch
vendored
Normal file
152
debian/patches/bugfix/all/Bluetooth-hci_uart-check-for-missing-tty-operations.patch
vendored
Normal file
|
@ -0,0 +1,152 @@
|
|||
From: Vladis Dronov <vdronov@redhat.com>
|
||||
Date: Tue, 30 Jul 2019 11:33:45 +0200
|
||||
Subject: Bluetooth: hci_uart: check for missing tty operations
|
||||
Origin: https://git.kernel.org/linus/b36a1552d7319bbfd5cf7f08726c23c5c66d4f73
|
||||
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2019-10207
|
||||
|
||||
commit b36a1552d7319bbfd5cf7f08726c23c5c66d4f73 upstream.
|
||||
|
||||
Certain ttys operations (pty_unix98_ops) lack tiocmget() and tiocmset()
|
||||
functions which are called by the certain HCI UART protocols (hci_ath,
|
||||
hci_bcm, hci_intel, hci_mrvl, hci_qca) via hci_uart_set_flow_control()
|
||||
or directly. This leads to an execution at NULL and can be triggered by
|
||||
an unprivileged user. Fix this by adding a helper function and a check
|
||||
for the missing tty operations in the protocols code.
|
||||
|
||||
This fixes CVE-2019-10207. The Fixes: lines list commits where calls to
|
||||
tiocm[gs]et() or hci_uart_set_flow_control() were added to the HCI UART
|
||||
protocols.
|
||||
|
||||
Link: https://syzkaller.appspot.com/bug?id=1b42faa2848963564a5b1b7f8c837ea7b55ffa50
|
||||
Reported-by: syzbot+79337b501d6aa974d0f6@syzkaller.appspotmail.com
|
||||
Cc: stable@vger.kernel.org # v2.6.36+
|
||||
Fixes: b3190df62861 ("Bluetooth: Support for Atheros AR300x serial chip")
|
||||
Fixes: 118612fb9165 ("Bluetooth: hci_bcm: Add suspend/resume PM functions")
|
||||
Fixes: ff2895592f0f ("Bluetooth: hci_intel: Add Intel baudrate configuration support")
|
||||
Fixes: 162f812f23ba ("Bluetooth: hci_uart: Add Marvell support")
|
||||
Fixes: fa9ad876b8e0 ("Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990")
|
||||
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
|
||||
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
||||
Reviewed-by: Yu-Chen, Cho <acho@suse.com>
|
||||
Tested-by: Yu-Chen, Cho <acho@suse.com>
|
||||
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
||||
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
---
|
||||
drivers/bluetooth/hci_ath.c | 3 +++
|
||||
drivers/bluetooth/hci_bcm.c | 3 +++
|
||||
drivers/bluetooth/hci_intel.c | 3 +++
|
||||
drivers/bluetooth/hci_ldisc.c | 13 +++++++++++++
|
||||
drivers/bluetooth/hci_mrvl.c | 3 +++
|
||||
drivers/bluetooth/hci_qca.c | 3 +++
|
||||
drivers/bluetooth/hci_uart.h | 1 +
|
||||
7 files changed, 29 insertions(+)
|
||||
|
||||
diff --git a/drivers/bluetooth/hci_ath.c b/drivers/bluetooth/hci_ath.c
|
||||
index d568fbd94d6c..20235925344d 100644
|
||||
--- a/drivers/bluetooth/hci_ath.c
|
||||
+++ b/drivers/bluetooth/hci_ath.c
|
||||
@@ -112,6 +112,9 @@ static int ath_open(struct hci_uart *hu)
|
||||
|
||||
BT_DBG("hu %p", hu);
|
||||
|
||||
+ if (!hci_uart_has_flow_control(hu))
|
||||
+ return -EOPNOTSUPP;
|
||||
+
|
||||
ath = kzalloc(sizeof(*ath), GFP_KERNEL);
|
||||
if (!ath)
|
||||
return -ENOMEM;
|
||||
diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
|
||||
index 800132369134..aa6b7ed9fdf1 100644
|
||||
--- a/drivers/bluetooth/hci_bcm.c
|
||||
+++ b/drivers/bluetooth/hci_bcm.c
|
||||
@@ -369,6 +369,9 @@ static int bcm_open(struct hci_uart *hu)
|
||||
|
||||
bt_dev_dbg(hu->hdev, "hu %p", hu);
|
||||
|
||||
+ if (!hci_uart_has_flow_control(hu))
|
||||
+ return -EOPNOTSUPP;
|
||||
+
|
||||
bcm = kzalloc(sizeof(*bcm), GFP_KERNEL);
|
||||
if (!bcm)
|
||||
return -ENOMEM;
|
||||
diff --git a/drivers/bluetooth/hci_intel.c b/drivers/bluetooth/hci_intel.c
|
||||
index 46ace321bf60..e9228520e4c7 100644
|
||||
--- a/drivers/bluetooth/hci_intel.c
|
||||
+++ b/drivers/bluetooth/hci_intel.c
|
||||
@@ -406,6 +406,9 @@ static int intel_open(struct hci_uart *hu)
|
||||
|
||||
BT_DBG("hu %p", hu);
|
||||
|
||||
+ if (!hci_uart_has_flow_control(hu))
|
||||
+ return -EOPNOTSUPP;
|
||||
+
|
||||
intel = kzalloc(sizeof(*intel), GFP_KERNEL);
|
||||
if (!intel)
|
||||
return -ENOMEM;
|
||||
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
|
||||
index c915daf01a89..efeb8137ec67 100644
|
||||
--- a/drivers/bluetooth/hci_ldisc.c
|
||||
+++ b/drivers/bluetooth/hci_ldisc.c
|
||||
@@ -299,6 +299,19 @@ static int hci_uart_send_frame(struct hci_dev *hdev, struct sk_buff *skb)
|
||||
return 0;
|
||||
}
|
||||
|
||||
+/* Check the underlying device or tty has flow control support */
|
||||
+bool hci_uart_has_flow_control(struct hci_uart *hu)
|
||||
+{
|
||||
+ /* serdev nodes check if the needed operations are present */
|
||||
+ if (hu->serdev)
|
||||
+ return true;
|
||||
+
|
||||
+ if (hu->tty->driver->ops->tiocmget && hu->tty->driver->ops->tiocmset)
|
||||
+ return true;
|
||||
+
|
||||
+ return false;
|
||||
+}
|
||||
+
|
||||
/* Flow control or un-flow control the device */
|
||||
void hci_uart_set_flow_control(struct hci_uart *hu, bool enable)
|
||||
{
|
||||
diff --git a/drivers/bluetooth/hci_mrvl.c b/drivers/bluetooth/hci_mrvl.c
|
||||
index ffb00669346f..23791df081ba 100644
|
||||
--- a/drivers/bluetooth/hci_mrvl.c
|
||||
+++ b/drivers/bluetooth/hci_mrvl.c
|
||||
@@ -66,6 +66,9 @@ static int mrvl_open(struct hci_uart *hu)
|
||||
|
||||
BT_DBG("hu %p", hu);
|
||||
|
||||
+ if (!hci_uart_has_flow_control(hu))
|
||||
+ return -EOPNOTSUPP;
|
||||
+
|
||||
mrvl = kzalloc(sizeof(*mrvl), GFP_KERNEL);
|
||||
if (!mrvl)
|
||||
return -ENOMEM;
|
||||
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
|
||||
index 77004c29da08..f96e58de049b 100644
|
||||
--- a/drivers/bluetooth/hci_qca.c
|
||||
+++ b/drivers/bluetooth/hci_qca.c
|
||||
@@ -450,6 +450,9 @@ static int qca_open(struct hci_uart *hu)
|
||||
|
||||
BT_DBG("hu %p qca_open", hu);
|
||||
|
||||
+ if (!hci_uart_has_flow_control(hu))
|
||||
+ return -EOPNOTSUPP;
|
||||
+
|
||||
qca = kzalloc(sizeof(struct qca_data), GFP_KERNEL);
|
||||
if (!qca)
|
||||
return -ENOMEM;
|
||||
diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
|
||||
index 00cab2fd7a1b..067a610f1372 100644
|
||||
--- a/drivers/bluetooth/hci_uart.h
|
||||
+++ b/drivers/bluetooth/hci_uart.h
|
||||
@@ -118,6 +118,7 @@ int hci_uart_tx_wakeup(struct hci_uart *hu);
|
||||
int hci_uart_init_ready(struct hci_uart *hu);
|
||||
void hci_uart_init_work(struct work_struct *work);
|
||||
void hci_uart_set_baudrate(struct hci_uart *hu, unsigned int speed);
|
||||
+bool hci_uart_has_flow_control(struct hci_uart *hu);
|
||||
void hci_uart_set_flow_control(struct hci_uart *hu, bool enable);
|
||||
void hci_uart_set_speeds(struct hci_uart *hu, unsigned int init_speed,
|
||||
unsigned int oper_speed);
|
||||
--
|
||||
cgit 1.2-0.3.lf.el7
|
||||
|
760
debian/patches/bugfix/all/Documentation-Add-section-about-CPU-vulnerabilities-.patch
vendored
Normal file
760
debian/patches/bugfix/all/Documentation-Add-section-about-CPU-vulnerabilities-.patch
vendored
Normal file
|
@ -0,0 +1,760 @@
|
|||
From: Tim Chen <tim.c.chen@linux.intel.com>
|
||||
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 <ak@linux.intel.com>
|
||||
Signed-off-by: Andi Kleen <ak@linux.intel.com>
|
||||
Co-developed-by: Tim Chen <tim.c.chen@linux.intel.com>
|
||||
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
|
||||
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
|
||||
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
|
||||
Cc: stable@vger.kernel.org
|
||||
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
||||
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
---
|
||||
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] <spec_ref1>` :ref:`[5] <spec_ref5>` :ref:`[7] <spec_ref7>`
|
||||
+:ref:`[10] <spec_ref10>` :ref:`[11] <spec_ref11>`.
|
||||
+
|
||||
+Spectre variant 1 (Bounds Check Bypass)
|
||||
+---------------------------------------
|
||||
+
|
||||
+The bounds check bypass attack :ref:`[2] <spec_ref2>` 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] <spec_ref12>`. 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] <spec_ref3>`. 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] <spec_ref13>` 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 <poison_btb>` 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] <spec_ref3>` :ref:`[9] <spec_ref9>` 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 <poison_btb>` 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] <spec_ref4>` 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
|
||||
+ <poison_btb>` 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 <poison_btb>` 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]
|
||||
+ <spec_ref2>` 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] <spec_ref3>` :ref:`[9] <spec_ref9>` 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] <spec_ref3>` 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] <spec_ref2>`.
|
||||
+
|
||||
+ 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 <set_spec_ctrl>`).
|
||||
+ 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 <set_spec_ctrl>`).
|
||||
+
|
||||
+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 <set_spec_ctrl>`).
|
||||
+ 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 <https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf>`_.
|
||||
+
|
||||
+.. _spec_ref2:
|
||||
+
|
||||
+[2] `Bounds check bypass <https://software.intel.com/security-software-guidance/software-guidance/bounds-check-bypass>`_.
|
||||
+
|
||||
+.. _spec_ref3:
|
||||
+
|
||||
+[3] `Deep dive: Retpoline: A branch target injection mitigation <https://software.intel.com/security-software-guidance/insights/deep-dive-retpoline-branch-target-injection-mitigation>`_.
|
||||
+
|
||||
+.. _spec_ref4:
|
||||
+
|
||||
+[4] `Deep Dive: Single Thread Indirect Branch Predictors <https://software.intel.com/security-software-guidance/insights/deep-dive-single-thread-indirect-branch-predictors>`_.
|
||||
+
|
||||
+AMD white papers:
|
||||
+
|
||||
+.. _spec_ref5:
|
||||
+
|
||||
+[5] `AMD64 technology indirect branch control extension <https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf>`_.
|
||||
+
|
||||
+.. _spec_ref6:
|
||||
+
|
||||
+[6] `Software techniques for managing speculation on AMD processors <https://developer.amd.com/wp-content/resources/90343-B_SoftwareTechniquesforManagingSpeculation_WP_7-18Update_FNL.pdf>`_.
|
||||
+
|
||||
+ARM white papers:
|
||||
+
|
||||
+.. _spec_ref7:
|
||||
+
|
||||
+[7] `Cache speculation side-channels <https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/download-the-whitepaper>`_.
|
||||
+
|
||||
+.. _spec_ref8:
|
||||
+
|
||||
+[8] `Cache speculation issues update <https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/latest-updates/cache-speculation-issues-update>`_.
|
||||
+
|
||||
+Google white paper:
|
||||
+
|
||||
+.. _spec_ref9:
|
||||
+
|
||||
+[9] `Retpoline: a software construct for preventing branch-target-injection <https://support.google.com/faqs/answer/7625886>`_.
|
||||
+
|
||||
+MIPS white paper:
|
||||
+
|
||||
+.. _spec_ref10:
|
||||
+
|
||||
+[10] `MIPS: response on speculative execution and side channel vulnerabilities <https://www.mips.com/blog/mips-response-on-speculative-execution-and-side-channel-vulnerabilities/>`_.
|
||||
+
|
||||
+Academic papers:
|
||||
+
|
||||
+.. _spec_ref11:
|
||||
+
|
||||
+[11] `Spectre Attacks: Exploiting Speculative Execution <https://spectreattack.com/spectre.pdf>`_.
|
||||
+
|
||||
+.. _spec_ref12:
|
||||
+
|
||||
+[12] `NetSpectre: Read Arbitrary Memory over Network <https://arxiv.org/abs/1807.10535>`_.
|
||||
+
|
||||
+.. _spec_ref13:
|
||||
+
|
||||
+[13] `Spectre Returns! Speculation Attacks using the Return Stack Buffer <https://www.usenix.org/system/files/conference/woot18/woot18-paper-koruyeh.pdf>`_.
|
||||
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
|
||||
|
170
debian/patches/bugfix/all/Documentation-Add-swapgs-description-to-the-Spectre-.patch
vendored
Normal file
170
debian/patches/bugfix/all/Documentation-Add-swapgs-description-to-the-Spectre-.patch
vendored
Normal file
|
@ -0,0 +1,170 @@
|
|||
From: Josh Poimboeuf <jpoimboe@redhat.com>
|
||||
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 <jpoimboe@redhat.com>
|
||||
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
||||
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
---
|
||||
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] <spec_ref12>`. 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 <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.
|
||||
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]
|
||||
<spec_ref2>` 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] <spec_ref3>` :ref:`[9] <spec_ref9>` 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
|
||||
|
67
debian/patches/bugfix/all/binder-fix-race-between-munmap-and-direct-reclaim.patch
vendored
Normal file
67
debian/patches/bugfix/all/binder-fix-race-between-munmap-and-direct-reclaim.patch
vendored
Normal file
|
@ -0,0 +1,67 @@
|
|||
From: Todd Kjos <tkjos@android.com>
|
||||
Date: Fri, 1 Mar 2019 15:06:06 -0800
|
||||
Subject: binder: fix race between munmap() and direct reclaim
|
||||
Origin: https://git.kernel.org/linus/5cec2d2e5839f9c0fec319c523a911e0a7fd299f
|
||||
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2019-1999
|
||||
|
||||
An munmap() on a binder device causes binder_vma_close() to be called
|
||||
which clears the alloc->vma pointer.
|
||||
|
||||
If direct reclaim causes binder_alloc_free_page() to be called, there
|
||||
is a race where alloc->vma is read into a local vma pointer and then
|
||||
used later after the mm->mmap_sem is acquired. This can result in
|
||||
calling zap_page_range() with an invalid vma which manifests as a
|
||||
use-after-free in zap_page_range().
|
||||
|
||||
The fix is to check alloc->vma after acquiring the mmap_sem (which we
|
||||
were acquiring anyway) and skip zap_page_range() if it has changed
|
||||
to NULL.
|
||||
|
||||
Signed-off-by: Todd Kjos <tkjos@google.com>
|
||||
Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
|
||||
Cc: stable <stable@vger.kernel.org>
|
||||
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
---
|
||||
drivers/android/binder_alloc.c | 17 ++++++++---------
|
||||
1 file changed, 8 insertions(+), 9 deletions(-)
|
||||
|
||||
diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c
|
||||
index 030c98f35cca..3863ef78e40f 100644
|
||||
--- a/drivers/android/binder_alloc.c
|
||||
+++ b/drivers/android/binder_alloc.c
|
||||
@@ -958,14 +958,13 @@ enum lru_status binder_alloc_free_page(struct list_head *item,
|
||||
|
||||
index = page - alloc->pages;
|
||||
page_addr = (uintptr_t)alloc->buffer + index * PAGE_SIZE;
|
||||
+
|
||||
+ mm = alloc->vma_vm_mm;
|
||||
+ if (!mmget_not_zero(mm))
|
||||
+ goto err_mmget;
|
||||
+ if (!down_write_trylock(&mm->mmap_sem))
|
||||
+ goto err_down_write_mmap_sem_failed;
|
||||
vma = binder_alloc_get_vma(alloc);
|
||||
- if (vma) {
|
||||
- if (!mmget_not_zero(alloc->vma_vm_mm))
|
||||
- goto err_mmget;
|
||||
- mm = alloc->vma_vm_mm;
|
||||
- if (!down_write_trylock(&mm->mmap_sem))
|
||||
- goto err_down_write_mmap_sem_failed;
|
||||
- }
|
||||
|
||||
list_lru_isolate(lru, item);
|
||||
spin_unlock(lock);
|
||||
@@ -979,9 +978,9 @@ enum lru_status binder_alloc_free_page(struct list_head *item,
|
||||
|
||||
trace_binder_unmap_user_end(alloc, index);
|
||||
|
||||
- up_write(&mm->mmap_sem);
|
||||
- mmput(mm);
|
||||
}
|
||||
+ up_write(&mm->mmap_sem);
|
||||
+ mmput(mm);
|
||||
|
||||
trace_binder_unmap_kernel_start(alloc, index);
|
||||
|
||||
--
|
||||
2.20.1
|
||||
|
64
debian/patches/bugfix/all/floppy-fix-div-by-zero-in-setup_format_params.patch
vendored
Normal file
64
debian/patches/bugfix/all/floppy-fix-div-by-zero-in-setup_format_params.patch
vendored
Normal file
|
@ -0,0 +1,64 @@
|
|||
From: Denis Efremov <efremov@ispras.ru>
|
||||
Date: Fri, 12 Jul 2019 21:55:20 +0300
|
||||
Subject: floppy: fix div-by-zero in setup_format_params
|
||||
Origin: https://git.kernel.org/linus/f3554aeb991214cbfafd17d55e2bfddb50282e32
|
||||
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2019-14284
|
||||
|
||||
[ Upstream commit f3554aeb991214cbfafd17d55e2bfddb50282e32 ]
|
||||
|
||||
This fixes a divide by zero error in the setup_format_params function of
|
||||
the floppy driver.
|
||||
|
||||
Two consecutive ioctls can trigger the bug: The first one should set the
|
||||
drive geometry with such .sect and .rate values for the F_SECT_PER_TRACK
|
||||
to become zero. Next, the floppy format operation should be called.
|
||||
|
||||
A floppy disk is not required to be inserted. An unprivileged user
|
||||
could trigger the bug if the device is accessible.
|
||||
|
||||
The patch checks F_SECT_PER_TRACK for a non-zero value in the
|
||||
set_geometry function. The proper check should involve a reasonable
|
||||
upper limit for the .sect and .rate fields, but it could change the
|
||||
UAPI.
|
||||
|
||||
The patch also checks F_SECT_PER_TRACK in the setup_format_params, and
|
||||
cancels the formatting operation in case of zero.
|
||||
|
||||
The bug was found by syzkaller.
|
||||
|
||||
Signed-off-by: Denis Efremov <efremov@ispras.ru>
|
||||
Tested-by: Willy Tarreau <w@1wt.eu>
|
||||
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
||||
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
||||
---
|
||||
drivers/block/floppy.c | 5 +++++
|
||||
1 file changed, 5 insertions(+)
|
||||
|
||||
(limited to 'drivers/block/floppy.c')
|
||||
|
||||
diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
|
||||
index a8de56f1936d..b1425b218606 100644
|
||||
--- a/drivers/block/floppy.c
|
||||
+++ b/drivers/block/floppy.c
|
||||
@@ -2119,6 +2119,9 @@ static void setup_format_params(int track)
|
||||
raw_cmd->kernel_data = floppy_track_buffer;
|
||||
raw_cmd->length = 4 * F_SECT_PER_TRACK;
|
||||
|
||||
+ if (!F_SECT_PER_TRACK)
|
||||
+ return;
|
||||
+
|
||||
/* allow for about 30ms for data transport per track */
|
||||
head_shift = (F_SECT_PER_TRACK + 5) / 6;
|
||||
|
||||
@@ -3243,6 +3246,8 @@ static int set_geometry(unsigned int cmd, struct floppy_struct *g,
|
||||
/* sanity checking for parameters. */
|
||||
if (g->sect <= 0 ||
|
||||
g->head <= 0 ||
|
||||
+ /* check for zero in F_SECT_PER_TRACK */
|
||||
+ (unsigned char)((g->sect << 2) >> FD_SIZECODE(g)) == 0 ||
|
||||
g->track <= 0 || g->track > UDP->tracks >> STRETCH(g) ||
|
||||
/* check if reserved bits are set */
|
||||
(g->stretch & ~(FD_STRETCH | FD_SWAPSIDES | FD_SECTBASEMASK)) != 0)
|
||||
--
|
||||
cgit 1.2-0.3.lf.el7
|
||||
|
55
debian/patches/bugfix/all/floppy-fix-out-of-bounds-read-in-copy_buffer.patch
vendored
Normal file
55
debian/patches/bugfix/all/floppy-fix-out-of-bounds-read-in-copy_buffer.patch
vendored
Normal file
|
@ -0,0 +1,55 @@
|
|||
From: Denis Efremov <efremov@ispras.ru>
|
||||
Date: Fri, 12 Jul 2019 21:55:23 +0300
|
||||
Subject: floppy: fix out-of-bounds read in copy_buffer
|
||||
Origin: https://git.kernel.org/linus/da99466ac243f15fbba65bd261bfc75ffa1532b6
|
||||
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2019-14283
|
||||
|
||||
[ Upstream commit da99466ac243f15fbba65bd261bfc75ffa1532b6 ]
|
||||
|
||||
This fixes a global out-of-bounds read access in the copy_buffer
|
||||
function of the floppy driver.
|
||||
|
||||
The FDDEFPRM ioctl allows one to set the geometry of a disk. The sect
|
||||
and head fields (unsigned int) of the floppy_drive structure are used to
|
||||
compute the max_sector (int) in the make_raw_rw_request function. It is
|
||||
possible to overflow the max_sector. Next, max_sector is passed to the
|
||||
copy_buffer function and used in one of the memcpy calls.
|
||||
|
||||
An unprivileged user could trigger the bug if the device is accessible,
|
||||
but requires a floppy disk to be inserted.
|
||||
|
||||
The patch adds the check for the .sect * .head multiplication for not
|
||||
overflowing in the set_geometry function.
|
||||
|
||||
The bug was found by syzkaller.
|
||||
|
||||
Signed-off-by: Denis Efremov <efremov@ispras.ru>
|
||||
Tested-by: Willy Tarreau <w@1wt.eu>
|
||||
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
||||
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
||||
---
|
||||
drivers/block/floppy.c | 6 ++++--
|
||||
1 file changed, 4 insertions(+), 2 deletions(-)
|
||||
|
||||
(limited to 'drivers/block/floppy.c')
|
||||
|
||||
diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
|
||||
index 8d69a8af8b78..4a9a4d12721a 100644
|
||||
--- a/drivers/block/floppy.c
|
||||
+++ b/drivers/block/floppy.c
|
||||
@@ -3244,8 +3244,10 @@ static int set_geometry(unsigned int cmd, struct floppy_struct *g,
|
||||
int cnt;
|
||||
|
||||
/* sanity checking for parameters. */
|
||||
- if (g->sect <= 0 ||
|
||||
- g->head <= 0 ||
|
||||
+ if ((int)g->sect <= 0 ||
|
||||
+ (int)g->head <= 0 ||
|
||||
+ /* check for overflow in max_sector */
|
||||
+ (int)(g->sect * g->head) <= 0 ||
|
||||
/* check for zero in F_SECT_PER_TRACK */
|
||||
(unsigned char)((g->sect << 2) >> FD_SIZECODE(g)) == 0 ||
|
||||
g->track <= 0 || g->track > UDP->tracks >> STRETCH(g) ||
|
||||
--
|
||||
cgit 1.2-0.3.lf.el7
|
||||
|
82
debian/patches/bugfix/all/input-gtco-bounds-check-collection-indent-level.patch
vendored
Normal file
82
debian/patches/bugfix/all/input-gtco-bounds-check-collection-indent-level.patch
vendored
Normal file
|
@ -0,0 +1,82 @@
|
|||
From: Grant Hernandez <granthernandez@google.com>
|
||||
Date: Sat, 13 Jul 2019 01:00:12 -0700
|
||||
Subject: Input: gtco - bounds check collection indent level
|
||||
Origin: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d657077eda7b5572d86f2f618391bb016b5d9a64
|
||||
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2019-13631
|
||||
|
||||
commit 2a017fd82c5402b3c8df5e3d6e5165d9e6147dc1 upstream.
|
||||
|
||||
The GTCO tablet input driver configures itself from an HID report sent
|
||||
via USB during the initial enumeration process. Some debugging messages
|
||||
are generated during the parsing. A debugging message indentation
|
||||
counter is not bounds checked, leading to the ability for a specially
|
||||
crafted HID report to cause '-' and null bytes be written past the end
|
||||
of the indentation array. As long as the kernel has CONFIG_DYNAMIC_DEBUG
|
||||
enabled, this code will not be optimized out. This was discovered
|
||||
during code review after a previous syzkaller bug was found in this
|
||||
driver.
|
||||
|
||||
Signed-off-by: Grant Hernandez <granthernandez@google.com>
|
||||
Cc: stable@vger.kernel.org
|
||||
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
||||
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
---
|
||||
drivers/input/tablet/gtco.c | 20 +++++++++++++++++---
|
||||
1 file changed, 17 insertions(+), 3 deletions(-)
|
||||
|
||||
diff --git a/drivers/input/tablet/gtco.c b/drivers/input/tablet/gtco.c
|
||||
index 4b8b9d7aa75e..35031228a6d0 100644
|
||||
--- a/drivers/input/tablet/gtco.c
|
||||
+++ b/drivers/input/tablet/gtco.c
|
||||
@@ -78,6 +78,7 @@ Scott Hill shill@gtcocalcomp.com
|
||||
|
||||
/* Max size of a single report */
|
||||
#define REPORT_MAX_SIZE 10
|
||||
+#define MAX_COLLECTION_LEVELS 10
|
||||
|
||||
|
||||
/* Bitmask whether pen is in range */
|
||||
@@ -223,8 +224,7 @@ static void parse_hid_report_descriptor(struct gtco *device, char * report,
|
||||
char maintype = 'x';
|
||||
char globtype[12];
|
||||
int indent = 0;
|
||||
- char indentstr[10] = "";
|
||||
-
|
||||
+ char indentstr[MAX_COLLECTION_LEVELS + 1] = { 0 };
|
||||
|
||||
dev_dbg(ddev, "======>>>>>>PARSE<<<<<<======\n");
|
||||
|
||||
@@ -350,6 +350,13 @@ static void parse_hid_report_descriptor(struct gtco *device, char * report,
|
||||
case TAG_MAIN_COL_START:
|
||||
maintype = 'S';
|
||||
|
||||
+ if (indent == MAX_COLLECTION_LEVELS) {
|
||||
+ dev_err(ddev, "Collection level %d would exceed limit of %d\n",
|
||||
+ indent + 1,
|
||||
+ MAX_COLLECTION_LEVELS);
|
||||
+ break;
|
||||
+ }
|
||||
+
|
||||
if (data == 0) {
|
||||
dev_dbg(ddev, "======>>>>>> Physical\n");
|
||||
strcpy(globtype, "Physical");
|
||||
@@ -369,8 +376,15 @@ static void parse_hid_report_descriptor(struct gtco *device, char * report,
|
||||
break;
|
||||
|
||||
case TAG_MAIN_COL_END:
|
||||
- dev_dbg(ddev, "<<<<<<======\n");
|
||||
maintype = 'E';
|
||||
+
|
||||
+ if (indent == 0) {
|
||||
+ dev_err(ddev, "Collection level already at zero\n");
|
||||
+ break;
|
||||
+ }
|
||||
+
|
||||
+ dev_dbg(ddev, "<<<<<<======\n");
|
||||
+
|
||||
indent--;
|
||||
for (x = 0; x < indent; x++)
|
||||
indentstr[x] = '-';
|
||||
--
|
||||
cgit 1.2-0.3.lf.el7
|
||||
|
|
@ -0,0 +1,162 @@
|
|||
From: Eric Dumazet <edumazet@google.com>
|
||||
Date: Wed, 27 Mar 2019 12:40:33 -0700
|
||||
Subject: inet: switch IP ID generator to siphash
|
||||
Origin: https://git.kernel.org/linus/df453700e8d81b1bdafdf684365ee2b9431fb702
|
||||
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2019-10638
|
||||
|
||||
[ Upstream commit df453700e8d81b1bdafdf684365ee2b9431fb702 ]
|
||||
|
||||
According to Amit Klein and Benny Pinkas, IP ID generation is too weak
|
||||
and might be used by attackers.
|
||||
|
||||
Even with recent net_hash_mix() fix (netns: provide pure entropy for net_hash_mix())
|
||||
having 64bit key and Jenkins hash is risky.
|
||||
|
||||
It is time to switch to siphash and its 128bit keys.
|
||||
|
||||
Signed-off-by: Eric Dumazet <edumazet@google.com>
|
||||
Reported-by: Amit Klein <aksecurity@gmail.com>
|
||||
Reported-by: Benny Pinkas <benny@pinkas.net>
|
||||
Signed-off-by: David S. Miller <davem@davemloft.net>
|
||||
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
---
|
||||
include/linux/siphash.h | 5 +++++
|
||||
include/net/netns/ipv4.h | 2 ++
|
||||
net/ipv4/route.c | 12 +++++++-----
|
||||
net/ipv6/output_core.c | 30 ++++++++++++++++--------------
|
||||
4 files changed, 30 insertions(+), 19 deletions(-)
|
||||
|
||||
diff --git a/include/linux/siphash.h b/include/linux/siphash.h
|
||||
index fa7a6b9cedbf..bf21591a9e5e 100644
|
||||
--- a/include/linux/siphash.h
|
||||
+++ b/include/linux/siphash.h
|
||||
@@ -21,6 +21,11 @@ typedef struct {
|
||||
u64 key[2];
|
||||
} siphash_key_t;
|
||||
|
||||
+static inline bool siphash_key_is_zero(const siphash_key_t *key)
|
||||
+{
|
||||
+ return !(key->key[0] | key->key[1]);
|
||||
+}
|
||||
+
|
||||
u64 __siphash_aligned(const void *data, size_t len, const siphash_key_t *key);
|
||||
#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
|
||||
u64 __siphash_unaligned(const void *data, size_t len, const siphash_key_t *key);
|
||||
diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
|
||||
index e47503b4e4d1..622db6bc2f02 100644
|
||||
--- a/include/net/netns/ipv4.h
|
||||
+++ b/include/net/netns/ipv4.h
|
||||
@@ -9,6 +9,7 @@
|
||||
#include <linux/uidgid.h>
|
||||
#include <net/inet_frag.h>
|
||||
#include <linux/rcupdate.h>
|
||||
+#include <linux/siphash.h>
|
||||
|
||||
struct tcpm_hash_bucket;
|
||||
struct ctl_table_header;
|
||||
@@ -214,5 +215,6 @@ struct netns_ipv4 {
|
||||
unsigned int ipmr_seq; /* protected by rtnl_mutex */
|
||||
|
||||
atomic_t rt_genid;
|
||||
+ siphash_key_t ip_id_key;
|
||||
};
|
||||
#endif
|
||||
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
|
||||
index 8bacbcd2db90..40bf19f7ae1a 100644
|
||||
--- a/net/ipv4/route.c
|
||||
+++ b/net/ipv4/route.c
|
||||
@@ -500,15 +500,17 @@ EXPORT_SYMBOL(ip_idents_reserve);
|
||||
|
||||
void __ip_select_ident(struct net *net, struct iphdr *iph, int segs)
|
||||
{
|
||||
- static u32 ip_idents_hashrnd __read_mostly;
|
||||
u32 hash, id;
|
||||
|
||||
- net_get_random_once(&ip_idents_hashrnd, sizeof(ip_idents_hashrnd));
|
||||
+ /* Note the following code is not safe, but this is okay. */
|
||||
+ if (unlikely(siphash_key_is_zero(&net->ipv4.ip_id_key)))
|
||||
+ get_random_bytes(&net->ipv4.ip_id_key,
|
||||
+ sizeof(net->ipv4.ip_id_key));
|
||||
|
||||
- hash = jhash_3words((__force u32)iph->daddr,
|
||||
+ hash = siphash_3u32((__force u32)iph->daddr,
|
||||
(__force u32)iph->saddr,
|
||||
- iph->protocol ^ net_hash_mix(net),
|
||||
- ip_idents_hashrnd);
|
||||
+ iph->protocol,
|
||||
+ &net->ipv4.ip_id_key);
|
||||
id = ip_idents_reserve(hash, segs);
|
||||
iph->id = htons(id);
|
||||
}
|
||||
diff --git a/net/ipv6/output_core.c b/net/ipv6/output_core.c
|
||||
index 4fe7c90962dd..868ae23dbae1 100644
|
||||
--- a/net/ipv6/output_core.c
|
||||
+++ b/net/ipv6/output_core.c
|
||||
@@ -10,15 +10,25 @@
|
||||
#include <net/secure_seq.h>
|
||||
#include <linux/netfilter.h>
|
||||
|
||||
-static u32 __ipv6_select_ident(struct net *net, u32 hashrnd,
|
||||
+static u32 __ipv6_select_ident(struct net *net,
|
||||
const struct in6_addr *dst,
|
||||
const struct in6_addr *src)
|
||||
{
|
||||
+ const struct {
|
||||
+ struct in6_addr dst;
|
||||
+ struct in6_addr src;
|
||||
+ } __aligned(SIPHASH_ALIGNMENT) combined = {
|
||||
+ .dst = *dst,
|
||||
+ .src = *src,
|
||||
+ };
|
||||
u32 hash, id;
|
||||
|
||||
- hash = __ipv6_addr_jhash(dst, hashrnd);
|
||||
- hash = __ipv6_addr_jhash(src, hash);
|
||||
- hash ^= net_hash_mix(net);
|
||||
+ /* Note the following code is not safe, but this is okay. */
|
||||
+ if (unlikely(siphash_key_is_zero(&net->ipv4.ip_id_key)))
|
||||
+ get_random_bytes(&net->ipv4.ip_id_key,
|
||||
+ sizeof(net->ipv4.ip_id_key));
|
||||
+
|
||||
+ hash = siphash(&combined, sizeof(combined), &net->ipv4.ip_id_key);
|
||||
|
||||
/* Treat id of 0 as unset and if we get 0 back from ip_idents_reserve,
|
||||
* set the hight order instead thus minimizing possible future
|
||||
@@ -41,7 +51,6 @@ static u32 __ipv6_select_ident(struct net *net, u32 hashrnd,
|
||||
*/
|
||||
__be32 ipv6_proxy_select_ident(struct net *net, struct sk_buff *skb)
|
||||
{
|
||||
- static u32 ip6_proxy_idents_hashrnd __read_mostly;
|
||||
struct in6_addr buf[2];
|
||||
struct in6_addr *addrs;
|
||||
u32 id;
|
||||
@@ -53,11 +62,7 @@ __be32 ipv6_proxy_select_ident(struct net *net, struct sk_buff *skb)
|
||||
if (!addrs)
|
||||
return 0;
|
||||
|
||||
- net_get_random_once(&ip6_proxy_idents_hashrnd,
|
||||
- sizeof(ip6_proxy_idents_hashrnd));
|
||||
-
|
||||
- id = __ipv6_select_ident(net, ip6_proxy_idents_hashrnd,
|
||||
- &addrs[1], &addrs[0]);
|
||||
+ id = __ipv6_select_ident(net, &addrs[1], &addrs[0]);
|
||||
return htonl(id);
|
||||
}
|
||||
EXPORT_SYMBOL_GPL(ipv6_proxy_select_ident);
|
||||
@@ -66,12 +71,9 @@ __be32 ipv6_select_ident(struct net *net,
|
||||
const struct in6_addr *daddr,
|
||||
const struct in6_addr *saddr)
|
||||
{
|
||||
- static u32 ip6_idents_hashrnd __read_mostly;
|
||||
u32 id;
|
||||
|
||||
- net_get_random_once(&ip6_idents_hashrnd, sizeof(ip6_idents_hashrnd));
|
||||
-
|
||||
- id = __ipv6_select_ident(net, ip6_idents_hashrnd, daddr, saddr);
|
||||
+ id = __ipv6_select_ident(net, daddr, saddr);
|
||||
return htonl(id);
|
||||
}
|
||||
EXPORT_SYMBOL(ipv6_select_ident);
|
||||
--
|
||||
cgit 1.2-0.3.lf.el7
|
||||
|
|
@ -0,0 +1,36 @@
|
|||
From: Young Xiao <92siuyang@gmail.com>
|
||||
Date: Fri, 14 Jun 2019 15:13:02 +0800
|
||||
Subject: nfc: Ensure presence of required attributes in the deactivate_target
|
||||
handler
|
||||
Origin: https://git.kernel.org/linus/385097a3675749cbc9e97c085c0e5dfe4269ca51
|
||||
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2019-12984
|
||||
|
||||
Check that the NFC_ATTR_TARGET_INDEX attributes (in addition to
|
||||
NFC_ATTR_DEVICE_INDEX) are provided by the netlink client prior to
|
||||
accessing them. This prevents potential unhandled NULL pointer dereference
|
||||
exceptions which can be triggered by malicious user-mode programs,
|
||||
if they omit one or both of these attributes.
|
||||
|
||||
Signed-off-by: Young Xiao <92siuyang@gmail.com>
|
||||
Signed-off-by: David S. Miller <davem@davemloft.net>
|
||||
---
|
||||
net/nfc/netlink.c | 3 ++-
|
||||
1 file changed, 2 insertions(+), 1 deletion(-)
|
||||
|
||||
diff --git a/net/nfc/netlink.c b/net/nfc/netlink.c
|
||||
index 1180b3e58a0a..ea64c90b14e8 100644
|
||||
--- a/net/nfc/netlink.c
|
||||
+++ b/net/nfc/netlink.c
|
||||
@@ -911,7 +911,8 @@ static int nfc_genl_deactivate_target(struct sk_buff *skb,
|
||||
u32 device_idx, target_idx;
|
||||
int rc;
|
||||
|
||||
- if (!info->attrs[NFC_ATTR_DEVICE_INDEX])
|
||||
+ if (!info->attrs[NFC_ATTR_DEVICE_INDEX] ||
|
||||
+ !info->attrs[NFC_ATTR_TARGET_INDEX])
|
||||
return -EINVAL;
|
||||
|
||||
device_idx = nla_get_u32(info->attrs[NFC_ATTR_DEVICE_INDEX]);
|
||||
--
|
||||
cgit 1.2-0.3.lf.el7
|
||||
|
65
debian/patches/bugfix/all/scsi-libsas-fix-a-race-condition-when-smp-task-timeout.patch
vendored
Normal file
65
debian/patches/bugfix/all/scsi-libsas-fix-a-race-condition-when-smp-task-timeout.patch
vendored
Normal file
|
@ -0,0 +1,65 @@
|
|||
From b90cd6f2b905905fb42671009dc0e27c310a16ae Mon Sep 17 00:00:00 2001
|
||||
From: Jason Yan <yanaijie@huawei.com>
|
||||
Date: Tue, 25 Sep 2018 10:56:54 +0800
|
||||
Subject: scsi: libsas: fix a race condition when smp task timeout
|
||||
Origin: https://git.kernel.org/linus/b90cd6f2b905905fb42671009dc0e27c310a16ae
|
||||
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2018-20836
|
||||
|
||||
When the lldd is processing the complete sas task in interrupt and set the
|
||||
task stat as SAS_TASK_STATE_DONE, the smp timeout timer is able to be
|
||||
triggered at the same time. And smp_task_timedout() will complete the task
|
||||
wheter the SAS_TASK_STATE_DONE is set or not. Then the sas task may freed
|
||||
before lldd end the interrupt process. Thus a use-after-free will happen.
|
||||
|
||||
Fix this by calling the complete() only when SAS_TASK_STATE_DONE is not
|
||||
set. And remove the check of the return value of the del_timer(). Once the
|
||||
LLDD sets DONE, it must call task->done(), which will call
|
||||
smp_task_done()->complete() and the task will be completed and freed
|
||||
correctly.
|
||||
|
||||
Reported-by: chenxiang <chenxiang66@hisilicon.com>
|
||||
Signed-off-by: Jason Yan <yanaijie@huawei.com>
|
||||
CC: John Garry <john.garry@huawei.com>
|
||||
CC: Johannes Thumshirn <jthumshirn@suse.de>
|
||||
CC: Ewan Milne <emilne@redhat.com>
|
||||
CC: Christoph Hellwig <hch@lst.de>
|
||||
CC: Tomas Henzl <thenzl@redhat.com>
|
||||
CC: Dan Williams <dan.j.williams@intel.com>
|
||||
CC: Hannes Reinecke <hare@suse.com>
|
||||
Reviewed-by: Hannes Reinecke <hare@suse.com>
|
||||
Reviewed-by: John Garry <john.garry@huawei.com>
|
||||
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
|
||||
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
---
|
||||
drivers/scsi/libsas/sas_expander.c | 9 ++++-----
|
||||
1 file changed, 4 insertions(+), 5 deletions(-)
|
||||
|
||||
diff --git a/drivers/scsi/libsas/sas_expander.c b/drivers/scsi/libsas/sas_expander.c
|
||||
index 52222940d398..0d1f72752ca2 100644
|
||||
--- a/drivers/scsi/libsas/sas_expander.c
|
||||
+++ b/drivers/scsi/libsas/sas_expander.c
|
||||
@@ -48,17 +48,16 @@ static void smp_task_timedout(struct timer_list *t)
|
||||
unsigned long flags;
|
||||
|
||||
spin_lock_irqsave(&task->task_state_lock, flags);
|
||||
- if (!(task->task_state_flags & SAS_TASK_STATE_DONE))
|
||||
+ if (!(task->task_state_flags & SAS_TASK_STATE_DONE)) {
|
||||
task->task_state_flags |= SAS_TASK_STATE_ABORTED;
|
||||
+ complete(&task->slow_task->completion);
|
||||
+ }
|
||||
spin_unlock_irqrestore(&task->task_state_lock, flags);
|
||||
-
|
||||
- complete(&task->slow_task->completion);
|
||||
}
|
||||
|
||||
static void smp_task_done(struct sas_task *task)
|
||||
{
|
||||
- if (!del_timer(&task->slow_task->timer))
|
||||
- return;
|
||||
+ del_timer(&task->slow_task->timer);
|
||||
complete(&task->slow_task->completion);
|
||||
}
|
||||
|
||||
--
|
||||
cgit 1.2-0.3.lf.el7
|
||||
|
140
debian/patches/bugfix/powerpc/powerpc-mm-64s-hash-Reallocate-context-ids-on-fork.patch
vendored
Normal file
140
debian/patches/bugfix/powerpc/powerpc-mm-64s-hash-Reallocate-context-ids-on-fork.patch
vendored
Normal file
|
@ -0,0 +1,140 @@
|
|||
From: Michael Ellerman <mpe@ellerman.id.au>
|
||||
Date: Wed, 12 Jun 2019 23:35:07 +1000
|
||||
Subject: powerpc/mm/64s/hash: Reallocate context ids on fork
|
||||
Origin: https://git.kernel.org/linus/ca72d88378b2f2444d3ec145dd442d449d3fefbc
|
||||
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2019-12817
|
||||
|
||||
When using the Hash Page Table (HPT) MMU, userspace memory mappings
|
||||
are managed at two levels. Firstly in the Linux page tables, much like
|
||||
other architectures, and secondly in the SLB (Segment Lookaside
|
||||
Buffer) and HPT. It's the SLB and HPT that are actually used by the
|
||||
hardware to do translations.
|
||||
|
||||
As part of the series adding support for 4PB user virtual address
|
||||
space using the hash MMU, we added support for allocating multiple
|
||||
"context ids" per process, one for each 512TB chunk of address space.
|
||||
These are tracked in an array called extended_id in the mm_context_t
|
||||
of a process that has done a mapping above 512TB.
|
||||
|
||||
If such a process forks (ie. clone(2) without CLONE_VM set) it's mm is
|
||||
copied, including the mm_context_t, and then init_new_context() is
|
||||
called to reinitialise parts of the mm_context_t as appropriate to
|
||||
separate the address spaces of the two processes.
|
||||
|
||||
The key step in ensuring the two processes have separate address
|
||||
spaces is to allocate a new context id for the process, this is done
|
||||
at the beginning of hash__init_new_context(). If we didn't allocate a
|
||||
new context id then the two processes would share mappings as far as
|
||||
the SLB and HPT are concerned, even though their Linux page tables
|
||||
would be separate.
|
||||
|
||||
For mappings above 512TB, which use the extended_id array, we
|
||||
neglected to allocate new context ids on fork, meaning the parent and
|
||||
child use the same ids and therefore share those mappings even though
|
||||
they're supposed to be separate. This can lead to the parent seeing
|
||||
writes done by the child, which is essentially memory corruption.
|
||||
|
||||
There is an additional exposure which is that if the child process
|
||||
exits, all its context ids are freed, including the context ids that
|
||||
are still in use by the parent for mappings above 512TB. One or more
|
||||
of those ids can then be reallocated to a third process, that process
|
||||
can then read/write to the parent's mappings above 512TB. Additionally
|
||||
if the freed id is used for the third process's primary context id,
|
||||
then the parent is able to read/write to the third process's mappings
|
||||
*below* 512TB.
|
||||
|
||||
All of these are fundamental failures to enforce separation between
|
||||
processes. The only mitigating factor is that the bug only occurs if a
|
||||
process creates mappings above 512TB, and most applications still do
|
||||
not create such mappings.
|
||||
|
||||
Only machines using the hash page table MMU are affected, eg. PowerPC
|
||||
970 (G5), PA6T, Power5/6/7/8/9. By default Power9 bare metal machines
|
||||
(powernv) use the Radix MMU and are not affected, unless the machine
|
||||
has been explicitly booted in HPT mode (using disable_radix on the
|
||||
kernel command line). KVM guests on Power9 may be affected if the host
|
||||
or guest is configured to use the HPT MMU. LPARs under PowerVM on
|
||||
Power9 are affected as they always use the HPT MMU. Kernels built with
|
||||
PAGE_SIZE=4K are not affected.
|
||||
|
||||
The fix is relatively simple, we need to reallocate context ids for
|
||||
all extended mappings on fork.
|
||||
|
||||
Fixes: f384796c40dc ("powerpc/mm: Add support for handling > 512TB address in SLB miss")
|
||||
Cc: stable@vger.kernel.org # v4.17+
|
||||
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
||||
---
|
||||
arch/powerpc/mm/mmu_context_book3s64.c | 46 +++++++++++++++++++++++---
|
||||
1 file changed, 42 insertions(+), 4 deletions(-)
|
||||
|
||||
diff --git a/arch/powerpc/mm/mmu_context_book3s64.c b/arch/powerpc/mm/mmu_context_book3s64.c
|
||||
index dbd8f762140b..68984d85ad6b 100644
|
||||
--- a/arch/powerpc/mm/mmu_context_book3s64.c
|
||||
+++ b/arch/powerpc/mm/mmu_context_book3s64.c
|
||||
@@ -53,14 +53,48 @@ int hash__alloc_context_id(void)
|
||||
}
|
||||
EXPORT_SYMBOL_GPL(hash__alloc_context_id);
|
||||
|
||||
+static int realloc_context_ids(mm_context_t *ctx)
|
||||
+{
|
||||
+ int i, id;
|
||||
+
|
||||
+ /*
|
||||
+ * id 0 (aka. ctx->id) is special, we always allocate a new one, even if
|
||||
+ * there wasn't one allocated previously (which happens in the exec
|
||||
+ * case where ctx is newly allocated).
|
||||
+ *
|
||||
+ * We have to be a bit careful here. We must keep the existing ids in
|
||||
+ * the array, so that we can test if they're non-zero to decide if we
|
||||
+ * need to allocate a new one. However in case of error we must free the
|
||||
+ * ids we've allocated but *not* any of the existing ones (or risk a
|
||||
+ * UAF). That's why we decrement i at the start of the error handling
|
||||
+ * loop, to skip the id that we just tested but couldn't reallocate.
|
||||
+ */
|
||||
+ for (i = 0; i < ARRAY_SIZE(ctx->extended_id); i++) {
|
||||
+ if (i == 0 || ctx->extended_id[i]) {
|
||||
+ id = hash__alloc_context_id();
|
||||
+ if (id < 0)
|
||||
+ goto error;
|
||||
+
|
||||
+ ctx->extended_id[i] = id;
|
||||
+ }
|
||||
+ }
|
||||
+
|
||||
+ /* The caller expects us to return id */
|
||||
+ return ctx->id;
|
||||
+
|
||||
+error:
|
||||
+ for (i--; i >= 0; i--) {
|
||||
+ if (ctx->extended_id[i])
|
||||
+ ida_free(&mmu_context_ida, ctx->extended_id[i]);
|
||||
+ }
|
||||
+
|
||||
+ return id;
|
||||
+}
|
||||
+
|
||||
static int hash__init_new_context(struct mm_struct *mm)
|
||||
{
|
||||
int index;
|
||||
|
||||
- index = hash__alloc_context_id();
|
||||
- if (index < 0)
|
||||
- return index;
|
||||
-
|
||||
/*
|
||||
* The old code would re-promote on fork, we don't do that when using
|
||||
* slices as it could cause problem promoting slices that have been
|
||||
@@ -78,6 +112,10 @@ static int hash__init_new_context(struct mm_struct *mm)
|
||||
if (mm->context.id == 0)
|
||||
slice_init_new_context_exec(mm);
|
||||
|
||||
+ index = realloc_context_ids(&mm->context);
|
||||
+ if (index < 0)
|
||||
+ return index;
|
||||
+
|
||||
subpage_prot_init_new_context(mm);
|
||||
|
||||
pkey_mm_init(mm);
|
||||
--
|
||||
2.20.1
|
||||
|
96
debian/patches/bugfix/powerpc/powerpc-tm-Fix-oops-on-sigreturn-on-systems-without-TM.patch
vendored
Normal file
96
debian/patches/bugfix/powerpc/powerpc-tm-Fix-oops-on-sigreturn-on-systems-without-TM.patch
vendored
Normal file
|
@ -0,0 +1,96 @@
|
|||
From: Michael Neuling <mikey@neuling.org>
|
||||
Date: Fri, 19 Jul 2019 15:05:02 +1000
|
||||
Subject: powerpc/tm: Fix oops on sigreturn on systems without TM
|
||||
Origin: https://git.kernel.org/torvalds/c/f16d80b75a096c52354c6e0a574993f3b0dfbdfe
|
||||
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2019-13648
|
||||
|
||||
commit f16d80b75a096c52354c6e0a574993f3b0dfbdfe upstream.
|
||||
|
||||
On systems like P9 powernv where we have no TM (or P8 booted with
|
||||
ppc_tm=off), userspace can construct a signal context which still has
|
||||
the MSR TS bits set. The kernel tries to restore this context which
|
||||
results in the following crash:
|
||||
|
||||
Unexpected TM Bad Thing exception at c0000000000022fc (msr 0x8000000102a03031) tm_scratch=800000020280f033
|
||||
Oops: Unrecoverable exception, sig: 6 [#1]
|
||||
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
|
||||
Modules linked in:
|
||||
CPU: 0 PID: 1636 Comm: sigfuz Not tainted 5.2.0-11043-g0a8ad0ffa4 #69
|
||||
NIP: c0000000000022fc LR: 00007fffb2d67e48 CTR: 0000000000000000
|
||||
REGS: c00000003fffbd70 TRAP: 0700 Not tainted (5.2.0-11045-g7142b497d8)
|
||||
MSR: 8000000102a03031 <SF,VEC,VSX,FP,ME,IR,DR,LE,TM[E]> CR: 42004242 XER: 00000000
|
||||
CFAR: c0000000000022e0 IRQMASK: 0
|
||||
GPR00: 0000000000000072 00007fffb2b6e560 00007fffb2d87f00 0000000000000669
|
||||
GPR04: 00007fffb2b6e728 0000000000000000 0000000000000000 00007fffb2b6f2a8
|
||||
GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
|
||||
GPR12: 0000000000000000 00007fffb2b76900 0000000000000000 0000000000000000
|
||||
GPR16: 00007fffb2370000 00007fffb2d84390 00007fffea3a15ac 000001000a250420
|
||||
GPR20: 00007fffb2b6f260 0000000010001770 0000000000000000 0000000000000000
|
||||
GPR24: 00007fffb2d843a0 00007fffea3a14a0 0000000000010000 0000000000800000
|
||||
GPR28: 00007fffea3a14d8 00000000003d0f00 0000000000000000 00007fffb2b6e728
|
||||
NIP [c0000000000022fc] rfi_flush_fallback+0x7c/0x80
|
||||
LR [00007fffb2d67e48] 0x7fffb2d67e48
|
||||
Call Trace:
|
||||
Instruction dump:
|
||||
e96a0220 e96a02a8 e96a0330 e96a03b8 394a0400 4200ffdc 7d2903a6 e92d0c00
|
||||
e94d0c08 e96d0c10 e82d0c18 7db242a6 <4c000024> 7db243a6 7db142a6 f82d0c18
|
||||
|
||||
The problem is the signal code assumes TM is enabled when
|
||||
CONFIG_PPC_TRANSACTIONAL_MEM is enabled. This may not be the case as
|
||||
with P9 powernv or if `ppc_tm=off` is used on P8.
|
||||
|
||||
This means any local user can crash the system.
|
||||
|
||||
Fix the problem by returning a bad stack frame to the user if they try
|
||||
to set the MSR TS bits with sigreturn() on systems where TM is not
|
||||
supported.
|
||||
|
||||
Found with sigfuz kernel selftest on P9.
|
||||
|
||||
This fixes CVE-2019-13648.
|
||||
|
||||
Fixes: 2b0a576d15e0 ("powerpc: Add new transactional memory state to the signal context")
|
||||
Cc: stable@vger.kernel.org # v3.9
|
||||
Reported-by: Praveen Pandey <Praveen.Pandey@in.ibm.com>
|
||||
Signed-off-by: Michael Neuling <mikey@neuling.org>
|
||||
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
||||
Link: https://lore.kernel.org/r/20190719050502.405-1-mikey@neuling.org
|
||||
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
---
|
||||
arch/powerpc/kernel/signal_32.c | 3 +++
|
||||
arch/powerpc/kernel/signal_64.c | 5 +++++
|
||||
2 files changed, 8 insertions(+)
|
||||
|
||||
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
|
||||
index fd59fef9931b..906b05c2adae 100644
|
||||
--- a/arch/powerpc/kernel/signal_32.c
|
||||
+++ b/arch/powerpc/kernel/signal_32.c
|
||||
@@ -1202,6 +1202,9 @@ SYSCALL_DEFINE0(rt_sigreturn)
|
||||
goto bad;
|
||||
|
||||
if (MSR_TM_ACTIVE(msr_hi<<32)) {
|
||||
+ /* Trying to start TM on non TM system */
|
||||
+ if (!cpu_has_feature(CPU_FTR_TM))
|
||||
+ goto bad;
|
||||
/* We only recheckpoint on return if we're
|
||||
* transaction.
|
||||
*/
|
||||
diff --git a/arch/powerpc/kernel/signal_64.c b/arch/powerpc/kernel/signal_64.c
|
||||
index 14b0f5b6a373..b5933d7219db 100644
|
||||
--- a/arch/powerpc/kernel/signal_64.c
|
||||
+++ b/arch/powerpc/kernel/signal_64.c
|
||||
@@ -750,6 +750,11 @@ SYSCALL_DEFINE0(rt_sigreturn)
|
||||
if (MSR_TM_ACTIVE(msr)) {
|
||||
/* We recheckpoint on return. */
|
||||
struct ucontext __user *uc_transact;
|
||||
+
|
||||
+ /* Trying to start TM on non TM system */
|
||||
+ if (!cpu_has_feature(CPU_FTR_TM))
|
||||
+ goto badframe;
|
||||
+
|
||||
if (__get_user(uc_transact, &uc->uc_link))
|
||||
goto badframe;
|
||||
if (restore_tm_sigcontexts(current, &uc->uc_mcontext,
|
||||
--
|
||||
cgit 1.2-0.3.lf.el7
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
From 6d7cc74d8aad33589c6cc6f38e33c4284abc07b8 Mon Sep 17 00:00:00 2001
|
||||
From: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
|
||||
Date: Wed, 12 Jun 2019 15:08:37 +0200
|
||||
Subject: [PATCH 1/1] arch/sh: Check for kprobe trap number before trying to
|
||||
handle a kprobe trap
|
||||
Origin: https://marc.info/?l=linux-sh&m=156034655921917&w=2
|
||||
|
||||
The DIE_TRAP notifier chain is run both for kprobe traps and for BUG/WARN
|
||||
traps. The kprobe code assumes to be only called for
|
||||
BREAKPOINT_INSTRUCTION, and concludes to have hit a concurrently removed
|
||||
kprobe if it finds anything else at the faulting locations. This includes
|
||||
TRAPA_BUG_OPCODE used for BUG and WARN.
|
||||
|
||||
The consequence is that kprobe_handler returns 1. This makes
|
||||
kprobe_exceptions_notify return NOTIFY_STOP, and prevents handling the BUG
|
||||
statement. This also prevents moving $pc away from the trap instruction,
|
||||
so the system locks up in an endless loop
|
||||
|
||||
Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
|
||||
---
|
||||
arch/sh/kernel/kprobes.c | 3 ++-
|
||||
1 file changed, 2 insertions(+), 1 deletion(-)
|
||||
|
||||
diff --git a/arch/sh/kernel/kprobes.c b/arch/sh/kernel/kprobes.c
|
||||
index 1f8c0d30567f..318296f48f1a 100644
|
||||
--- a/arch/sh/kernel/kprobes.c
|
||||
+++ b/arch/sh/kernel/kprobes.c
|
||||
@@ -485,7 +485,8 @@ int __kprobes kprobe_exceptions_notify(struct notifier_block *self,
|
||||
struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
|
||||
|
||||
addr = (kprobe_opcode_t *) (args->regs->pc);
|
||||
- if (val == DIE_TRAP) {
|
||||
+ if (val == DIE_TRAP &&
|
||||
+ args->trapnr == (BREAKPOINT_INSTRUCTION & 0xff)) {
|
||||
if (!kprobe_running()) {
|
||||
if (kprobe_handler(args->regs)) {
|
||||
ret = NOTIFY_STOP;
|
||||
--
|
||||
2.11.0
|
||||
|
110
debian/patches/bugfix/x86/x86-cpufeatures-Carve-out-CQM-features-retrieval.patch
vendored
Normal file
110
debian/patches/bugfix/x86/x86-cpufeatures-Carve-out-CQM-features-retrieval.patch
vendored
Normal file
|
@ -0,0 +1,110 @@
|
|||
From: Borislav Petkov <bp@suse.de>
|
||||
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 <fenghua.yu@intel.com> to keep the mechanical,
|
||||
sole code movement separate for easy review.
|
||||
|
||||
No functional changes.
|
||||
|
||||
Signed-off-by: Borislav Petkov <bp@suse.de>
|
||||
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
||||
Cc: Fenghua Yu <fenghua.yu@intel.com>
|
||||
Cc: x86@kernel.org
|
||||
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
---
|
||||
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
|
||||
|
211
debian/patches/bugfix/x86/x86-cpufeatures-Combine-word-11-and-12-into-a-new-sc.patch
vendored
Normal file
211
debian/patches/bugfix/x86/x86-cpufeatures-Combine-word-11-and-12-into-a-new-sc.patch
vendored
Normal file
|
@ -0,0 +1,211 @@
|
|||
From: Fenghua Yu <fenghua.yu@intel.com>
|
||||
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 <fenghua.yu@intel.com>
|
||||
Signed-off-by: Borislav Petkov <bp@suse.de>
|
||||
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
||||
Cc: Aaron Lewis <aaronlewis@google.com>
|
||||
Cc: Andy Lutomirski <luto@kernel.org>
|
||||
Cc: Babu Moger <babu.moger@amd.com>
|
||||
Cc: "Chang S. Bae" <chang.seok.bae@intel.com>
|
||||
Cc: "Sean J Christopherson" <sean.j.christopherson@intel.com>
|
||||
Cc: Frederic Weisbecker <frederic@kernel.org>
|
||||
Cc: "H. Peter Anvin" <hpa@zytor.com>
|
||||
Cc: Ingo Molnar <mingo@redhat.com>
|
||||
Cc: Jann Horn <jannh@google.com>
|
||||
Cc: Juergen Gross <jgross@suse.com>
|
||||
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
Cc: kvm ML <kvm@vger.kernel.org>
|
||||
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
|
||||
Cc: Masami Hiramatsu <mhiramat@kernel.org>
|
||||
Cc: Nadav Amit <namit@vmware.com>
|
||||
Cc: Paolo Bonzini <pbonzini@redhat.com>
|
||||
Cc: Pavel Tatashin <pasha.tatashin@oracle.com>
|
||||
Cc: Peter Feiner <pfeiner@google.com>
|
||||
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
|
||||
Cc: "Radim Krčmář" <rkrcmar@redhat.com>
|
||||
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
|
||||
Cc: Ravi V Shankar <ravi.v.shankar@intel.com>
|
||||
Cc: Sherry Hurwitz <sherry.hurwitz@amd.com>
|
||||
Cc: Thomas Gleixner <tglx@linutronix.de>
|
||||
Cc: Thomas Lendacky <Thomas.Lendacky@amd.com>
|
||||
Cc: x86 <x86@kernel.org>
|
||||
Link: https://lkml.kernel.org/r/1560794416-217638-2-git-send-email-fenghua.yu@intel.com
|
||||
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
---
|
||||
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
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
From: Josh Poimboeuf <jpoimboe@redhat.com>
|
||||
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 <jpoimboe@redhat.com>
|
||||
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
||||
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
---
|
||||
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
|
||||
|
175
debian/patches/bugfix/x86/x86-insn-eval-Fix-use-after-free-access-to-LDT-entry.patch
vendored
Normal file
175
debian/patches/bugfix/x86/x86-insn-eval-Fix-use-after-free-access-to-LDT-entry.patch
vendored
Normal file
|
@ -0,0 +1,175 @@
|
|||
From: Jann Horn <jannh@google.com>
|
||||
Date: Sun, 2 Jun 2019 03:15:58 +0200
|
||||
Subject: x86/insn-eval: Fix use-after-free access to LDT entry
|
||||
Origin: https://git.kernel.org/linus/de9f869616dd95e95c00bdd6b0fcd3421e8a4323
|
||||
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2019-13233
|
||||
|
||||
get_desc() computes a pointer into the LDT while holding a lock that
|
||||
protects the LDT from being freed, but then drops the lock and returns the
|
||||
(now potentially dangling) pointer to its caller.
|
||||
|
||||
Fix it by giving the caller a copy of the LDT entry instead.
|
||||
|
||||
Fixes: 670f928ba09b ("x86/insn-eval: Add utility function to get segment descriptor")
|
||||
Cc: stable@vger.kernel.org
|
||||
Signed-off-by: Jann Horn <jannh@google.com>
|
||||
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
||||
---
|
||||
arch/x86/lib/insn-eval.c | 47 ++++++++++++++++++++++++-----------------------
|
||||
1 file changed, 24 insertions(+), 23 deletions(-)
|
||||
|
||||
diff --git a/arch/x86/lib/insn-eval.c b/arch/x86/lib/insn-eval.c
|
||||
index cf00ab6c6621..306c3a0902ba 100644
|
||||
--- a/arch/x86/lib/insn-eval.c
|
||||
+++ b/arch/x86/lib/insn-eval.c
|
||||
@@ -557,7 +557,8 @@ static int get_reg_offset_16(struct insn *insn, struct pt_regs *regs,
|
||||
}
|
||||
|
||||
/**
|
||||
- * get_desc() - Obtain pointer to a segment descriptor
|
||||
+ * get_desc() - Obtain contents of a segment descriptor
|
||||
+ * @out: Segment descriptor contents on success
|
||||
* @sel: Segment selector
|
||||
*
|
||||
* Given a segment selector, obtain a pointer to the segment descriptor.
|
||||
@@ -565,18 +566,18 @@ static int get_reg_offset_16(struct insn *insn, struct pt_regs *regs,
|
||||
*
|
||||
* Returns:
|
||||
*
|
||||
- * Pointer to segment descriptor on success.
|
||||
+ * True on success, false on failure.
|
||||
*
|
||||
* NULL on error.
|
||||
*/
|
||||
-static struct desc_struct *get_desc(unsigned short sel)
|
||||
+static bool get_desc(struct desc_struct *out, unsigned short sel)
|
||||
{
|
||||
struct desc_ptr gdt_desc = {0, 0};
|
||||
unsigned long desc_base;
|
||||
|
||||
#ifdef CONFIG_MODIFY_LDT_SYSCALL
|
||||
if ((sel & SEGMENT_TI_MASK) == SEGMENT_LDT) {
|
||||
- struct desc_struct *desc = NULL;
|
||||
+ bool success = false;
|
||||
struct ldt_struct *ldt;
|
||||
|
||||
/* Bits [15:3] contain the index of the desired entry. */
|
||||
@@ -584,12 +585,14 @@ static struct desc_struct *get_desc(unsigned short sel)
|
||||
|
||||
mutex_lock(¤t->active_mm->context.lock);
|
||||
ldt = current->active_mm->context.ldt;
|
||||
- if (ldt && sel < ldt->nr_entries)
|
||||
- desc = &ldt->entries[sel];
|
||||
+ if (ldt && sel < ldt->nr_entries) {
|
||||
+ *out = ldt->entries[sel];
|
||||
+ success = true;
|
||||
+ }
|
||||
|
||||
mutex_unlock(¤t->active_mm->context.lock);
|
||||
|
||||
- return desc;
|
||||
+ return success;
|
||||
}
|
||||
#endif
|
||||
native_store_gdt(&gdt_desc);
|
||||
@@ -604,9 +607,10 @@ static struct desc_struct *get_desc(unsigned short sel)
|
||||
desc_base = sel & ~(SEGMENT_RPL_MASK | SEGMENT_TI_MASK);
|
||||
|
||||
if (desc_base > gdt_desc.size)
|
||||
- return NULL;
|
||||
+ return false;
|
||||
|
||||
- return (struct desc_struct *)(gdt_desc.address + desc_base);
|
||||
+ *out = *(struct desc_struct *)(gdt_desc.address + desc_base);
|
||||
+ return true;
|
||||
}
|
||||
|
||||
/**
|
||||
@@ -628,7 +632,7 @@ static struct desc_struct *get_desc(unsigned short sel)
|
||||
*/
|
||||
unsigned long insn_get_seg_base(struct pt_regs *regs, int seg_reg_idx)
|
||||
{
|
||||
- struct desc_struct *desc;
|
||||
+ struct desc_struct desc;
|
||||
short sel;
|
||||
|
||||
sel = get_segment_selector(regs, seg_reg_idx);
|
||||
@@ -666,11 +670,10 @@ unsigned long insn_get_seg_base(struct pt_regs *regs, int seg_reg_idx)
|
||||
if (!sel)
|
||||
return -1L;
|
||||
|
||||
- desc = get_desc(sel);
|
||||
- if (!desc)
|
||||
+ if (!get_desc(&desc, sel))
|
||||
return -1L;
|
||||
|
||||
- return get_desc_base(desc);
|
||||
+ return get_desc_base(&desc);
|
||||
}
|
||||
|
||||
/**
|
||||
@@ -692,7 +695,7 @@ unsigned long insn_get_seg_base(struct pt_regs *regs, int seg_reg_idx)
|
||||
*/
|
||||
static unsigned long get_seg_limit(struct pt_regs *regs, int seg_reg_idx)
|
||||
{
|
||||
- struct desc_struct *desc;
|
||||
+ struct desc_struct desc;
|
||||
unsigned long limit;
|
||||
short sel;
|
||||
|
||||
@@ -706,8 +709,7 @@ static unsigned long get_seg_limit(struct pt_regs *regs, int seg_reg_idx)
|
||||
if (!sel)
|
||||
return 0;
|
||||
|
||||
- desc = get_desc(sel);
|
||||
- if (!desc)
|
||||
+ if (!get_desc(&desc, sel))
|
||||
return 0;
|
||||
|
||||
/*
|
||||
@@ -716,8 +718,8 @@ static unsigned long get_seg_limit(struct pt_regs *regs, int seg_reg_idx)
|
||||
* not tested when checking the segment limits. In practice,
|
||||
* this means that the segment ends in (limit << 12) + 0xfff.
|
||||
*/
|
||||
- limit = get_desc_limit(desc);
|
||||
- if (desc->g)
|
||||
+ limit = get_desc_limit(&desc);
|
||||
+ if (desc.g)
|
||||
limit = (limit << 12) + 0xfff;
|
||||
|
||||
return limit;
|
||||
@@ -741,7 +743,7 @@ static unsigned long get_seg_limit(struct pt_regs *regs, int seg_reg_idx)
|
||||
*/
|
||||
int insn_get_code_seg_params(struct pt_regs *regs)
|
||||
{
|
||||
- struct desc_struct *desc;
|
||||
+ struct desc_struct desc;
|
||||
short sel;
|
||||
|
||||
if (v8086_mode(regs))
|
||||
@@ -752,8 +754,7 @@ int insn_get_code_seg_params(struct pt_regs *regs)
|
||||
if (sel < 0)
|
||||
return sel;
|
||||
|
||||
- desc = get_desc(sel);
|
||||
- if (!desc)
|
||||
+ if (!get_desc(&desc, sel))
|
||||
return -EINVAL;
|
||||
|
||||
/*
|
||||
@@ -761,10 +762,10 @@ int insn_get_code_seg_params(struct pt_regs *regs)
|
||||
* determines whether a segment contains data or code. If this is a data
|
||||
* segment, return error.
|
||||
*/
|
||||
- if (!(desc->type & BIT(3)))
|
||||
+ if (!(desc.type & BIT(3)))
|
||||
return -EINVAL;
|
||||
|
||||
- switch ((desc->l << 1) | desc->d) {
|
||||
+ switch ((desc.l << 1) | desc.d) {
|
||||
case 0: /*
|
||||
* Legacy mode. CS.L=0, CS.D=0. Address and operand size are
|
||||
* both 16-bit.
|
||||
--
|
||||
cgit 1.2-0.3.lf.el7
|
||||
|
261
debian/patches/bugfix/x86/x86-speculation-Enable-Spectre-v1-swapgs-mitigations.patch
vendored
Normal file
261
debian/patches/bugfix/x86/x86-speculation-Enable-Spectre-v1-swapgs-mitigations.patch
vendored
Normal file
|
@ -0,0 +1,261 @@
|
|||
From: Josh Poimboeuf <jpoimboe@redhat.com>
|
||||
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:<percpu_offset>, %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:<percpu_offset>, %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 <jpoimboe@redhat.com>
|
||||
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
||||
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
|
||||
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
---
|
||||
.../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 <asm/e820/api.h>
|
||||
#include <asm/hypervisor.h>
|
||||
|
||||
+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],
|
200
debian/patches/bugfix/x86/x86-speculation-Prepare-entry-code-for-Spectre-v1-sw.patch
vendored
Normal file
200
debian/patches/bugfix/x86/x86-speculation-Prepare-entry-code-for-Spectre-v1-sw.patch
vendored
Normal file
|
@ -0,0 +1,200 @@
|
|||
From: Josh Poimboeuf <jpoimboe@redhat.com>
|
||||
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:<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.
|
||||
|
||||
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 <jpoimboe@redhat.com>
|
||||
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
||||
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
|
||||
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
---
|
||||
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
|
||||
|
159
debian/patches/bugfix/x86/x86-speculation-swapgs-Exclude-ATOMs-from-speculatio.patch
vendored
Normal file
159
debian/patches/bugfix/x86/x86-speculation-swapgs-Exclude-ATOMs-from-speculatio.patch
vendored
Normal file
|
@ -0,0 +1,159 @@
|
|||
From: Thomas Gleixner <tglx@linutronix.de>
|
||||
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 <andrew.cooper3@citrix.com>
|
||||
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
||||
Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
|
||||
Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
|
||||
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
---
|
||||
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
|
||||
|
|
@ -0,0 +1,75 @@
|
|||
From: Ben Hutchings <ben@decadent.org.uk>
|
||||
Date: Thu, 08 Aug 2019 02:59:40 +0100
|
||||
Subject: inet: Avoid ABI change for IP ID hash change
|
||||
Forwarded: not-needed
|
||||
|
||||
"inet: switch IP ID generator to siphash" adds a new member to struct
|
||||
netns_ipv4. Since this is embedded in struct net, it changes the
|
||||
offsets of all the following members. However struct net itself is
|
||||
not embedded in anything, and is always allocated by built-in code.
|
||||
So move the new member to the end of struct net, and hide it from
|
||||
genksyms.
|
||||
|
||||
Also hide the added element and member from modules, as they won't be
|
||||
able to rely on their being present until we bump ABI.
|
||||
|
||||
---
|
||||
--- a/include/net/net_namespace.h
|
||||
+++ b/include/net/net_namespace.h
|
||||
@@ -163,6 +163,7 @@ struct net {
|
||||
atomic_t fnhe_genid;
|
||||
#if !defined(__GENKSYMS__) && !defined(MODULE)
|
||||
int ipv4_sysctl_tcp_min_snd_mss;
|
||||
+ siphash_key_t ipv4_ip_id_key;
|
||||
#endif
|
||||
} __randomize_layout;
|
||||
|
||||
--- a/include/net/netns/ipv4.h
|
||||
+++ b/include/net/netns/ipv4.h
|
||||
@@ -216,6 +216,6 @@ struct netns_ipv4 {
|
||||
unsigned int ipmr_seq; /* protected by rtnl_mutex */
|
||||
|
||||
atomic_t rt_genid;
|
||||
- siphash_key_t ip_id_key;
|
||||
+ /* siphash_key_t ip_id_key; - bwh: moved to end of struct net */
|
||||
};
|
||||
#endif
|
||||
--- a/net/ipv4/route.c
|
||||
+++ b/net/ipv4/route.c
|
||||
@@ -503,14 +503,14 @@ void __ip_select_ident(struct net *net,
|
||||
u32 hash, id;
|
||||
|
||||
/* Note the following code is not safe, but this is okay. */
|
||||
- if (unlikely(siphash_key_is_zero(&net->ipv4.ip_id_key)))
|
||||
- get_random_bytes(&net->ipv4.ip_id_key,
|
||||
- sizeof(net->ipv4.ip_id_key));
|
||||
+ if (unlikely(siphash_key_is_zero(&net->ipv4_ip_id_key)))
|
||||
+ get_random_bytes(&net->ipv4_ip_id_key,
|
||||
+ sizeof(net->ipv4_ip_id_key));
|
||||
|
||||
hash = siphash_3u32((__force u32)iph->daddr,
|
||||
(__force u32)iph->saddr,
|
||||
iph->protocol,
|
||||
- &net->ipv4.ip_id_key);
|
||||
+ &net->ipv4_ip_id_key);
|
||||
id = ip_idents_reserve(hash, segs);
|
||||
iph->id = htons(id);
|
||||
}
|
||||
--- a/net/ipv6/output_core.c
|
||||
+++ b/net/ipv6/output_core.c
|
||||
@@ -24,11 +24,11 @@ static u32 __ipv6_select_ident(struct ne
|
||||
u32 hash, id;
|
||||
|
||||
/* Note the following code is not safe, but this is okay. */
|
||||
- if (unlikely(siphash_key_is_zero(&net->ipv4.ip_id_key)))
|
||||
- get_random_bytes(&net->ipv4.ip_id_key,
|
||||
- sizeof(net->ipv4.ip_id_key));
|
||||
+ if (unlikely(siphash_key_is_zero(&net->ipv4_ip_id_key)))
|
||||
+ get_random_bytes(&net->ipv4_ip_id_key,
|
||||
+ sizeof(net->ipv4_ip_id_key));
|
||||
|
||||
- hash = siphash(&combined, sizeof(combined), &net->ipv4.ip_id_key);
|
||||
+ hash = siphash(&combined, sizeof(combined), &net->ipv4_ip_id_key);
|
||||
|
||||
/* Treat id of 0 as unset and if we get 0 back from ip_idents_reserve,
|
||||
* set the hight order instead thus minimizing possible future
|
138
debian/patches/debian/abi/revert-x86-cpufeatures-combine-word-11-and-12-into-a-new-sc.patch
vendored
Normal file
138
debian/patches/debian/abi/revert-x86-cpufeatures-combine-word-11-and-12-into-a-new-sc.patch
vendored
Normal file
|
@ -0,0 +1,138 @@
|
|||
From: Ben Hutchings <ben@decadent.org.uk>
|
||||
Date: Thu, 08 Aug 2019 02:42:32 +0100
|
||||
Subject: Revert "x86/cpufeatures: Combine word 11 and 12 into a new scattered features word"
|
||||
Forwarded: not-needed
|
||||
|
||||
Renumbering CPU feature bits is a kABI change (even if genksyms
|
||||
doesn't notice it). And we actually had just enough spare bits in the
|
||||
existing scattered features words.
|
||||
|
||||
---
|
||||
--- 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_LNX_4,
|
||||
- CPUID_DUMMY,
|
||||
+ CPUID_F_0_EDX,
|
||||
+ CPUID_F_1_EDX,
|
||||
CPUID_8000_0008_EBX,
|
||||
CPUID_6_EAX,
|
||||
CPUID_8000_000A_EDX,
|
||||
--- a/arch/x86/include/asm/cpufeatures.h
|
||||
+++ b/arch/x86/include/asm/cpufeatures.h
|
||||
@@ -271,16 +271,13 @@
|
||||
#define X86_FEATURE_XGETBV1 (10*32+ 2) /* XGETBV with ECX = 1 instruction */
|
||||
#define X86_FEATURE_XSAVES (10*32+ 3) /* XSAVES/XRSTORS instructions */
|
||||
|
||||
-/*
|
||||
- * 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 */
|
||||
+/* 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 */
|
||||
|
||||
/* AMD-defined CPU features, CPUID level 0x80000008 (EBX), word 13 */
|
||||
#define X86_FEATURE_CLZERO (13*32+ 0) /* CLZERO instruction */
|
||||
--- a/arch/x86/kernel/cpu/common.c
|
||||
+++ b/arch/x86/kernel/cpu/common.c
|
||||
@@ -810,25 +810,33 @@ static void init_speculation_control(str
|
||||
|
||||
static void init_cqm(struct cpuinfo_x86 *c)
|
||||
{
|
||||
- if (!cpu_has(c, X86_FEATURE_CQM_LLC)) {
|
||||
- c->x86_cache_max_rmid = -1;
|
||||
- c->x86_cache_occ_scale = -1;
|
||||
- return;
|
||||
- }
|
||||
-
|
||||
- /* will be overridden if occupancy monitoring exists */
|
||||
- c->x86_cache_max_rmid = cpuid_ebx(0xf);
|
||||
-
|
||||
- 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;
|
||||
+ u32 eax, ebx, ecx, edx;
|
||||
|
||||
- /* QoS sub-leaf, EAX=0Fh, ECX=1 */
|
||||
- cpuid_count(0xf, 1, &eax, &ebx, &ecx, &edx);
|
||||
+ /* Additional Intel-defined flags: level 0x0000000F */
|
||||
+ if (c->cpuid_level >= 0x0000000F) {
|
||||
|
||||
- c->x86_cache_max_rmid = ecx;
|
||||
- c->x86_cache_occ_scale = ebx;
|
||||
+ /* 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;
|
||||
+ }
|
||||
}
|
||||
}
|
||||
|
||||
--- a/arch/x86/kernel/cpu/cpuid-deps.c
|
||||
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
|
||||
@@ -59,9 +59,6 @@ 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 },
|
||||
{}
|
||||
};
|
||||
|
||||
--- a/arch/x86/kernel/cpu/scattered.c
|
||||
+++ b/arch/x86/kernel/cpu/scattered.c
|
||||
@@ -21,10 +21,6 @@ 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 },
|
||||
--- a/arch/x86/kvm/cpuid.h
|
||||
+++ b/arch/x86/kvm/cpuid.h
|
||||
@@ -47,6 +47,8 @@ static const struct cpuid_reg reverse_cp
|
||||
[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},
|
37
debian/patches/debian/abi/x86-cpufeatures-move-swapgs-feature-bits-to-existing.patch
vendored
Normal file
37
debian/patches/debian/abi/x86-cpufeatures-move-swapgs-feature-bits-to-existing.patch
vendored
Normal file
|
@ -0,0 +1,37 @@
|
|||
From: Ben Hutchings <ben@decadent.org.uk>
|
||||
Date: Thu, 08 Aug 2019 02:40:23 +0100
|
||||
Subject: x86/cpufeatures: Move swapgs feature bits to existing scattered words
|
||||
Forwarded: not-needed
|
||||
|
||||
Renumbering CPU feature bits is a kABI change (even if genksyms
|
||||
doesn't notice it). Move the new feature bits for the mitigations to
|
||||
spare bits in the existing "scattered" feature words.
|
||||
|
||||
---
|
||||
--- a/arch/x86/include/asm/cpufeatures.h
|
||||
+++ b/arch/x86/include/asm/cpufeatures.h
|
||||
@@ -108,6 +108,7 @@
|
||||
#define X86_FEATURE_EXTD_APICID ( 3*32+26) /* Extended APICID (8 bits) */
|
||||
#define X86_FEATURE_AMD_DCM ( 3*32+27) /* AMD multi-node processor */
|
||||
#define X86_FEATURE_APERFMPERF ( 3*32+28) /* P-State hardware coordination feedback capability (APERF/MPERF MSRs) */
|
||||
+#define X86_FEATURE_FENCE_SWAPGS_USER ( 3*32+29) /* "" LFENCE in user entry SWAPGS path */
|
||||
#define X86_FEATURE_NONSTOP_TSC_S3 ( 3*32+30) /* TSC doesn't stop in S3 state */
|
||||
#define X86_FEATURE_TSC_KNOWN_FREQ ( 3*32+31) /* TSC has known frequency */
|
||||
|
||||
@@ -221,6 +222,7 @@
|
||||
#define X86_FEATURE_ZEN ( 7*32+28) /* "" CPU is AMD family 0x17 (Zen) */
|
||||
#define X86_FEATURE_L1TF_PTEINV ( 7*32+29) /* "" L1TF workaround PTE inversion */
|
||||
#define X86_FEATURE_IBRS_ENHANCED ( 7*32+30) /* Enhanced IBRS */
|
||||
+#define X86_FEATURE_FENCE_SWAPGS_KERNEL ( 7*32+31) /* "" LFENCE in kernel entry SWAPGS path */
|
||||
|
||||
/* Virtualization flags: Linux defined, word 8 */
|
||||
#define X86_FEATURE_TPR_SHADOW ( 8*32+ 0) /* Intel TPR Shadow */
|
||||
@@ -279,8 +281,6 @@
|
||||
#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 */
|
|
@ -69,7 +69,6 @@ bugfix/x86/platform-x86-ideapad-laptop-add-ideapad-v510-15ikb-t.patch
|
|||
bugfix/x86/platform-x86-ideapad-laptop-add-several-models-to-no.patch
|
||||
bugfix/x86/perf-tools-fix-unwind-build-on-i386.patch
|
||||
bugfix/sh/sh-boot-do-not-use-hyphen-in-exported-variable-name.patch
|
||||
bugfix/sh/sh-check-for-kprobe-trap-number-before-trying-to-handle-a-kprobe-trap.patch
|
||||
bugfix/powerpc/powerpc-lib-sstep-fix-building-for-powerpcspe.patch
|
||||
bugfix/powerpc/powerpc-lib-makefile-don-t-pull-in-quad.o-for-32-bit.patch
|
||||
bugfix/arm/arm-mm-export-__sync_icache_dcache-for-xen-privcmd.patch
|
||||
|
@ -232,6 +231,25 @@ bugfix/all/tcp-add-tcp_min_snd_mss-sysctl.patch
|
|||
bugfix/all/tcp-enforce-tcp_min_snd_mss-in-tcp_mtu_probing.patch
|
||||
bugfix/all/tcp-refine-memory-limit-test-in-tcp_fragment.patch
|
||||
bugfix/all/ptrace-Fix-ptracer_cred-handling-for-PTRACE_TRACEME.patch
|
||||
bugfix/x86/x86-insn-eval-Fix-use-after-free-access-to-LDT-entry.patch
|
||||
bugfix/powerpc/powerpc-mm-64s-hash-Reallocate-context-ids-on-fork.patch
|
||||
bugfix/all/nfc-Ensure-presence-of-required-attributes-in-the-deactivate_target.patch
|
||||
bugfix/all/binder-fix-race-between-munmap-and-direct-reclaim.patch
|
||||
bugfix/all/scsi-libsas-fix-a-race-condition-when-smp-task-timeout.patch
|
||||
bugfix/all/input-gtco-bounds-check-collection-indent-level.patch
|
||||
bugfix/all/net-switch-IP-ID-generator-to-siphash.patch
|
||||
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
|
||||
|
@ -321,3 +339,6 @@ bugfix/arm64/huawei-taishan/0033-scsi-hisi_sas-fix-calls-to-dma_set_mask_and_coh
|
|||
|
||||
# ABI maintenance
|
||||
debian/abi/tcp-avoid-abi-change-for-dos-fixes.patch
|
||||
debian/abi/x86-cpufeatures-move-swapgs-feature-bits-to-existing.patch
|
||||
debian/abi/revert-x86-cpufeatures-combine-word-11-and-12-into-a-new-sc.patch
|
||||
debian/abi/inet-avoid-abi-change-for-ip-id-hash-change.patch
|
||||
|
|
Loading…
Reference in New Issue