stable inclusion
from stable-v5.10.187
commit 93df00f9d48d48466ddbe01a06eaaf3311ecfb53
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7NLYY
CVE: CVE-2023-20593

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=93df00f9d48d48466ddbe01a06eaaf3311ecfb53

--------------------------------

Upstream commit: 522b1d69219d8f083173819fde04f994aa051a98

Add a fix for the Zen2 VZEROUPPER data corruption bug where under
certain circumstances executing VZEROUPPER can cause register
corruption or leak data.

The optimal fix is through microcode but in the case the proper
microcode revision has not been applied, enable a fallback fix using
a chicken bit.
Signed-off-by: NBorislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

 Conflicts:
	arch/x86/include/asm/microcode_amd.h
	arch/x86/kernel/cpu/common.c
Signed-off-by: NYu Liao <liaoyu15@huawei.com>

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>
Signed-off-by: NYu Liao <liaoyu15@huawei.com>

amd inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6XNL2
CVE: NA

-------------------------------------------------
Error report detail:
*** ERROR - ABI BREAKAGE WAS DETECTED ***

The following symbols have been changed (this will cause an ABI breakage):
new kabi:
0x65d25289	__SCK__tp_func_xdp_exception	vmlinux	EXPORT_SYMBOL_GPL
0x5e9265ee	__tracepoint_xdp_exception	vmlinux	EXPORT_SYMBOL_GPL
old kabi:
0x5e0fbbff	__SCK__tp_func_xdp_exception	vmlinux	EXPORT_SYMBOL_GPL
0x017cc464	__tracepoint_xdp_exception	vmlinux	EXPORT_SYMBOL_GPL
Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>
(cherry picked from commit 600130a3)

amd inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6XNL2
CVE: NA

-------------------------------------------------

This reverts commit a9cbff64.

This patch could introduce build warnings, should be reverted.
The build warning messages:
WARNING: modpost: EXPORT symbol "__SCT__perf_lopwr_cb" [vmlinux] version generation failed, symbol will not be versioned.
    WARNING: modpost: EXPORT symbol "__SCT__perf_lopwr_cb" [vmlinux] version generation failed, symbol will not be versioned.
Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>
(cherry picked from commit fb465f68)

stable inclusion
from stable-v5.10.150
commit 7ae8bed9087a904201ac39b159ef4b1947049465
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0XA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7ae8bed9087a904201ac39b159ef4b1947049465

--------------------------------

[ Upstream commit ea9da788 ]

Section 1.9 of TLFS v6.0b says:

"All structures are padded in such a way that fields are aligned
naturally (that is, an 8-byte field is aligned to an offset of 8 bytes
and so on)".

'struct enlightened_vmcs' has a glitch:

...
        struct {
                u32                nested_flush_hypercall:1; /*   836: 0  4 */
                u32                msr_bitmap:1;         /*   836: 1  4 */
                u32                reserved:30;          /*   836: 2  4 */
        } hv_enlightenments_control;                     /*   836     4 */
        u32                        hv_vp_id;             /*   840     4 */
        u64                        hv_vm_id;             /*   844     8 */
        u64                        partition_assist_page; /*   852     8 */
...

And the observed values in 'partition_assist_page' make no sense at
all. Fix the layout by padding the structure properly.

Fixes: 68d1eb72 ("x86/hyper-v: define struct hv_enlightened_vmcs and clean field bits")
Reviewed-by: NMaxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: NSean Christopherson <seanjc@google.com>
Link: https://lore.kernel.org/r/20220830133737.1539624-2-vkuznets@redhat.comSigned-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.150
commit 6ed7b05a3592e96023989417f617f80a5e25dedd
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0XA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6ed7b05a3592e96023989417f617f80a5e25dedd

--------------------------------

[ Upstream commit 712f210a ]

In preparation for reducing the use of ksize(), record the actual
allocation size for later memcpy(). This avoids copying extra
(uninitialized!) bytes into the patch buffer when the requested
allocation size isn't exactly the size of a kmalloc bucket.
Additionally, fix potential future issues where runtime bounds checking
will notice that the buffer was allocated to a smaller value than
returned by ksize().

Fixes: 757885e9 ("x86, microcode, amd: Early microcode patch loading support for AMD")
Suggested-by: NDaniel Micay <danielmicay@gmail.com>
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/lkml/CA+DvKQ+bp7Y7gmaVhacjv9uF6Ar-o4tet872h4Q8RPYPJjcJQA@mail.gmail.com/Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.15.94
commit 8f12dcab90e886d0169a9cd372a8bb35339cfc19
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6FB6C
CVE: CVE-2022-27672

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8f12dcab90e886d0169a9cd372a8bb35339cfc19

--------------------------------

commit be8de49b upstream.

Certain AMD processors are vulnerable to a cross-thread return address
predictions bug. When running in SMT mode and one of the sibling threads
transitions out of C0 state, the other sibling thread could use return
target predictions from the sibling thread that transitioned out of C0.

The Spectre v2 mitigations cover the Linux kernel, as it fills the RSB
when context switching to the idle thread. However, KVM allows a VMM to
prevent exiting guest mode when transitioning out of C0. A guest could
act maliciously in this situation, so create a new x86 BUG that can be
used to detect if the processor is vulnerable.
Reviewed-by: NBorislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
Message-Id: <91cec885656ca1fcd4f0185ce403a53dd9edecb7.1675956146.git.thomas.lendacky@amd.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Guo Mengqi <guomengqi3@huawei.com
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.162
commit 4b1dcf8ec9b2f11b57f1ff5dcaa1f8575c7dacb5
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6BTWC
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.168&id=4b1dcf8ec9b2f11b57f1ff5dcaa1f8575c7dacb5

--------------------------------

[ Upstream commit c8d5ed67 ]

The generic entry code has support for TIF_NOTIFY_SIGNAL already. Just
provide the TIF bit.

[ tglx: Adopted to other TIF changes in x86 ]
Signed-off-by: NJens Axboe <axboe@kernel.dk>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20201026203230.386348-4-axboe@kernel.dkSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v6.2-rc1
commit 3f148f33
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6C6UC
CVE: CVE-2023-0597

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3f148f3318140035e87decc1214795ff0755757b

--------------------------------

KASAN maps shadow for the entire CPU-entry-area:
  [CPU_ENTRY_AREA_BASE, CPU_ENTRY_AREA_BASE + CPU_ENTRY_AREA_MAP_SIZE]

This will explode once the per-cpu entry areas are randomized since it
will increase CPU_ENTRY_AREA_MAP_SIZE to 512 GB and KASAN fails to
allocate shadow for such big area.

Fix this by allocating KASAN shadow only for really used cpu entry area
addresses mapped by cea_map_percpu_pages()

Thanks to the 0day folks for finding and reporting this to be an issue.

[ dhansen: tweak changelog since this will get committed before peterz's
	   actual cpu-entry-area randomization ]
Signed-off-by: NAndrey Ryabinin <ryabinin.a.a@gmail.com>
Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com>
Tested-by: NYujie Liu <yujie.liu@intel.com>
Cc: kernel test robot <yujie.liu@intel.com>
Link: https://lore.kernel.org/r/202210241508.2e203c3d-yujie.liu@intel.comSigned-off-by: NTong Tiangen <tongtiangen@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v6.2-rc1
commit 97e3d26b
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6C6UC
CVE: CVE-2023-0597

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=97e3d26b5e5f371b3ee223d94dd123e6c442ba80

--------------------------------

Seth found that the CPU-entry-area; the piece of per-cpu data that is
mapped into the userspace page-tables for kPTI is not subject to any
randomization -- irrespective of kASLR settings.

On x86_64 a whole P4D (512 GB) of virtual address space is reserved for
this structure, which is plenty large enough to randomize things a
little.

As such, use a straight forward randomization scheme that avoids
duplicates to spread the existing CPUs over the available space.

  [ bp: Fix le build. ]
Reported-by: NSeth Jenkins <sethjenkins@google.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Confilict:
	arch/x86/mm/cpu_entry_area.c

	Use get_random_u32() instead of prandom_u32_max() in init_cea_offsets().

        With CONFIG_RANDOMIZE_BASE=y, KASLR use prandom_seed_state() init prandom seed before
        init_cea_offsets(). But when CONFIG_RANDOMIZE_BASE=n, prandom seed init after
        init_cea_offsets() cause cea is always 0.

        The patch d4150779("random32: use real rng for non-deterministic randomness")
        use get_random_u32() instead of prandom_u32() in prandom_u32_max()
        that make prandom_u32_max() don't need to wait prandom seed init().
	But the patch has many pre-patches that have not been merged,

	So,we adopt the current solution as a workaround. directly use
	get_random_u32() in init_cea_offsets() to simplify code.
Signed-off-by: NKe Liu <liuke94@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.141
commit e5796ff9acc5e922be3b1a599e004534e4fe23cf
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e5796ff9acc5e922be3b1a599e004534e4fe23cf

--------------------------------

commit 33292497 upstream.

Turns out that i386 doesn't unconditionally have LFENCE, as such the
loop in __FILL_RETURN_BUFFER isn't actually speculation safe on such
chips.

Fixes: ba6e31af ("x86/speculation: Add LFENCE to RSB fill sequence")
Reported-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/Yv9tj9vbQ9nNlXoY@worktop.programming.kicks-ass.netSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.141
commit adee8f3082b01e5dab620d651e3ec75f57c0c855
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I685FC

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=adee8f3082b01e5dab620d651e3ec75f57c0c855

--------------------------------

commit 4e3aa923 upstream.

Commit 2b129932 ("x86/speculation: Add RSB VM Exit protections")
made a right mess of the RSB stuffing, rewrite the whole thing to not
suck.

Thanks to Andrew for the enlightening comment about Post-Barrier RSB
things so we can make this code less magical.

Cc: stable@vger.kernel.org
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/YvuNdDWoUZSBjYcm@worktop.programming.kicks-ass.net
[bwh: Backported to 5.10: adjust context]
Signed-off-by: NBen Hutchings <benh@debian.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.15
commit 746700d2
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6B4YT
CVE: NA

--------------------------------

AMD future CPUs will require a 5-level NPT if host CR4.LA57 is set.
To prevent kvm_mmu_get_tdp_level() from incorrectly changing NPT level
on behalf of CPUs, add a new parameter in kvm_configure_mmu() to force
a fixed TDP level.
Signed-off-by: NWei Huang <wei.huang2@amd.com>
Message-Id: <20210818165549.3771014-2-wei.huang2@amd.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>

amd inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6A0G7
CVE: NA

--------------------------------

Below AMD platform features are incorrect detected:

X86_FEATURE_SME,
X86_FEATURE_SEV,
X86_FEATURE_VM_PAGE_FLUSH,
X86_FEATURE_SEV_ES,
X86_FEATURE_SME_COHERENT

This bug is introduced by commit ac376dd8.
The definition and use of CPUID_8000_001F_EAX will cause c.x86_capability
get a conflict wrong value.
Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.15-rc1
commit 9164d949
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I65D55
CVE: NA

--------------------------------

Factor out a helper function rather than export cpu_llc_id, which is
needed in order to be able to build the AMD uncore driver as a module.
Signed-off-by: NKim Phillips <kim.phillips@amd.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: NIngo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20210817221048.88063-7-kim.phillips@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v5.19-rc1
commit db1af129
category: feature
feature: Intel In Filed Scan(IFS)
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I651S7
CVE: N/A
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
commit/?id=db1af129

Intel-SIG: commit db1af129 ("x86/msr-index: Define INTEGRITY_CAPABILITIES MSR")

-------------------------------------

x86/msr-index: Define INTEGRITY_CAPABILITIES MSR

The INTEGRITY_CAPABILITIES MSR is enumerated by bit 2 of the
CORE_CAPABILITIES MSR.

Add defines for the CORE_CAPS enumeration as well as for the integrity
MSR.
Reviewed-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20220506225410.1652287-3-tony.luck@intel.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAichun Shi <aichun.shi@intel.com>

mainline inclusion
from mainline-v5.19-rc1
commit d3287fb0
category: feature
feature: Intel In Filed Scan(IFS)
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I651S7
CVE: N/A
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
commit/?id=d3287fb0

Intel-SIG: commit d3287fb0 ("x86/microcode/intel: Expose collect_cpu_info_early() for IFS")

-------------------------------------

x86/microcode/intel: Expose collect_cpu_info_early() for IFS

IFS is a CPU feature that allows a binary blob, similar to microcode,
to be loaded and consumed to perform low level validation of CPU
circuitry. In fact, it carries the same Processor Signature
(family/model/stepping) details that are contained in Intel microcode
blobs.

In support of an IFS driver to trigger loading, validation, and running
of these tests blobs, make the functionality of cpu_signatures_match()
and collect_cpu_info_early() available outside of the microcode driver.

Add an "intel_" prefix and drop the "_early" suffix from
collect_cpu_info_early() and EXPORT_SYMBOL_GPL() it. Add
declaration to x86 <asm/cpu.h>

Make cpu_signatures_match() an inline function in x86 <asm/cpu.h>,
and also give it an "intel_" prefix.

No functional change intended.
Reviewed-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NJithu Joseph <jithu.joseph@intel.com>
Co-developed-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20220506225410.1652287-2-tony.luck@intel.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAichun Shi <aichun.shi@intel.com>

stable inclusion
from stable-v5.10.140
commit 14cbbb9c9914663d0eeca6b59c1c9d4f5a547ee0
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I63FTT

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=14cbbb9c9914663d0eeca6b59c1c9d4f5a547ee0

--------------------------------

commit 7df54884 upstream.

Older Intel CPUs that are not in the affected processor list for MMIO
Stale Data vulnerabilities currently report "Not affected" in sysfs,
which may not be correct. Vulnerability status for these older CPUs is
unknown.

Add known-not-affected CPUs to the whitelist. Report "unknown"
mitigation status for CPUs that are not in blacklist, whitelist and also
don't enumerate MSR ARCH_CAPABILITIES bits that reflect hardware
immunity to MMIO Stale Data vulnerabilities.

Mitigation is not deployed when the status is unknown.

  [ bp: Massage, fixup. ]

Fixes: 8d50cdf8 ("x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data")
Suggested-by: NAndrew Cooper <andrew.cooper3@citrix.com>
Suggested-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NPawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/a932c154772f2121794a5f2eded1a11013114711.1657846269.git.pawan.kumar.gupta@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
Reviewed-by: NWei Li <liwei391@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I60L10
CVE: NA

--------------------------------

If a function is patched, instructions at the beginning are modified to be
'jump codes' which jump to new function. This requires the function be big
enough, otherwise the modification may be out of function range.

Currently each architecture needs to implement arch_klp_func_can_patch()
to check function size. However, there exists following problems:
  1. arch 'x86' didn't implement arch_klp_func_can_patch();
  2. implementations in arm64 & ppc32, function size is checked only if
     there's a long jump. There is a scenario where a very short function
     is successfully patched, but as kernel module increases, someday long
     jump is required, then the function become unable to be patched.
  3. implementaions look like duplicate.

In this patch, introduce macro KLP_MAX_REPLACE_SIZE to denote the maximum
size that will be replaced on patching, then move the check ahead into
klp_init_object_loaded().

Fixes: c33e4283 ("livepatch/core: Allow implementation without ftrace")
Signed-off-by: NZheng Yejian <zhengyejian1@huawei.com>
Reviewed-by: NKuohai Xu <xukuohai@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I60L10
CVE: NA

--------------------------------

In arm/arm64/ppc32/ppc64, this field is named as old_insns, so uniform it.
Signed-off-by: NZheng Yejian <zhengyejian1@huawei.com>
Reviewed-by: NKuohai Xu <xukuohai@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v6.1-rc1
commit 610c2380
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I601MP
CVE: NA

--------------------------------

IBS_OP_DATA2 DataSrc provides detail about location of the data
being accessed from by load ops. Define macros for legacy and
extended DataSrc values.
Signed-off-by: NRavi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20220928095805.596-3-ravi.bangoria@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v6.0-rc1
commit 326ecc15
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I601MP
CVE: NA

--------------------------------

IBS support has been enhanced with two new features in upcoming uarch:

  1. DataSrc extension and
  2. L3 miss filtering.

Additional set of bits has been introduced in IBS registers to use these
features. Define these new bits into arch/x86/ header.

  [ bp: Massage commit message. ]
Signed-off-by: NRavi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Acked-by: NIan Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20220604044519.594-7-ravi.bangoria@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v6.0-rc1
commit c390241a
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5YLE2
CVE: NA

--------------------------------

If AMD Performance Monitoring Version 2 (PerfMonV2) is
supported, use bits 0-7, 32-37 as EventSelect and bits
8-15, 24-27 as UnitMask for Data Fabric (DF) events.
Signed-off-by: NSandipan Das <sandipan.das@amd.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/ffc24d5a3375b1d6e457d88e83241114de5c1942.1652954372.git.sandipan.das@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

mainline inclusion
from mainline-v6.0-rc1
commit 16b48c3f
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5YLE2
CVE: NA

--------------------------------

If AMD Performance Monitoring Version 2 (PerfMonV2) is
supported, use CPUID leaf 0x80000022 EBX to detect the
number of Data Fabric (DF) PMCs. This offers more
flexibility if the counts change in later processor
families.
Signed-off-by: NSandipan Das <sandipan.das@amd.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/bac7b2806561e03f2acc7fdc9db94f102df80e1d.1652954372.git.sandipan.das@amd.comSigned-off-by: NXie Haocheng <haocheng.xie@amd.com>

amd inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5S3WV
CVE: NA

-------------------------------------------------

Error report detail:
*** ERROR - ABI BREAKAGE WAS DETECTED ***

The following symbols have been changed (this will cause an ABI breakage):
new kabi:
0x65d25289	__SCK__tp_func_xdp_exception	vmlinux	EXPORT_SYMBOL_GPL
0x5e9265ee	__tracepoint_xdp_exception	vmlinux	EXPORT_SYMBOL_GPL
old kabi:
0x5e0fbbff	__SCK__tp_func_xdp_exception	vmlinux	EXPORT_SYMBOL_GPL
0x017cc464	__tracepoint_xdp_exception	vmlinux	EXPORT_SYMBOL_GPL
Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>

category: bugfix
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5RQLJ
CVE: NA

Intel-SIG: x86/fpu: Fix KABI broken caused by introducing of guest
permissions in struct fpu.

--------------------------------

Using KABI_EXTEND macro to avoid kabi change caused by the commit:
980fe2fd x86/fpu: Extend fpu_xstate_prctl() with guest permissions
Signed-off-by: NLin Wang <lin.x.wang@intel.com>

mainline inclusion
from mainline-v5.17-rc1
commit c862dcd1
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5RQLJ
CVE: NA

Intel-SIG: commit c862dcd1 x86/fpu: Fix inline prefix warnings.

--------------------------------

Fix sparse warnings in xstate and remove inline prefix.

Fixes: 980fe2fd ("x86/fpu: Extend fpu_xstate_prctl() with guest permissions")
Signed-off-by: NYang Zhong <yang.zhong@intel.com>
Reported-by: Nkernel test robot <lkp@intel.com>
Message-Id: <20220113180825.322333-1-yang.zhong@intel.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NLin Wang <lin.x.wang@intel.com>

mainline inclusion
from mainline-v5.17-rc1
commit b5274b1b
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5RQLJ
CVE: NA

Intel-SIG: commit b5274b1b kvm: x86: Disable interception for IA32_XFD on demand.

--------------------------------

Always intercepting IA32_XFD causes non-negligible overhead when this
register is updated frequently in the guest.

Disable r/w emulation after intercepting the first WRMSR(IA32_XFD)
with a non-zero value.

Disable WRMSR emulation implies that IA32_XFD becomes out-of-sync
with the software states in fpstate and the per-cpu xfd cache. This
leads to two additional changes accordingly:

  - Call fpu_sync_guest_vmexit_xfd_state() after vm-exit to bring
    software states back in-sync with the MSR, before handle_exit_irqoff()
    is called.

  - Always trap #NM once write interception is disabled for IA32_XFD.
    The #NM exception is rare if the guest doesn't use dynamic
    features. Otherwise, there is at most one exception per guest
    task given a dynamic feature.

p.s. We have confirmed that SDM is being revised to say that
when setting IA32_XFD[18] the AMX register state is not guaranteed
to be preserved. This clarification avoids adding mess for a creative
guest which sets IA32_XFD[18]=1 before saving active AMX state to
its own storage.
Signed-off-by: NKevin Tian <kevin.tian@intel.com>
Signed-off-by: NJing Liu <jing2.liu@intel.com>
Signed-off-by: NYang Zhong <yang.zhong@intel.com>
Message-Id: <20220105123532.12586-22-yang.zhong@intel.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NLin Wang <lin.x.wang@intel.com>

mainline inclusion
from mainline-v5.17-rc1
commit 5429cead
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5RQLJ
CVE: NA

Intel-SIG: commit 5429cead x86/fpu: Provide fpu_sync_guest_vmexit_xfd_state().

--------------------------------

KVM can disable the write emulation for the XFD MSR when the vCPU's fpstate
is already correctly sized to reduce the overhead.

When write emulation is disabled the XFD MSR state after a VMEXIT is
unknown and therefore not in sync with the software states in fpstate and
the per CPU XFD cache.

Provide fpu_sync_guest_vmexit_xfd_state() which has to be invoked after a
VMEXIT before enabling interrupts when write emulation is disabled for the
XFD MSR.

It could be invoked unconditionally even when write emulation is enabled
for the price of a pointless MSR read.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NJing Liu <jing2.liu@intel.com>
Signed-off-by: NYang Zhong <yang.zhong@intel.com>
Message-Id: <20220105123532.12586-21-yang.zhong@intel.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NLin Wang <lin.x.wang@intel.com>

mainline inclusion
from mainline-v5.17-rc1
commit c60427dd
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5RQLJ
CVE: NA

Intel-SIG: commit c60427dd x86/fpu: Add uabi_size to guest_fpu.

--------------------------------

Userspace needs to inquire KVM about the buffer size to work
with the new KVM_SET_XSAVE and KVM_GET_XSAVE2. Add the size info
to guest_fpu for KVM to access.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NWei Wang <wei.w.wang@intel.com>
Signed-off-by: NJing Liu <jing2.liu@intel.com>
Signed-off-by: NYang Zhong <yang.zhong@intel.com>
Message-Id: <20220105123532.12586-18-yang.zhong@intel.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NLin Wang <lin.x.wang@intel.com>

mainline inclusion
from mainline-v5.17-rc1
commit 1df4fd83
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5RQLJ
CVE: NA

Intel-SIG: commit 1df4fd83 x86/fpu: Prepare xfd_err in struct fpu_guest.

--------------------------------

When XFD causes an instruction to generate #NM, IA32_XFD_ERR
contains information about which disabled state components are
being accessed. The #NM handler is expected to check this
information and then enable the state components by clearing
IA32_XFD for the faulting task (if having permission).

If the XFD_ERR value generated in guest is consumed/clobbered
by the host before the guest itself doing so, it may lead to
non-XFD-related #NM treated as XFD #NM in host (due to non-zero
value in XFD_ERR), or XFD-related #NM treated as non-XFD #NM in
guest (XFD_ERR cleared by the host #NM handler).

Introduce a new field in fpu_guest to save the guest xfd_err value.
KVM is expected to save guest xfd_err before interrupt is enabled
and restore it right before entering the guest (with interrupt
disabled).
Signed-off-by: NJing Liu <jing2.liu@intel.com>
Signed-off-by: NKevin Tian <kevin.tian@intel.com>
Signed-off-by: NJing Liu <jing2.liu@intel.com>
Signed-off-by: NYang Zhong <yang.zhong@intel.com>
Message-Id: <20220105123532.12586-12-yang.zhong@intel.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NLin Wang <lin.x.wang@intel.com>

mainline inclusion
from mainline-v5.17-rc1
commit 8eb9a48a
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5RQLJ
CVE: NA

Intel-SIG: commit 8eb9a48a x86/fpu: Provide fpu_update_guest_xfd() for IA32_XFD emulation.

--------------------------------

Guest XFD can be updated either in the emulation path or in the
restore path.

Provide a wrapper to update guest_fpu::fpstate::xfd. If the guest
fpstate is currently in-use, also update the per-cpu xfd cache and
the actual MSR.
Signed-off-by: NKevin Tian <kevin.tian@intel.com>
Signed-off-by: NJing Liu <jing2.liu@intel.com>
Signed-off-by: NYang Zhong <yang.zhong@intel.com>
Message-Id: <20220105123532.12586-10-yang.zhong@intel.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NLin Wang <lin.x.wang@intel.com>

mainline inclusion
from mainline-v5.17-rc1
commit 0781d60f
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5RQLJ
CVE: NA

Intel-SIG: commit 0781d60f x86/fpu: Provide fpu_enable_guest_xfd_features() for KVM.

--------------------------------

Provide a wrapper for expanding the guest fpstate buffer according
to requested xfeatures. KVM wants to call this wrapper to manage
any dynamic xstate used by the guest.
Suggested-by: NSean Christopherson <seanjc@google.com>
Signed-off-by: NSean Christopherson <seanjc@google.com>
Signed-off-by: NKevin Tian <kevin.tian@intel.com>
Signed-off-by: NYang Zhong <yang.zhong@intel.com>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-Id: <20220105123532.12586-8-yang.zhong@intel.com>
[Remove unnecessary 32-bit check. - Paolo]
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NLin Wang <lin.x.wang@intel.com>

mainline inclusion
from mainline-v5.17-rc1
commit 36487e62
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5RQLJ
CVE: NA

Intel-SIG: commit 36487e62 x86/fpu: Prepare guest FPU for dynamically enabled FPU features.

--------------------------------

To support dynamically enabled FPU features for guests prepare the guest
pseudo FPU container to keep track of the currently enabled xfeatures and
the guest permissions.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NJing Liu <jing2.liu@intel.com>
Signed-off-by: NYang Zhong <yang.zhong@intel.com>
Message-Id: <20220105123532.12586-3-yang.zhong@intel.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NLin Wang <lin.x.wang@intel.com>

mainline inclusion
from mainline-v5.17-rc1
commit 980fe2fd
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5RQLJ
CVE: NA

Intel-SIG: commit 980fe2fd x86/fpu: Extend fpu_xstate_prctl() with guest permissions.

--------------------------------

KVM requires a clear separation of host user space and guest permissions
for dynamic XSTATE components.

Add a guest permissions member to struct fpu and a separate set of prctl()
arguments: ARCH_GET_XCOMP_GUEST_PERM and ARCH_REQ_XCOMP_GUEST_PERM.

The semantics are equivalent to the host user space permission control
except for the following constraints:

  1) Permissions have to be requested before the first vCPU is created

  2) Permissions are frozen when the first vCPU is created to ensure
     consistency. Any attempt to expand permissions via the prctl() after
     that point is rejected.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NJing Liu <jing2.liu@intel.com>
Signed-off-by: NYang Zhong <yang.zhong@intel.com>
Message-Id: <20220105123532.12586-2-yang.zhong@intel.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NLin Wang <lin.x.wang@intel.com>

mainline inclusion
from mainline-v5.18
commit 7c1ef591
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I596WO
CVE: NA

Intel-SIG: commit 7c1ef591 x86/cpufeatures: Re-enable ENQCMD.
Incremental backporting patches for DSA/IAA on Intel Xeon platform.

--------------------------------

The ENQCMD feature can only be used if CONFIG_INTEL_IOMMU_SVM is set.
Add X86_FEATURE_ENQCMD to the disabled features mask as appropriate so
that cpu_feature_enabled() can be used to check the feature.

  [ bp: Massage commit message. ]
Signed-off-by: NFenghua Yu <fenghua.yu@intel.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NTony Luck <tony.luck@intel.com>
Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20220207230254.3342514-10-fenghua.yu@intel.comSigned-off-by: NXiaochen Shen <xiaochen.shen@intel.com>

mainline inclusion
from mainline-v5.16
commit 00ecd540
category: feature
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I596WO
CVE: NA

Intel-SIG: commit 00ecd540 iommu/vt-d: Clean up unused PASID updating functions.
Incremental backporting patches for DSA/IAA on Intel Xeon platform.

--------------------------------

update_pasid() and its call chain are currently unused in the tree because
Thomas disabled the ENQCMD feature. The feature will be re-enabled shortly
using a different approach and update_pasid() and its call chain will not
be used in the new approach.

Remove the useless functions.
Signed-off-by: NFenghua Yu <fenghua.yu@intel.com>
Reviewed-by: NTony Luck <tony.luck@intel.com>
Link: https://lore.kernel.org/r/20210920192349.2602141-1-fenghua.yu@intel.comSigned-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Link: https://lore.kernel.org/r/20211014053839.727419-8-baolu.lu@linux.intel.comSigned-off-by: NJoerg Roedel <jroedel@suse.de>
Signed-off-by: NXiaochen Shen <xiaochen.shen@intel.com>

mainline inclusion
from mainline-v5.12
commit 6ae58d87
category: bugfix
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I596WO
CVE: NA

Intel-SIG: commit 6ae58d87 x86/asm: Annotate movdir64b()'s dst argument with __iomem.
Incremental backporting patches for DSA/IAA on Intel Xeon platform.

--------------------------------

Add a missing __iomem annotation to address a sparse warning. The caller
is expected to pass an __iomem annotated pointer to this function. The
current usages send a 64-bytes command descriptor to an MMIO location
(portal) on a device for consumption. When future usages for the
MOVDIR64B instruction warrant a separate variant of a memory to memory
operation, the argument annotation can be revisited.

Also, from the comment in movdir64b() @__dst must be supplied as an
lvalue because this tells the compiler what the object is (its size) the
instruction accesses. I.e., not the pointers but what they point to,
thus the deref'ing '*'."

The actual sparse warning is:

  sparse warnings: (new ones prefixed by >>)
     drivers/dma/idxd/submit.c: note: in included file (through include/linux/io.h, include/linux/pci.h):
  >> arch/x86/include/asm/io.h:422:27: sparse: sparse: incorrect type in \
     argument 1 (different address spaces)
		   @@     expected void *dst
		   @@     got void [noderef] __iomem *dst @@
     arch/x86/include/asm/io.h:422:27: sparse:     expected void *dst
     arch/x86/include/asm/io.h:422:27: sparse:     got void [noderef] __iomem *dst

 [ bp: Massage commit message. ]

Fixes: 0888e103 ("x86/asm: Carve out a generic movdir64b() helper for general usage")
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NDave Jiang <dave.jiang@intel.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NBen Widawsky <ben.widawsky@intel.com>
Reviewed-by: NDan Williams <dan.j.williams@intel.com>
Link: https://lkml.kernel.org/r/161003787823.4062451.6564503265464317197.stgit@djiang5-desk3.ch.intel.comSigned-off-by: NXiaochen Shen <xiaochen.shen@intel.com>

mainline inclusion
from mainline-v6.0-rc1
commit 8add9a3a
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5OHOB
CVE: NA

--------------------------------

Currently, the arch_efi_call_virt() assumes all users of it will have
defined a type 'efi_##f##_t' to make use of it.

Simplify the arch_efi_call_virt() macro by eliminating the explicit
need for efi_##f##_t type for every user of this macro.
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
Acked-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
[ardb: apply Sudeep's ARM fix to i686, Loongarch and RISC-V too]
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5GB28
CVE: NA

-------------------------------

x86/powerpc has it's implementation of copy_mc_to_user(), we add generic
fallback in include/linux/uaccess.h prepare for other architechures to
enable CONFIG_ARCH_HAS_COPY_MC.
Signed-off-by: NTong Tiangen <tongtiangen@huawei.com>