commit af48f51cb5934738a3ee97e951d7dededf029488 Author: Greg Kroah-Hartman Date: Fri Mar 11 10:13:34 2022 +0100 Linux 4.14.271 Link: https://lore.kernel.org/r/20220309155856.090281301@linuxfoundation.org Link: https://lore.kernel.org/r/20220310140807.524313448@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 1b9f4115738af90427a8c94a3980bc52fbb23296 Author: Juergen Gross Date: Fri Feb 25 16:05:43 2022 +0100 xen/netfront: react properly to failing gnttab_end_foreign_access_ref() Commit 66e3531b33ee51dad17c463b4d9c9f52e341503d upstream. When calling gnttab_end_foreign_access_ref() the returned value must be tested and the reaction to that value should be appropriate. In case of failure in xennet_get_responses() the reaction should not be to crash the system, but to disable the network device. The calls in setup_netfront() can be replaced by calls of gnttab_end_foreign_access(). While at it avoid double free of ring pages and grant references via xennet_disconnect_backend() in this case. This is CVE-2022-23042 / part of XSA-396. Reported-by: Demi Marie Obenour Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman commit 94b8ccbcc063325d23daa1cea89ef799c8c673e9 Author: Juergen Gross Date: Fri Feb 25 16:05:43 2022 +0100 xen/gnttab: fix gnttab_end_foreign_access() without page specified Commit 42baefac638f06314298087394b982ead9ec444b upstream. gnttab_end_foreign_access() is used to free a grant reference and optionally to free the associated page. In case the grant is still in use by the other side processing is being deferred. This leads to a problem in case no page to be freed is specified by the caller: the caller doesn't know that the page is still mapped by the other side and thus should not be used for other purposes. The correct way to handle this situation is to take an additional reference to the granted page in case handling is being deferred and to drop that reference when the grant reference could be freed finally. This requires that there are no users of gnttab_end_foreign_access() left directly repurposing the granted page after the call, as this might result in clobbered data or information leaks via the not yet freed grant reference. This is part of CVE-2022-23041 / XSA-396. Reported-by: Simon Gaiser Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman commit 22fd4f3fc1cd37d3daa4462f3184b20adb9342f5 Author: Juergen Gross Date: Fri Feb 25 16:05:42 2022 +0100 xen/9p: use alloc/free_pages_exact() Commit 5cadd4bb1d7fc9ab201ac14620d1a478357e4ebd upstream. Instead of __get_free_pages() and free_pages() use alloc_pages_exact() and free_pages_exact(). This is in preparation of a change of gnttab_end_foreign_access() which will prohibit use of high-order pages. By using the local variable "order" instead of ring->intf->ring_order in the error path of xen_9pfs_front_alloc_dataring() another bug is fixed, as the error path can be entered before ring->intf->ring_order is being set. By using alloc_pages_exact() the size in bytes is specified for the allocation, which fixes another bug for the case of order < (PAGE_SHIFT - XEN_PAGE_SHIFT). This is part of CVE-2022-23041 / XSA-396. Reported-by: Simon Gaiser Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman commit 9a7fa4be28ac13725e9e344572cced8b215b93c9 Author: Juergen Gross Date: Fri Feb 25 16:05:42 2022 +0100 xen: remove gnttab_query_foreign_access() Commit 1dbd11ca75fe664d3e54607547771d021f531f59 upstream. Remove gnttab_query_foreign_access(), as it is unused and unsafe to use. All previous use cases assumed a grant would not be in use after gnttab_query_foreign_access() returned 0. This information is useless in best case, as it only refers to a situation in the past, which could have changed already. Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman commit a37eb077983e678bece23d4061fe5a6614f41354 Author: Juergen Gross Date: Fri Feb 25 16:05:42 2022 +0100 xen/gntalloc: don't use gnttab_query_foreign_access() Commit d3b6372c5881cb54925212abb62c521df8ba4809 upstream. Using gnttab_query_foreign_access() is unsafe, as it is racy by design. The use case in the gntalloc driver is not needed at all. While at it replace the call of gnttab_end_foreign_access_ref() with a call of gnttab_end_foreign_access(), which is what is really wanted there. In case the grant wasn't used due to an allocation failure, just free the grant via gnttab_free_grant_reference(). This is CVE-2022-23039 / part of XSA-396. Reported-by: Demi Marie Obenour Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman commit bbf2a869c3c279fd9b665802112d8d9086bba242 Author: Juergen Gross Date: Fri Feb 25 16:05:42 2022 +0100 xen/scsifront: don't use gnttab_query_foreign_access() for mapped status Commit 33172ab50a53578a95691310f49567c9266968b0 upstream. It isn't enough to check whether a grant is still being in use by calling gnttab_query_foreign_access(), as a mapping could be realized by the other side just after having called that function. In case the call was done in preparation of revoking a grant it is better to do so via gnttab_try_end_foreign_access() and check the success of that operation instead. This is CVE-2022-23038 / part of XSA-396. Reported-by: Demi Marie Obenour Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman commit fbb5d5edd233c25774109dc0a673702c7b4985e5 Author: Juergen Gross Date: Fri Feb 25 16:05:41 2022 +0100 xen/netfront: don't use gnttab_query_foreign_access() for mapped status Commit 31185df7e2b1d2fa1de4900247a12d7b9c7087eb upstream. It isn't enough to check whether a grant is still being in use by calling gnttab_query_foreign_access(), as a mapping could be realized by the other side just after having called that function. In case the call was done in preparation of revoking a grant it is better to do so via gnttab_end_foreign_access_ref() and check the success of that operation instead. This is CVE-2022-23037 / part of XSA-396. Reported-by: Demi Marie Obenour Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman commit 60dd3ab592fe8c004cc400a3a38d369c44d6212f Author: Juergen Gross Date: Fri Feb 25 16:05:41 2022 +0100 xen/blkfront: don't use gnttab_query_foreign_access() for mapped status Commit abf1fd5919d6238ee3bc5eb4a9b6c3947caa6638 upstream. It isn't enough to check whether a grant is still being in use by calling gnttab_query_foreign_access(), as a mapping could be realized by the other side just after having called that function. In case the call was done in preparation of revoking a grant it is better to do so via gnttab_end_foreign_access_ref() and check the success of that operation instead. For the ring allocation use alloc_pages_exact() in order to avoid high order pages in case of a multi-page ring. If a grant wasn't unmapped by the backend without persistent grants being used, set the device state to "error". This is CVE-2022-23036 / part of XSA-396. Reported-by: Demi Marie Obenour Signed-off-by: Juergen Gross Reviewed-by: Roger Pau Monné Signed-off-by: Greg Kroah-Hartman commit 1b2f59f854e7069ba059adfe03d648ea643eba51 Author: Juergen Gross Date: Fri Feb 25 16:05:41 2022 +0100 xen/grant-table: add gnttab_try_end_foreign_access() Commit 6b1775f26a2da2b05a6dc8ec2b5d14e9a4701a1a upstream. Add a new grant table function gnttab_try_end_foreign_access(), which will remove and free a grant if it is not in use. Its main use case is to either free a grant if it is no longer in use, or to take some other action if it is still in use. This other action can be an error exit, or (e.g. in the case of blkfront persistent grant feature) some special handling. This is CVE-2022-23036, CVE-2022-23038 / part of XSA-396. Reported-by: Demi Marie Obenour Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman commit 67d21d5bddef88c1977378e4aca2b9c6a4af9edc Author: Juergen Gross Date: Fri Feb 25 16:05:40 2022 +0100 xen/xenbus: don't let xenbus_grant_ring() remove grants in error case Commit 3777ea7bac3113005b7180e6b9dadf16d19a5827 upstream. Letting xenbus_grant_ring() tear down grants in the error case is problematic, as the other side could already have used these grants. Calling gnttab_end_foreign_access_ref() without checking success is resulting in an unclear situation for any caller of xenbus_grant_ring() as in the error case the memory pages of the ring page might be partially mapped. Freeing them would risk unwanted foreign access to them, while not freeing them would leak memory. In order to remove the need to undo any gnttab_grant_foreign_access() calls, use gnttab_alloc_grant_references() to make sure no further error can occur in the loop granting access to the ring pages. It should be noted that this way of handling removes leaking of grant entries in the error case, too. This is CVE-2022-23040 / part of XSA-396. Reported-by: Demi Marie Obenour Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman commit 0848347b970455401febb23fcfedab42f99d40aa Author: Russell King (Oracle) Date: Thu Mar 10 10:22:14 2022 +0000 ARM: fix build warning in proc-v7-bugs.c commit b1a384d2cbccb1eb3f84765020d25e2c1929706e upstream. The kernel test robot discovered that building without HARDEN_BRANCH_PREDICTOR issues a warning due to a missing argument to pr_info(). Add the missing argument. Reported-by: kernel test robot Fixes: 9dd78194a372 ("ARM: report Spectre v2 status through sysfs") Signed-off-by: Russell King (Oracle) Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 21bf814f57f9f8c142b920e996d8f01444a153eb Author: Nathan Chancellor Date: Wed Mar 9 15:07:27 2022 -0700 ARM: Do not use NOCROSSREFS directive with ld.lld commit 36168e387fa7d0f1fe0cd5cf76c8cea7aee714fa upstream. ld.lld does not support the NOCROSSREFS directive at the moment, which breaks the build after commit b9baf5c8c5c3 ("ARM: Spectre-BHB workaround"): ld.lld: error: ./arch/arm/kernel/vmlinux.lds:34: AT expected, but got NOCROSSREFS Support for this directive will eventually be implemented, at which point a version check can be added. To avoid breaking the build in the meantime, just define NOCROSSREFS to nothing when using ld.lld, with a link to the issue for tracking. Cc: stable@vger.kernel.org Fixes: b9baf5c8c5c3 ("ARM: Spectre-BHB workaround") Link: https://github.com/ClangBuiltLinux/linux/issues/1609 Signed-off-by: Nathan Chancellor Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 76898a6bba872b801749523518bda71085ee4615 Author: Russell King (Oracle) Date: Wed Mar 9 19:08:42 2022 +0000 ARM: fix co-processor register typo commit 33970b031dc4653cc9dc80f2886976706c4c8ef1 upstream. In the recent Spectre BHB patches, there was a typo that is only exposed in certain configurations: mcr p15,0,XX,c7,r5,4 should have been mcr p15,0,XX,c7,c5,4 Reported-by: kernel test robot Fixes: b9baf5c8c5c3 ("ARM: Spectre-BHB workaround") Signed-off-by: Russell King (Oracle) Acked-by: Catalin Marinas Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0aa01cfbfc1ab9f305a7fe868d13230aa95788d6 Author: Emmanuel Gil Peyrot Date: Tue Mar 8 20:18:20 2022 +0100 ARM: fix build error when BPF_SYSCALL is disabled commit 330f4c53d3c2d8b11d86ec03a964b86dc81452f5 upstream. It was missing a semicolon. Signed-off-by: Emmanuel Gil Peyrot Reviewed-by: Nathan Chancellor Fixes: 25875aa71dfe ("ARM: include unprivileged BPF status in Spectre V2 reporting"). Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e01553f4048027183dc480ada93dc34b5d056a42 Author: Russell King (Oracle) Date: Mon Mar 7 19:28:32 2022 +0000 ARM: include unprivileged BPF status in Spectre V2 reporting commit 25875aa71dfefd1959f07e626c4d285b88b27ac2 upstream. The mitigations for Spectre-BHB are only applied when an exception is taken, but when unprivileged BPF is enabled, userspace can load BPF programs that can be used to exploit the problem. When unprivileged BPF is enabled, report the vulnerable status via the spectre_v2 sysfs file. Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman commit cf32c1579d50f1e26970557bc68b365d0ae10a89 Author: Russell King (Oracle) Date: Thu Feb 10 16:05:45 2022 +0000 ARM: Spectre-BHB workaround commit b9baf5c8c5c356757f4f9d8180b5e9d234065bc3 upstream. Workaround the Spectre BHB issues for Cortex-A15, Cortex-A57, Cortex-A72, Cortex-A73 and Cortex-A75. We also include Brahma B15 as well to be safe, which is affected by Spectre V2 in the same ways as Cortex-A15. Reviewed-by: Catalin Marinas Signed-off-by: Russell King (Oracle) [changes due to lack of SYSTEM_FREEING_INITMEM - gregkh] Signed-off-by: Greg Kroah-Hartman commit 5a4427812d2f0bd3c435a16a5ab4a54e552309a0 Author: Russell King (Oracle) Date: Fri Feb 11 19:49:50 2022 +0000 ARM: use LOADADDR() to get load address of sections commit 8d9d651ff2270a632e9dc497b142db31e8911315 upstream. Use the linker's LOADADDR() macro to get the load address of the sections, and provide a macro to set the start and end symbols. Acked-by: Catalin Marinas Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman commit 17ee39b4c6157055732ee2717ee4c9818e0dac2f Author: Russell King (Oracle) Date: Fri Feb 11 19:46:15 2022 +0000 ARM: early traps initialisation commit 04e91b7324760a377a725e218b5ee783826d30f5 upstream. Provide a couple of helpers to copy the vectors and stubs, and also to flush the copied vectors and stubs. Acked-by: Catalin Marinas Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman commit 2d44960d3edf9994998ff798ef618e666c4f0143 Author: Russell King (Oracle) Date: Fri Feb 11 16:45:54 2022 +0000 ARM: report Spectre v2 status through sysfs commit 9dd78194a3722fa6712192cdd4f7032d45112a9a upstream. As per other architectures, add support for reporting the Spectre vulnerability status via sysfs CPU. Acked-by: Catalin Marinas Signed-off-by: Russell King (Oracle) [ preserve res variable and add SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED - gregkh ] Signed-off-by: Greg Kroah-Hartman commit c169216a63ad1547b79e4688e6983ac54a5631fc Author: Mark Rutland Date: Fri Aug 9 14:22:40 2019 +0100 arm/arm64: smccc/psci: add arm_smccc_1_1_get_conduit() commit 6b7fe77c334ae59fed9500140e08f4f896b36871 upstream. SMCCC callers are currently amassing a collection of enums for the SMCCC conduit, and are having to dig into the PSCI driver's internals in order to figure out what to do. Let's clean this up, with common SMCCC_CONDUIT_* definitions, and an arm_smccc_1_1_get_conduit() helper that abstracts the PSCI driver's internal state. We can kill off the PSCI_CONDUIT_* definitions once we've migrated users over to the new interface. Signed-off-by: Mark Rutland Acked-by: Lorenzo Pieralisi Acked-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit d0f9db16eb4e3c0a8b5dd23c746f9faeb4b24ccb Author: Steven Price Date: Mon Oct 21 16:28:21 2019 +0100 arm/arm64: Provide a wrapper for SMCCC 1.1 calls commit 541625ac47ce9d0835efaee0fcbaa251b0000a37 upstream. SMCCC 1.1 calls may use either HVC or SMC depending on the PSCI conduit. Rather than coding this in every call site, provide a macro which uses the correct instruction. The macro also handles the case where no conduit is configured/available returning a not supported error in res, along with returning the conduit used for the call. This allow us to remove some duplicated code and will be useful later when adding paravirtualized time hypervisor calls. Signed-off-by: Steven Price Acked-by: Will Deacon Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 38c557efd4cd5e59dee1d021009278b491523fee Author: Josh Poimboeuf Date: Fri Feb 25 14:32:28 2022 -0800 x86/speculation: Warn about eIBRS + LFENCE + Unprivileged eBPF + SMT commit 0de05d056afdb00eca8c7bbb0c79a3438daf700c upstream. The commit 44a3918c8245 ("x86/speculation: Include unprivileged eBPF status in Spectre v2 mitigation reporting") added a warning for the "eIBRS + unprivileged eBPF" combination, which has been shown to be vulnerable against Spectre v2 BHB-based attacks. However, there's no warning about the "eIBRS + LFENCE retpoline + unprivileged eBPF" combo. The LFENCE adds more protection by shortening the speculation window after a mispredicted branch. That makes an attack significantly more difficult, even with unprivileged eBPF. So at least for now the logic doesn't warn about that combination. But if you then add SMT into the mix, the SMT attack angle weakens the effectiveness of the LFENCE considerably. So extend the "eIBRS + unprivileged eBPF" warning to also include the "eIBRS + LFENCE + unprivileged eBPF + SMT" case. [ bp: Massage commit message. ] Suggested-by: Alyssa Milburn Signed-off-by: Josh Poimboeuf Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman commit 2b871b5fedb85c1962ccab26c64bef9bf6f377d4 Author: Josh Poimboeuf Date: Fri Feb 25 14:31:49 2022 -0800 x86/speculation: Warn about Spectre v2 LFENCE mitigation commit eafd987d4a82c7bb5aa12f0e3b4f8f3dea93e678 upstream. With: f8a66d608a3e ("x86,bugs: Unconditionally allow spectre_v2=retpoline,amd") it became possible to enable the LFENCE "retpoline" on Intel. However, Intel doesn't recommend it, as it has some weaknesses compared to retpoline. Now AMD doesn't recommend it either. It can still be left available as a cmdline option. It's faster than retpoline but is weaker in certain scenarios -- particularly SMT, but even non-SMT may be vulnerable in some cases. So just unconditionally warn if the user requests it on the cmdline. [ bp: Massage commit message. ] Signed-off-by: Josh Poimboeuf Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman commit 416ec8f017b368ab953f624b075a7b0ffd296b9e Author: Kim Phillips Date: Mon Feb 28 11:23:16 2022 -0600 x86/speculation: Update link to AMD speculation whitepaper commit e9b6013a7ce31535b04b02ba99babefe8a8599fa upstream. Update the link to the "Software Techniques for Managing Speculation on AMD Processors" whitepaper. Signed-off-by: Kim Phillips Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman commit 85938688be23ecd36a06757096896b2779b80d97 Author: Kim Phillips Date: Mon Feb 28 11:23:15 2022 -0600 x86/speculation: Use generic retpoline by default on AMD commit 244d00b5dd4755f8df892c86cab35fb2cfd4f14b upstream. AMD retpoline may be susceptible to speculation. The speculation execution window for an incorrect indirect branch prediction using LFENCE/JMP sequence may potentially be large enough to allow exploitation using Spectre V2. By default, don't use retpoline,lfence on AMD. Instead, use the generic retpoline. Signed-off-by: Kim Phillips Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman commit 383973dc1a9dfc7baf12652b9e75498bef16aed9 Author: Josh Poimboeuf Date: Fri Feb 18 11:49:08 2022 -0800 x86/speculation: Include unprivileged eBPF status in Spectre v2 mitigation reporting commit 44a3918c8245ab10c6c9719dd12e7a8d291980d8 upstream. With unprivileged eBPF enabled, eIBRS (without retpoline) is vulnerable to Spectre v2 BHB-based attacks. When both are enabled, print a warning message and report it in the 'spectre_v2' sysfs vulnerabilities file. Signed-off-by: Josh Poimboeuf Signed-off-by: Borislav Petkov Reviewed-by: Thomas Gleixner [fllinden@amazon.com: backported to 4.14] Signed-off-by: Frank van der Linden Signed-off-by: Greg Kroah-Hartman commit d2109c347ec237f6a4cf4d44336abdeeab82ec8f Author: Peter Zijlstra Date: Wed Feb 16 20:57:02 2022 +0100 Documentation/hw-vuln: Update spectre doc commit 5ad3eb1132453b9795ce5fd4572b1c18b292cca9 upstream. Update the doc with the new fun. [ bp: Massage commit message. ] Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov Reviewed-by: Thomas Gleixner [fllinden@amazon.com: backported to 4.14] Signed-off-by: Frank van der Linden Signed-off-by: Greg Kroah-Hartman commit 716c06c7196f2ff22777b5bb3c713094ec677a93 Author: Peter Zijlstra Date: Wed Feb 16 20:57:01 2022 +0100 x86/speculation: Add eIBRS + Retpoline options commit 1e19da8522c81bf46b335f84137165741e0d82b7 upstream. Thanks to the chaps at VUsec it is now clear that eIBRS is not sufficient, therefore allow enabling of retpolines along with eIBRS. Add spectre_v2=eibrs, spectre_v2=eibrs,lfence and spectre_v2=eibrs,retpoline options to explicitly pick your preferred means of mitigation. Since there's new mitigations there's also user visible changes in /sys/devices/system/cpu/vulnerabilities/spectre_v2 to reflect these new mitigations. [ bp: Massage commit message, trim error messages, do more precise eIBRS mode checking. ] Co-developed-by: Josh Poimboeuf Signed-off-by: Josh Poimboeuf Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov Reviewed-by: Patrick Colp Reviewed-by: Thomas Gleixner [fllinden@amazon.com: backported to 4.14 (no Hygon)] Signed-off-by: Frank van der Linden Signed-off-by: Greg Kroah-Hartman commit 35c13d13becb5b951ea0fc708dda03fe900cf879 Author: Peter Zijlstra (Intel) Date: Wed Feb 16 20:57:00 2022 +0100 x86/speculation: Rename RETPOLINE_AMD to RETPOLINE_LFENCE commit d45476d9832409371537013ebdd8dc1a7781f97a upstream. The RETPOLINE_AMD name is unfortunate since it isn't necessarily AMD only, in fact Hygon also uses it. Furthermore it will likely be sufficient for some Intel processors. Therefore rename the thing to RETPOLINE_LFENCE to better describe what it is. Add the spectre_v2=retpoline,lfence option as an alias to spectre_v2=retpoline,amd to preserve existing setups. However, the output of /sys/devices/system/cpu/vulnerabilities/spectre_v2 will be changed. [ bp: Fix typos, massage. ] Co-developed-by: Josh Poimboeuf Signed-off-by: Josh Poimboeuf Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov Reviewed-by: Thomas Gleixner [fllinden@amazon.com: backported to 4.14] Signed-off-by: Frank van der Linden Signed-off-by: Greg Kroah-Hartman commit 3862830dd5b8d6769466f648cf259766b0f686a4 Author: Peter Zijlstra Date: Tue Oct 26 14:01:46 2021 +0200 x86,bugs: Unconditionally allow spectre_v2=retpoline,amd commit f8a66d608a3e471e1202778c2a36cbdc96bae73b upstream. Currently Linux prevents usage of retpoline,amd on !AMD hardware, this is unfriendly and gets in the way of testing. Remove this restriction. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Borislav Petkov Acked-by: Josh Poimboeuf Tested-by: Alexei Starovoitov Link: https://lore.kernel.org/r/20211026120310.487348118@infradead.org [fllinden@amazon.com: backported to 4.14 (no Hygon in 4.14)] Signed-off-by: Frank van der Linden Signed-off-by: Greg Kroah-Hartman commit bd63aa4ff3c9113ff0a97023b6e688e0b37e6fb4 Author: Borislav Petkov Date: Mon Jun 15 08:51:25 2020 +0200 x86/speculation: Merge one test in spectre_v2_user_select_mitigation() commit a5ce9f2bb665d1d2b31f139a02dbaa2dfbb62fa6 upstream. Merge the test whether the CPU supports STIBP into the test which determines whether STIBP is required. Thus try to simplify what is already an insane logic. Remove a superfluous newline in a comment, while at it. Signed-off-by: Borislav Petkov Cc: Anthony Steinhauser Link: https://lkml.kernel.org/r/20200615065806.GB14668@zn.tnic [fllinden@amazon.com: fixed contextual conflict (comment) for 4.14] Signed-off-by: Frank van der Linden Signed-off-by: Greg Kroah-Hartman