powerpc-64s-fix-unrecoverable-mce-calling-async-hand.patch
powerpc-32s-fix-kuap_kernel_restore.patch
pseries-eeh-fix-the-kdump-kernel-crash-during-eeh_ps.patch
+x86-platform-olpc-correct-ifdef-symbol-to-intended-config_olpc_xo15_sci.patch
+x86-kconfig-correct-reference-to-mwinchip3d.patch
+x86-sev-return-an-error-on-a-returned-non-zero-sw_exitinfo1.patch
+x86-fpu-restore-the-masking-out-of-reserved-mxcsr-bits.patch
+x86-entry-correct-reference-to-intended-config_64_bit.patch
+x86-entry-clear-x86_feature_smap-when-config_x86_smap-n.patch
+x86-hpet-use-another-crystalball-to-evaluate-hpet-usability.patch
--- /dev/null
+From 3958b9c34c2729597e182cc606cc43942fd19f7c Mon Sep 17 00:00:00 2001
+From: Vegard Nossum <vegard.nossum@oracle.com>
+Date: Mon, 4 Oct 2021 00:34:23 +0200
+Subject: x86/entry: Clear X86_FEATURE_SMAP when CONFIG_X86_SMAP=n
+
+From: Vegard Nossum <vegard.nossum@oracle.com>
+
+commit 3958b9c34c2729597e182cc606cc43942fd19f7c upstream.
+
+Commit
+
+ 3c73b81a9164 ("x86/entry, selftests: Further improve user entry sanity checks")
+
+added a warning if AC is set when in the kernel.
+
+Commit
+
+ 662a0221893a3d ("x86/entry: Fix AC assertion")
+
+changed the warning to only fire if the CPU supports SMAP.
+
+However, the warning can still trigger on a machine that supports SMAP
+but where it's disabled in the kernel config and when running the
+syscall_nt selftest, for example:
+
+ ------------[ cut here ]------------
+ WARNING: CPU: 0 PID: 49 at irqentry_enter_from_user_mode
+ CPU: 0 PID: 49 Comm: init Tainted: G T 5.15.0-rc4+ #98 e6202628ee053b4f310759978284bd8bb0ce6905
+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
+ RIP: 0010:irqentry_enter_from_user_mode
+ ...
+ Call Trace:
+ ? irqentry_enter
+ ? exc_general_protection
+ ? asm_exc_general_protection
+ ? asm_exc_general_protectio
+
+IS_ENABLED(CONFIG_X86_SMAP) could be added to the warning condition, but
+even this would not be enough in case SMAP is disabled at boot time with
+the "nosmap" parameter.
+
+To be consistent with "nosmap" behaviour, clear X86_FEATURE_SMAP when
+!CONFIG_X86_SMAP.
+
+Found using entry-fuzz + satrandconfig.
+
+ [ bp: Massage commit message. ]
+
+Fixes: 3c73b81a9164 ("x86/entry, selftests: Further improve user entry sanity checks")
+Fixes: 662a0221893a ("x86/entry: Fix AC assertion")
+Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20211003223423.8666-1-vegard.nossum@oracle.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cpu/common.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/x86/kernel/cpu/common.c
++++ b/arch/x86/kernel/cpu/common.c
+@@ -320,6 +320,7 @@ static __always_inline void setup_smap(s
+ #ifdef CONFIG_X86_SMAP
+ cr4_set_bits(X86_CR4_SMAP);
+ #else
++ clear_cpu_cap(c, X86_FEATURE_SMAP);
+ cr4_clear_bits(X86_CR4_SMAP);
+ #endif
+ }
--- /dev/null
+From 2c861f2b859385e9eaa6e464a8a7435b5a6bf564 Mon Sep 17 00:00:00 2001
+From: Lukas Bulwahn <lukas.bulwahn@gmail.com>
+Date: Tue, 3 Aug 2021 13:35:23 +0200
+Subject: x86/entry: Correct reference to intended CONFIG_64_BIT
+
+From: Lukas Bulwahn <lukas.bulwahn@gmail.com>
+
+commit 2c861f2b859385e9eaa6e464a8a7435b5a6bf564 upstream.
+
+Commit in Fixes adds a condition with IS_ENABLED(CONFIG_64_BIT),
+but the intended config item is called CONFIG_64BIT, as defined in
+arch/x86/Kconfig.
+
+Fortunately, scripts/checkkconfigsymbols.py warns:
+
+64_BIT
+Referencing files: arch/x86/include/asm/entry-common.h
+
+Correct the reference to the intended config symbol.
+
+Fixes: 662a0221893a ("x86/entry: Fix AC assertion")
+Suggested-by: Randy Dunlap <rdunlap@infradead.org>
+Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: <stable@vger.kernel.org>
+Link: https://lkml.kernel.org/r/20210803113531.30720-2-lukas.bulwahn@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/include/asm/entry-common.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/include/asm/entry-common.h
++++ b/arch/x86/include/asm/entry-common.h
+@@ -25,7 +25,7 @@ static __always_inline void arch_check_u
+ * For !SMAP hardware we patch out CLAC on entry.
+ */
+ if (boot_cpu_has(X86_FEATURE_SMAP) ||
+- (IS_ENABLED(CONFIG_64_BIT) && boot_cpu_has(X86_FEATURE_XENPV)))
++ (IS_ENABLED(CONFIG_64BIT) && boot_cpu_has(X86_FEATURE_XENPV)))
+ mask |= X86_EFLAGS_AC;
+
+ WARN_ON_ONCE(flags & mask);
--- /dev/null
+From d298b03506d3e161f7492c440babb0bfae35e650 Mon Sep 17 00:00:00 2001
+From: Borislav Petkov <bp@suse.de>
+Date: Wed, 6 Oct 2021 18:33:52 +0200
+Subject: x86/fpu: Restore the masking out of reserved MXCSR bits
+
+From: Borislav Petkov <bp@suse.de>
+
+commit d298b03506d3e161f7492c440babb0bfae35e650 upstream.
+
+Ser Olmy reported a boot failure:
+
+ init[1] bad frame in sigreturn frame:(ptrval) ip:b7c9fbe6 sp:bf933310 orax:ffffffff \
+ in libc-2.33.so[b7bed000+156000]
+ Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
+ CPU: 0 PID: 1 Comm: init Tainted: G W 5.14.9 #1
+ Hardware name: Hewlett-Packard HP PC/HP Board, BIOS JD.00.06 12/06/2001
+ Call Trace:
+ dump_stack_lvl
+ dump_stack
+ panic
+ do_exit.cold
+ do_group_exit
+ get_signal
+ arch_do_signal_or_restart
+ ? force_sig_info_to_task
+ ? force_sig
+ exit_to_user_mode_prepare
+ syscall_exit_to_user_mode
+ do_int80_syscall_32
+ entry_INT80_32
+
+on an old 32-bit Intel CPU:
+
+ vendor_id : GenuineIntel
+ cpu family : 6
+ model : 6
+ model name : Celeron (Mendocino)
+ stepping : 5
+ microcode : 0x3
+
+Ser bisected the problem to the commit in Fixes.
+
+tglx suggested reverting the rejection of invalid MXCSR values which
+this commit introduced and replacing it with what the old code did -
+simply masking them out to zero.
+
+Further debugging confirmed his suggestion:
+
+ fpu->state.fxsave.mxcsr: 0xb7be13b4, mxcsr_feature_mask: 0xffbf
+ WARNING: CPU: 0 PID: 1 at arch/x86/kernel/fpu/signal.c:384 __fpu_restore_sig+0x51f/0x540
+
+so restore the original behavior only for 32-bit kernels where you have
+ancient machines with buggy hardware. For 32-bit programs on 64-bit
+kernels, user space which supplies wrong MXCSR values is considered
+malicious so fail the sigframe restoration there.
+
+Fixes: 6f9866a166cd ("x86/fpu/signal: Let xrstor handle the features to init")
+Reported-by: Ser Olmy <ser.olmy@protonmail.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Tested-by: Ser Olmy <ser.olmy@protonmail.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lkml.kernel.org/r/YVtA67jImg3KlBTw@zn.tnic
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/fpu/signal.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+--- a/arch/x86/kernel/fpu/signal.c
++++ b/arch/x86/kernel/fpu/signal.c
+@@ -379,9 +379,14 @@ static int __fpu_restore_sig(void __user
+ sizeof(fpu->state.fxsave)))
+ return -EFAULT;
+
+- /* Reject invalid MXCSR values. */
+- if (fpu->state.fxsave.mxcsr & ~mxcsr_feature_mask)
+- return -EINVAL;
++ if (IS_ENABLED(CONFIG_X86_64)) {
++ /* Reject invalid MXCSR values. */
++ if (fpu->state.fxsave.mxcsr & ~mxcsr_feature_mask)
++ return -EINVAL;
++ } else {
++ /* Mask invalid bits out for historical reasons (broken hardware). */
++ fpu->state.fxsave.mxcsr &= ~mxcsr_feature_mask;
++ }
+
+ /* Enforce XFEATURE_MASK_FPSSE when XSAVE is enabled */
+ if (use_xsave())
--- /dev/null
+From 6e3cd95234dc1eda488f4f487c281bac8fef4d9b Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Thu, 30 Sep 2021 19:21:39 +0200
+Subject: x86/hpet: Use another crystalball to evaluate HPET usability
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit 6e3cd95234dc1eda488f4f487c281bac8fef4d9b upstream.
+
+On recent Intel systems the HPET stops working when the system reaches PC10
+idle state.
+
+The approach of adding PCI ids to the early quirks to disable HPET on
+these systems is a whack a mole game which makes no sense.
+
+Check for PC10 instead and force disable HPET if supported. The check is
+overbroad as it does not take ACPI, intel_idle enablement and command
+line parameters into account. That's fine as long as there is at least
+PMTIMER available to calibrate the TSC frequency. The decision can be
+overruled by adding "hpet=force" on the kernel command line.
+
+Remove the related early PCI quirks for affected Ice Cake and Coffin Lake
+systems as they are not longer required. That should also cover all
+other systems, i.e. Tiger Rag and newer generations, which are most
+likely affected by this as well.
+
+Fixes: Yet another hardware trainwreck
+Reported-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Tested-by: Jakub Kicinski <kuba@kernel.org>
+Reviewed-by: Rafael J. Wysocki <rafael@kernel.org>
+Cc: stable@vger.kernel.org
+Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Cc: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/early-quirks.c | 6 ---
+ arch/x86/kernel/hpet.c | 81 +++++++++++++++++++++++++++++++++++++++++
+ 2 files changed, 81 insertions(+), 6 deletions(-)
+
+--- a/arch/x86/kernel/early-quirks.c
++++ b/arch/x86/kernel/early-quirks.c
+@@ -714,12 +714,6 @@ static struct chipset early_qrk[] __init
+ */
+ { PCI_VENDOR_ID_INTEL, 0x0f00,
+ PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, force_disable_hpet},
+- { PCI_VENDOR_ID_INTEL, 0x3e20,
+- PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, force_disable_hpet},
+- { PCI_VENDOR_ID_INTEL, 0x3ec4,
+- PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, force_disable_hpet},
+- { PCI_VENDOR_ID_INTEL, 0x8a12,
+- PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, force_disable_hpet},
+ { PCI_VENDOR_ID_BROADCOM, 0x4331,
+ PCI_CLASS_NETWORK_OTHER, PCI_ANY_ID, 0, apple_airport_reset},
+ {}
+--- a/arch/x86/kernel/hpet.c
++++ b/arch/x86/kernel/hpet.c
+@@ -10,6 +10,7 @@
+ #include <asm/irq_remapping.h>
+ #include <asm/hpet.h>
+ #include <asm/time.h>
++#include <asm/mwait.h>
+
+ #undef pr_fmt
+ #define pr_fmt(fmt) "hpet: " fmt
+@@ -916,6 +917,83 @@ static bool __init hpet_counting(void)
+ return false;
+ }
+
++static bool __init mwait_pc10_supported(void)
++{
++ unsigned int eax, ebx, ecx, mwait_substates;
++
++ if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
++ return false;
++
++ if (!cpu_feature_enabled(X86_FEATURE_MWAIT))
++ return false;
++
++ if (boot_cpu_data.cpuid_level < CPUID_MWAIT_LEAF)
++ return false;
++
++ cpuid(CPUID_MWAIT_LEAF, &eax, &ebx, &ecx, &mwait_substates);
++
++ return (ecx & CPUID5_ECX_EXTENSIONS_SUPPORTED) &&
++ (ecx & CPUID5_ECX_INTERRUPT_BREAK) &&
++ (mwait_substates & (0xF << 28));
++}
++
++/*
++ * Check whether the system supports PC10. If so force disable HPET as that
++ * stops counting in PC10. This check is overbroad as it does not take any
++ * of the following into account:
++ *
++ * - ACPI tables
++ * - Enablement of intel_idle
++ * - Command line arguments which limit intel_idle C-state support
++ *
++ * That's perfectly fine. HPET is a piece of hardware designed by committee
++ * and the only reasons why it is still in use on modern systems is the
++ * fact that it is impossible to reliably query TSC and CPU frequency via
++ * CPUID or firmware.
++ *
++ * If HPET is functional it is useful for calibrating TSC, but this can be
++ * done via PMTIMER as well which seems to be the last remaining timer on
++ * X86/INTEL platforms that has not been completely wreckaged by feature
++ * creep.
++ *
++ * In theory HPET support should be removed altogether, but there are older
++ * systems out there which depend on it because TSC and APIC timer are
++ * dysfunctional in deeper C-states.
++ *
++ * It's only 20 years now that hardware people have been asked to provide
++ * reliable and discoverable facilities which can be used for timekeeping
++ * and per CPU timer interrupts.
++ *
++ * The probability that this problem is going to be solved in the
++ * forseeable future is close to zero, so the kernel has to be cluttered
++ * with heuristics to keep up with the ever growing amount of hardware and
++ * firmware trainwrecks. Hopefully some day hardware people will understand
++ * that the approach of "This can be fixed in software" is not sustainable.
++ * Hope dies last...
++ */
++static bool __init hpet_is_pc10_damaged(void)
++{
++ unsigned long long pcfg;
++
++ /* Check whether PC10 substates are supported */
++ if (!mwait_pc10_supported())
++ return false;
++
++ /* Check whether PC10 is enabled in PKG C-state limit */
++ rdmsrl(MSR_PKG_CST_CONFIG_CONTROL, pcfg);
++ if ((pcfg & 0xF) < 8)
++ return false;
++
++ if (hpet_force_user) {
++ pr_warn("HPET force enabled via command line, but dysfunctional in PC10.\n");
++ return false;
++ }
++
++ pr_info("HPET dysfunctional in PC10. Force disabled.\n");
++ boot_hpet_disable = true;
++ return true;
++}
++
+ /**
+ * hpet_enable - Try to setup the HPET timer. Returns 1 on success.
+ */
+@@ -929,6 +1007,9 @@ int __init hpet_enable(void)
+ if (!is_hpet_capable())
+ return 0;
+
++ if (hpet_is_pc10_damaged())
++ return 0;
++
+ hpet_set_mapping();
+ if (!hpet_virt_address)
+ return 0;
--- /dev/null
+From 225bac2dc5d192e55f2c50123ee539b1edf8a411 Mon Sep 17 00:00:00 2001
+From: Lukas Bulwahn <lukas.bulwahn@gmail.com>
+Date: Tue, 3 Aug 2021 13:35:25 +0200
+Subject: x86/Kconfig: Correct reference to MWINCHIP3D
+
+From: Lukas Bulwahn <lukas.bulwahn@gmail.com>
+
+commit 225bac2dc5d192e55f2c50123ee539b1edf8a411 upstream.
+
+Commit in Fixes intended to exclude the Winchip series and referred to
+CONFIG_WINCHIP3D, but the config symbol is called CONFIG_MWINCHIP3D.
+
+Hence, scripts/checkkconfigsymbols.py warns:
+
+WINCHIP3D
+Referencing files: arch/x86/Kconfig
+
+Correct the reference to the intended config symbol.
+
+Fixes: 69b8d3fcabdc ("x86/Kconfig: Exclude i586-class CPUs lacking PAE support from the HIGHMEM64G Kconfig group")
+Suggested-by: Randy Dunlap <rdunlap@infradead.org>
+Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: <stable@vger.kernel.org>
+Link: https://lkml.kernel.org/r/20210803113531.30720-4-lukas.bulwahn@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/Kconfig | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/Kconfig
++++ b/arch/x86/Kconfig
+@@ -1400,7 +1400,7 @@ config HIGHMEM4G
+
+ config HIGHMEM64G
+ bool "64GB"
+- depends on !M486SX && !M486 && !M586 && !M586TSC && !M586MMX && !MGEODE_LX && !MGEODEGX1 && !MCYRIXIII && !MELAN && !MWINCHIPC6 && !WINCHIP3D && !MK6
++ depends on !M486SX && !M486 && !M586 && !M586TSC && !M586MMX && !MGEODE_LX && !MGEODEGX1 && !MCYRIXIII && !MELAN && !MWINCHIPC6 && !MWINCHIP3D && !MK6
+ select X86_PAE
+ help
+ Select this if you have a 32-bit processor and more than 4
--- /dev/null
+From 4758fd801f919b8b9acad78d2e49a195ec2be46b Mon Sep 17 00:00:00 2001
+From: Lukas Bulwahn <lukas.bulwahn@gmail.com>
+Date: Tue, 3 Aug 2021 13:35:24 +0200
+Subject: x86/platform/olpc: Correct ifdef symbol to intended CONFIG_OLPC_XO15_SCI
+
+From: Lukas Bulwahn <lukas.bulwahn@gmail.com>
+
+commit 4758fd801f919b8b9acad78d2e49a195ec2be46b upstream.
+
+The refactoring in the commit in Fixes introduced an ifdef
+CONFIG_OLPC_XO1_5_SCI, however the config symbol is actually called
+"CONFIG_OLPC_XO15_SCI".
+
+Fortunately, ./scripts/checkkconfigsymbols.py warns:
+
+OLPC_XO1_5_SCI
+Referencing files: arch/x86/platform/olpc/olpc.c
+
+Correct this ifdef condition to the intended config symbol.
+
+Fixes: ec9964b48033 ("Platform: OLPC: Move EC-specific functionality out from x86")
+Suggested-by: Randy Dunlap <rdunlap@infradead.org>
+Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: <stable@vger.kernel.org>
+Link: https://lkml.kernel.org/r/20210803113531.30720-3-lukas.bulwahn@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/platform/olpc/olpc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/platform/olpc/olpc.c
++++ b/arch/x86/platform/olpc/olpc.c
+@@ -274,7 +274,7 @@ static struct olpc_ec_driver ec_xo1_driv
+
+ static struct olpc_ec_driver ec_xo1_5_driver = {
+ .ec_cmd = olpc_xo1_ec_cmd,
+-#ifdef CONFIG_OLPC_XO1_5_SCI
++#ifdef CONFIG_OLPC_XO15_SCI
+ /*
+ * XO-1.5 EC wakeups are available when olpc-xo15-sci driver is
+ * compiled in
--- /dev/null
+From 06f2ac3d4219bbbfd93d79e01966a42053084f11 Mon Sep 17 00:00:00 2001
+From: Tom Lendacky <thomas.lendacky@amd.com>
+Date: Thu, 30 Sep 2021 23:42:01 -0500
+Subject: x86/sev: Return an error on a returned non-zero SW_EXITINFO1[31:0]
+
+From: Tom Lendacky <thomas.lendacky@amd.com>
+
+commit 06f2ac3d4219bbbfd93d79e01966a42053084f11 upstream.
+
+After returning from a VMGEXIT NAE event, SW_EXITINFO1[31:0] is checked
+for a value of 1, which indicates an error and that SW_EXITINFO2
+contains exception information. However, future versions of the GHCB
+specification may define new values for SW_EXITINFO1[31:0], so really
+any non-zero value should be treated as an error.
+
+Fixes: 597cfe48212a ("x86/boot/compressed/64: Setup a GHCB-based VC Exception handler")
+Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: <stable@vger.kernel.org> # 5.10+
+Link: https://lkml.kernel.org/r/efc772af831e9e7f517f0439b13b41f56bad8784.1633063321.git.thomas.lendacky@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/sev-shared.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/x86/kernel/sev-shared.c
++++ b/arch/x86/kernel/sev-shared.c
+@@ -130,6 +130,8 @@ static enum es_result sev_es_ghcb_hv_cal
+ } else {
+ ret = ES_VMM_ERROR;
+ }
++ } else if (ghcb->save.sw_exit_info_1 & 0xffffffff) {
++ ret = ES_VMM_ERROR;
+ } else {
+ ret = ES_OK;
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
