stable inclusion
from stable-v5.10.104
commit 6d4985b8a0bf716dba5ae2caefcd906e9ca3df03
bugzilla: https://gitee.com/openeuler/kernel/issues/I56XAC

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

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

[ Upstream commit 5bfa685e ]

It appears that a read access to GIC[DR]_I[CS]PENDRn doesn't always
result in the pending interrupts being accurately reported if they are
mapped to a HW interrupt. This is particularily visible when acking
the timer interrupt and reading the GICR_ISPENDR1 register immediately
after, for example (the interrupt appears as not-pending while it really
is...).

This is because a HW interrupt has its 'active and pending state' kept
in the *physical* distributor, and not in the virtual one, as mandated
by the spec (this is what allows the direct deactivation). The virtual
distributor only caries the pending and active *states* (note the
plural, as these are two independent and non-overlapping states).

Fix it by reading the HW state back, either from the timer itself or
from the distributor if necessary.
Reported-by: NRicardo Koller <ricarkol@google.com>
Tested-by: NRicardo Koller <ricarkol@google.com>
Reviewed-by: NRicardo Koller <ricarkol@google.com>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220208123726.3604198-1-maz@kernel.orgSigned-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NYu Liao <liaoyu15@huawei.com>
Reviewed-by: NWei Li <liwei391@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: 186819 https://gitee.com/openeuler/kernel/issues/I58L00

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

The gic_arch_restore_irqs() depends on commit e7e6a881 ("arm64:
irqflags: fix incomplete save & restore"). While it is reverted in commit
2e680920 ("Revert "arm64: irqflags: fix incomplete save & restore""),
we should update the logic here too.

Currently the upper 32 bits of 'flags' is always zero, change to use
'GIC_PRIO_PSR_I_SET' to indicate the interrupt enabling status.

Fixes: abde6b94 ("stop_machine: mask pseudo nmi before running the callback")
Signed-off-by: NWei Li <liwei391@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.102
commit 429ef36c4fc497a9a958768c3ffb75c139abfa1e
bugzilla: https://gitee.com/openeuler/kernel/issues/I567K6

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

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

[ Upstream commit f26573e2 ]

The BL32/TEE reserved-memory region is now inherited from the common
family dtsi (meson-g12-common) so we can drop it from board files.
Signed-off-by: NChristian Hewitt <christianshewitt@gmail.com>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Link: https://lore.kernel.org/r/20220126044954.19069-4-christianshewitt@gmail.comSigned-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NYu Liao <liaoyu15@huawei.com>
Reviewed-by: NWei Li <liwei391@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.102
commit 1415f22ee541a708ded842075015f4407a8743cf
bugzilla: https://gitee.com/openeuler/kernel/issues/I567K6

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

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

[ Upstream commit 08982a1b ]

Add an additional reserved memory region for the BL32 trusted firmware
present in many devices that boot from Amlogic vendor u-boot.
Signed-off-by: NChristian Hewitt <christianshewitt@gmail.com>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Link: https://lore.kernel.org/r/20220126044954.19069-3-christianshewitt@gmail.comSigned-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NYu Liao <liaoyu15@huawei.com>
Reviewed-by: NWei Li <liwei391@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.102
commit 605080f19eb7edde039cec7bee1646b2eefeaea2
bugzilla: https://gitee.com/openeuler/kernel/issues/I567K6

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

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

[ Upstream commit 76577c91 ]

Add an additional reserved memory region for the BL32 trusted firmware
present in many devices that boot from Amlogic vendor u-boot.
Suggested-by: NMateusz Krzak <kszaquitto@gmail.com>
Signed-off-by: NChristian Hewitt <christianshewitt@gmail.com>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Link: https://lore.kernel.org/r/20220126044954.19069-2-christianshewitt@gmail.comSigned-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NYu Liao <liaoyu15@huawei.com>
Reviewed-by: NWei Li <liwei391@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

Fix below build errors:
error: implicit declaration of function ‘reserve_crashkernel_high’
undefined reference to `request_quick_kexec_res'
undefined reference to `reserve_quick_kexec'

1. An empty reserve_crashkernel_high() should be defined when
   CONFIG_KEXEC_CORE is not set.
2. CONFIG_ARM64_PMEM_RESERVE needs to be changed to CONFIG_QUICK_KEXEC.
   This is a mistake.

Fixes: d61f4ca0 ("arm64: quick_kexec: Move to stand-alone file")
Fixes: baac34dd ("arm64: kdump: Use page-level mapping for the high memory of crashkernel")
Signed-off-by: NZhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: NHanjun Guo <guohanjun@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.15-rc1
commit b9a51949
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I56LDF

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

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

vgic_get_irq(intid) is used all over the vgic code in order to get a
reference to a struct irq. It warns whenever intid is not a valid number
(like when it's a reserved IRQ number). The issue is that this warning
can be triggered from userspace (e.g., KVM_IRQ_LINE for intid 1020).

Drop the WARN call from vgic_get_irq.
Signed-off-by: NRicardo Koller <ricarkol@google.com>
Reviewed-by: NOliver Upton <oupton@google.com>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210818213205.598471-1-ricarkol@google.comSigned-off-by: NLin Yujun <linyujun809@huawei.com>
Reviewed-by: NZhang Jianhua <chris.zjh@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

When efi is enabled, the memory block will initialize after early
parameters parse. And, memblock_setclr_flag should be used after
the initialization of the memory block.

However, "arm64: Request resources for reserved memory via memmap"
could use memblock_setclr_flag when the memory block is empty. To
fix this, memblock_setclr_flag should call after the initialization
of the memory block.

Fixes: 374db2be ("arm64: Request resources for reserved memory via memmap")
Signed-off-by: NPeng Liu <liupeng256@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.101
commit ce3ca12c632a6b3db26ad6995cf6cbadc344cbb0
bugzilla: https://gitee.com/openeuler/kernel/issues/I5669Z

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

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

commit 91f6d5f1 upstream.

The port node does not have a unit-address, remove it.
This fixes the warnings:
lcd-controller@30320000: 'port' is a required property
lcd-controller@30320000: 'port@0' does not match any of the regexes:
'pinctrl-[0-9]+'

Fixes: commit d0081bd0 ("arm64: dts: imx8mq: Add NWL MIPI DSI controller")
Signed-off-by: NAlexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: NFabio Estevam <festevam@gmail.com>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NYu Liao <liaoyu15@huawei.com>
Reviewed-by: NWei Li <liwei391@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.101
commit e5a64f548a45be007feee22a85f1cf837bae7c95
bugzilla: https://gitee.com/openeuler/kernel/issues/I5669Z

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

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

[ Upstream commit bc41099f ]

Typo in audio amplifier node, dioo2133 -> dio2133
Signed-off-by: NDongjin Kim <tobetter@gmail.com>
Fixes: ef599f5f ("arm64: dts: meson: convert ODROID-N2 to dtsi")
Fixes: 67d141c1 ("arm64: dts: meson: odroid-n2: add jack audio output support")
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Link: https://lore.kernel.org/r/YfKQJejh0bfGYvof@anyangSigned-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NYu Liao <liaoyu15@huawei.com>
Reviewed-by: NWei Li <liwei391@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I56HL6

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

Arm64 pseudo-NMI feature code brings some additional nops
when CONFIG_ARM64_PSEUDO_NMI is not set, which is not
necessary. So add necessary ifdeffery to avoid it.
Signed-off-by: NHe Ying <heying24@huawei.com>
Reviewed-by: NZhang Jianhua <chris.zjh@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

Reference: https://lore.kernel.org/lkml/20190609164147.971147667@linuxfoundation.org/

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

The digest() hook relies on a crc value from the shash_desc context.
However, this context is not initialized while digest() hook is called,
and an arbitrary value is read causing the algorithm generating wrong
result.

This patch fixes this issue by passing a 0 as the initial crc value in
the digest() hook.
Signed-off-by: NGUO Zihua <guozihua@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I52611
CVE: NA
Signed-off-by: NGuan Jing <guanjing6@huawei.com>
Reviewed-by: NChen Hui <judy.chenhui@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4ZII6

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

Kernel panic happened on 'arm64 big endian' board after calling function
that has been live-patched. It can be reproduced as follows:
  1. Insert 'livepatch-sample.ko' to patch function 'cmdline_proc_show';
  2. Enable patch by execute:
     echo 1 > /sys/kernel/livepatch/livepatch-sample/enabled
  3. Call 'cmdline_proc_show' by execute:
     cat /proc/cmdline
  4. Then we get following panic logs:
     > kernel BUG at arch/arm64/kernel/traps.c:408!
     > Internal error: Oops - BUG: 0 [#1] SMP
     > Modules linked in: dump_mem(OE) livepatch_cmdline1(OEK)
     > [last unloaded: dump_mem]
     > CPU: 3 PID: 1752 Comm: cat Session: 0 Tainted: G           OE K
     > 5.10.0+ #2
     > Hardware name: Hisilicon PhosphorHi1382 (DT)
     > pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--)
     > pc : do_undefinstr+0x23c/0x2b4
     > lr : do_undefinstr+0x5c/0x2b4
     > sp : ffffffc010ac3a80
     > x29: ffffffc010ac3a80 x28: ffffff82eb0a8000
     > x27: 0000000000000000 x26: 0000000000000001
     > x25: 0000000000000000 x24: 0000000000001000
     > x23: 0000000000000000 x22: ffffffd0e0f16000
     > x21: ffffffd0e0ae7000 x20: ffffffc010ac3b00
     > x19: 0000000000021fd6 x18: ffffffd0e04aad94
     > x17: 0000000000000000 x16: 0000000000000000
     > x15: ffffffd0e04b519c x14: 0000000000000000
     > x13: 0000000000000000 x12: 0000000000000000
     > x11: 0000000000000000 x10: 0000000000000000
     > x9 : 0000000000000000 x8 : 0000000000000000
     > x7 : 0000000000000000 x6 : ffffffd0e0f16100
     > x5 : 0000000000000000 x4 : 00000000d5300000
     > x3 : 0000000000000000 x2 : ffffffd0e0f160f0
     > x1 : ffffffd0e0f16103 x0 : 0000000000000005
     > Call trace:
     >  do_undefinstr+0x23c/0x2b4
     >  el1_undef+0x2c/0x44
     >  el1_sync_handler+0xa4/0xb0
     >  el1_sync+0x74/0x100
     >  cmdline_proc_show+0xc/0x44
     >  proc_reg_read_iter+0xb0/0xc4
     >  new_sync_read+0x10c/0x15c
     >  vfs_read+0x144/0x18c
     >  ksys_read+0x78/0xe8
     >  __arm64_sys_read+0x24/0x30

We compare first 6 instructions of 'cmdline_proc_show' before and after
patch (see below). There are 4 instructions modified, so this is case
that offset between old and new function is out of 128M. And we found
that instruction at 'cmdline_proc_show+0xc' seems incorrect (it expects
to be '00021fd6').
  origin:     patched:
  --------    --------
  fd7bbea9    929ff7f0
  21d500f0    f2a91b30
  fd030091    f2d00010
  211040f9    d61f0200 <-- cmdline_proc_show+0xc (expect is '00021fd6')
  f30b00f9    f30b00f9
  f30300aa    f30300aa

It is caused by an incorrect big-to-little endian conversion, and we
correct it.

Fixes: e429c61d livepatch/arm64: Support livepatch 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: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I53WZ9

--------------------------------
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: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I53WZ9

--------------------------------
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: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I53WZ9

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

Currently when unpatch a function, we check whether 'func_stack' has only
one item then delete it:
  > if (list_is_singular(&func_node->func_stack)) {
  > 	list_del_rcu(&func->stack_node);
  > 	......
  > } else {
  > 	list_del_rcu(&func->stack_node);
  > 	next_func = list_first_or_null_rcu(&func_node->func_stack);
  > 	......
  > }

We can optimize it as delete first then check whether 'func_stack' is
empty or not.
Suggested-by: NXu Kuohai <xukuohai@huawei.com>
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: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I53WZ9

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

Structure 'arch_klp_data' contains fields which are used to save codes of
a function before patching. In arm, they are 'old_insns' and 'old_insn'
(depending on CONFIG_ARM_MODULE_PLTS enabled or not):
    struct arch_klp_data {
    #ifdef CONFIG_ARM_MODULE_PLTS
            u32 old_insns[LJMP_INSN_SIZE];
    #else
            u32 old_insn;
    #endif
    };

We can use array 'old_insns' to replace 'old_insn' so that no need to
depend on CONFIG_ARM_MODULE_PLTS.

The similar scenario exists in arm64, so we also do the optimization.
Suggested-by: NXu Kuohai <xukuohai@huawei.com>
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: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I53WZ9

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

Before commit ec7ce700674f ("[Huawei] livepatch: put memory alloc and
free out stop machine"), procedure of restore codes of old function in
'arch_klp_unpatch_func' is like:
  1. copy old codes which saved in func_node into array 'old_insns';
  2. free memory of func_node;
  3. patch text with old codes in array 'old_insns';

But after above commit, operation of freeing memory of func_node in
procedure 2 is done after 'arch_klp_unpatch_func' succeed. And then
operation of copying old codes in procedure 1 seems redundant, so we
can just remove it.
Suggested-by: NXu Kuohai <xukuohai@huawei.com>
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: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I53WZ9

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

Codes related to patching text in 'arch_klp_patch_func' and
'arch_klp_unpatch_func' are duplicate, we can reduce them.

And There is issue in arm/arm64 that 'offset' between pc and new function
address is out of valid range is NOT considered if MODULE_PLTS
is not enabled (CONFIG_ARM_MODULE_PLTS in arm, CONFIG_ARM_MODULE_PLTS
in arm64). We fix it by always checking that 'offset'.

Fixes: 2fa9f353 livepatch/arm: Support livepatch without ftrace
Fixes: e429c61d livepatch/arm64: Support livepatch without ftrace
Suggested-by: NXu Kuohai <xukuohai@huawei.com>
Signed-off-by: NZheng Yejian <zhengyejian1@huawei.com>
Reviewed-by: NKuohai Xu <xukuohai@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.96
commit bf0d4ae5c6c28ac37655ea33926fa3cf1498169f
bugzilla: https://gitee.com/openeuler/kernel/issues/I55NWB

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

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

commit 38e0257e upstream.

The erratum 1418040 workaround enables CNTVCT_EL1 access trapping in EL0
when executing compat threads. The workaround is applied when switching
between tasks, but the need for the workaround could also change at an
exec(), when a non-compat task execs a compat binary or vice versa. Apply
the workaround in arch_setup_new_exec().

This leaves a small window of time between SET_PERSONALITY and
arch_setup_new_exec where preemption could occur and confuse the old
workaround logic that compares TIF_32BIT between prev and next. Instead, we
can just read cntkctl to make sure it's in the state that the next task
needs. I measured cntkctl read time to be about the same as a mov from a
general-purpose register on N1. Update the workaround logic to examine the
current value of cntkctl instead of the previous task's compat state.

Fixes: d49f7d73 ("arm64: Move handling of erratum 1418040 into C code")
Cc: <stable@vger.kernel.org> # 5.9.x
Signed-off-by: ND Scott Phillips <scott@os.amperecomputing.com>
Reviewed-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20211220234114.3926-1-scott@os.amperecomputing.comSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Conflicts:
	arch/arm64/kernel/process.c
Signed-off-by: NYu Liao <liaoyu15@huawei.com>
Reviewed-by: NWei Li <liwei391@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

For the case crashkernel=X@offset and crashkernel=X,high, we've explicitly
used 'crashk_res' to mark the scope of the page-level mapping required, so
NO_BLOCK_MAPPINGS should not be required for other areas. Otherwise,
system performance will be affected. In fact, only the case crashkernel=X
requires page-level mapping for all low memory under 4G because it
attempts high memory after it fails to request low memory first, and we
cannot predict its final location.
Signed-off-by: NZhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

If the crashkernel has both high memory above 4G and low memory under 4G,
kexec always loads the content such as Imge and dtb to the high memory
instead of the low memory. This means that only high memory requires write
protection based on page-level mapping. The allocation of high memory does
not depend on the DMA boundary. So we can reserve the high memory first
even if the crashkernel reservation is deferred.
Signed-off-by: NZhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

If the crashkernel reservation is deferred, such boundaries are not known
when the linear mapping is created. But its upper limit is fixed, cannot
above 4G. Therefore, unless otherwise required, block mapping should be
used for memory above 4G to improve performance.
Signed-off-by: NZhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

To be consistent with the style of other ARCHs such as x86, the kexec
commit b5a34a20984c ("arm64: support more than one crash kernel regions")
requires all crash regions to be named "Crash kernel". Update the name of
crashk_low_res, so that we can directly use the latest kexec tool without
having to maintain a private version.
Signed-off-by: NZhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.108
commit 2c010c61e614f3ae5d26bf0803797075cc649f0b
category: bugfix
bugzilla: 186460 https://gitee.com/src-openeuler/kernel/issues/I53MHA
CVE: CVE-2022-23960

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

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

[ Upstream commit 7f34b43e ]

The newly introduced TRAMP_VALIAS definition causes a build warning
with clang-14:

arch/arm64/include/asm/vectors.h:66:31: error: arithmetic on a null pointer treated as a cast from integer to pointer is a GNU extension [-Werror,-Wnull-pointer-arithmetic]
                return (char *)TRAMP_VALIAS + SZ_2K * slot;

Change the addition to something clang does not complain about.

Fixes: bd09128d ("arm64: Add percpu vectors for EL1")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NJames Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20220316183833.1563139-1-arnd@kernel.orgSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com>
Reviewed-by: NLiao Chang <liaochang1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.107
commit 7a0d13ef67a1084e1a77bf4d2334cc482699f861
category: bugfix
bugzilla: 186460 https://gitee.com/src-openeuler/kernel/issues/I53MHA
CVE: CVE-2022-23960

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

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

KVM's infrastructure for spectre mitigations in the vectors in v5.10 and
earlier is different, it uses templates which are used to build a set of
vectors at runtime.

There are two copy-and-paste errors in the templates: __spectre_bhb_loop_k24
should loop 24 times and __spectre_bhb_loop_k32 32.

Fix these.
Reported-by: NPavel Machek <pavel@denx.de>
Link: https://lore.kernel.org/all/20220310234858.GB16308@amd/Signed-off-by: NJames Morse <james.morse@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com>
Reviewed-by: NLiao Chang <liaochang1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.105
commit b65b87e718c33caa46d5246d8fbeda895aa9cf5b
category: bugfix
bugzilla: 186460 https://gitee.com/src-openeuler/kernel/issues/I53MHA
CVE: CVE-2022-23960

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

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

commit 58c9a506 upstream.

The mitigations for Spectre-BHB are only applied when an exception is
taken from user-space. The mitigation status is reported via the spectre_v2
sysfs vulnerabilities file.

When unprivileged eBPF is enabled the mitigation in the exception vectors
can be avoided by an eBPF program.

When unprivileged eBPF is enabled, print a warning and report vulnerable
via the sysfs vulnerabilities file.
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NJames Morse <james.morse@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com>
Reviewed-by: NLiao Chang <liaochang1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.105
commit 551717cf3b58f11311d10f70eb027d4b275135de
category: bugfix
bugzilla: 186460 https://gitee.com/src-openeuler/kernel/issues/I53MHA
CVE: CVE-2022-23960

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

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

commit 228a26b9 upstream.

Future CPUs may implement a clearbhb instruction that is sufficient
to mitigate SpectreBHB. CPUs that implement this instruction, but
not CSV2.3 must be affected by Spectre-BHB.

Add support to use this instruction as the BHB mitigation on CPUs
that support it. The instruction is in the hint space, so it will
be treated by a NOP as older CPUs.
Reviewed-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
[ modified for stable: Use a KVM vector template instead of alternatives,
  removed bitmap of mitigations ]
Signed-off-by: NJames Morse <james.morse@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com>
Reviewed-by: NLiao Chang <liaochang1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.105
commit 38c26bdb3cc53f219d6ab75ac1a95436f393c60f
category: bugfix
bugzilla: 186460 https://gitee.com/src-openeuler/kernel/issues/I53MHA
CVE: CVE-2022-23960

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

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

commit a5905d6a upstream.

KVM allows the guest to discover whether the ARCH_WORKAROUND SMCCC are
implemented, and to preserve that state during migration through its
firmware register interface.

Add the necessary boiler plate for SMCCC_ARCH_WORKAROUND_3.
Reviewed-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NJames Morse <james.morse@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com>
Reviewed-by: NLiao Chang <liaochang1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.105
commit e192c8baa69ac8a5585d61ac535aa1e5eb795e80
category: bugfix
bugzilla: 186460 https://gitee.com/src-openeuler/kernel/issues/I53MHA
CVE: CVE-2022-23960

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

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

commit 558c303c upstream.

Speculation attacks against some high-performance processors can
make use of branch history to influence future speculation.
When taking an exception from user-space, a sequence of branches
or a firmware call overwrites or invalidates the branch history.

The sequence of branches is added to the vectors, and should appear
before the first indirect branch. For systems using KPTI the sequence
is added to the kpti trampoline where it has a free register as the exit
from the trampoline is via a 'ret'. For systems not using KPTI, the same
register tricks are used to free up a register in the vectors.

For the firmware call, arch-workaround-3 clobbers 4 registers, so
there is no choice but to save them to the EL1 stack. This only happens
for entry from EL0, so if we take an exception due to the stack access,
it will not become re-entrant.

For KVM, the existing branch-predictor-hardening vectors are used.
When a spectre version of these vectors is in use, the firmware call
is sufficient to mitigate against Spectre-BHB. For the non-spectre
versions, the sequence of branches is added to the indirect vector.
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
[ modified for stable, removed bitmap of mitigations,  use kvm template
  infrastructure ]
Signed-off-by: NJames Morse <james.morse@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com>
Reviewed-by: NLiao Chang <liaochang1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.105
commit 192023e6baf7cce7fb76ff3a5c24c55968c774ff
category: bugfix
bugzilla: 186460 https://gitee.com/src-openeuler/kernel/issues/I53MHA
CVE: CVE-2022-23960

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

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

commit 5bdf3437 upstream.

CPUs vulnerable to Spectre-BHB either need to make an SMC-CC firmware
call from the vectors, or run a sequence of branches. This gets added
to the hyp vectors. If there is no support for arch-workaround-1 in
firmware, the indirect vector will be used.

kvm_init_vector_slots() only initialises the two indirect slots if
the platform is vulnerable to Spectre-v3a. pKVM's hyp_map_vectors()
only initialises __hyp_bp_vect_base if the platform is vulnerable to
Spectre-v3a.

As there are about to more users of the indirect vectors, ensure
their entries in hyp_spectre_vector_selector[] are always initialised,
and __hyp_bp_vect_base defaults to the regular VA mapping.

The Spectre-v3a check is moved to a helper
kvm_system_needs_idmapped_vectors(), and merged with the code
that creates the hyp mappings.
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NJames Morse <james.morse@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com>
Reviewed-by: NLiao Chang <liaochang1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.105
commit 13a807a0a080383ceab6c40e53c0228108423e51
category: bugfix
bugzilla: 186460 https://gitee.com/src-openeuler/kernel/issues/I53MHA
CVE: CVE-2022-23960

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

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

commit dee435be upstream.

Speculation attacks against some high-performance processors can
make use of branch history to influence future speculation as part of
a spectre-v2 attack. This is not mitigated by CSV2, meaning CPUs that
previously reported 'Not affected' are now moderately mitigated by CSV2.

Update the value in /sys/devices/system/cpu/vulnerabilities/spectre_v2
to also show the state of the BHB mitigation.
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NJames Morse <james.morse@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com>
Reviewed-by: NLiao Chang <liaochang1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.105
commit 1f63326a5211208e2c5868650e47f13a9072afde
category: bugfix
bugzilla: 186460 https://gitee.com/src-openeuler/kernel/issues/I53MHA
CVE: CVE-2022-23960

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

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

commit bd09128d upstream.

The Spectre-BHB workaround adds a firmware call to the vectors. This
is needed on some CPUs, but not others. To avoid the unaffected CPU in
a big/little pair from making the firmware call, create per cpu vectors.

The per-cpu vectors only apply when returning from EL0.

Systems using KPTI can use the canonical 'full-fat' vectors directly at
EL1, the trampoline exit code will switch to this_cpu_vector on exit to
EL0. Systems not using KPTI should always use this_cpu_vector.

this_cpu_vector will point at a vector in tramp_vecs or
__bp_harden_el1_vectors, depending on whether KPTI is in use.
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NJames Morse <james.morse@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com>
Reviewed-by: NLiao Chang <liaochang1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.105
commit 56cf5326bdf9c20de9a45e4a7a4c0ae16833e561
category: bugfix
bugzilla: 186460 https://gitee.com/src-openeuler/kernel/issues/I53MHA
CVE: CVE-2022-23960

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

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

commit b28a8eeb upstream.

The trampoline code needs to use the address of symbols in the wider
kernel, e.g. vectors. PC-relative addressing wouldn't work as the
trampoline code doesn't run at the address the linker expected.

tramp_ventry uses a literal pool, unless CONFIG_RANDOMIZE_BASE is
set, in which case it uses the data page as a literal pool because
the data page can be unmapped when running in user-space, which is
required for CPUs vulnerable to meltdown.

Pull this logic out as a macro, instead of adding a third copy
of it.
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NJames Morse <james.morse@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com>
Reviewed-by: NLiao Chang <liaochang1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.105
commit 3f21b7e355237aa2f8196ad44c2b7456a739518d
category: bugfix
bugzilla: 186460 https://gitee.com/src-openeuler/kernel/issues/I53MHA
CVE: CVE-2022-23960

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

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

commit ba268923 upstream.

Some CPUs affected by Spectre-BHB need a sequence of branches, or a
firmware call to be run before any indirect branch. This needs to go
in the vectors. No CPU needs both.

While this can be patched in, it would run on all CPUs as there is a
single set of vectors. If only one part of a big/little combination is
affected, the unaffected CPUs have to run the mitigation too.

Create extra vectors that include the sequence. Subsequent patches will
allow affected CPUs to select this set of vectors. Later patches will
modify the loop count to match what the CPU requires.
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NJames Morse <james.morse@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com>
Reviewed-by: NLiao Chang <liaochang1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.105
commit 49379552969acee3237387cc258848437e127d98
category: bugfix
bugzilla: 186460 https://gitee.com/src-openeuler/kernel/issues/I53MHA
CVE: CVE-2022-23960

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

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

commit aff65393 upstream.

kpti is an optional feature, for systems not using kpti a set of
vectors for the spectre-bhb mitigations is needed.

Add another set of vectors, __bp_harden_el1_vectors, that will be
used if a mitigation is needed and kpti is not in use.

The EL1 ventries are repeated verbatim as there is no additional
work needed for entry from EL1.
Reviewed-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NJames Morse <james.morse@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com>
Reviewed-by: NLiao Chang <liaochang1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.105
commit 26211252c1c104732a0fea6c37645f1b670587f5
category: bugfix
bugzilla: 186460 https://gitee.com/src-openeuler/kernel/issues/I53MHA
CVE: CVE-2022-23960

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

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

commit a9c406e6 upstream.

Adding a second set of vectors to .entry.tramp.text will make it
larger than a single 4K page.

Allow the trampoline text to occupy up to three pages by adding two
more fixmap slots. Previous changes to tramp_valias allowed it to reach
beyond a single page.
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NJames Morse <james.morse@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com>
Reviewed-by: NLiao Chang <liaochang1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.105
commit 73ee716a1f6356ca86d16d4ffc97fcfc7961d3ef
category: bugfix
bugzilla: 186460 https://gitee.com/src-openeuler/kernel/issues/I53MHA
CVE: CVE-2022-23960

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

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

commit c47e4d04 upstream.

Spectre-BHB needs to add sequences to the vectors. Having one global
set of vectors is a problem for big/little systems where the sequence
is costly on cpus that are not vulnerable.

Making the vectors per-cpu in the style of KVM's bh_harden_hyp_vecs
requires the vectors to be generated by macros.

Make the kpti re-mapping of the kernel optional, so the macros can be
used without kpti.
Reviewed-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NJames Morse <james.morse@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com>
Reviewed-by: NLiao Chang <liaochang1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.105
commit 8c691e5308c531deede16bef4f2d933d5f859ce7
category: bugfix
bugzilla: 186460 https://gitee.com/src-openeuler/kernel/issues/I53MHA
CVE: CVE-2022-23960

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

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

commit 13d7a083 upstream.

The macros for building the kpti trampoline are all behind
CONFIG_UNMAP_KERNEL_AT_EL0, and in a region that outputs to the
.entry.tramp.text section.

Move the macros out so they can be used to generate other kinds of
trampoline. Only the symbols need to be guarded by
CONFIG_UNMAP_KERNEL_AT_EL0 and appear in the .entry.tramp.text section.
Reviewed-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NJames Morse <james.morse@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com>
Reviewed-by: NLiao Chang <liaochang1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>