From: Greg Kroah-Hartman Date: Mon, 11 Oct 2021 07:48:03 +0000 (+0200) Subject: 5.14-stable patches X-Git-Tag: v5.14.12~11 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=e68fd979b2706a21d59d9b39407a01c538c23061;p=thirdparty%2Fkernel%2Fstable-queue.git 5.14-stable patches added patches: x86-entry-clear-x86_feature_smap-when-config_x86_smap-n.patch x86-entry-correct-reference-to-intended-config_64_bit.patch x86-fpu-restore-the-masking-out-of-reserved-mxcsr-bits.patch x86-hpet-use-another-crystalball-to-evaluate-hpet-usability.patch x86-kconfig-correct-reference-to-mwinchip3d.patch x86-platform-olpc-correct-ifdef-symbol-to-intended-config_olpc_xo15_sci.patch x86-sev-return-an-error-on-a-returned-non-zero-sw_exitinfo1.patch --- diff --git a/queue-5.14/series b/queue-5.14/series index 3f7b76b43e0..4c91add6044 100644 --- a/queue-5.14/series +++ b/queue-5.14/series @@ -142,3 +142,10 @@ powerpc-traps-do-not-enable-irqs-in-_exception.patch 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 diff --git a/queue-5.14/x86-entry-clear-x86_feature_smap-when-config_x86_smap-n.patch b/queue-5.14/x86-entry-clear-x86_feature_smap-when-config_x86_smap-n.patch new file mode 100644 index 00000000000..a9b1fb51f95 --- /dev/null +++ b/queue-5.14/x86-entry-clear-x86_feature_smap-when-config_x86_smap-n.patch @@ -0,0 +1,69 @@ +From 3958b9c34c2729597e182cc606cc43942fd19f7c Mon Sep 17 00:00:00 2001 +From: Vegard Nossum +Date: Mon, 4 Oct 2021 00:34:23 +0200 +Subject: x86/entry: Clear X86_FEATURE_SMAP when CONFIG_X86_SMAP=n + +From: Vegard Nossum + +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 +Signed-off-by: Borislav Petkov +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20211003223423.8666-1-vegard.nossum@oracle.com +Signed-off-by: Greg Kroah-Hartman +--- + 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 + } diff --git a/queue-5.14/x86-entry-correct-reference-to-intended-config_64_bit.patch b/queue-5.14/x86-entry-correct-reference-to-intended-config_64_bit.patch new file mode 100644 index 00000000000..6d8f7075eeb --- /dev/null +++ b/queue-5.14/x86-entry-correct-reference-to-intended-config_64_bit.patch @@ -0,0 +1,42 @@ +From 2c861f2b859385e9eaa6e464a8a7435b5a6bf564 Mon Sep 17 00:00:00 2001 +From: Lukas Bulwahn +Date: Tue, 3 Aug 2021 13:35:23 +0200 +Subject: x86/entry: Correct reference to intended CONFIG_64_BIT + +From: Lukas Bulwahn + +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 +Signed-off-by: Lukas Bulwahn +Signed-off-by: Borislav Petkov +Cc: +Link: https://lkml.kernel.org/r/20210803113531.30720-2-lukas.bulwahn@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.14/x86-fpu-restore-the-masking-out-of-reserved-mxcsr-bits.patch b/queue-5.14/x86-fpu-restore-the-masking-out-of-reserved-mxcsr-bits.patch new file mode 100644 index 00000000000..409f83f1757 --- /dev/null +++ b/queue-5.14/x86-fpu-restore-the-masking-out-of-reserved-mxcsr-bits.patch @@ -0,0 +1,87 @@ +From d298b03506d3e161f7492c440babb0bfae35e650 Mon Sep 17 00:00:00 2001 +From: Borislav Petkov +Date: Wed, 6 Oct 2021 18:33:52 +0200 +Subject: x86/fpu: Restore the masking out of reserved MXCSR bits + +From: Borislav Petkov + +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 +Signed-off-by: Borislav Petkov +Tested-by: Ser Olmy +Cc: +Link: https://lkml.kernel.org/r/YVtA67jImg3KlBTw@zn.tnic +Signed-off-by: Greg Kroah-Hartman +--- + 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()) diff --git a/queue-5.14/x86-hpet-use-another-crystalball-to-evaluate-hpet-usability.patch b/queue-5.14/x86-hpet-use-another-crystalball-to-evaluate-hpet-usability.patch new file mode 100644 index 00000000000..422cd493aa7 --- /dev/null +++ b/queue-5.14/x86-hpet-use-another-crystalball-to-evaluate-hpet-usability.patch @@ -0,0 +1,159 @@ +From 6e3cd95234dc1eda488f4f487c281bac8fef4d9b Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Thu, 30 Sep 2021 19:21:39 +0200 +Subject: x86/hpet: Use another crystalball to evaluate HPET usability + +From: Thomas Gleixner + +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 +Signed-off-by: Thomas Gleixner +Tested-by: Jakub Kicinski +Reviewed-by: Rafael J. Wysocki +Cc: stable@vger.kernel.org +Cc: Kai-Heng Feng +Cc: Bjorn Helgaas +Signed-off-by: Greg Kroah-Hartman +--- + 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 + #include + #include ++#include + + #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; diff --git a/queue-5.14/x86-kconfig-correct-reference-to-mwinchip3d.patch b/queue-5.14/x86-kconfig-correct-reference-to-mwinchip3d.patch new file mode 100644 index 00000000000..21934020c63 --- /dev/null +++ b/queue-5.14/x86-kconfig-correct-reference-to-mwinchip3d.patch @@ -0,0 +1,41 @@ +From 225bac2dc5d192e55f2c50123ee539b1edf8a411 Mon Sep 17 00:00:00 2001 +From: Lukas Bulwahn +Date: Tue, 3 Aug 2021 13:35:25 +0200 +Subject: x86/Kconfig: Correct reference to MWINCHIP3D + +From: Lukas Bulwahn + +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 +Signed-off-by: Lukas Bulwahn +Signed-off-by: Borislav Petkov +Cc: +Link: https://lkml.kernel.org/r/20210803113531.30720-4-lukas.bulwahn@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + 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 diff --git a/queue-5.14/x86-platform-olpc-correct-ifdef-symbol-to-intended-config_olpc_xo15_sci.patch b/queue-5.14/x86-platform-olpc-correct-ifdef-symbol-to-intended-config_olpc_xo15_sci.patch new file mode 100644 index 00000000000..2fab14eb49a --- /dev/null +++ b/queue-5.14/x86-platform-olpc-correct-ifdef-symbol-to-intended-config_olpc_xo15_sci.patch @@ -0,0 +1,42 @@ +From 4758fd801f919b8b9acad78d2e49a195ec2be46b Mon Sep 17 00:00:00 2001 +From: Lukas Bulwahn +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 + +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 +Signed-off-by: Lukas Bulwahn +Signed-off-by: Borislav Petkov +Cc: +Link: https://lkml.kernel.org/r/20210803113531.30720-3-lukas.bulwahn@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + 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 diff --git a/queue-5.14/x86-sev-return-an-error-on-a-returned-non-zero-sw_exitinfo1.patch b/queue-5.14/x86-sev-return-an-error-on-a-returned-non-zero-sw_exitinfo1.patch new file mode 100644 index 00000000000..69bd182e09a --- /dev/null +++ b/queue-5.14/x86-sev-return-an-error-on-a-returned-non-zero-sw_exitinfo1.patch @@ -0,0 +1,36 @@ +From 06f2ac3d4219bbbfd93d79e01966a42053084f11 Mon Sep 17 00:00:00 2001 +From: Tom Lendacky +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 + +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 +Signed-off-by: Borislav Petkov +Cc: # 5.10+ +Link: https://lkml.kernel.org/r/efc772af831e9e7f517f0439b13b41f56bad8784.1633063321.git.thomas.lendacky@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + 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; + }