drivers-net-ibmvnic-update-vnic-protocol-version-rep.patch
ath9k_htc-silence-undersized-packet-warnings.patch
perf-probe-accept-the-instance-number-of-kretprobe-e.patch
+x86_64-fix-jiffies-odr-violation.patch
+x86-pci-mark-intel-c620-mroms-as-having-non-compliant-bars.patch
+x86-speculation-prevent-rogue-cross-process-ssbd-shutdown.patch
--- /dev/null
+From 1574051e52cb4b5b7f7509cfd729b76ca1117808 Mon Sep 17 00:00:00 2001
+From: Xiaochun Lee <lixc17@lenovo.com>
+Date: Thu, 14 May 2020 23:31:07 -0400
+Subject: x86/PCI: Mark Intel C620 MROMs as having non-compliant BARs
+
+From: Xiaochun Lee <lixc17@lenovo.com>
+
+commit 1574051e52cb4b5b7f7509cfd729b76ca1117808 upstream.
+
+The Intel C620 Platform Controller Hub has MROM functions that have non-PCI
+registers (undocumented in the public spec) where BAR 0 is supposed to be,
+which results in messages like this:
+
+ pci 0000:00:11.0: [Firmware Bug]: reg 0x30: invalid BAR (can't size)
+
+Mark these MROM functions as having non-compliant BARs so we don't try to
+probe any of them. There are no other BARs on these devices.
+
+See the Intel C620 Series Chipset Platform Controller Hub Datasheet,
+May 2019, Document Number 336067-007US, sec 2.1, 35.5, 35.6.
+
+[bhelgaas: commit log, add 0xa26d]
+Link: https://lore.kernel.org/r/1589513467-17070-1-git-send-email-lixiaochun.2888@163.com
+Signed-off-by: Xiaochun Lee <lixc17@lenovo.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/pci/fixup.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/arch/x86/pci/fixup.c
++++ b/arch/x86/pci/fixup.c
+@@ -571,6 +571,10 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_IN
+ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6f60, pci_invalid_bar);
+ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fa0, pci_invalid_bar);
+ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fc0, pci_invalid_bar);
++DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0xa1ec, pci_invalid_bar);
++DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0xa1ed, pci_invalid_bar);
++DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0xa26c, pci_invalid_bar);
++DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0xa26d, pci_invalid_bar);
+
+ /*
+ * Device [1022:7914]
--- /dev/null
+From dbbe2ad02e9df26e372f38cc3e70dab9222c832e Mon Sep 17 00:00:00 2001
+From: Anthony Steinhauser <asteinhauser@google.com>
+Date: Sun, 5 Jan 2020 12:19:43 -0800
+Subject: x86/speculation: Prevent rogue cross-process SSBD shutdown
+
+From: Anthony Steinhauser <asteinhauser@google.com>
+
+commit dbbe2ad02e9df26e372f38cc3e70dab9222c832e upstream.
+
+On context switch the change of TIF_SSBD and TIF_SPEC_IB are evaluated
+to adjust the mitigations accordingly. This is optimized to avoid the
+expensive MSR write if not needed.
+
+This optimization is buggy and allows an attacker to shutdown the SSBD
+protection of a victim process.
+
+The update logic reads the cached base value for the speculation control
+MSR which has neither the SSBD nor the STIBP bit set. It then OR's the
+SSBD bit only when TIF_SSBD is different and requests the MSR update.
+
+That means if TIF_SSBD of the previous and next task are the same, then
+the base value is not updated, even if TIF_SSBD is set. The MSR write is
+not requested.
+
+Subsequently if the TIF_STIBP bit differs then the STIBP bit is updated
+in the base value and the MSR is written with a wrong SSBD value.
+
+This was introduced when the per task/process conditional STIPB
+switching was added on top of the existing SSBD switching.
+
+It is exploitable if the attacker creates a process which enforces SSBD
+and has the contrary value of STIBP than the victim process (i.e. if the
+victim process enforces STIBP, the attacker process must not enforce it;
+if the victim process does not enforce STIBP, the attacker process must
+enforce it) and schedule it on the same core as the victim process. If
+the victim runs after the attacker the victim becomes vulnerable to
+Spectre V4.
+
+To fix this, update the MSR value independent of the TIF_SSBD difference
+and dependent on the SSBD mitigation method available. This ensures that
+a subsequent STIPB initiated MSR write has the correct state of SSBD.
+
+[ tglx: Handle X86_FEATURE_VIRT_SSBD & X86_FEATURE_VIRT_SSBD correctly
+ and massaged changelog ]
+
+Fixes: 5bfbe3ad5840 ("x86/speculation: Prepare for per task indirect branch speculation control")
+Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/process.c | 28 ++++++++++------------------
+ 1 file changed, 10 insertions(+), 18 deletions(-)
+
+--- a/arch/x86/kernel/process.c
++++ b/arch/x86/kernel/process.c
+@@ -337,28 +337,20 @@ static __always_inline void __speculatio
+ u64 msr = x86_spec_ctrl_base;
+ bool updmsr = false;
+
+- /*
+- * If TIF_SSBD is different, select the proper mitigation
+- * method. Note that if SSBD mitigation is disabled or permanentely
+- * enabled this branch can't be taken because nothing can set
+- * TIF_SSBD.
+- */
+- if (tif_diff & _TIF_SSBD) {
+- if (static_cpu_has(X86_FEATURE_VIRT_SSBD)) {
++ /* Handle change of TIF_SSBD depending on the mitigation method. */
++ if (static_cpu_has(X86_FEATURE_VIRT_SSBD)) {
++ if (tif_diff & _TIF_SSBD)
+ amd_set_ssb_virt_state(tifn);
+- } else if (static_cpu_has(X86_FEATURE_LS_CFG_SSBD)) {
++ } else if (static_cpu_has(X86_FEATURE_LS_CFG_SSBD)) {
++ if (tif_diff & _TIF_SSBD)
+ amd_set_core_ssb_state(tifn);
+- } else if (static_cpu_has(X86_FEATURE_SPEC_CTRL_SSBD) ||
+- static_cpu_has(X86_FEATURE_AMD_SSBD)) {
+- msr |= ssbd_tif_to_spec_ctrl(tifn);
+- updmsr = true;
+- }
++ } else if (static_cpu_has(X86_FEATURE_SPEC_CTRL_SSBD) ||
++ static_cpu_has(X86_FEATURE_AMD_SSBD)) {
++ updmsr |= !!(tif_diff & _TIF_SSBD);
++ msr |= ssbd_tif_to_spec_ctrl(tifn);
+ }
+
+- /*
+- * Only evaluate TIF_SPEC_IB if conditional STIBP is enabled,
+- * otherwise avoid the MSR write.
+- */
++ /* Only evaluate TIF_SPEC_IB if conditional STIBP is enabled. */
+ if (IS_ENABLED(CONFIG_SMP) &&
+ static_branch_unlikely(&switch_to_cond_stibp)) {
+ updmsr |= !!(tif_diff & _TIF_SPEC_IB);
--- /dev/null
+From d8ad6d39c35d2b44b3d48b787df7f3359381dcbf Mon Sep 17 00:00:00 2001
+From: Bob Haarman <inglorion@google.com>
+Date: Tue, 2 Jun 2020 12:30:59 -0700
+Subject: x86_64: Fix jiffies ODR violation
+
+From: Bob Haarman <inglorion@google.com>
+
+commit d8ad6d39c35d2b44b3d48b787df7f3359381dcbf upstream.
+
+'jiffies' and 'jiffies_64' are meant to alias (two different symbols that
+share the same address). Most architectures make the symbols alias to the
+same address via a linker script assignment in their
+arch/<arch>/kernel/vmlinux.lds.S:
+
+jiffies = jiffies_64;
+
+which is effectively a definition of jiffies.
+
+jiffies and jiffies_64 are both forward declared for all architectures in
+include/linux/jiffies.h. jiffies_64 is defined in kernel/time/timer.c.
+
+x86_64 was peculiar in that it wasn't doing the above linker script
+assignment, but rather was:
+1. defining jiffies in arch/x86/kernel/time.c instead via the linker script.
+2. overriding the symbol jiffies_64 from kernel/time/timer.c in
+arch/x86/kernel/vmlinux.lds.s via 'jiffies_64 = jiffies;'.
+
+As Fangrui notes:
+
+ In LLD, symbol assignments in linker scripts override definitions in
+ object files. GNU ld appears to have the same behavior. It would
+ probably make sense for LLD to error "duplicate symbol" but GNU ld
+ is unlikely to adopt for compatibility reasons.
+
+This results in an ODR violation (UB), which seems to have survived
+thus far. Where it becomes harmful is when;
+
+1. -fno-semantic-interposition is used:
+
+As Fangrui notes:
+
+ Clang after LLVM commit 5b22bcc2b70d
+ ("[X86][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local")
+ defaults to -fno-semantic-interposition similar semantics which help
+ -fpic/-fPIC code avoid GOT/PLT when the referenced symbol is defined
+ within the same translation unit. Unlike GCC
+ -fno-semantic-interposition, Clang emits such relocations referencing
+ local symbols for non-pic code as well.
+
+This causes references to jiffies to refer to '.Ljiffies$local' when
+jiffies is defined in the same translation unit. Likewise, references to
+jiffies_64 become references to '.Ljiffies_64$local' in translation units
+that define jiffies_64. Because these differ from the names used in the
+linker script, they will not be rewritten to alias one another.
+
+2. Full LTO
+
+Full LTO effectively treats all source files as one translation
+unit, causing these local references to be produced everywhere. When
+the linker processes the linker script, there are no longer any
+references to jiffies_64' anywhere to replace with 'jiffies'. And
+thus '.Ljiffies$local' and '.Ljiffies_64$local' no longer alias
+at all.
+
+In the process of porting patches enabling Full LTO from arm64 to x86_64,
+spooky bugs have been observed where the kernel appeared to boot, but init
+doesn't get scheduled.
+
+Avoid the ODR violation by matching other architectures and define jiffies
+only by linker script. For -fno-semantic-interposition + Full LTO, there
+is no longer a global definition of jiffies for the compiler to produce a
+local symbol which the linker script won't ensure aliases to jiffies_64.
+
+Fixes: 40747ffa5aa8 ("asmlinkage: Make jiffies visible")
+Reported-by: Nathan Chancellor <natechancellor@gmail.com>
+Reported-by: Alistair Delva <adelva@google.com>
+Debugged-by: Nick Desaulniers <ndesaulniers@google.com>
+Debugged-by: Sami Tolvanen <samitolvanen@google.com>
+Suggested-by: Fangrui Song <maskray@google.com>
+Signed-off-by: Bob Haarman <inglorion@google.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # build+boot on
+Reviewed-by: Andi Kleen <ak@linux.intel.com>
+Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
+Cc: stable@vger.kernel.org
+Link: https://github.com/ClangBuiltLinux/linux/issues/852
+Link: https://lkml.kernel.org/r/20200602193100.229287-1-inglorion@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/time.c | 4 ----
+ arch/x86/kernel/vmlinux.lds.S | 4 ++--
+ 2 files changed, 2 insertions(+), 6 deletions(-)
+
+--- a/arch/x86/kernel/time.c
++++ b/arch/x86/kernel/time.c
+@@ -23,10 +23,6 @@
+ #include <asm/hpet.h>
+ #include <asm/time.h>
+
+-#ifdef CONFIG_X86_64
+-__visible volatile unsigned long jiffies __cacheline_aligned_in_smp = INITIAL_JIFFIES;
+-#endif
+-
+ unsigned long profile_pc(struct pt_regs *regs)
+ {
+ unsigned long pc = instruction_pointer(regs);
+--- a/arch/x86/kernel/vmlinux.lds.S
++++ b/arch/x86/kernel/vmlinux.lds.S
+@@ -34,13 +34,13 @@ OUTPUT_FORMAT(CONFIG_OUTPUT_FORMAT, CONF
+ #ifdef CONFIG_X86_32
+ OUTPUT_ARCH(i386)
+ ENTRY(phys_startup_32)
+-jiffies = jiffies_64;
+ #else
+ OUTPUT_ARCH(i386:x86-64)
+ ENTRY(phys_startup_64)
+-jiffies_64 = jiffies;
+ #endif
+
++jiffies = jiffies_64;
++
+ #if defined(CONFIG_X86_64)
+ /*
+ * On 64-bit, align RODATA to 2MB so we retain large page mappings for
projects / thirdparty / kernel / stable-queue.git / commitdiff
