- 27 7月, 2023 3 次提交
-
-
由 Michael Kelley 提交于
stable inclusion from stable-v5.10.157 commit 22870431cd250df3eec96753d9422bfc9f0d52a4 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7MU59 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=22870431cd250df3eec96753d9422bfc9f0d52a4 -------------------------------- commit 4dbd6a3e upstream. Current code re-calculates the size after aligning the starting and ending physical addresses on a page boundary. But the re-calculation also embeds the masking of high order bits that exceed the size of the physical address space (via PHYSICAL_PAGE_MASK). If the masking removes any high order bits, the size calculation results in a huge value that is likely to immediately fail. Fix this by re-calculating the page-aligned size first. Then mask any high order bits using PHYSICAL_PAGE_MASK. Fixes: ffa71f33 ("x86, ioremap: Fix incorrect physical address handling in PAE mode") Signed-off-by: NMichael Kelley <mikelley@microsoft.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Acked-by: NDave Hansen <dave.hansen@linux.intel.com> Cc: <stable@kernel.org> Link: https://lore.kernel.org/r/1668624097-14884-2-git-send-email-mikelley@microsoft.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Nsanglipeng <sanglipeng1@jd.com> (cherry picked from commit 19edc371)
-
由 Maxim Levitsky 提交于
stable inclusion from stable-v5.10.157 commit 3fdeacf087ff92c85162b8a0e111dfe2479238ac category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7MU59 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3fdeacf087ff92c85162b8a0e111dfe2479238ac -------------------------------- commit 05311ce9 upstream. It is valid to receive external interrupt and have broken IDT entry, which will lead to #GP with exit_int_into that will contain the index of the IDT entry (e.g any value). Other exceptions can happen as well, like #NP or #SS (if stack switch fails). Thus this warning can be user triggred and has very little value. Cc: stable@vger.kernel.org Signed-off-by: NMaxim Levitsky <mlevitsk@redhat.com> Message-Id: <20221103141351.50662-10-mlevitsk@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Nsanglipeng <sanglipeng1@jd.com> (cherry picked from commit 17072e6b)
-
由 Maxim Levitsky 提交于
stable inclusion from stable-v5.10.157 commit 7e5cb13091e62b2ad2fe1d3a48753c7219a3e9f9 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7MU59 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7e5cb13091e62b2ad2fe1d3a48753c7219a3e9f9 -------------------------------- commit 917401f2 upstream. If the VM was terminated while nested, we free the nested state while the vCPU still is in nested mode. Soon a warning will be added for this condition. Cc: stable@vger.kernel.org Signed-off-by: NMaxim Levitsky <mlevitsk@redhat.com> Message-Id: <20221103141351.50662-2-mlevitsk@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Nsanglipeng <sanglipeng1@jd.com> (cherry picked from commit 79d5a52a)
-
- 21 7月, 2023 1 次提交
-
-
由 Adrian Hunter 提交于
stable inclusion from stable-v5.10.156 commit 5e2f14d77223ab7c0bae83f8f2ab3bde6a2bb028 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7MCG1 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5e2f14d77223ab7c0bae83f8f2ab3bde6a2bb028 -------------------------------- commit ce0d998b upstream. Deal with errata TGL052, ADL037 and RPL017 "Trace May Contain Incorrect Data When Configured With Single Range Output Larger Than 4KB" by disabling single range output whenever larger than 4KB. Fixes: 67063847 ("perf/x86/intel/pt: Opportunistically use single range output mode") Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20221112151508.13768-1-adrian.hunter@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Nsanglipeng <sanglipeng1@jd.com> (cherry picked from commit cf7159d6)
-
- 20 7月, 2023 1 次提交
-
-
由 Borislav Petkov 提交于
stable inclusion from stable-v5.10.155 commit 154d744fbefcd13648ff036db2d185319afa74dc category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7M5F4 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=154d744fbefcd13648ff036db2d185319afa74dc -------------------------------- commit 2632daeb upstream. DE_CFG contains the LFENCE serializing bit, restore it on resume too. This is relevant to older families due to the way how they do S3. Unify and correct naming while at it. Fixes: e4d0e84e ("x86/cpu/AMD: Make LFENCE a serializing instruction") Reported-by: NAndrew Cooper <Andrew.Cooper3@citrix.com> Reported-by: NPawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Cc: <stable@kernel.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Nsanglipeng <sanglipeng1@jd.com> (cherry picked from commit c983d6f2)
-
- 19 7月, 2023 19 次提交
-
-
由 Maxim Levitsky 提交于
stable inclusion from stable-v5.10.154 commit e5cef906cb409a7b56641561a715d431b034d1c2 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e5cef906cb409a7b56641561a715d431b034d1c2 -------------------------------- commit ad8f9e69 upstream. Update the emulation mode when handling writes to CR0, because toggling CR0.PE switches between Real and Protected Mode, and toggling CR0.PG when EFER.LME=1 switches between Long and Protected Mode. This is likely a benign bug because there is no writeback of state, other than the RIP increment, and when toggling CR0.PE, the CPU has to execute code from a very low memory address. Signed-off-by: NMaxim Levitsky <mlevitsk@redhat.com> Message-Id: <20221025124741.228045-14-mlevitsk@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit 132efd7d)
-
由 Maxim Levitsky 提交于
stable inclusion from stable-v5.10.154 commit ce9261accccd2a0edffa9b65cd9d23400f71bdfa category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ce9261accccd2a0edffa9b65cd9d23400f71bdfa -------------------------------- commit d087e0f7 upstream. Some instructions update the cpu execution mode, which needs to update the emulation mode. Extract this code, and make assign_eip_far use it. assign_eip_far now reads CS, instead of getting it via a parameter, which is ok, because callers always assign CS to the same value before calling this function. No functional change is intended. Signed-off-by: NMaxim Levitsky <mlevitsk@redhat.com> Message-Id: <20221025124741.228045-12-mlevitsk@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit 53b7bf02)
-
由 Maxim Levitsky 提交于
stable inclusion from stable-v5.10.154 commit c8a2fd7a715d9882eed5ddb4105bce2f6a8163c2 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c8a2fd7a715d9882eed5ddb4105bce2f6a8163c2 -------------------------------- commit 5015bb89 upstream. SYSEXIT is one of the instructions that can change the processor mode, thus ctxt->mode should be updated after it. Note that this is likely a benign bug, because the only problematic mode change is from 32 bit to 64 bit which can lead to truncation of RIP, and it is not possible to do with sysexit, since sysexit running in 32 bit mode will be limited to 32 bit version. Signed-off-by: NMaxim Levitsky <mlevitsk@redhat.com> Message-Id: <20221025124741.228045-11-mlevitsk@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit 78979ae9)
-
由 Jim Mattson 提交于
stable inclusion from stable-v5.10.154 commit e0c7410378cd1adbfd35a65faca5df8936631b1a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e0c7410378cd1adbfd35a65faca5df8936631b1a -------------------------------- commit 0469e56a upstream. KVM_GET_SUPPORTED_CPUID should only enumerate features that KVM actually supports. CPUID.80000001:EBX[27:16] are reserved bits and should be masked off. Fixes: 07716717 ("KVM: Enhance guest cpuid management") Signed-off-by: NJim Mattson <jmattson@google.com> Cc: stable@vger.kernel.org Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit d6c7c247)
-
由 Jim Mattson 提交于
stable inclusion from stable-v5.10.154 commit 9302ebc1c21d93ef7004cd228c8b493dc64f7194 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9302ebc1c21d93ef7004cd228c8b493dc64f7194 -------------------------------- commit 7030d853 upstream. KVM_GET_SUPPORTED_CPUID should only enumerate features that KVM actually supports. The following ranges of CPUID.80000008H are reserved and should be masked off: ECX[31:18] ECX[11:8] In addition, the PerfTscSize field at ECX[17:16] should also be zero because KVM does not set the PERFTSC bit at CPUID.80000001H.ECX[27]. Fixes: 24c82e57 ("KVM: Sanitize cpuid") Signed-off-by: NJim Mattson <jmattson@google.com> Message-Id: <20220929225203.2234702-3-jmattson@google.com> Cc: stable@vger.kernel.org Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit c5b7da51)
-
由 Jim Mattson 提交于
stable inclusion from stable-v5.10.154 commit cc40c5f3e9211523873c001d34e2f6695d57249b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=cc40c5f3e9211523873c001d34e2f6695d57249b -------------------------------- commit 079f6889 upstream. KVM_GET_SUPPORTED_CPUID should only enumerate features that KVM actually supports. In the case of CPUID.8000001AH, only three bits are currently defined. The 125 reserved bits should be masked off. Fixes: 24c82e57 ("KVM: Sanitize cpuid") Signed-off-by: NJim Mattson <jmattson@google.com> Message-Id: <20220929225203.2234702-4-jmattson@google.com> Cc: stable@vger.kernel.org Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit f7e9643b)
-
由 Jim Mattson 提交于
stable inclusion from stable-v5.10.154 commit bd64a88f364cbe2e19b5f55be1cffef2b47bd0a5 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bd64a88f364cbe2e19b5f55be1cffef2b47bd0a5 -------------------------------- commit eeb69eab upstream. KVM_GET_SUPPORTED_CPUID should only enumerate features that KVM actually supports. CPUID.80000006H:EDX[17:16] are reserved bits and should be masked off. Fixes: 43d05de2 ("KVM: pass through CPUID(0x80000006)") Signed-off-by: NJim Mattson <jmattson@google.com> Message-Id: <20220929225203.2234702-2-jmattson@google.com> Cc: stable@vger.kernel.org Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit 4a3cecf6)
-
由 Kan Liang 提交于
stable inclusion from stable-v5.10.154 commit 29d106d086d2f39f8635f402004d1c17a6205583 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=29d106d086d2f39f8635f402004d1c17a6205583 -------------------------------- commit 6f8faf47 upstream. The intel_pebs_isolation quirk checks both model number and stepping. Cooper Lake has a different stepping (11) than the other Skylake Xeon. It cannot benefit from the optimization in commit 9b545c04 ("perf/x86/kvm: Avoid unnecessary work in guest filtering"). Add the stepping of Cooper Lake into the isolation_ucodes[] table. Signed-off-by: NKan Liang <kan.liang@linux.intel.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20221031154550.571663-1-kan.liang@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit af05d8ef)
-
由 Kan Liang 提交于
stable inclusion from stable-v5.10.154 commit 98f6e7c337036dff5a851f557950f5846d3f7d73 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=98f6e7c337036dff5a851f557950f5846d3f7d73 -------------------------------- commit acc5568b upstream. According to the latest event list, update the MEM_INST_RETIRED events which support the DataLA facility. Fixes: 60176089 ("perf/x86/intel: Add Icelake support") Reported-by: NJannis Klinkenberg <jannis.klinkenberg@rwth-aachen.de> Signed-off-by: NKan Liang <kan.liang@linux.intel.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20221031154119.571386-1-kan.liang@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit 6a9a09a5)
-
由 Alexander Graf 提交于
stable inclusion from stable-v5.10.154 commit 4dbb739eb29c99c8b59bbb7bbaa71ec1b438f37c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4dbb739eb29c99c8b59bbb7bbaa71ec1b438f37c -------------------------------- [ Upstream commit 1739c701 ] The KVM_X86_SET_MSR_FILTER ioctls contains a pointer in the passed in struct which means it has a different struct size depending on whether it gets called from 32bit or 64bit code. This patch introduces compat code that converts from the 32bit struct to its 64bit counterpart which then gets used going forward internally. With this applied, 32bit QEMU can successfully set MSR bitmaps when running on 64bit kernels. Reported-by: NAndrew Randrianasulu <randrianasulu@gmail.com> Fixes: 1a155254 ("KVM: x86: Introduce MSR filtering") Signed-off-by: NAlexander Graf <graf@amazon.com> Message-Id: <20221017184541.2658-4-graf@amazon.com> Cc: stable@vger.kernel.org Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit 28455b50)
-
由 Alexander Graf 提交于
stable inclusion from stable-v5.10.154 commit bb584caee8957469dfd7549dc7accdce806f23dd category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bb584caee8957469dfd7549dc7accdce806f23dd -------------------------------- [ Upstream commit 2e3272bc ] In the next patch we want to introduce a second caller to set_msr_filter() which constructs its own filter list on the stack. Refactor the original function so it takes it as argument instead of reading it through copy_from_user(). Signed-off-by: NAlexander Graf <graf@amazon.com> Message-Id: <20221017184541.2658-3-graf@amazon.com> Cc: stable@vger.kernel.org Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit 418a1835)
-
由 Aaron Lewis 提交于
stable inclusion from stable-v5.10.154 commit 9faacf442d11c872e7e2a66a6d1844459336dfb1 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9faacf442d11c872e7e2a66a6d1844459336dfb1 -------------------------------- [ Upstream commit cf5029d5 ] The flags for KVM_CAP_X86_USER_SPACE_MSR and KVM_X86_SET_MSR_FILTER have no protection for their unused bits. Without protection, future development for these features will be difficult. Add the protection needed to make it possible to extend these features in the future. Signed-off-by: NAaron Lewis <aaronlewis@google.com> Message-Id: <20220714161314.1715227-1-aaronlewis@google.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Stable-dep-of: 2e3272bc ("KVM: x86: Copy filter arg outside kvm_vm_ioctl_set_msr_filter()") Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit 9c3c43a4)
-
由 Zhang Rui 提交于
stable inclusion from stable-v5.10.154 commit 5bdbccc79c86424fef1960de76abab9e83cfbdc9 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5bdbccc79c86424fef1960de76abab9e83cfbdc9 -------------------------------- [ Upstream commit 71eac706 ] Today, core ID is assumed to be unique within each package. But an AlderLake-N platform adds a Module level between core and package, Linux excludes the unknown modules bits from the core ID, resulting in duplicate core ID's. To keep core ID unique within a package, Linux must include all APIC-ID bits for known or unknown levels above the core and below the package in the core ID. It is important to understand that core ID's have always come directly from the APIC-ID encoding, which comes from the BIOS. Thus there is no guarantee that they start at 0, or that they are contiguous. As such, naively using them for array indexes can be problematic. [ dhansen: un-known -> unknown ] Fixes: 7745f03e ("x86/topology: Add CPUID.1F multi-die/package support") Suggested-by: NLen Brown <len.brown@intel.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NLen Brown <len.brown@intel.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20221014090147.1836-5-rui.zhang@intel.comSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit d065f1f2)
-
由 Zhang Rui 提交于
stable inclusion from stable-v5.10.154 commit 6c31fc028a657e8d53cec5127a39a35cce6dba08 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6c31fc028a657e8d53cec5127a39a35cce6dba08 -------------------------------- [ Upstream commit 2b12a7a1 ] CPUID.1F/B does not enumerate Package level explicitly, instead, all the APIC-ID bits above the enumerated levels are assumed to be package ID bits. Current code gets package ID by shifting out all the APIC-ID bits that Linux supports, rather than shifting out all the APIC-ID bits that CPUID.1F enumerates. This introduces problems when CPUID.1F enumerates a level that Linux does not support. For example, on a single package AlderLake-N, there are 2 Ecore Modules with 4 atom cores in each module. Linux does not support the Module level and interprets the Module ID bits as package ID and erroneously reports a multi module system as a multi-package system. Fix this by using APIC-ID bits above all the CPUID.1F enumerated levels as package ID. [ dhansen: spelling fix ] Fixes: 7745f03e ("x86/topology: Add CPUID.1F multi-die/package support") Suggested-by: NLen Brown <len.brown@intel.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NLen Brown <len.brown@intel.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20221014090147.1836-4-rui.zhang@intel.comSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit c73302dc)
-
由 Yazen Ghannam 提交于
stable inclusion from stable-v5.10.154 commit f5ad52da145a460b11d3a02a74c995fc33cce2f0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f5ad52da145a460b11d3a02a74c995fc33cce2f0 -------------------------------- [ Upstream commit cb09a379 ] CPUID Leaf 0x1F defines a DIE_TYPE level (nb: ECX[8:15] level type == 0x5), but CPUID Leaf 0xB does not. However, detect_extended_topology() will set struct cpuinfo_x86.cpu_die_id regardless of whether a valid Die ID was found. Only set cpu_die_id if a DIE_TYPE level is found. CPU topology code may use another value for cpu_die_id, e.g. the AMD NodeId on AMD-based systems. Code ordering should be maintained so that the CPUID Leaf 0x1F Die ID value will take precedence on systems that may use another value. Suggested-by: NBorislav Petkov <bp@alien8.de> Signed-off-by: NYazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20201109210659.754018-5-Yazen.Ghannam@amd.com Stable-dep-of: 2b12a7a1 ("x86/topology: Fix multiple packages shown on a single-package system") Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit e6bbde6c)
-
由 Sean Christopherson 提交于
stable inclusion from stable-v5.10.154 commit 570fa3bcd2f9328efc2123f8c46a50ea6b64b004 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=570fa3bcd2f9328efc2123f8c46a50ea6b64b004 -------------------------------- [ Upstream commit 5623f751 ] Add a dedicated "exception type" for #DBs, as #DBs can be fault-like or trap-like depending the sub-type of #DB, and effectively defer the decision of what to do with the #DB to the caller. For the emulator's two calls to exception_type(), treat the #DB as fault-like, as the emulator handles only code breakpoint and general detect #DBs, both of which are fault-like. For event injection, which uses exception_type() to determine whether to set EFLAGS.RF=1 on the stack, keep the current behavior of not setting RF=1 for #DBs. Intel and AMD explicitly state RF isn't set on code #DBs, so exempting by failing the "== EXCPT_FAULT" check is correct. The only other fault-like #DB is General Detect, and despite Intel and AMD both strongly implying (through omission) that General Detect #DBs should set RF=1, hardware (multiple generations of both Intel and AMD), in fact does not. Through insider knowledge, extreme foresight, sheer dumb luck, or some combination thereof, KVM correctly handled RF for General Detect #DBs. Fixes: 38827dbd ("KVM: x86: Do not update EFLAGS on faulting emulation") Cc: stable@vger.kernel.org Signed-off-by: NSean Christopherson <seanjc@google.com> Reviewed-by: NMaxim Levitsky <mlevitsk@redhat.com> Link: https://lore.kernel.org/r/20220830231614.3580124-9-seanjc@google.comSigned-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit dfdc32ea)
-
由 Sean Christopherson 提交于
stable inclusion from stable-v5.10.154 commit e5d7c6786befe4aca0ba645dc5b836fc60ea733c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e5d7c6786befe4aca0ba645dc5b836fc60ea733c -------------------------------- [ Upstream commit a61d7c54 ] Trace exceptions that are re-injected, not just those that KVM is injecting for the first time. Debugging re-injection bugs is painful enough as is, not having visibility into what KVM is doing only makes things worse. Delay propagating pending=>injected in the non-reinjection path so that the tracing can properly identify reinjected exceptions. Signed-off-by: NSean Christopherson <seanjc@google.com> Reviewed-by: NMaxim Levitsky <mlevitsk@redhat.com> Signed-off-by: NMaciej S. Szmigiero <maciej.szmigiero@oracle.com> Message-Id: <25470690a38b4d2b32b6204875dd35676c65c9f2.1651440202.git.maciej.szmigiero@oracle.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Stable-dep-of: 5623f751 ("KVM: x86: Treat #DBs from the emulator as fault-like (code and DR7.GD=1)") Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit fff0a58b)
-
由 Sean Christopherson 提交于
stable inclusion from stable-v5.10.154 commit 8364786152d5abf887162612c23f932d8cda164f category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8364786152d5abf887162612c23f932d8cda164f -------------------------------- [ Upstream commit def9d705 ] Don't propagate vmcs12's VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL to vmcs02. KVM doesn't disallow L1 from using VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL even when KVM itself doesn't use the control, e.g. due to the various CPU errata that where the MSR can be corrupted on VM-Exit. Preserve KVM's (vmcs01) setting to hopefully avoid having to toggle the bit in vmcs02 at a later point. E.g. if KVM is loading PERF_GLOBAL_CTRL when running L1, then odds are good KVM will also load the MSR when running L2. Fixes: 8bf00a52 ("KVM: VMX: add support for switching of PERF_GLOBAL_CTRL") Cc: stable@vger.kernel.org Signed-off-by: NSean Christopherson <seanjc@google.com> Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com> Link: https://lore.kernel.org/r/20220830133737.1539624-18-vkuznets@redhat.comSigned-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit ad9e97af)
-
由 Sean Christopherson 提交于
stable inclusion from stable-v5.10.154 commit 523e1dd9f8d4d8cf064488473ef518c8dedcfeec category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=523e1dd9f8d4d8cf064488473ef518c8dedcfeec -------------------------------- [ Upstream commit 389ab252 ] When preparing controls for vmcs02, grab KVM's desired controls from vmcs01's shadow state instead of recalculating the controls from scratch, or in the secondary execution controls, instead of using the dedicated cache. Calculating secondary exec controls is eye-poppingly expensive due to the guest CPUID checks, hence the dedicated cache, but the other calculations aren't exactly free either. Explicitly clear several bits (x2APIC, DESC exiting, and load EFER on exit) as appropriate as they may be set in vmcs01, whereas the previous implementation relied on dynamic bits being cleared in the calculator. Intentionally propagate VM_{ENTRY,EXIT}_LOAD_IA32_PERF_GLOBAL_CTRL from vmcs01 to vmcs02. Whether or not PERF_GLOBAL_CTRL is loaded depends on whether or not perf itself is active, so unless perf stops between the exit from L1 and entry to L2, vmcs01 will hold the desired value. This is purely an optimization as atomic_switch_perf_msrs() will set/clear the control as needed at VM-Enter, i.e. it avoids two extra VMWRITEs in the case where perf is active (versus starting with the bits clear in vmcs02, which was the previous behavior). Cc: Zeng Guang <guang.zeng@intel.com> Signed-off-by: NSean Christopherson <seanjc@google.com> Message-Id: <20210810171952.2758100-3-seanjc@google.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Stable-dep-of: def9d705 ("KVM: nVMX: Don't propagate vmcs12's PERF_GLOBAL_CTRL settings to vmcs02") Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> Conflicts: arch/x86/kvm/vmx/vmx.h (cherry picked from commit 63a8a234)
-
- 25 6月, 2023 1 次提交
-
-
由 Zheng Zengkai 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5RQLJ -------------------------------- 5a2451f1 ("x86/fpu: Avoid kabi change caused by struct fpu") will lead to performance degradation of libmicro pthread_create testcase. Assuming that no 3rd party driver will reach into struct fpu, replace kabi fix macro from KABI_DEPRECATE to KABI_BROKEN_REMOVE for element "union fpregs_state state" of struct fpu. Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> (cherry picked from commit b60bbfca)
-
- 14 6月, 2023 1 次提交
-
-
由 Liu Jian 提交于
hulk inclusion category: feature bugzilla: NA CVE: N/A ---------------------------------------------------- Some network acceleration solutions, such as sockmap, are valid only for internal packets of the local host. The bpf_is_local_ipaddr() bpf helper function is added so that the ebpf program can determine whether a packet is an internal packet of the local host. Signed-off-by: NLiu Jian <liujian56@huawei.com>
-
- 08 6月, 2023 2 次提交
-
-
由 Stefan Metzmacher 提交于
stable inclusion from stable-v5.10.162 commit f0a5f0dc0131c6483908601f6e4907befb609c97 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6LQMS Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f0a5f0dc0131c6483908601f6e4907befb609c97 -------------------------------- [ Upstream commit 50b7b6f2 ] As io_threads are fully set up USER threads it's clearer to separate the code path from the KTHREAD logic. The only remaining difference to user space threads is that io_threads never return to user space again. Instead they loop within the given worker function. The fact that they never return to user space means they don't have an user space thread stack. In order to indicate that to tools like gdb we reset the stack and instruction pointers to 0. This allows gdb attach to user space processes using io-uring, which like means that they have io_threads, without printing worrying message like this: warning: Selected architecture i386:x86-64 is not compatible with reported target architecture i386 warning: Architecture rejected target-supplied description The output will be something like this: (gdb) info threads Id Target Id Frame * 1 LWP 4863 "io_uring-cp-for" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 2 LWP 4864 "iou-mgr-4863" 0x0000000000000000 in ?? () 3 LWP 4865 "iou-wrk-4863" 0x0000000000000000 in ?? () (gdb) thread 3 [Switching to thread 3 (LWP 4865)] #0 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () Backtrace stopped: Cannot access memory at address 0x0 Fixes: 4727dc20 ("arch: setup PF_IO_WORKER threads like PF_KTHREAD") Link: https://lore.kernel.org/io-uring/044d0bad-6888-a211-e1d3-159a4aeed52d@polymtl.ca/T/#m1bbf5727e3d4e839603f6ec7ed79c7eebfba6267Signed-off-by: NStefan Metzmacher <metze@samba.org> cc: Linus Torvalds <torvalds@linux-foundation.org> cc: Jens Axboe <axboe@kernel.dk> cc: Andy Lutomirski <luto@kernel.org> cc: linux-kernel@vger.kernel.org cc: io-uring@vger.kernel.org cc: x86@kernel.org Link: https://lore.kernel.org/r/20210505110310.237537-1-metze@samba.orgReviewed-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> (cherry picked from commit 6e14bf4c)
-
由 Jens Axboe 提交于
stable inclusion from stable-v5.10.162 commit 320c8057eceb18c5d836fcbe0ffb0035fcfe28ff category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6LQMS Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=320c8057eceb18c5d836fcbe0ffb0035fcfe28ff -------------------------------- PF_IO_WORKER are kernel threads too, but they aren't PF_KTHREAD in the sense that we don't assign ->set_child_tid with our own structure. Just ensure that every arch sets up the PF_IO_WORKER threads like kthreads in the arch implementation of copy_thread(). Signed-off-by: NJens Axboe <axboe@kernel.dk> Conflict: arch/s390/kernel/process.c arch/x86/kernel/process.c Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> (cherry picked from commit 5b0c03b1)
-
- 07 6月, 2023 4 次提交
-
-
由 Zeng Heng 提交于
hulk inclusion category: bugfix issue: https://gitee.com/openeuler/kernel/issues/I69VF6 -------------------------------- If kdump is enabled, when using mce_inject to inject errors, EFI boot loader would decompress & load second kernel for saving the vmcore file. For normal errors that is fine. However, in the MCE case, the panic CPU that firstly enters into mce_panic() is running within NMI interrupt context, and the processor blocks delivery of subsequent NMIs until the next execution of the IRET instruction. When the panic CPU takes long time in the panic processing route, and causes the watchdog timeout, at this moment, the processor already receives NMI interrupt in the background. In the reproducer sequence below, panic CPU would run into EFI loader and raise page fault exception (like visiting `vidmem` variable when attempting to call debug_putstr()), the CPU would execute IRET instruction when it exits from the page fault handler. But the loader never registers handler for NMI vector in IDT, lack of vector handler would cause reboot, which interrupts kdump procedure and fails to save the vmcore file. Here is steps to reproduce the above issue (it's sporadic): 1. # cat uncorrected CPU 1 BANK 4 STATUS uncorrected 0xc0 MCGSTATUS EIPV MCIP ADDR 0x1234 RIP 0xdeadbabe RAISINGCPU 0 MCGCAP SER CMCI TES 0x6 2. # modprobe mce_inject 3. # mce-inject uncorrected For increasing the probability of reproduction of this issue, there are two ways to increase the probability of the bug: 1. modify the threshold value of watchdog (increase NMI frequency); 2. and/or add delays before panic() in mce_panic() and modify PANIC_TIMEOUT macro; Fixes: ca0e22d4 ("x86/boot/compressed/64: Always switch to own page table") Signed-off-by: NZeng Heng <zengheng4@huawei.com> [ Tidy up changelog, add comments. ] Signed-off-by: NIngo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20230110102745.2514694-1-zengheng4@huawei.com (cherry picked from commit 28410785)
-
由 Chen Zhongjin 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6DK3O CVE: NA -------------------------------- check_paravirt() calls orc_find() before its implementation code. If CONFIG_DYNAMIC_FTRACE is enabled, orc_find() will be declared earlier and compiling will not fail. Otherwise it will fail for "implicit declaration of function 'orc_find'". Move declaration of orc_find() out of CONFIG_DYNAMIC_FTRACE macro to fix this. Fixes: cbb12ea4718a ("[Huawei] x86/unwind: Fix orc entry for paravirt {save,restore}_fl") Signed-off-by: NChen Zhongjin <chenzhongjin@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> (cherry picked from commit 78380898)
-
由 Chen Zhongjin 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6DK3O CVE: NA -------------------------------- When CONFIG_PARAVIRT_XXL is enabled, the code of {save,restore}_fl is defined as: ff 14 25 00 00 00 00 callq *0x0 which will be patched to call the xen paravirt function, or native implementation, in 'paravirt_patch_64.c': pushfq; popq %rax // for native_save_fl pushq %rdi; popfq // for native_restore_fl The orc metadata is generated with insn 'callq', so it can become inconsistent with the real insn 'push;pop'. This makes stacktrace on the 'pop' insn fail and incorrect stacktrace result can be returned. To prevent reliable stacktrace broken, check the insns when unwind pt_regs stack frame: When there are 'push;pop' combination and both insns don't change orc entry, it means the stack state is inconsistent with orc on pop. Add one slot to sp_offset for on original orc entry to get the correct orc entry. Signed-off-by: NChen Zhongjin <chenzhongjin@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> (cherry picked from commit cd5fe777)
-
由 Wei Li 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I7BAJ0 -------------------------------- EulerFS was introduced as a technical preview feature in the 21.09 innovation version. Considering the current discontinuation of Intel Optane hardware and immature ecosystem, it has been decided to turn it off in the 22.03 LTS version. It will continue to evolve as an innovative feature in future innovation versions. Signed-off-by: NWei Li <liwei391@huawei.com> (cherry picked from commit 42e496a1)
-
- 02 6月, 2023 1 次提交
-
-
由 Yang Yingliang 提交于
hulk inclusion category: performance bugzilla: https://gitee.com/openeuler/kernel/issues/I7ADMY -------------------------------- Enable MITIGATION_FALSE_SHARING by default on x86 and arm64 Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
- 30 5月, 2023 2 次提交
-
-
由 xiongzhou4 提交于
GCC inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I734PM --------------------------------- This feature add value profile support for kernel by changing GCOV option "-fprofile-arcs" to "-fprofile-generate" when the new added config "PGO_KERNEL" is set to y. Like GCOV, the symbols required by value profile are migrated from GCC source codes as they cannot be linked to kernel. Specifically, from libgcc/libgcov-profiler.c to kernel/gcov/gcc_base.c. kernel options: CONFIG_PGO_KERNEL=y Signed-off-by: NXiong Zhou <xiongzhou4@huawei.com> Reviewed-by: NLi Yancheng <liyancheng@huawei.com>
-
由 Zhao Wenhui 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I737X1 ------------------------------- Expand qos_level from {-1,0} to [-2, 2], to distinguish the tasks expected to be with extremely high or low priority level. Using qos_level_weight to reweight the shares when calculating group's weight. Meanwhile, set offline task's schedule policy to SCHED_IDLE so that it can be preempted at check_preempt_wakeup. Signed-off-by: NZhao Wenhui <zhaowenhui8@huawei.com>
-
- 26 5月, 2023 1 次提交
-
-
由 zhoujiadong 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6V4RY CVE: NA --------------------------------- The NIC driver supports the following features: Supports IPv4/IPv6 TCP/UDP checksum, TSO, LRO offload and RSS functions. Supports interrupt aggregation parameter configuration and interrupt adaptation. Supports 802.1Q VLAN (Virtual Local Area Network) offloading and filtering. Supports NIC SR-IOV (Single Root I/O Virtualization). Support PF promiscuous mode Supports VF QinQ mode. Supports VF link state configuration and QoS configuration. Support VF MAC address management. Support VF spoofchk check. Support port lighting. Support Ethernet mouth self-negotiation, support pause frame. Signed-off-by: Nzhoujiadong <zhoujiadong5@huawei.com> Reviewed-by: NWulike (Collin) <wulike1@huawei.com>
-
- 23 5月, 2023 4 次提交
-
-
由 Chen Zhongjin 提交于
stable inclusion from stable-v5.10.153 commit b55d6ea965ba1f4c16c238af49f35b26f6bfc3fe category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b55d6ea965ba1f4c16c238af49f35b26f6bfc3fe -------------------------------- [ Upstream commit 230db824 ] When a console stack dump is initiated with CONFIG_GCOV_PROFILE_ALL enabled, show_trace_log_lvl() gets out of sync with the ORC unwinder, causing the stack trace to show all text addresses as unreliable: # echo l > /proc/sysrq-trigger [ 477.521031] sysrq: Show backtrace of all active CPUs [ 477.523813] NMI backtrace for cpu 0 [ 477.524492] CPU: 0 PID: 1021 Comm: bash Not tainted 6.0.0 #65 [ 477.525295] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-1.fc36 04/01/2014 [ 477.526439] Call Trace: [ 477.526854] <TASK> [ 477.527216] ? dump_stack_lvl+0xc7/0x114 [ 477.527801] ? dump_stack+0x13/0x1f [ 477.528331] ? nmi_cpu_backtrace.cold+0xb5/0x10d [ 477.528998] ? lapic_can_unplug_cpu+0xa0/0xa0 [ 477.529641] ? nmi_trigger_cpumask_backtrace+0x16a/0x1f0 [ 477.530393] ? arch_trigger_cpumask_backtrace+0x1d/0x30 [ 477.531136] ? sysrq_handle_showallcpus+0x1b/0x30 [ 477.531818] ? __handle_sysrq.cold+0x4e/0x1ae [ 477.532451] ? write_sysrq_trigger+0x63/0x80 [ 477.533080] ? proc_reg_write+0x92/0x110 [ 477.533663] ? vfs_write+0x174/0x530 [ 477.534265] ? handle_mm_fault+0x16f/0x500 [ 477.534940] ? ksys_write+0x7b/0x170 [ 477.535543] ? __x64_sys_write+0x1d/0x30 [ 477.536191] ? do_syscall_64+0x6b/0x100 [ 477.536809] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 477.537609] </TASK> This happens when the compiled code for show_stack() has a single word on the stack, and doesn't use a tail call to show_stack_log_lvl(). (CONFIG_GCOV_PROFILE_ALL=y is the only known case of this.) Then the __unwind_start() skip logic hits an off-by-one bug and fails to unwind all the way to the intended starting frame. Fix it by reverting the following commit: f1d9a2ab ("x86/unwind/orc: Don't skip the first frame for inactive tasks") The original justification for that commit no longer exists. That original issue was later fixed in a different way, with the following commit: f2ac57a4 ("x86/unwind/orc: Fix inactive tasks with stack pointer in %sp on GCC 10 compiled kernels") Fixes: f1d9a2ab ("x86/unwind/orc: Don't skip the first frame for inactive tasks") Signed-off-by: NChen Zhongjin <chenzhongjin@huawei.com> [jpoimboe: rewrite commit log] Signed-off-by: NJosh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: NPeter Zijlstra <peterz@infradead.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>
-
由 Maxim Levitsky 提交于
stable inclusion from stable-v5.10.153 commit fb94152aae8859335655b89e98685db742a2dd09 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fb94152aae8859335655b89e98685db742a2dd09 -------------------------------- [ Upstream commit b329f5dd ] clear_cpu_cap(&boot_cpu_data) is very similar to setup_clear_cpu_cap() except that the latter also sets a bit in 'cpu_caps_cleared' which later clears the same cap in secondary cpus, which is likely what is meant here. Fixes: 47125db2 ("perf/x86/intel/lbr: Support Architectural LBR") Signed-off-by: NMaxim Levitsky <mlevitsk@redhat.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NKan Liang <kan.liang@linux.intel.com> Link: https://lkml.kernel.org/r/20220718141123.136106-2-mlevitsk@redhat.comSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>
-
由 Chang S. Bae 提交于
mainline inclusion from mainline-v6.3-rc4 commit b1588884 category: bugfix bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I73H0T CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b15888840207c2bfe678dd1f68a32db54315e71f Intel-SIG: commit b1588884 x86/fpu/xstate: Prevent false-positive warning in __copy_xstate_uabi_buf(). -------------------------------- __copy_xstate_to_uabi_buf() copies either from the tasks XSAVE buffer or from init_fpstate into the ptrace buffer. Dynamic features, like XTILEDATA, have an all zeroes init state and are not saved in init_fpstate, which means the corresponding bit is not set in the xfeatures bitmap of the init_fpstate header. But __copy_xstate_to_uabi_buf() retrieves addresses for both the tasks xstate and init_fpstate unconditionally via __raw_xsave_addr(). So if the tasks XSAVE buffer has a dynamic feature set, then the address retrieval for init_fpstate triggers the warning in __raw_xsave_addr() which checks the feature bit in the init_fpstate header. Remove the address retrieval from init_fpstate for extended features. They have an all zeroes init state so init_fpstate has zeros for them. Then zeroing the user buffer for the init state is the same as copying them from init_fpstate. Fixes: 2308ee57 ("x86/fpu/amx: Enable the AMX feature in 64-bit mode") Reported-by: NMingwei Zhang <mizhang@google.com> Link: https://lore.kernel.org/kvm/20230221163655.920289-2-mizhang@google.com/Signed-off-by: NChang S. Bae <chang.seok.bae@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Tested-by: NMingwei Zhang <mizhang@google.com> Link: https://lore.kernel.org/all/20230227210504.18520-2-chang.seok.bae%40intel.com Cc: stable@vger.kernel.org Signed-off-by: NLin Wang <lin.x.wang@intel.com>
-
由 Chang S. Bae 提交于
mainline inclusion from mainline-v6.1-rc2 commit 471f0aa7 category: bugfix bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I73H0T CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=471f0aa7fa64e23766a1473b32d9ec3f0718895a Intel-SIG: commit 471f0aa7 x86/fpu: Fix copy_xstate_to_uabi() to copy init states correctly. -------------------------------- When an extended state component is not present in fpstate, but in init state, the function copies from init_fpstate via copy_feature(). But, dynamic states are not present in init_fpstate because of all-zeros init states. Then retrieving them from init_fpstate will explode like this: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... RIP: 0010:memcpy_erms+0x6/0x10 ? __copy_xstate_to_uabi_buf+0x381/0x870 fpu_copy_guest_fpstate_to_uabi+0x28/0x80 kvm_arch_vcpu_ioctl+0x14c/0x1460 [kvm] ? __this_cpu_preempt_check+0x13/0x20 ? vmx_vcpu_put+0x2e/0x260 [kvm_intel] kvm_vcpu_ioctl+0xea/0x6b0 [kvm] ? kvm_vcpu_ioctl+0xea/0x6b0 [kvm] ? __fget_light+0xd4/0x130 __x64_sys_ioctl+0xe3/0x910 ? debug_smp_processor_id+0x17/0x20 ? fpregs_assert_state_consistent+0x27/0x50 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Adjust the 'mask' to zero out the userspace buffer for the features that are not available both from fpstate and from init_fpstate. The dynamic features depend on the compacted XSAVE format. Ensure it is enabled before reading XCOMP_BV in init_fpstate. Fixes: 2308ee57 ("x86/fpu/amx: Enable the AMX feature in 64-bit mode") Reported-by: NYuan Yao <yuan.yao@intel.com> Suggested-by: NDave Hansen <dave.hansen@intel.com> Signed-off-by: NChang S. Bae <chang.seok.bae@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Tested-by: NYuan Yao <yuan.yao@intel.com> Link: https://lore.kernel.org/lkml/BYAPR11MB3717EDEF2351C958F2C86EED95259@BYAPR11MB3717.namprd11.prod.outlook.com/ Link: https://lkml.kernel.org/r/20221021185844.13472-1-chang.seok.bae@intel.comSigned-off-by: NLin Wang <lin.x.wang@intel.com>
-