Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 09 9月, 2022 4 次提交
  3. 23 8月, 2022 11 次提交
  5. 19 8月, 2022 1 次提交
    • C
      KVM: Rename mmu_notifier_* to mmu_invalidate_* · 20ec3ebd
      由 Chao Peng 提交于 
      The motivation of this renaming is to make these variables and related
helper functions less mmu_notifier bound and can also be used for non
mmu_notifier based page invalidation. mmu_invalidate_* was chosen to
better describe the purpose of 'invalidating' a page that those
variables are used for.

  - mmu_notifier_seq/range_start/range_end are renamed to
    mmu_invalidate_seq/range_start/range_end.

  - mmu_notifier_retry{_hva} helper functions are renamed to
    mmu_invalidate_retry{_hva}.

  - mmu_notifier_count is renamed to mmu_invalidate_in_progress to
    avoid confusion with mn_active_invalidate_count.

  - While here, also update kvm_inc/dec_notifier_count() to
    kvm_mmu_invalidate_begin/end() to match the change for
    mmu_notifier_count.

No functional change intended.
Signed-off-by: NChao Peng <chao.p.peng@linux.intel.com>
Message-Id: <20220816125322.1110439-3-chao.p.peng@linux.intel.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      20ec3ebd
  7. 17 8月, 2022 4 次提交
  9. 10 8月, 2022 2 次提交
    • X
      bpf, arm64: Fix bpf trampoline instruction endianness · aada4766
      由 Xu Kuohai 提交于 
      The sparse tool complains as follows:

arch/arm64/net/bpf_jit_comp.c:1684:16:
	warning: incorrect type in assignment (different base types)
arch/arm64/net/bpf_jit_comp.c:1684:16:
	expected unsigned int [usertype] *branch
arch/arm64/net/bpf_jit_comp.c:1684:16:
	got restricted __le32 [usertype] *
arch/arm64/net/bpf_jit_comp.c:1700:52:
	error: subtraction of different types can't work (different base
	types)
arch/arm64/net/bpf_jit_comp.c:1734:29:
	warning: incorrect type in assignment (different base types)
arch/arm64/net/bpf_jit_comp.c:1734:29:
	expected unsigned int [usertype] *
arch/arm64/net/bpf_jit_comp.c:1734:29:
	got restricted __le32 [usertype] *
arch/arm64/net/bpf_jit_comp.c:1918:52:
	error: subtraction of different types can't work (different base
	types)

This is because the variable branch in function invoke_bpf_prog and the
variable branches in function prepare_trampoline are defined as type
u32 *, which conflicts with ctx->image's type __le32 *, so sparse complains
when assignment or arithmetic operation are performed on these two
variables and ctx->image.

Since arm64 instructions are always little-endian, change the type of
these two variables to __le32 * and call cpu_to_le32() to convert
instruction to little-endian before writing it to memory. This is also
in line with emit() which internally does cpu_to_le32(), too.

Fixes: efc9909f ("bpf, arm64: Add bpf trampoline for arm64")
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NXu Kuohai <xukuohai@huawei.com>
Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
Reviewed-by: NJean-Philippe Brucker <jean-philippe@linaro.org>
Link: https://lore.kernel.org/bpf/20220808040735.1232002-1-xukuohai@huawei.com
      aada4766
    • Y
      KVM: arm64: Fix compile error due to sign extension · ae3b1da9
      由 Yang Yingliang 提交于 
      Use GENMASK() to generate the masks of device type and device id,
fixing compilation errors due to the sign extension when using
older versions of GCC (such as is 7.5):

In function ‘kvm_vm_ioctl_set_device_addr.isra.38’,
    inlined from ‘kvm_arch_vm_ioctl’ at arch/arm64/kvm/arm.c:1454:10:
././include/linux/compiler_types.h:354:38: error: call to ‘__compiletime_assert_599’ \
declared with attribute error: FIELD_GET: mask is not constant
  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)

Fixes: 9f968c92 ("KVM: arm64: vgic-v2: Add helper for legacy dist/cpuif base address setting")
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
[maz: tidy up commit message]
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220810013435.1525363-1-yangyingliang@huawei.com
      ae3b1da9
  11. 09 8月, 2022 1 次提交
  13. 08 8月, 2022 1 次提交
    • A
      bpf, arm64: Allocate program buffer using kvcalloc instead of kcalloc · 19f68ed6
      由 Aijun Sun 提交于 
      It is not necessary to allocate contiguous physical memory for BPF
program buffer using kcalloc. When the BPF program is large more than
memory page size, kcalloc allocates multiple memory pages from buddy
system. If the device can not provide sufficient memory, for example
in low-end android devices [0], memory allocation for BPF program is
likely to fail.

Test cases in lib/test_bpf.c all pass on ARM64 QEMU.

[0]
  AndroidTestSuit: page allocation failure: order:4,
  mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=foreground,mems_allowed=0
  Call trace:
   dump_stack+0xa4/0x114
   warn_alloc+0xf8/0x14c
   __alloc_pages_slowpath+0xac8/0xb14
   __alloc_pages_nodemask+0x194/0x3d0
   kmalloc_order_trace+0x44/0x1e8
   __kmalloc+0x29c/0x66c
   bpf_int_jit_compile+0x17c/0x568
   bpf_prog_select_runtime+0x4c/0x1b0
   bpf_prepare_filter+0x5fc/0x6bc
   bpf_prog_create_from_user+0x118/0x1c0
   seccomp_set_mode_filter+0x1c4/0x7cc
   __do_sys_prctl+0x380/0x1424
   __arm64_sys_prctl+0x20/0x2c
   el0_svc_common+0xc8/0x22c
   el0_svc_handler+0x1c/0x28
   el0_svc+0x8/0x100
Signed-off-by: NAijun Sun <aijun.sun@unisoc.com>
Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20220804025442.22524-1-aijun.sun@unisoc.com
      19f68ed6
  15. 02 8月, 2022 1 次提交
  17. 31 7月, 2022 1 次提交
  19. 30 7月, 2022 2 次提交
    • B
      profile: setup_profiling_timer() is moslty not implemented · 787dbea1
      由 Ben Dooks 提交于 
      The setup_profiling_timer() is mostly un-implemented by many
architectures.  In many places it isn't guarded by CONFIG_PROFILE which is
needed for it to be used.  Make it a weak symbol in kernel/profile.c and
remove the 'return -EINVAL' implementations from the kenrel.

There are a couple of architectures which do return 0 from the
setup_profiling_timer() function but they don't seem to do anything else
with it.  To keep the /proc compatibility for now, leave these for a
future update or removal.

On ARM, this fixes the following sparse warning:
arch/arm/kernel/smp.c:793:5: warning: symbol 'setup_profiling_timer' was not declared. Should it be static?

Link: https://lkml.kernel.org/r/20220721195509.418205-1-ben-linux@fluff.orgSigned-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      787dbea1
    • Z
      memblock,arm64: expand the static memblock memory table · 450d0e74
      由 Zhou Guanghui 提交于 
      In a system(Huawei Ascend ARM64 SoC) using HBM, a multi-bit ECC error
occurs, and the BIOS will mark the corresponding area (for example, 2 MB)
as unusable.  When the system restarts next time, these areas are not
reported or reported as EFI_UNUSABLE_MEMORY.  Both cases lead to an
increase in the number of memblocks, whereas EFI_UNUSABLE_MEMORY leads to
a larger number of memblocks.

For example, if the EFI_UNUSABLE_MEMORY type is reported:
...
memory[0x92]    [0x0000200834a00000-0x0000200835bfffff], 0x0000000001200000 bytes on node 7 flags: 0x0
memory[0x93]    [0x0000200835c00000-0x0000200835dfffff], 0x0000000000200000 bytes on node 7 flags: 0x4
memory[0x94]    [0x0000200835e00000-0x00002008367fffff], 0x0000000000a00000 bytes on node 7 flags: 0x0
memory[0x95]    [0x0000200836800000-0x00002008369fffff], 0x0000000000200000 bytes on node 7 flags: 0x4
memory[0x96]    [0x0000200836a00000-0x0000200837bfffff], 0x0000000001200000 bytes on node 7 flags: 0x0
memory[0x97]    [0x0000200837c00000-0x0000200837dfffff], 0x0000000000200000 bytes on node 7 flags: 0x4
memory[0x98]    [0x0000200837e00000-0x000020087fffffff], 0x0000000048200000 bytes on node 7 flags: 0x0
memory[0x99]    [0x0000200880000000-0x0000200bcfffffff], 0x0000000350000000 bytes on node 6 flags: 0x0
memory[0x9a]    [0x0000200bd0000000-0x0000200bd01fffff], 0x0000000000200000 bytes on node 6 flags: 0x4
memory[0x9b]    [0x0000200bd0200000-0x0000200bd07fffff], 0x0000000000600000 bytes on node 6 flags: 0x0
memory[0x9c]    [0x0000200bd0800000-0x0000200bd09fffff], 0x0000000000200000 bytes on node 6 flags: 0x4
memory[0x9d]    [0x0000200bd0a00000-0x0000200fcfffffff], 0x00000003ff600000 bytes on node 6 flags: 0x0
memory[0x9e]    [0x0000200fd0000000-0x0000200fd01fffff], 0x0000000000200000 bytes on node 6 flags: 0x4
memory[0x9f]    [0x0000200fd0200000-0x0000200fffffffff], 0x000000002fe00000 bytes on node 6 flags: 0x0
...

The EFI memory map is parsed to construct the memblock arrays before the
memblock arrays can be resized.  As the result, memory regions beyond
INIT_MEMBLOCK_REGIONS are lost.

Add a new macro INIT_MEMBLOCK_MEMORY_REGIONS to replace
INIT_MEMBLOCK_REGTIONS to define the size of the static memblock.memory
array.

Allow overriding memblock.memory array size with architecture defined
INIT_MEMBLOCK_MEMORY_REGIONS and make arm64 to set
INIT_MEMBLOCK_MEMORY_REGIONS to 1024 when CONFIG_EFI is enabled.

Link: https://lkml.kernel.org/r/20220615102742.96450-1-zhouguanghui1@huawei.comSigned-off-by: NZhou Guanghui <zhouguanghui1@huawei.com>
Acked-by: NMike Rapoport <rppt@linux.ibm.com>
Tested-by: NDarren Hart <darren@os.amperecomputing.com>
Acked-by: Will Deacon <will@kernel.org>		[arm64]
Reviewed-by: NAnshuman Khandual <anshuman.khandual@arm.com>
Cc: Xu Qiang <xuqiang36@huawei.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      450d0e74
  21. 29 7月, 2022 1 次提交
    • G
      crypto: arm64/poly1305 - fix a read out-of-bound · 7ae19d42
      由 GUO Zihua 提交于 
      A kasan error was reported during fuzzing:

BUG: KASAN: slab-out-of-bounds in neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon]
Read of size 4 at addr ffff0010e293f010 by task syz-executor.5/1646715
CPU: 4 PID: 1646715 Comm: syz-executor.5 Kdump: loaded Not tainted 5.10.0.aarch64 #1
Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.59 01/31/2019
Call trace:
 dump_backtrace+0x0/0x394
 show_stack+0x34/0x4c arch/arm64/kernel/stacktrace.c:196
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x158/0x1e4 lib/dump_stack.c:118
 print_address_description.constprop.0+0x68/0x204 mm/kasan/report.c:387
 __kasan_report+0xe0/0x140 mm/kasan/report.c:547
 kasan_report+0x44/0xe0 mm/kasan/report.c:564
 check_memory_region_inline mm/kasan/generic.c:187 [inline]
 __asan_load4+0x94/0xd0 mm/kasan/generic.c:252
 neon_poly1305_blocks.constprop.0+0x1b4/0x250 [poly1305_neon]
 neon_poly1305_do_update+0x6c/0x15c [poly1305_neon]
 neon_poly1305_update+0x9c/0x1c4 [poly1305_neon]
 crypto_shash_update crypto/shash.c:131 [inline]
 shash_finup_unaligned+0x84/0x15c crypto/shash.c:179
 crypto_shash_finup+0x8c/0x140 crypto/shash.c:193
 shash_digest_unaligned+0xb8/0xe4 crypto/shash.c:201
 crypto_shash_digest+0xa4/0xfc crypto/shash.c:217
 crypto_shash_tfm_digest+0xb4/0x150 crypto/shash.c:229
 essiv_skcipher_setkey+0x164/0x200 [essiv]
 crypto_skcipher_setkey+0xb0/0x160 crypto/skcipher.c:612
 skcipher_setkey+0x3c/0x50 crypto/algif_skcipher.c:305
 alg_setkey+0x114/0x2a0 crypto/af_alg.c:220
 alg_setsockopt+0x19c/0x210 crypto/af_alg.c:253
 __sys_setsockopt+0x190/0x2e0 net/socket.c:2123
 __do_sys_setsockopt net/socket.c:2134 [inline]
 __se_sys_setsockopt net/socket.c:2131 [inline]
 __arm64_sys_setsockopt+0x78/0x94 net/socket.c:2131
 __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]
 invoke_syscall+0x64/0x100 arch/arm64/kernel/syscall.c:48
 el0_svc_common.constprop.0+0x220/0x230 arch/arm64/kernel/syscall.c:155
 do_el0_svc+0xb4/0xd4 arch/arm64/kernel/syscall.c:217
 el0_svc+0x24/0x3c arch/arm64/kernel/entry-common.c:353
 el0_sync_handler+0x160/0x164 arch/arm64/kernel/entry-common.c:369
 el0_sync+0x160/0x180 arch/arm64/kernel/entry.S:683

This error can be reproduced by the following code compiled as ko on a
system with kasan enabled:

#include <linux/module.h>
#include <linux/crypto.h>
#include <crypto/hash.h>
#include <crypto/poly1305.h>

char test_data[] = "\x00\x01\x02\x03\x04\x05\x06\x07"
                   "\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f"
                   "\x10\x11\x12\x13\x14\x15\x16\x17"
                   "\x18\x19\x1a\x1b\x1c\x1d\x1e";

int init(void)
{
        struct crypto_shash *tfm = NULL;
        char *data = NULL, *out = NULL;

        tfm = crypto_alloc_shash("poly1305", 0, 0);
        data = kmalloc(POLY1305_KEY_SIZE - 1, GFP_KERNEL);
        out = kmalloc(POLY1305_DIGEST_SIZE, GFP_KERNEL);
        memcpy(data, test_data, POLY1305_KEY_SIZE - 1);
        crypto_shash_tfm_digest(tfm, data, POLY1305_KEY_SIZE - 1, out);

        kfree(data);
        kfree(out);
        return 0;
}

void deinit(void)
{
}

module_init(init)
module_exit(deinit)
MODULE_LICENSE("GPL");

The root cause of the bug sits in neon_poly1305_blocks. The logic
neon_poly1305_blocks() performed is that if it was called with both s[]
and r[] uninitialized, it will first try to initialize them with the
data from the first "block" that it believed to be 32 bytes in length.
First 16 bytes are used as the key and the next 16 bytes for s[]. This
would lead to the aforementioned read out-of-bound. However, after
calling poly1305_init_arch(), only 16 bytes were deducted from the input
and s[] is initialized yet again with the following 16 bytes. The second
initialization of s[] is certainly redundent which indicates that the
first initialization should be for r[] only.

This patch fixes the issue by calling poly1305_init_arm64() instead of
poly1305_init_arch(). This is also the implementation for the same
algorithm on arm platform.

Fixes: f569ca16 ("crypto: arm64/poly1305 - incorporate OpenSSL/CRYPTOGAMS NEON implementation")
Cc: stable@vger.kernel.org
Signed-off-by: NGUO Zihua <guozihua@huawei.com>
Reviewed-by: NEric Biggers <ebiggers@google.com>
Acked-by: NWill Deacon <will@kernel.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      7ae19d42
  23. 28 7月, 2022 6 次提交
  25. 27 7月, 2022 1 次提交
  27. 26 7月, 2022 4 次提交