From: Greg Kroah-Hartman Date: Mon, 15 Jun 2020 13:35:10 +0000 (+0200) Subject: 4.19-stable patches X-Git-Tag: v5.4.47~104 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=af1a4c3bb78a4e49a1acd57955af8cbff5f876b5;p=thirdparty%2Fkernel%2Fstable-queue.git 4.19-stable patches added patches: x86-pci-mark-intel-c620-mroms-as-having-non-compliant-bars.patch x86-speculation-prevent-rogue-cross-process-ssbd-shutdown.patch x86_64-fix-jiffies-odr-violation.patch --- diff --git a/queue-4.19/series b/queue-4.19/series index 3e619f9641e..9e8c18d4a2c 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -25,3 +25,6 @@ perf-probe-accept-the-instance-number-of-kretprobe-e.patch mm-add-kvfree_sensitive-for-freeing-sensitive-data-o.patch aio-fix-async-fsync-creds.patch btrfs-tree-checker-check-level-for-leaves-and-nodes.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 diff --git a/queue-4.19/x86-pci-mark-intel-c620-mroms-as-having-non-compliant-bars.patch b/queue-4.19/x86-pci-mark-intel-c620-mroms-as-having-non-compliant-bars.patch new file mode 100644 index 00000000000..c2e8fbf16f5 --- /dev/null +++ b/queue-4.19/x86-pci-mark-intel-c620-mroms-as-having-non-compliant-bars.patch @@ -0,0 +1,45 @@ +From 1574051e52cb4b5b7f7509cfd729b76ca1117808 Mon Sep 17 00:00:00 2001 +From: Xiaochun Lee +Date: Thu, 14 May 2020 23:31:07 -0400 +Subject: x86/PCI: Mark Intel C620 MROMs as having non-compliant BARs + +From: Xiaochun Lee + +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 +Signed-off-by: Bjorn Helgaas +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/pci/fixup.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/arch/x86/pci/fixup.c ++++ b/arch/x86/pci/fixup.c +@@ -572,6 +572,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:7808] diff --git a/queue-4.19/x86-speculation-prevent-rogue-cross-process-ssbd-shutdown.patch b/queue-4.19/x86-speculation-prevent-rogue-cross-process-ssbd-shutdown.patch new file mode 100644 index 00000000000..ea81101ebe2 --- /dev/null +++ b/queue-4.19/x86-speculation-prevent-rogue-cross-process-ssbd-shutdown.patch @@ -0,0 +1,96 @@ +From dbbe2ad02e9df26e372f38cc3e70dab9222c832e Mon Sep 17 00:00:00 2001 +From: Anthony Steinhauser +Date: Sun, 5 Jan 2020 12:19:43 -0800 +Subject: x86/speculation: Prevent rogue cross-process SSBD shutdown + +From: Anthony Steinhauser + +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 +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -413,28 +413,20 @@ static __always_inline void __speculatio + + lockdep_assert_irqs_disabled(); + +- /* +- * 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); diff --git a/queue-4.19/x86_64-fix-jiffies-odr-violation.patch b/queue-4.19/x86_64-fix-jiffies-odr-violation.patch new file mode 100644 index 00000000000..3bd96a3aef7 --- /dev/null +++ b/queue-4.19/x86_64-fix-jiffies-odr-violation.patch @@ -0,0 +1,125 @@ +From d8ad6d39c35d2b44b3d48b787df7f3359381dcbf Mon Sep 17 00:00:00 2001 +From: Bob Haarman +Date: Tue, 2 Jun 2020 12:30:59 -0700 +Subject: x86_64: Fix jiffies ODR violation + +From: Bob Haarman + +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//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 +Reported-by: Alistair Delva +Debugged-by: Nick Desaulniers +Debugged-by: Sami Tolvanen +Suggested-by: Fangrui Song +Signed-off-by: Bob Haarman +Signed-off-by: Thomas Gleixner +Tested-by: Sedat Dilek # build+boot on +Reviewed-by: Andi Kleen +Reviewed-by: Josh Poimboeuf +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 + +--- + 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 +@@ -24,10 +24,6 @@ + #include + #include + +-#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 +@@ -36,13 +36,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