[PATCH 0/5 v11] KASan for Arm

[PATCH 0/5 v11] KASan for Arm

[Linus Walleij]

This is the v11 version of the KASan patches for ARM.

The main changes from the v10 version is:

- LPAE now compiles and works again, at least Versatile Express
  Cortex A15 TC1 in QEMU (which is the LPAE system I have
  access to).

- Rewrite some of the page directory initialization after
  helpful feedback from Mike Rapoport and Russell King.

Also minor improvements to commit messages and comments
in the code so it is clear (for most cases I hope) why
some ifdefs etc are there.

All tested platforms from ARMv4 thru ARMv7 work fine. I
have not been able to re-test with the Qualcomm DragonBoard
APQ8060 yet, but I suspect the problem there is that the
DT parser code reaches out into non-kernel memory and
needs some de-instrumentation, possibly combined with the
memory holding the device tree getting corrupted or reused
before we have a chance to parse it.

Abbott Liu (1):
  ARM: Define the virtual space of KASan's shadow region

Andrey Ryabinin (3):
  ARM: Disable KASan instrumentation for some code
  ARM: Replace string mem* functions for KASan
  ARM: Enable KASan for ARM

Linus Walleij (1):
  ARM: Initialize the mapping of KASan shadow memory

 Documentation/arm/memory.rst                  |   5 +
 Documentation/dev-tools/kasan.rst             |   4 +-
 .../features/debug/KASAN/arch-support.txt     |   2 +-
 arch/arm/Kconfig                              |  10 +
 arch/arm/boot/compressed/Makefile             |   1 +
 arch/arm/boot/compressed/string.c             |  19 ++
 arch/arm/include/asm/kasan.h                  |  32 ++
 arch/arm/include/asm/kasan_def.h              |  81 +++++
 arch/arm/include/asm/memory.h                 |   5 +
 arch/arm/include/asm/pgalloc.h                |   8 +-
 arch/arm/include/asm/string.h                 |  21 ++
 arch/arm/include/asm/thread_info.h            |   8 +
 arch/arm/include/asm/uaccess-asm.h            |   2 +-
 arch/arm/kernel/entry-armv.S                  |   3 +-
 arch/arm/kernel/entry-common.S                |   9 +-
 arch/arm/kernel/head-common.S                 |   7 +-
 arch/arm/kernel/setup.c                       |   2 +
 arch/arm/kernel/unwind.c                      |   6 +-
 arch/arm/lib/memcpy.S                         |   3 +
 arch/arm/lib/memmove.S                        |   5 +-
 arch/arm/lib/memset.S                         |   3 +
 arch/arm/mm/Makefile                          |   5 +
 arch/arm/mm/kasan_init.c                      | 288 ++++++++++++++++++
 arch/arm/mm/mmu.c                             |  18 ++
 arch/arm/mm/pgd.c                             |  16 +-
 arch/arm/vdso/Makefile                        |   2 +
 26 files changed, 551 insertions(+), 14 deletions(-)
 create mode 100644 arch/arm/include/asm/kasan.h
 create mode 100644 arch/arm/include/asm/kasan_def.h
 create mode 100644 arch/arm/mm/kasan_init.c

-- 
2.25.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/5 v11] ARM: Disable KASan instrumentation for some code

[Linus Walleij]

From: Andrey Ryabinin <aryabinin@virtuozzo.com>

Disable instrumentation for arch/arm/boot/compressed/*
since that code is executed before the kernel has even
set up its mappings and definately out of scope for
KASan.

Disable instrumentation of arch/arm/vdso/* because that code
is not linked with the kernel image, so the KASan management
code would fail to link.

Disable instrumentation of arch/arm/mm/physaddr.c. See commit
ec6d06efb0ba ("arm64: Add support for CONFIG_DEBUG_VIRTUAL")
for more details.

Disable kasan check in the function unwind_pop_register because
it does not matter that kasan checks failed when unwind_pop_register()
reads the stack memory of a task.

Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: kasan-dev@googlegroups.com
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G
Reported-by: Florian Fainelli <f.fainelli@gmail.com>
Reported-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v10->v11:
- Resend with the other changes.
ChangeLog v9->v10:
- Rebase on v5.8-rc1
ChangeLog v8->v9:
- Collect Ard's tags.
ChangeLog v7->v8:
- Do not sanitize arch/arm/mm/mmu.c.
  Apart from being intuitively correct, it turns out that KASan
  will insert a __asan_load4() into the set_pte_at() function
  in mmu.c and this is something that KASan calls in the early
  initialization, to set up the shadow memory. Naturally,
  __asan_load4() cannot be called before the shadow memory is
  set up so we need to exclude mmu.c from sanitization.
ChangeLog v6->v7:
- Removed the KVM instrumentaton disablement since KVM
  on ARM32 is gone.
---
 arch/arm/boot/compressed/Makefile | 1 +
 arch/arm/kernel/unwind.c          | 6 +++++-
 arch/arm/mm/Makefile              | 2 ++
 arch/arm/vdso/Makefile            | 2 ++
 4 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 00602a6fba04..bb8d193d13de 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -24,6 +24,7 @@ OBJS		+= hyp-stub.o
 endif
 
 GCOV_PROFILE		:= n
+KASAN_SANITIZE		:= n
 
 # Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
 KCOV_INSTRUMENT		:= n
diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
index d2bd0df2318d..f35eb584a18a 100644
--- a/arch/arm/kernel/unwind.c
+++ b/arch/arm/kernel/unwind.c
@@ -236,7 +236,11 @@ static int unwind_pop_register(struct unwind_ctrl_block *ctrl,
 		if (*vsp >= (unsigned long *)ctrl->sp_high)
 			return -URC_FAILURE;
 
-	ctrl->vrs[reg] = *(*vsp)++;
+	/* Use READ_ONCE_NOCHECK here to avoid this memory access
+	 * from being tracked by KASAN.
+	 */
+	ctrl->vrs[reg] = READ_ONCE_NOCHECK(*(*vsp));
+	(*vsp)++;
 	return URC_OK;
 }
 
diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index 7cb1699fbfc4..99699c32d8a5 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -7,6 +7,7 @@ obj-y				:= extable.o fault.o init.o iomap.o
 obj-y				+= dma-mapping$(MMUEXT).o
 obj-$(CONFIG_MMU)		+= fault-armv.o flush.o idmap.o ioremap.o \
 				   mmap.o pgd.o mmu.o pageattr.o
+KASAN_SANITIZE_mmu.o		:= n
 
 ifneq ($(CONFIG_MMU),y)
 obj-y				+= nommu.o
@@ -16,6 +17,7 @@ endif
 obj-$(CONFIG_ARM_PTDUMP_CORE)	+= dump.o
 obj-$(CONFIG_ARM_PTDUMP_DEBUGFS)	+= ptdump_debugfs.o
 obj-$(CONFIG_MODULES)		+= proc-syms.o
+KASAN_SANITIZE_physaddr.o	:= n
 obj-$(CONFIG_DEBUG_VIRTUAL)	+= physaddr.o
 
 obj-$(CONFIG_ALIGNMENT_TRAP)	+= alignment.o
diff --git a/arch/arm/vdso/Makefile b/arch/arm/vdso/Makefile
index d3c9f03e7e79..71d18d59bd35 100644
--- a/arch/arm/vdso/Makefile
+++ b/arch/arm/vdso/Makefile
@@ -42,6 +42,8 @@ GCOV_PROFILE := n
 # Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
 KCOV_INSTRUMENT := n
 
+KASAN_SANITIZE := n
+
 # Force dependency
 $(obj)/vdso.o : $(obj)/vdso.so
 
-- 
2.25.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 2/5 v11] ARM: Replace string mem* functions for KASan

[Linus Walleij]

From: Andrey Ryabinin <aryabinin@virtuozzo.com>

Functions like memset()/memmove()/memcpy() do a lot of memory
accesses.

If a bad pointer is passed to one of these functions it is important
to catch this. Compiler instrumentation cannot do this since these
functions are written in assembly.

KASan replaces these memory functions with instrumented variants.

The original functions are declared as weak symbols so that
the strong definitions in mm/kasan/kasan.c can replace them.

The original functions have aliases with a '__' prefix in their
name, so we can call the non-instrumented variant if needed.

We must use __memcpy()/__memset() in place of memcpy()/memset()
when we copy .data to RAM and when we clear .bss, because
kasan_early_init cannot be called before the initialization of
.data and .bss.

For the kernel compression and EFI libstub's custom string
libraries we need a special quirk: even if these are built
without KASan enabled, they rely on the global headers for their
custom string libraries, which means that e.g. memcpy()
will be defined to __memcpy() and we get link failures.
Since these implementations are written i C rather than
assembly we use e.g. __alias(memcpy) to redirected any
users back to the local implementation.

Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: kasan-dev@googlegroups.com
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G
Reported-by: Russell King - ARM Linux <linux@armlinux.org.uk>
Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v10->v11:
- Resend with the other changes.
ChangeLog v9->v10:
- Rebase on v5.8-rc1
ChangeLog v8->v9:
- Collect Ard's tags.
ChangeLog v7->v8:
- Use the less invasive version of handling the global redefines
  of the string functions in the decompressor: __alias() the
  functions locally in the library.
- Put in some more comments so readers of the code knows what
  is going on.
ChangeLog v6->v7:
- Move the hacks around __SANITIZE_ADDRESS__ into this file
- Edit the commit message
- Rebase on the other v2 patches
---
 arch/arm/boot/compressed/string.c | 19 +++++++++++++++++++
 arch/arm/include/asm/string.h     | 21 +++++++++++++++++++++
 arch/arm/kernel/head-common.S     |  4 ++--
 arch/arm/lib/memcpy.S             |  3 +++
 arch/arm/lib/memmove.S            |  5 ++++-
 arch/arm/lib/memset.S             |  3 +++
 6 files changed, 52 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/compressed/string.c b/arch/arm/boot/compressed/string.c
index ade5079bebbf..8c0fa276d994 100644
--- a/arch/arm/boot/compressed/string.c
+++ b/arch/arm/boot/compressed/string.c
@@ -7,6 +7,25 @@
 
 #include <linux/string.h>
 
+/*
+ * The decompressor is built without KASan but uses the same redirects as the
+ * rest of the kernel when CONFIG_KASAN is enabled, defining e.g. memcpy()
+ * to __memcpy() but since we are not linking with the main kernel string
+ * library in the decompressor, that will lead to link failures.
+ *
+ * Undefine KASan's versions, define the wrapped functions and alias them to
+ * the right names so that when e.g. __memcpy() appear in the code, it will
+ * still be linked to this local version of memcpy().
+ */
+#ifdef CONFIG_KASAN
+#undef memcpy
+#undef memmove
+#undef memset
+void *__memcpy(void *__dest, __const void *__src, size_t __n) __alias(memcpy);
+void *__memmove(void *__dest, __const void *__src, size_t count) __alias(memmove);
+void *__memset(void *s, int c, size_t count) __alias(memset);
+#endif
+
 void *memcpy(void *__dest, __const void *__src, size_t __n)
 {
 	int i = 0;
diff --git a/arch/arm/include/asm/string.h b/arch/arm/include/asm/string.h
index 111a1d8a41dd..947f93037d87 100644
--- a/arch/arm/include/asm/string.h
+++ b/arch/arm/include/asm/string.h
@@ -5,6 +5,9 @@
 /*
  * We don't do inline string functions, since the
  * optimised inline asm versions are not small.
+ *
+ * The __underscore versions of some functions are for KASan to be able
+ * to replace them with instrumented versions.
  */
 
 #define __HAVE_ARCH_STRRCHR
@@ -15,15 +18,18 @@ extern char * strchr(const char * s, int c);
 
 #define __HAVE_ARCH_MEMCPY
 extern void * memcpy(void *, const void *, __kernel_size_t);
+extern void *__memcpy(void *dest, const void *src, __kernel_size_t n);
 
 #define __HAVE_ARCH_MEMMOVE
 extern void * memmove(void *, const void *, __kernel_size_t);
+extern void *__memmove(void *dest, const void *src, __kernel_size_t n);
 
 #define __HAVE_ARCH_MEMCHR
 extern void * memchr(const void *, int, __kernel_size_t);
 
 #define __HAVE_ARCH_MEMSET
 extern void * memset(void *, int, __kernel_size_t);
+extern void *__memset(void *s, int c, __kernel_size_t n);
 
 #define __HAVE_ARCH_MEMSET32
 extern void *__memset32(uint32_t *, uint32_t v, __kernel_size_t);
@@ -39,4 +45,19 @@ static inline void *memset64(uint64_t *p, uint64_t v, __kernel_size_t n)
 	return __memset64(p, v, n * 8, v >> 32);
 }
 
+/*
+ * For files that are not instrumented (e.g. mm/slub.c) we
+ * must use non-instrumented versions of the mem*
+ * functions named __memcpy() etc. All such kernel code has
+ * been tagged with KASAN_SANITIZE_file.o = n, which means
+ * that the address sanitization argument isn't passed to the
+ * compiler, and __SANITIZE_ADDRESS__ is not set. As a result
+ * these defines kick in.
+ */
+#if defined(CONFIG_KASAN) && !defined(__SANITIZE_ADDRESS__)
+#define memcpy(dst, src, len) __memcpy(dst, src, len)
+#define memmove(dst, src, len) __memmove(dst, src, len)
+#define memset(s, c, n) __memset(s, c, n)
+#endif
+
 #endif
diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
index 4a3982812a40..6840c7c60a85 100644
--- a/arch/arm/kernel/head-common.S
+++ b/arch/arm/kernel/head-common.S
@@ -95,7 +95,7 @@ __mmap_switched:
  THUMB(	ldmia	r4!, {r0, r1, r2, r3} )
  THUMB(	mov	sp, r3 )
 	sub	r2, r2, r1
-	bl	memcpy				@ copy .data to RAM
+	bl	__memcpy			@ copy .data to RAM
 #endif
 
    ARM(	ldmia	r4!, {r0, r1, sp} )
@@ -103,7 +103,7 @@ __mmap_switched:
  THUMB(	mov	sp, r3 )
 	sub	r2, r1, r0
 	mov	r1, #0
-	bl	memset				@ clear .bss
+	bl	__memset			@ clear .bss
 
 	ldmia	r4, {r0, r1, r2, r3}
 	str	r9, [r0]			@ Save processor ID
diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S
index 09a333153dc6..ad4625d16e11 100644
--- a/arch/arm/lib/memcpy.S
+++ b/arch/arm/lib/memcpy.S
@@ -58,6 +58,8 @@
 
 /* Prototype: void *memcpy(void *dest, const void *src, size_t n); */
 
+.weak memcpy
+ENTRY(__memcpy)
 ENTRY(mmiocpy)
 ENTRY(memcpy)
 
@@ -65,3 +67,4 @@ ENTRY(memcpy)
 
 ENDPROC(memcpy)
 ENDPROC(mmiocpy)
+ENDPROC(__memcpy)
diff --git a/arch/arm/lib/memmove.S b/arch/arm/lib/memmove.S
index b50e5770fb44..fd123ea5a5a4 100644
--- a/arch/arm/lib/memmove.S
+++ b/arch/arm/lib/memmove.S
@@ -24,12 +24,14 @@
  * occurring in the opposite direction.
  */
 
+.weak memmove
+ENTRY(__memmove)
 ENTRY(memmove)
 	UNWIND(	.fnstart			)
 
 		subs	ip, r0, r1
 		cmphi	r2, ip
-		bls	memcpy
+		bls	__memcpy
 
 		stmfd	sp!, {r0, r4, lr}
 	UNWIND(	.fnend				)
@@ -222,3 +224,4 @@ ENTRY(memmove)
 18:		backward_copy_shift	push=24	pull=8
 
 ENDPROC(memmove)
+ENDPROC(__memmove)
diff --git a/arch/arm/lib/memset.S b/arch/arm/lib/memset.S
index 6ca4535c47fb..0e7ff0423f50 100644
--- a/arch/arm/lib/memset.S
+++ b/arch/arm/lib/memset.S
@@ -13,6 +13,8 @@
 	.text
 	.align	5
 
+.weak memset
+ENTRY(__memset)
 ENTRY(mmioset)
 ENTRY(memset)
 UNWIND( .fnstart         )
@@ -132,6 +134,7 @@ UNWIND( .fnstart            )
 UNWIND( .fnend   )
 ENDPROC(memset)
 ENDPROC(mmioset)
+ENDPROC(__memset)
 
 ENTRY(__memset32)
 UNWIND( .fnstart         )
-- 
2.25.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 3/5 v11] ARM: Define the virtual space of KASan's shadow region

[Linus Walleij]

From: Abbott Liu <liuwenliang@huawei.com>

Define KASAN_SHADOW_OFFSET,KASAN_SHADOW_START and KASAN_SHADOW_END for
the Arm kernel address sanitizer. We are "stealing" lowmem (the 4GB
addressable by a 32bit architecture) out of the virtual address
space to use as shadow memory for KASan as follows:

 +----+ 0xffffffff
 |    |\
 |    | |-> Static kernel image (vmlinux) BSS and page table
 |    |/
 +----+ PAGE_OFFSET
 |    |\
 |    | |->  Loadable kernel modules virtual address space area
 |    |/
 +----+ MODULES_VADDR = KASAN_SHADOW_END
 |    |\
 |    | |-> The shadow area of kernel virtual address.
 |    |/
 +----+->  TASK_SIZE (start of kernel space) = KASAN_SHADOW_START the
 |    |\   shadow address of MODULES_VADDR
 |    | |
 |    | |
 |    | |-> The user space area in lowmem. The kernel address
 |    | |   sanitizer do not use this space, nor does it map it.
 |    | |
 |    | |
 |    | |
 |    | |
 |    |/
 ------ 0

0 .. TASK_SIZE is the memory that can be used by shared
userspace/kernelspace. It us used for userspace processes and for
passing parameters and memory buffers in system calls etc. We do not
need to shadow this area.

KASAN_SHADOW_START:
 This value begins with the MODULE_VADDR's shadow address. It is the
 start of kernel virtual space. Since we have modules to load, we need
 to cover also that area with shadow memory so we can find memory
 bugs in modules.

KASAN_SHADOW_END
 This value is the 0x100000000's shadow address: the mapping that would
 be after the end of the kernel memory at 0xffffffff. It is the end of
 kernel address sanitizer shadow area. It is also the start of the
 module area.

KASAN_SHADOW_OFFSET:
 This value is used to map an address to the corresponding shadow
 address by the following formula:

   shadow_addr = (address >> 3) + KASAN_SHADOW_OFFSET;

 As you would expect, >> 3 is equal to dividing by 8, meaning each
 byte in the shadow memory covers 8 bytes of kernel memory, so one
 bit shadow memory per byte of kernel memory is used.

 The KASAN_SHADOW_OFFSET is provided in a Kconfig option depending
 on the VMSPLIT layout of the system: the kernel and userspace can
 split up lowmem in different ways according to needs, so we calculate
 the shadow offset depending on this.

When kasan is enabled, the definition of TASK_SIZE is not an 8-bit
rotated constant, so we need to modify the TASK_SIZE access code in the
*.s file.

The kernel and modules may use different amounts of memory,
according to the VMSPLIT configuration, which in turn
determines the PAGE_OFFSET.

We use the following KASAN_SHADOW_OFFSETs depending on how the
virtual memory is split up:

- 0x1f000000 if we have 1G userspace / 3G kernelspace split:
  - The kernel address space is 3G (0xc0000000)
  - PAGE_OFFSET is then set to 0x40000000 so the kernel static
    image (vmlinux) uses addresses 0x40000000 .. 0xffffffff
  - On top of that we have the MODULES_VADDR which under
    the worst case (using ARM instructions) is
    PAGE_OFFSET - 16M (0x01000000) = 0x3f000000
    so the modules use addresses 0x3f000000 .. 0x3fffffff
  - So the addresses 0x3f000000 .. 0xffffffff need to be
    covered with shadow memory. That is 0xc1000000 bytes
    of memory.
  - 1/8 of that is needed for its shadow memory, so
    0x18200000 bytes of shadow memory is needed. We
    "steal" that from the remaining lowmem.
  - The KASAN_SHADOW_START becomes 0x26e00000, to
    KASAN_SHADOW_END at 0x3effffff.
  - Now we can calculate the KASAN_SHADOW_OFFSET for any
    kernel address as 0x3f000000 needs to map to the first
    byte of shadow memory and 0xffffffff needs to map to
    the last byte of shadow memory. Since:
    SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET
    0x26e00000 = (0x3f000000 >> 3) + KASAN_SHADOW_OFFSET
    KASAN_SHADOW_OFFSET = 0x26e00000 - (0x3f000000 >> 3)
    KASAN_SHADOW_OFFSET = 0x26e00000 - 0x07e00000
    KASAN_SHADOW_OFFSET = 0x1f000000

- 0x5f000000 if we have 2G userspace / 2G kernelspace split:
  - The kernel space is 2G (0x80000000)
  - PAGE_OFFSET is set to 0x80000000 so the kernel static
    image uses 0x80000000 .. 0xffffffff.
  - On top of that we have the MODULES_VADDR which under
    the worst case (using ARM instructions) is
    PAGE_OFFSET - 16M (0x01000000) = 0x7f000000
    so the modules use addresses 0x7f000000 .. 0x7fffffff
  - So the addresses 0x7f000000 .. 0xffffffff need to be
    covered with shadow memory. That is 0x81000000 bytes
    of memory.
  - 1/8 of that is needed for its shadow memory, so
    0x10200000 bytes of shadow memory is needed. We
    "steal" that from the remaining lowmem.
  - The KASAN_SHADOW_START becomes 0x6ee00000, to
    KASAN_SHADOW_END at 0x7effffff.
  - Now we can calculate the KASAN_SHADOW_OFFSET for any
    kernel address as 0x7f000000 needs to map to the first
    byte of shadow memory and 0xffffffff needs to map to
    the last byte of shadow memory. Since:
    SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET
    0x6ee00000 = (0x7f000000 >> 3) + KASAN_SHADOW_OFFSET
    KASAN_SHADOW_OFFSET = 0x6ee00000 - (0x7f000000 >> 3)
    KASAN_SHADOW_OFFSET = 0x6ee00000 - 0x0fe00000
    KASAN_SHADOW_OFFSET = 0x5f000000

- 0x9f000000 if we have 3G userspace / 1G kernelspace split,
  and this is the default split for ARM:
  - The kernel address space is 1GB (0x40000000)
  - PAGE_OFFSET is set to 0xc0000000 so the kernel static
    image uses 0xc0000000 .. 0xffffffff.
  - On top of that we have the MODULES_VADDR which under
    the worst case (using ARM instructions) is
    PAGE_OFFSET - 16M (0x01000000) = 0xbf000000
    so the modules use addresses 0xbf000000 .. 0xbfffffff
  - So the addresses 0xbf000000 .. 0xffffffff need to be
    covered with shadow memory. That is 0x41000000 bytes
    of memory.
  - 1/8 of that is needed for its shadow memory, so
    0x08200000 bytes of shadow memory is needed. We
    "steal" that from the remaining lowmem.
  - The KASAN_SHADOW_START becomes 0xb6e00000, to
    KASAN_SHADOW_END at 0xbfffffff.
  - Now we can calculate the KASAN_SHADOW_OFFSET for any
    kernel address as 0xbf000000 needs to map to the first
    byte of shadow memory and 0xffffffff needs to map to
    the last byte of shadow memory. Since:
    SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET
    0xb6e00000 = (0xbf000000 >> 3) + KASAN_SHADOW_OFFSET
    KASAN_SHADOW_OFFSET = 0xb6e00000 - (0xbf000000 >> 3)
    KASAN_SHADOW_OFFSET = 0xb6e00000 - 0x17e00000
    KASAN_SHADOW_OFFSET = 0x9f000000

- 0x8f000000 if we have 3G userspace / 1G kernelspace with
  full 1 GB low memory (VMSPLIT_3G_OPT):
  - The kernel address space is 1GB (0x40000000)
  - PAGE_OFFSET is set to 0xb0000000 so the kernel static
    image uses 0xb0000000 .. 0xffffffff.
  - On top of that we have the MODULES_VADDR which under
    the worst case (using ARM instructions) is
    PAGE_OFFSET - 16M (0x01000000) = 0xaf000000
    so the modules use addresses 0xaf000000 .. 0xaffffff
  - So the addresses 0xaf000000 .. 0xffffffff need to be
    covered with shadow memory. That is 0x51000000 bytes
    of memory.
  - 1/8 of that is needed for its shadow memory, so
    0x0a200000 bytes of shadow memory is needed. We
    "steal" that from the remaining lowmem.
  - The KASAN_SHADOW_START becomes 0xa4e00000, to
    KASAN_SHADOW_END at 0xaeffffff.
  - Now we can calculate the KASAN_SHADOW_OFFSET for any
    kernel address as 0xaf000000 needs to map to the first
    byte of shadow memory and 0xffffffff needs to map to
    the last byte of shadow memory. Since:
    SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET
    0xa4e00000 = (0xaf000000 >> 3) + KASAN_SHADOW_OFFSET
    KASAN_SHADOW_OFFSET = 0xa4e00000 - (0xaf000000 >> 3)
    KASAN_SHADOW_OFFSET = 0xa4e00000 - 0x15e00000
    KASAN_SHADOW_OFFSET = 0x8f000000

- The default value of 0xffffffff for KASAN_SHADOW_OFFSET
  is an error value. We should always match one of the
  above shadow offsets.

When we do this, TASK_SIZE will sometimes get a bit odd values
that will not fit into immediate mov assembly instructions.
To account for this, we need to rewrite some assembly using
TASK_SIZE like this:

-       mov     r1, #TASK_SIZE
+       ldr     r1, =TASK_SIZE

or

-       cmp     r4, #TASK_SIZE
+       ldr     r0, =TASK_SIZE
+       cmp     r4, r0

this is done to avoid the immediate #TASK_SIZE that need to
fit into a limited number of bits.

Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: kasan-dev@googlegroups.com
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G
Reported-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v10->v11:
- Resend with the other changes.
ChangeLog v9->v10:
- Rebase on v5.8-rc1
ChangeLog v8->v9:
- Collect Ard's tags.
ChangeLog v7->v8:
- Rewrote the PMD clearing code to take into account that
  KASan may not always be adjacent to MODULES_VADDR: if we
  compile for thumb, then there will be an 8 MB hole between
  the shadow memory and MODULES_VADDR. Make this explicit and
  use the KASAN defines with an explicit ifdef so it is clear
  what is going on in the prepare_page_table().
- Patch memory.rst to reflect the location of KASan shadow
  memory.
ChangeLog v6->v7:
- Use the SPDX license identifier.
- Rewrote the commit message and updates the illustration.
- Move KASAN_OFFSET Kconfig set-up into this patch and put it
  right after PAGE_OFFSET so it is clear how this works, and
  we have all defines in one patch.
- Added KASAN_SHADOW_OFFSET of 0x8f000000 for 3G_OPT.
  See the calculation in the commit message.
- Updated the commit message with detailed information on
  how KASAN_SHADOW_OFFSET is obtained for the different
  VMSPLIT/PAGE_OFFSET options.
---
 Documentation/arm/memory.rst       |  5 ++
 arch/arm/Kconfig                   |  9 ++++
 arch/arm/include/asm/kasan_def.h   | 81 ++++++++++++++++++++++++++++++
 arch/arm/include/asm/memory.h      |  5 ++
 arch/arm/include/asm/uaccess-asm.h |  2 +-
 arch/arm/kernel/entry-armv.S       |  3 +-
 arch/arm/kernel/entry-common.S     |  9 ++--
 arch/arm/mm/mmu.c                  | 18 +++++++
 8 files changed, 127 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/include/asm/kasan_def.h

diff --git a/Documentation/arm/memory.rst b/Documentation/arm/memory.rst
index 0521b4ce5c96..36bae90cfb1e 100644
--- a/Documentation/arm/memory.rst
+++ b/Documentation/arm/memory.rst
@@ -72,6 +72,11 @@ MODULES_VADDR	MODULES_END-1	Kernel module space
 				Kernel modules inserted via insmod are
 				placed here using dynamic mappings.
 
+TASK_SIZE	MODULES_VADDR-1	KASAn shadow memory when KASan is in use.
+				The range from MODULES_VADDR to the top
+				of the memory is shadowed here with 1 bit
+				per byte of memory.
+
 00001000	TASK_SIZE-1	User space mappings
 				Per-thread mappings are placed here via
 				the mmap() system call.
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2ac74904a3ce..d291cdb84c9d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1328,6 +1328,15 @@ config PAGE_OFFSET
 	default 0xB0000000 if VMSPLIT_3G_OPT
 	default 0xC0000000
 
+config KASAN_SHADOW_OFFSET
+	hex
+	depends on KASAN
+	default 0x1f000000 if PAGE_OFFSET=0x40000000
+	default 0x5f000000 if PAGE_OFFSET=0x80000000
+	default 0x9f000000 if PAGE_OFFSET=0xC0000000
+	default 0x8f000000 if PAGE_OFFSET=0xB0000000
+	default 0xffffffff
+
 config NR_CPUS
 	int "Maximum number of CPUs (2-32)"
 	range 2 32
diff --git a/arch/arm/include/asm/kasan_def.h b/arch/arm/include/asm/kasan_def.h
new file mode 100644
index 000000000000..5739605aa7cf
--- /dev/null
+++ b/arch/arm/include/asm/kasan_def.h
@@ -0,0 +1,81 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ *  arch/arm/include/asm/kasan_def.h
+ *
+ *  Copyright (c) 2018 Huawei Technologies Co., Ltd.
+ *
+ *  Author: Abbott Liu <liuwenliang@huawei.com>
+ */
+
+#ifndef __ASM_KASAN_DEF_H
+#define __ASM_KASAN_DEF_H
+
+#ifdef CONFIG_KASAN
+
+/*
+ * Define KASAN_SHADOW_OFFSET,KASAN_SHADOW_START and KASAN_SHADOW_END for
+ * the Arm kernel address sanitizer. We are "stealing" lowmem (the 4GB
+ * addressable by a 32bit architecture) out of the virtual address
+ * space to use as shadow memory for KASan as follows:
+ *
+ * +----+ 0xffffffff
+ * |    |							\
+ * |    | |-> Static kernel image (vmlinux) BSS and page table
+ * |    |/
+ * +----+ PAGE_OFFSET
+ * |    |							\
+ * |    | |->  Loadable kernel modules virtual address space area
+ * |    |/
+ * +----+ MODULES_VADDR = KASAN_SHADOW_END
+ * |    |						\
+ * |    | |-> The shadow area of kernel virtual address.
+ * |    |/
+ * +----+->  TASK_SIZE (start of kernel space) = KASAN_SHADOW_START the
+ * |    |\   shadow address of MODULES_VADDR
+ * |    | |
+ * |    | |
+ * |    | |-> The user space area in lowmem. The kernel address
+ * |    | |   sanitizer do not use this space, nor does it map it.
+ * |    | |
+ * |    | |
+ * |    | |
+ * |    | |
+ * |    |/
+ * ------ 0
+ *
+ * 1) KASAN_SHADOW_START
+ *   This value begins with the MODULE_VADDR's shadow address. It is the
+ *   start of kernel virtual space. Since we have modules to load, we need
+ *   to cover also that area with shadow memory so we can find memory
+ *   bugs in modules.
+ *
+ * 2) KASAN_SHADOW_END
+ *   This value is the 0x100000000's shadow address: the mapping that would
+ *   be after the end of the kernel memory at 0xffffffff. It is the end of
+ *   kernel address sanitizer shadow area. It is also the start of the
+ *   module area.
+ *
+ * 3) KASAN_SHADOW_OFFSET:
+ *   This value is used to map an address to the corresponding shadow
+ *   address by the following formula:
+ *
+ *	shadow_addr = (address >> 3) + KASAN_SHADOW_OFFSET;
+ *
+ *  As you would expect, >> 3 is equal to dividing by 8, meaning each
+ *  byte in the shadow memory covers 8 bytes of kernel memory, so one
+ *  bit shadow memory per byte of kernel memory is used.
+ *
+ *  The KASAN_SHADOW_OFFSET is provided in a Kconfig option depending
+ *  on the VMSPLIT layout of the system: the kernel and userspace can
+ *  split up lowmem in different ways according to needs, so we calculate
+ *  the shadow offset depending on this.
+ */
+
+#define KASAN_SHADOW_SCALE_SHIFT	3
+#define KASAN_SHADOW_OFFSET	_AC(CONFIG_KASAN_SHADOW_OFFSET, UL)
+#define KASAN_SHADOW_END	((UL(1) << (32 - KASAN_SHADOW_SCALE_SHIFT)) \
+				 + KASAN_SHADOW_OFFSET)
+#define KASAN_SHADOW_START      ((KASAN_SHADOW_END >> 3) + KASAN_SHADOW_OFFSET)
+
+#endif
+#endif
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 99035b5891ef..5cfa9e5dc733 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -18,6 +18,7 @@
 #ifdef CONFIG_NEED_MACH_MEMORY_H
 #include <mach/memory.h>
 #endif
+#include <asm/kasan_def.h>
 
 /* PAGE_OFFSET - the virtual address of the start of the kernel image */
 #define PAGE_OFFSET		UL(CONFIG_PAGE_OFFSET)
@@ -28,7 +29,11 @@
  * TASK_SIZE - the maximum size of a user space task.
  * TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area
  */
+#ifndef CONFIG_KASAN
 #define TASK_SIZE		(UL(CONFIG_PAGE_OFFSET) - UL(SZ_16M))
+#else
+#define TASK_SIZE		(KASAN_SHADOW_START)
+#endif
 #define TASK_UNMAPPED_BASE	ALIGN(TASK_SIZE / 3, SZ_16M)
 
 /*
diff --git a/arch/arm/include/asm/uaccess-asm.h b/arch/arm/include/asm/uaccess-asm.h
index 907571fd05c6..e6eb7a2aaf1e 100644
--- a/arch/arm/include/asm/uaccess-asm.h
+++ b/arch/arm/include/asm/uaccess-asm.h
@@ -85,7 +85,7 @@
 	 */
 	.macro	uaccess_entry, tsk, tmp0, tmp1, tmp2, disable
 	ldr	\tmp1, [\tsk, #TI_ADDR_LIMIT]
-	mov	\tmp2, #TASK_SIZE
+	ldr	\tmp2, =TASK_SIZE
 	str	\tmp2, [\tsk, #TI_ADDR_LIMIT]
  DACR(	mrc	p15, 0, \tmp0, c3, c0, 0)
  DACR(	str	\tmp0, [sp, #SVC_DACR])
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 55a47df04773..c4220f51fcf3 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -427,7 +427,8 @@ ENDPROC(__fiq_abt)
 	@ if it was interrupted in a critical region.  Here we
 	@ perform a quick test inline since it should be false
 	@ 99.9999% of the time.  The rest is done out of line.
-	cmp	r4, #TASK_SIZE
+	ldr	r0, =TASK_SIZE
+	cmp	r4, r0
 	blhs	kuser_cmpxchg64_fixup
 #endif
 #endif
diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index 271cb8a1eba1..fee279e28a72 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -50,7 +50,8 @@ __ret_fast_syscall:
  UNWIND(.cantunwind	)
 	disable_irq_notrace			@ disable interrupts
 	ldr	r2, [tsk, #TI_ADDR_LIMIT]
-	cmp	r2, #TASK_SIZE
+	ldr	r1, =TASK_SIZE
+	cmp	r2, r1
 	blne	addr_limit_check_failed
 	ldr	r1, [tsk, #TI_FLAGS]		@ re-check for syscall tracing
 	tst	r1, #_TIF_SYSCALL_WORK | _TIF_WORK_MASK
@@ -87,7 +88,8 @@ __ret_fast_syscall:
 #endif
 	disable_irq_notrace			@ disable interrupts
 	ldr	r2, [tsk, #TI_ADDR_LIMIT]
-	cmp	r2, #TASK_SIZE
+	ldr     r1, =TASK_SIZE
+	cmp     r2, r1
 	blne	addr_limit_check_failed
 	ldr	r1, [tsk, #TI_FLAGS]		@ re-check for syscall tracing
 	tst	r1, #_TIF_SYSCALL_WORK | _TIF_WORK_MASK
@@ -128,7 +130,8 @@ ret_slow_syscall:
 	disable_irq_notrace			@ disable interrupts
 ENTRY(ret_to_user_from_irq)
 	ldr	r2, [tsk, #TI_ADDR_LIMIT]
-	cmp	r2, #TASK_SIZE
+	ldr     r1, =TASK_SIZE
+	cmp	r2, r1
 	blne	addr_limit_check_failed
 	ldr	r1, [tsk, #TI_FLAGS]
 	tst	r1, #_TIF_WORK_MASK
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 628028bfbb92..46ee62d39f04 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -29,6 +29,7 @@
 #include <asm/traps.h>
 #include <asm/procinfo.h>
 #include <asm/memory.h>
+#include <asm/kasan_def.h>
 
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
@@ -1264,8 +1265,25 @@ static inline void prepare_page_table(void)
 	/*
 	 * Clear out all the mappings below the kernel image.
 	 */
+#ifdef CONFIG_KASAN
+	/*
+	 * KASan's shadow memory inserts itself between the TASK_SIZE
+	 * and MODULES_VADDR. Do not clear the KASan shadow memory mappings.
+	 */
+	for (addr = 0; addr < KASAN_SHADOW_START; addr += PMD_SIZE)
+		pmd_clear(pmd_off_k(addr));
+	/*
+	 * Skip over the KASan shadow area. KASAN_SHADOW_END is sometimes
+	 * equal to MODULES_VADDR and then we exit the pmd clearing. If we
+	 * are using a thumb-compiled kernel, there there will be 8MB more
+	 * to clear as KASan always offset to 16 MB below MODULES_VADDR.
+	 */
+	for (addr = KASAN_SHADOW_END; addr < MODULES_VADDR; addr += PMD_SIZE)
+		pmd_clear(pmd_off_k(addr));
+#else
 	for (addr = 0; addr < MODULES_VADDR; addr += PMD_SIZE)
 		pmd_clear(pmd_off_k(addr));
+#endif
 
 #ifdef CONFIG_XIP_KERNEL
 	/* The XIP kernel is mapped in the module area -- skip over it */
-- 
2.25.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 4/5 v11] ARM: Initialize the mapping of KASan shadow memory

[Linus Walleij]

This patch initializes KASan shadow region's page table and memory.
There are two stage for KASan initializing:

1. At early boot stage the whole shadow region is mapped to just
   one physical page (kasan_zero_page). It is finished by the function
   kasan_early_init which is called by __mmap_switched(arch/arm/kernel/
   head-common.S)

2. After the calling of paging_init, we use kasan_zero_page as zero
   shadow for some memory that KASan does not need to track, and we
   allocate a new shadow space for the other memory that KASan need to
   track. These issues are finished by the function kasan_init which is
   call by setup_arch.

When using KASan we also need to increase the THREAD_SIZE_ORDER
from 1 to 2 as the extra calls for shadow memory uses quite a bit
of stack.

As we need to make a temporary copy of the PGD when setting up
shadow memory we create a helpful PGD_SIZE definition for both
LPAE and non-LPAE setups.

The KASan core code unconditionally calls pud_populate() so this
needs to be changed from BUG() to do {} while (0) when building
with KASan enabled.

After the initial development by Andre Ryabinin several modifications
have been made to this code:

Abbott Liu <liuwenliang@huawei.com>
- Add support ARM LPAE: If LPAE is enabled, KASan shadow region's
  mapping table need be copied in the pgd_alloc() function.
- Change kasan_pte_populate,kasan_pmd_populate,kasan_pud_populate,
  kasan_pgd_populate from .meminit.text section to .init.text section.
  Reported by Florian Fainelli <f.fainelli@gmail.com>

Linus Walleij <linus.walleij@linaro.org>:
- Drop the custom mainpulation of TTBR0 and just use
  cpu_switch_mm() to switch the pgd table.
- Adopt to handle 4th level page tabel folding.
- Rewrite the entire page directory and page entry initialization
  sequence to be recursive based on ARM64:s kasan_init.c.

Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: kasan-dev@googlegroups.com
Cc: Mike Rapoport <rppt@linux.ibm.com>
Co-Developed-by: Abbott Liu <liuwenliang@huawei.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G
Reported-by: Russell King - ARM Linux <linux@armlinux.org.uk>
Reported-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v10->v11:
- Fix compilation on LPAE systems.
- Move the check for valid pgdp, pudp and pmdp into the loop for
  each level moving over the directory pointers: we were just lucky
  that we just needed one directory for each level so this fixes
  the pmdp issue with LPAE and KASan now works like a charm on
  LPAE as well.
- Fold fourth level page directory (p4d) into the global page directory
  pgd and just skip into the page upper directory (pud) directly. We
  do not anticipate that ARM32 will every use 5-level page tables.
- Simplify the ifdeffery around the temporary pgd.
- Insert a comment about pud_populate() that is unconditionally called
  by the KASan core code.
ChangeLog v9->v10:
- Rebase onto v5.8-rc1
- add support for folded p4d page tables, use the primitives necessary
  for the 4th level folding, add (empty) walks of p4d level.
- Use the <linux/pgtable.h> header file that has now appeared as part
  of the VM consolidation series.
- Use a recursive method to walk pgd/p4d/pud/pmd/pte instead of the
  separate early/main calls and the flat call structure used in the
  old code. This was inspired by the ARM64 KASan init code.
- Assume authorship of this code, I have now written the majority of
  it so the blame is on me and noone else.
ChangeLog v8->v9:
- Drop the custom CP15 manipulation and cache flushing for swapping
  TTBR0 and instead just use cpu_switch_mm().
- Collect Ard's tags.
ChangeLog v7->v8:
- Rebased.
ChangeLog v6->v7:
- Use SPDX identifer for the license.
- Move the TTBR0 accessor calls into this patch.
---
 arch/arm/include/asm/kasan.h       |  32 ++++
 arch/arm/include/asm/pgalloc.h     |   8 +-
 arch/arm/include/asm/thread_info.h |   8 +
 arch/arm/kernel/head-common.S      |   3 +
 arch/arm/kernel/setup.c            |   2 +
 arch/arm/mm/Makefile               |   3 +
 arch/arm/mm/kasan_init.c           | 288 +++++++++++++++++++++++++++++
 arch/arm/mm/pgd.c                  |  16 +-
 8 files changed, 358 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/include/asm/kasan.h
 create mode 100644 arch/arm/mm/kasan_init.c

diff --git a/arch/arm/include/asm/kasan.h b/arch/arm/include/asm/kasan.h
new file mode 100644
index 000000000000..56b954db160e
--- /dev/null
+++ b/arch/arm/include/asm/kasan.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * arch/arm/include/asm/kasan.h
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * Author: Andrey Ryabinin <ryabinin.a.a@gmail.com>
+ *
+ */
+
+#ifndef __ASM_KASAN_H
+#define __ASM_KASAN_H
+
+#ifdef CONFIG_KASAN
+
+#include <asm/kasan_def.h>
+
+#define KASAN_SHADOW_SCALE_SHIFT 3
+
+/*
+ * The compiler uses a shadow offset assuming that addresses start
+ * from 0. Kernel addresses don't start from 0, so shadow
+ * for kernel really starts from 'compiler's shadow offset' +
+ * ('kernel address space start' >> KASAN_SHADOW_SCALE_SHIFT)
+ */
+
+extern void kasan_init(void);
+
+#else
+static inline void kasan_init(void) { }
+#endif
+
+#endif
diff --git a/arch/arm/include/asm/pgalloc.h b/arch/arm/include/asm/pgalloc.h
index 069da393110c..3bf1905df9c3 100644
--- a/arch/arm/include/asm/pgalloc.h
+++ b/arch/arm/include/asm/pgalloc.h
@@ -21,6 +21,7 @@
 #define _PAGE_KERNEL_TABLE	(PMD_TYPE_TABLE | PMD_BIT4 | PMD_DOMAIN(DOMAIN_KERNEL))
 
 #ifdef CONFIG_ARM_LPAE
+#define PGD_SIZE		(PTRS_PER_PGD * sizeof(pgd_t))
 
 static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
 {
@@ -39,14 +40,19 @@ static inline void pud_populate(struct mm_struct *mm, pud_t *pud, pmd_t *pmd)
 }
 
 #else	/* !CONFIG_ARM_LPAE */
+#define PGD_SIZE		(PAGE_SIZE << 2)
 
 /*
  * Since we have only two-level page tables, these are trivial
  */
 #define pmd_alloc_one(mm,addr)		({ BUG(); ((pmd_t *)2); })
 #define pmd_free(mm, pmd)		do { } while (0)
+#ifdef CONFIG_KASAN
+/* The KASan core unconditionally calls pud_populate() on all architectures */
+#define pud_populate(mm,pmd,pte)	do { } while (0)
+#else
 #define pud_populate(mm,pmd,pte)	BUG()
-
+#endif
 #endif	/* CONFIG_ARM_LPAE */
 
 extern pgd_t *pgd_alloc(struct mm_struct *mm);
diff --git a/arch/arm/include/asm/thread_info.h b/arch/arm/include/asm/thread_info.h
index 3609a6980c34..02813a5d9e10 100644
--- a/arch/arm/include/asm/thread_info.h
+++ b/arch/arm/include/asm/thread_info.h
@@ -13,7 +13,15 @@
 #include <asm/fpstate.h>
 #include <asm/page.h>
 
+#ifdef CONFIG_KASAN
+/*
+ * KASan uses a lot of extra stack space so the thread size order needs to
+ * be increased.
+ */
+#define THREAD_SIZE_ORDER	2
+#else
 #define THREAD_SIZE_ORDER	1
+#endif
 #define THREAD_SIZE		(PAGE_SIZE << THREAD_SIZE_ORDER)
 #define THREAD_START_SP		(THREAD_SIZE - 8)
 
diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
index 6840c7c60a85..89c80154b9ef 100644
--- a/arch/arm/kernel/head-common.S
+++ b/arch/arm/kernel/head-common.S
@@ -111,6 +111,9 @@ __mmap_switched:
 	str	r8, [r2]			@ Save atags pointer
 	cmp	r3, #0
 	strne	r10, [r3]			@ Save control register values
+#ifdef CONFIG_KASAN
+	bl	kasan_early_init
+#endif
 	mov	lr, #0
 	b	start_kernel
 ENDPROC(__mmap_switched)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index d8e18cdd96d3..b0820847bb92 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -58,6 +58,7 @@
 #include <asm/unwind.h>
 #include <asm/memblock.h>
 #include <asm/virt.h>
+#include <asm/kasan.h>
 
 #include "atags.h"
 
@@ -1130,6 +1131,7 @@ void __init setup_arch(char **cmdline_p)
 	early_ioremap_reset();
 
 	paging_init(mdesc);
+	kasan_init();
 	request_standard_resources(mdesc);
 
 	if (mdesc->restart)
diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index 99699c32d8a5..4536159bc8fa 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -113,3 +113,6 @@ obj-$(CONFIG_CACHE_L2X0_PMU)	+= cache-l2x0-pmu.o
 obj-$(CONFIG_CACHE_XSC3L2)	+= cache-xsc3l2.o
 obj-$(CONFIG_CACHE_TAUROS2)	+= cache-tauros2.o
 obj-$(CONFIG_CACHE_UNIPHIER)	+= cache-uniphier.o
+
+KASAN_SANITIZE_kasan_init.o	:= n
+obj-$(CONFIG_KASAN)		+= kasan_init.o
diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
new file mode 100644
index 000000000000..535dce42e59d
--- /dev/null
+++ b/arch/arm/mm/kasan_init.c
@@ -0,0 +1,288 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * This file contains kasan initialization code for ARM.
+ *
+ * Copyright (c) 2018 Samsung Electronics Co., Ltd.
+ * Author: Andrey Ryabinin <ryabinin.a.a@gmail.com>
+ * Author: Linus Walleij <linus.walleij@linaro.org>
+ */
+
+#define pr_fmt(fmt) "kasan: " fmt
+#include <linux/kasan.h>
+#include <linux/kernel.h>
+#include <linux/memblock.h>
+#include <linux/sched/task.h>
+#include <linux/start_kernel.h>
+#include <linux/pgtable.h>
+#include <asm/cputype.h>
+#include <asm/highmem.h>
+#include <asm/mach/map.h>
+#include <asm/memory.h>
+#include <asm/page.h>
+#include <asm/pgalloc.h>
+#include <asm/procinfo.h>
+#include <asm/proc-fns.h>
+
+#include "mm.h"
+
+static pgd_t tmp_pgd_table[PTRS_PER_PGD] __initdata __aligned(PGD_SIZE);
+
+pmd_t tmp_pmd_table[PTRS_PER_PMD] __page_aligned_bss;
+
+static __init void *kasan_alloc_block(size_t size, int node)
+{
+	return memblock_alloc_try_nid(size, size, __pa(MAX_DMA_ADDRESS),
+				      MEMBLOCK_ALLOC_KASAN, node);
+}
+
+static void __init kasan_pte_populate(pmd_t *pmdp, unsigned long addr,
+				      unsigned long end, int node, bool early)
+{
+	unsigned long next;
+	pte_t *ptep = pte_offset_kernel(pmdp, addr);
+
+	do {
+		next = addr + PAGE_SIZE;
+
+		if (pte_none(*ptep)) {
+			pte_t entry;
+			void *p;
+
+			/*
+			 * The early shadow memory is mapping all KASan operations to one and the same page
+			 * in memory, "kasan_early_shadow_page" so that the instrumentation will work on
+			 * a scratch area until we can set up the proper KASan shadow memory.
+			 */
+			if (early) {
+				p = kasan_early_shadow_page;
+				entry = pfn_pte(virt_to_pfn(kasan_early_shadow_page),
+						__pgprot(_L_PTE_DEFAULT | L_PTE_DIRTY
+							 | L_PTE_XN));
+			} else {
+				p = kasan_alloc_block(PAGE_SIZE, node);
+				if (!p) {
+					panic("%s failed to alloc pte for address 0x%lx\n",
+					      __func__, addr);
+					return;
+				}
+				memset(p, KASAN_SHADOW_INIT, PAGE_SIZE);
+				entry = pfn_pte(virt_to_pfn(p),
+					__pgprot(pgprot_val(PAGE_KERNEL)));
+			}
+
+			set_pte_at(&init_mm, addr, ptep, entry);
+		}
+	} while (ptep++, addr = next, addr != end && pte_none(READ_ONCE(*ptep)));
+}
+
+/*
+ * The pmd (page middle directory) used on LPAE?
+ */
+static void __init kasan_pmd_populate(pud_t *pudp, unsigned long addr,
+				      unsigned long end, int node, bool early)
+{
+	unsigned long next;
+	pmd_t *pmdp = pmd_offset(pudp, addr);
+
+	do {
+		if (pmd_none(*pmdp)) {
+			void *p = early ? kasan_early_shadow_pte : kasan_alloc_block(PAGE_SIZE, node);
+
+			if (!p) {
+				panic("%s failed to allocate pmd for address 0x%lx\n",
+				      __func__, addr);
+				return;
+			}
+			pmd_populate_kernel(&init_mm, pmdp, p);
+			flush_pmd_entry(pmdp);
+		}
+
+		next = pmd_addr_end(addr, end);
+		kasan_pte_populate(pmdp, addr, next, node, early);
+	} while (pmdp++, addr = next, addr != end && pmd_none(READ_ONCE(*pmdp)));
+}
+
+/*
+ * The pud (page upper directory) is only used on LPAE systems.
+ */
+static void __init kasan_pud_populate(p4d_t *p4dp, unsigned long addr,
+				      unsigned long end, int node, bool early)
+{
+	unsigned long next;
+	pud_t *pudp = pud_offset(p4dp, addr);
+
+	do {
+		/*
+		 * FIXME: necessary?
+		 * Allocate and populate the PUD if it doesn't already exist
+		 * On non-LPAE systems using just 2-level page tables pud_none()
+		 * will always be zero and this will be skipped.
+		 */
+		if (!early && pud_none(*pudp)) {
+			void *p = kasan_alloc_block(PAGE_SIZE, node);
+
+			if (!p) {
+				panic("%s failed to allocate pud for address 0x%lx\n",
+				      __func__, addr);
+				return;
+			}
+			if (IS_ENABLED(CONFIG_ARM_LPAE)) {
+				pr_info("populating pud addr %lx\n", addr);
+				pud_populate(&init_mm, pudp, p);
+			}
+		}
+
+		next = pud_addr_end(addr, end);
+		kasan_pmd_populate(pudp, addr, next, node, early);
+	} while (pudp++, addr = next, addr != end && pud_none(READ_ONCE(*pudp)));
+}
+
+static void __init kasan_pgd_populate(unsigned long addr, unsigned long end,
+				      int node, bool early)
+{
+	unsigned long next;
+	pgd_t *pgdp;
+	p4d_t *p4dp;
+
+	pgdp = pgd_offset_k(addr);
+
+	do {
+		/* Allocate and populate the PGD if it doesn't already exist */
+		if (!early && pgd_none(*pgdp)) {
+			void *p = kasan_alloc_block(PAGE_SIZE, node);
+
+			if (!p) {
+				panic("%s failed to allocate pgd for address 0x%lx\n",
+				      __func__, addr);
+				return;
+			}
+			pgd_populate(&init_mm, pgdp, p);
+		}
+
+		next = pgd_addr_end(addr, end);
+		/*
+		 * We just immediately jump over the p4p fourth level page
+		 * directory since we believe ARM32 will never gain four level
+		 * page tables.
+		 */
+		p4dp = p4d_offset(pgdp, addr);
+
+		kasan_pud_populate(p4dp, addr, next, node, early);
+	} while (pgdp++, addr = next, addr != end);
+}
+
+extern struct proc_info_list *lookup_processor_type(unsigned int);
+
+void __init kasan_early_init(void)
+{
+	struct proc_info_list *list;
+
+	/*
+	 * locate processor in the list of supported processor
+	 * types.  The linker builds this table for us from the
+	 * entries in arch/arm/mm/proc-*.S
+	 */
+	list = lookup_processor_type(read_cpuid_id());
+	if (list) {
+#ifdef MULTI_CPU
+		processor = *list->proc;
+#endif
+	}
+
+	BUILD_BUG_ON((KASAN_SHADOW_END - (1UL << 29)) != KASAN_SHADOW_OFFSET);
+	/*
+	 * We walk the page table and set all of the shadow memory to point
+	 * to the scratch page.
+	 */
+	kasan_pgd_populate(KASAN_SHADOW_START, KASAN_SHADOW_END, NUMA_NO_NODE,
+			   true);
+}
+
+static void __init clear_pgds(unsigned long start,
+			unsigned long end)
+{
+	for (; start && start < end; start += PMD_SIZE)
+		pmd_clear(pmd_off_k(start));
+}
+
+static int __init create_mapping(unsigned long start, unsigned long end,
+				int node)
+{
+	pr_info("populating shadow for %lx, %lx\n", start, end);
+	kasan_pgd_populate(start, end, NUMA_NO_NODE, false);
+	return 0;
+}
+
+void __init kasan_init(void)
+{
+	struct memblock_region *reg;
+	int i;
+
+	/*
+	 * We are going to perform proper setup of shadow memory.
+	 *
+	 * At first we should unmap early shadow (clear_pgds() call bellow).
+	 * However, instrumented code couldn't execute without shadow memory.
+	 *
+	 * To keep the early shadow memory MMU tables around while setting up
+	 * the proper shadow memory, we copy swapper_pg_dir (the initial page
+	 * table) to tmp_pgd_table and use that to keep the early shadow memory
+	 * mapped until the full shadow setup is finished. Then we swap back
+	 * to the proper swapper_pg_dir.
+	 */
+	memcpy(tmp_pgd_table, swapper_pg_dir, sizeof(tmp_pgd_table));
+#ifdef CONFIG_ARM_LPAE
+	memcpy(tmp_pmd_table,
+	       pgd_page_vaddr(*pgd_offset_k(KASAN_SHADOW_START)),
+	       sizeof(tmp_pmd_table));
+	set_pgd(&tmp_pgd_table[pgd_index(KASAN_SHADOW_START)],
+		__pgd(__pa(tmp_pmd_table) | PMD_TYPE_TABLE | L_PGD_SWAPPER));
+#endif
+	cpu_switch_mm(tmp_pgd_table, &init_mm);
+	clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);
+
+	kasan_populate_early_shadow(kasan_mem_to_shadow((void *)VMALLOC_START),
+				    kasan_mem_to_shadow((void *)-1UL) + 1);
+
+	for_each_memblock(memory, reg) {
+		void *start = __va(reg->base);
+		void *end = __va(reg->base + reg->size);
+
+		if (reg->base + reg->size > arm_lowmem_limit)
+			end = __va(arm_lowmem_limit);
+		if (start >= end)
+			break;
+
+		create_mapping((unsigned long)kasan_mem_to_shadow(start),
+			(unsigned long)kasan_mem_to_shadow(end),
+			NUMA_NO_NODE);
+	}
+
+	/*
+	 * 1. The module global variables are in MODULES_VADDR ~ MODULES_END,
+	 *    so we need to map this area.
+	 * 2. PKMAP_BASE ~ PKMAP_BASE+PMD_SIZE's shadow and MODULES_VADDR
+	 *    ~ MODULES_END's shadow is in the same PMD_SIZE, so we can't
+	 *    use kasan_populate_zero_shadow.
+	 */
+	create_mapping(
+		(unsigned long)kasan_mem_to_shadow((void *)MODULES_VADDR),
+		(unsigned long)kasan_mem_to_shadow((void *)(PKMAP_BASE +
+							PMD_SIZE)),
+		NUMA_NO_NODE);
+
+	/*
+	 * KAsan may reuse the contents of kasan_early_shadow_pte directly, so
+	 * we should make sure that it maps the zero page read-only.
+	 */
+	for (i = 0; i < PTRS_PER_PTE; i++)
+		set_pte_at(&init_mm, KASAN_SHADOW_START + i*PAGE_SIZE,
+			&kasan_early_shadow_pte[i],
+			pfn_pte(virt_to_pfn(kasan_early_shadow_page),
+				__pgprot(pgprot_val(PAGE_KERNEL)
+					| L_PTE_RDONLY)));
+	memset(kasan_early_shadow_page, 0, PAGE_SIZE);
+	cpu_switch_mm(swapper_pg_dir, &init_mm);
+	pr_info("Kernel address sanitizer initialized\n");
+	init_task.kasan_depth = 0;
+}
diff --git a/arch/arm/mm/pgd.c b/arch/arm/mm/pgd.c
index c5e1b27046a8..f8e9bc58a84f 100644
--- a/arch/arm/mm/pgd.c
+++ b/arch/arm/mm/pgd.c
@@ -66,7 +66,21 @@ pgd_t *pgd_alloc(struct mm_struct *mm)
 	new_pmd = pmd_alloc(mm, new_pud, 0);
 	if (!new_pmd)
 		goto no_pmd;
-#endif
+#ifdef CONFIG_KASAN
+	/*
+	 * Copy PMD table for KASAN shadow mappings.
+	 */
+	init_pgd = pgd_offset_k(TASK_SIZE);
+	init_p4d = p4d_offset(init_pgd, TASK_SIZE);
+	init_pud = pud_offset(init_p4d, TASK_SIZE);
+	init_pmd = pmd_offset(init_pud, TASK_SIZE);
+	new_pmd = pmd_offset(new_pud, TASK_SIZE);
+	memcpy(new_pmd, init_pmd,
+	       (pmd_index(MODULES_VADDR) - pmd_index(TASK_SIZE))
+	       * sizeof(pmd_t));
+	clean_dcache_area(new_pmd, PTRS_PER_PMD * sizeof(pmd_t));
+#endif /* CONFIG_KASAN */
+#endif /* CONFIG_LPAE */
 
 	if (!vectors_high()) {
 		/*
-- 
2.25.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 5/5 v11] ARM: Enable KASan for ARM

[Linus Walleij]

From: Andrey Ryabinin <ryabinin@virtuozzo.com>

This patch enables the kernel address sanitizer for ARM. XIP_KERNEL
has not been tested and is therefore not allowed for now.

Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: kasan-dev@googlegroups.com
Acked-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G
Signed-off-by: Abbott Liu <liuwenliang@huawei.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v10->v11:
- Resend with the other changes.
ChangeLog v9->v10:
- Rebase on v5.8-rc1
ChangeLog v8->v9:
- Fix the arch feature matrix for Arm to include KASan.
- Collect Ard's tags.
ChangeLog v7->v8:
- Moved the hacks to __ADDRESS_SANITIZE__ to the patch
  replacing the memory access functions.
- Moved the definition of KASAN_OFFSET out of this patch
  and to the patch that defines the virtual memory used by
  KASan.
---
 Documentation/dev-tools/kasan.rst                   | 4 ++--
 Documentation/features/debug/KASAN/arch-support.txt | 2 +-
 arch/arm/Kconfig                                    | 1 +
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
index c652d740735d..0962365e1405 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -21,8 +21,8 @@ global variables yet.
 
 Tag-based KASAN is only supported in Clang and requires version 7.0.0 or later.
 
-Currently generic KASAN is supported for the x86_64, arm64, xtensa, s390 and
-riscv architectures, and tag-based KASAN is supported only for arm64.
+Currently generic KASAN is supported for the x86_64, arm, arm64, xtensa, s390
+and riscv architectures, and tag-based KASAN is supported only for arm64.
 
 Usage
 -----
diff --git a/Documentation/features/debug/KASAN/arch-support.txt b/Documentation/features/debug/KASAN/arch-support.txt
index 6ff38548923e..a73c55fb76e6 100644
--- a/Documentation/features/debug/KASAN/arch-support.txt
+++ b/Documentation/features/debug/KASAN/arch-support.txt
@@ -8,7 +8,7 @@
     -----------------------
     |       alpha: | TODO |
     |         arc: | TODO |
-    |         arm: | TODO |
+    |         arm: |  ok  |
     |       arm64: |  ok  |
     |         c6x: | TODO |
     |        csky: | TODO |
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d291cdb84c9d..6a6059f8bab9 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -65,6 +65,7 @@ config ARM
 	select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
 	select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
 	select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
+	select HAVE_ARCH_KASAN if MMU && !XIP_KERNEL
 	select HAVE_ARCH_MMAP_RND_BITS if MMU
 	select HAVE_ARCH_SECCOMP_FILTER if AEABI && !OABI_COMPAT
 	select HAVE_ARCH_THREAD_STRUCT_WHITELIST
-- 
2.25.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/5 v11] KASan for Arm

[Florian Fainelli]

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

Hi Linus,

On 6/30/2020 6:37 AM, Linus Walleij wrote:
> This is the v11 version of the KASan patches for ARM.
> 
> The main changes from the v10 version is:
> 
> - LPAE now compiles and works again, at least Versatile Express
>   Cortex A15 TC1 in QEMU (which is the LPAE system I have
>   access to).
> 
> - Rewrite some of the page directory initialization after
>   helpful feedback from Mike Rapoport and Russell King.
> 
> Also minor improvements to commit messages and comments
> in the code so it is clear (for most cases I hope) why
> some ifdefs etc are there.
> 
> All tested platforms from ARMv4 thru ARMv7 work fine. I
> have not been able to re-test with the Qualcomm DragonBoard
> APQ8060 yet, but I suspect the problem there is that the
> DT parser code reaches out into non-kernel memory and
> needs some de-instrumentation, possibly combined with the
> memory holding the device tree getting corrupted or reused
> before we have a chance to parse it.

So one of my systems (BCM7278 chip), we do indeed reach the point where
unflatten_dt_nodes crashes the system and I guess this is a "pass" for now.

On another system though (BCM7445 chip) with a physical memory map that
looks like this:

0x0000_0000 - 0x3fff_ffff (MEMC0)
0x4000_0000 - 0x7fff_ffff (MEMC1)
0x8000_0000 - 0xbfff_ffff (MEMC2)

we get the attached boot error.
-- 
Florian

[-- Attachment #2: bcm97445vms.log --]
[-- Type: text/plain, Size: 7201 bytes --]

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.8.0-rc2-gbe67c43c4125 (fainelli@fainelli-desktop) (arm-linux-gcc (crosstool-NG ) 6.3.0, GNU ld (crosstool-NG
) 2.26.20160125) #29 SMP Tue Jun 30 09:42:15 PDT 2020
[    0.000000] CPU: ARMv7 Processor [420f00f3] revision 3 (ARMv7), cr=30c5387d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] OF: fdt: Machine model: BCM97445VMS
[    0.000000] printk: bootconsole [earlycon0] enabled
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] cma: Reserved 16 MiB at 0x00000000bec00000
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000000000-0x000000002fffffff]
[    0.000000]   Normal   empty
[    0.000000]   HighMem  [mem 0x0000000030000000-0x00000000bfffefff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x000000003dffffff]
[    0.000000]   node   0: [mem 0x0000000040000000-0x00000000bfffefff]
[    0.000000] Zeroed struct page in unavailable ranges: 1 pages
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000000bfffefff]
[    0.000000] kasan: populating shadow for b7000000, bd000000
[    0.000000] 8<--- cut here ---
[    0.000000] Unable to handle kernel paging request at virtual address bc9ffe00
[    0.000000] pgd = (ptrval)
[    0.000000] [bc9ffe00] *pgd=80000000006003, *pmd=00000000
[    0.000000] Internal error: Oops: 206 [#1] SMP ARM
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.8.0-rc2-gbe67c43c4125 #29
[    0.000000] Hardware name: Broadcom STB (Flattened Device Tree)
[    0.000000] PC is at check_memory_region+0xb0/0x1bc
[    0.000000] LR is at 0x40
[    0.000000] pc : [<c044f180>]    lr : [<00000040>]    psr: 000000d3
[    0.000000] sp : c2603c48  ip : bc9ffe00  fp : c2603c74
[    0.000000] r10: b81ee000  r9 : 00000000  r8 : bca00000
[    0.000000] r7 : 00000000  r6 : 00000200  r5 : bc9fffff  r4 : ecffffff
[    0.000000] r3 : c181e5fc  r2 : 00000001  r1 : 00001000  r0 : ecfff000
[    0.000000] Flags: nzcv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment user
[    0.000000] Control: 30c5387d  Table: 018751e0  DAC: fffffffd
[    0.000000] Process swapper (pid: 0, stack limit = 0x(ptrval))
[    0.000000] Stack: (0xc2603c48 to 0xc2604000)
[    0.000000] 3c40:                   c181e5fc 00001000 ecfff000 00000000 00000000 00000001
[    0.000000] 3c60: 00000000 b81ee000 c2603c94 c2603c78 c044ceac c044f0dc 00001000 00000000
[    0.000000] 3c80: ecfff000 00000000 c2603cd4 c2603c98 c181e5fc c044ce90 3fffffff 00000000
[    0.000000] 3ca0: 00000001 00000000 ffffffff 00000000 00000001 00000000 0002d000 b81ef000
[    0.000000] 3cc0: c29374d8 ed1eef70 c2603d04 c2603cd8 c180d36c c181e554 3fffffff 00000000
[    0.000000] 3ce0: 00000001 00000000 ffffffff ed1eef70 b8200000 ed1eef78 c2603d74 c2603d08
[    0.000000] 3d00: c180d5c0 c180d2f8 2d00071f 00c00000 c2603d3c c269a8c0 00002933 c0006e00
[    0.000000] 3d20: bd000000 c0003010 c260a284 c16cc084 2d000000 00000000 c10b6764 c10b6648
[    0.000000] 3d40: bd000000 00000000 c180b080 c269ab20 c2960638 c18750d8 c165831c bd000000
[    0.000000] 3d60: b7000000 c16cc000 c2603dc4 c2603d78 c180d8f8 c180d380 c29374c0 00000000
[    0.000000] 3d80: c1872a44 ffff1000 0002ffff 00001000 c16cc000 c269a8c0 30000000 c2d9cc80
[    0.000000] 3da0: c0008000 c1872a44 c269a8c0 e12fff1e c2603f40 c1860b48 c2603ee4 c2603dc8
[    0.000000] 3dc0: c1805c08 c180d714 0000006c 30c5387d c1200740 c2603edc 00000000 00000000
[    0.000000] 3de0: c02268c8 30c5387d 00000024 c2603df8 184c07c0 c2603ea0 c1200740 c2603edc
[    0.000000] 3e00: 41b58ab3 c165670c c1805430 c02b2ad0 c02b36c8 c02b3f08 00000000 b74c07cc
[    0.000000] 3e20: c2606d48 c2606d40 c2606d48 c2936440 c2603ed4 c2603e40 c02b36c8 c02b3f08
[    0.000000] 3e40: c2603eb4 00000000 c2603e74 c2603e58 c2603e74 c2603e60 c029891c c044ec28
[    0.000000] 3e60: 41b58ab3 c1658c9c c02b3638 c2603e78 c031d24c c044ec28 00000000 c2660178
[    0.000000] 3e80: c2603edc c2660020 c1875350 c26601ec c2660030 07723000 c295bf80 c295c7c0
[    0.000000] 3ea0: 00000000 c2606d48 c2603ec4 c2603eb8 c044ec88 00000000 c2603ee4 b74c07e4
[    0.000000] 3ec0: c2603fc0 c2606d40 c2606d48 c2936440 420f00f3 30c5387d c2603ff4 c2603ee8
[    0.000000] 3ee0: c1800d40 c180543c 00000000 00000000 00000000 00000000 00000000 00000000
[    0.000000] 3f00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    0.000000] 3f20: 41b58ab3 c16557f4 c1800c64 00000000 00000000 00000000 00000000 00000000
[    0.000000] 3f40: c1872a44 00000000 00000000 00000000 00000000 c180d638 b7000000 c2935000
[    0.000000] 3f60: 30c0387d b7000000 c2603fe4 c2603f78 c180d638 c0223ae4 02933403 00c00000
[    0.000000] 3f80: 00000000 c269a8c0 00002933 c0006fb8 bf000000 c0003010 c260a284 c16cc084
[    0.000000] 3fa0: 00000000 00000000 02933000 00000000 bf000000 00000001 00000000 c1800334
[    0.000000] 3fc0: 00000000 00000000 ffffffff c1800334 00000000 30c0387d ffffffff 07723000
[    0.000000] 3fe0: 420f00f3 30c5387d 00000000 c2603ff8 00000000 c1800c70 00000000 00000000
[    0.000000] Backtrace:
[    0.000000] [<c044f0d0>] (check_memory_region) from [<c044ceac>] (memset+0x28/0x44)
[    0.000000]  r10:b81ee000 r9:00000000 r8:00000001 r7:00000000 r6:00000000 r5:ecfff000
[    0.000000]  r4:00001000 r3:c181e5fc
[    0.000000] [<c044ce84>] (memset) from [<c181e5fc>] (memblock_alloc_try_nid+0xb4/0xc4)
[    0.000000]  r7:00000000 r6:ecfff000 r5:00000000 r4:00001000
[    0.000000] [<c181e548>] (memblock_alloc_try_nid) from [<c180d36c>] (kasan_alloc_block.constprop.6+0x80/0x88)
[    0.000000]  r9:ed1eef70 r8:c29374d8 r7:b81ef000 r6:0002d000 r5:00000000 r4:00000001
[    0.000000] [<c180d2ec>] (kasan_alloc_block.constprop.6) from [<c180d5c0>] (kasan_pgd_populate.constprop.2+0x24c/0x32c)
[    0.000000]  r5:ed1eef78 r4:b8200000
[    0.000000] [<c180d374>] (kasan_pgd_populate.constprop.2) from [<c180d8f8>] (kasan_init+0x1f0/0x324)
[    0.000000]  r10:c16cc000 r9:b7000000 r8:bd000000 r7:c165831c r6:c18750d8 r5:c2960638
[    0.000000]  r4:c269ab20
[    0.000000] [<c180d708>] (kasan_init) from [<c1805c08>] (setup_arch+0x7d8/0xfa4)
[    0.000000]  r10:c1860b48 r9:c2603f40 r8:e12fff1e r7:c269a8c0 r6:c1872a44 r5:c0008000
[    0.000000]  r4:c2d9cc80
[    0.000000] [<c1805430>] (setup_arch) from [<c1800d40>] (start_kernel+0xdc/0x6b4)
[    0.000000]  r10:30c5387d r9:420f00f3 r8:c2936440 r7:c2606d48 r6:c2606d40 r5:c2603fc0
[    0.000000]  r4:b74c07e4
[    0.000000] [<c1800c64>] (start_kernel) from [<00000000>] (0x0)
[    0.000000]  r10:30c5387d r9:420f00f3 r8:07723000 r7:ffffffff r6:30c0387d r5:00000000
[    0.000000]  r4:c1800334
[    0.000000] Code: e286e007 a1a0e006 e1b0e1ce 0a00002d (e1cc60d0)
[    0.000000] random: get_random_bytes called from print_oops_end_marker+0x48/0x58 with crng_init=0
[    0.000000] ---[ end trace 0000000000000000 ]---
[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[    0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---


[-- Attachment #3: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/5 v11] KASan for Arm

[Ard Biesheuvel]

On Tue, 30 Jun 2020 at 15:39, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> This is the v11 version of the KASan patches for ARM.
>
> The main changes from the v10 version is:
>
> - LPAE now compiles and works again, at least Versatile Express
>   Cortex A15 TC1 in QEMU (which is the LPAE system I have
>   access to).
>
> - Rewrite some of the page directory initialization after
>   helpful feedback from Mike Rapoport and Russell King.
>
> Also minor improvements to commit messages and comments
> in the code so it is clear (for most cases I hope) why
> some ifdefs etc are there.
>
> All tested platforms from ARMv4 thru ARMv7 work fine. I
> have not been able to re-test with the Qualcomm DragonBoard
> APQ8060 yet, but I suspect the problem there is that the
> DT parser code reaches out into non-kernel memory and
> needs some de-instrumentation, possibly combined with the
> memory holding the device tree getting corrupted or reused
> before we have a chance to parse it.
>
> Abbott Liu (1):
>   ARM: Define the virtual space of KASan's shadow region
>
> Andrey Ryabinin (3):
>   ARM: Disable KASan instrumentation for some code
>   ARM: Replace string mem* functions for KASan
>   ARM: Enable KASan for ARM
>
> Linus Walleij (1):
>   ARM: Initialize the mapping of KASan shadow memory
>

Hi,

I needed the changes below to make this work on a 16 core GICv3
QEMU/KVM vm with 8 GB of RAM

Without masking start, I get a strange error where kasan_alloc_block()
runs out of memory, probably because one of the do..while stop
conditions fails to trigger and we loop until we run out of lowmem.

The TLB flush is really essential to make any of these page table
modifications take effect right away, and strange things can happen if
you don't. I also saw a crash in the DT unflatten code without this
change, but that is probably because it is simply the code that runs
immediately after.

If you see anything like

Unable to handle kernel paging request at virtual address b744077c
[b744077c] *pgd=80000040206003, *pmd=6abf5003, *pte=c000006abb471f

where the CPU faults on an address that appears to have a valid
mapping at each level, it means that the page table walker was using a
stale TLB entry to do the translation, triggered a fault and when we
look at the page tables in software, everything looks like it is
supposed to.




diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
index 535dce42e59d..b457922f8a48 100644
--- a/arch/arm/mm/kasan_init.c
+++ b/arch/arm/mm/kasan_init.c
@@ -209,7 +209,7 @@ static int __init create_mapping(unsigned long
start, unsigned long end,
                                int node)
 {
        pr_info("populating shadow for %lx, %lx\n", start, end);
-       kasan_pgd_populate(start, end, NUMA_NO_NODE, false);
+       kasan_pgd_populate(start & PAGE_MASK, end, NUMA_NO_NODE, false);
        return 0;
 }

@@ -281,6 +281,7 @@ void __init kasan_init(void)
                        pfn_pte(virt_to_pfn(kasan_early_shadow_page),
                                __pgprot(pgprot_val(PAGE_KERNEL)
                                        | L_PTE_RDONLY)));
+       local_flush_tlb_all();
        memset(kasan_early_shadow_page, 0, PAGE_SIZE);
        cpu_switch_mm(swapper_pg_dir, &init_mm);
        pr_info("Kernel address sanitizer initialized\n");



>  Documentation/arm/memory.rst                  |   5 +
>  Documentation/dev-tools/kasan.rst             |   4 +-
>  .../features/debug/KASAN/arch-support.txt     |   2 +-
>  arch/arm/Kconfig                              |  10 +
>  arch/arm/boot/compressed/Makefile             |   1 +
>  arch/arm/boot/compressed/string.c             |  19 ++
>  arch/arm/include/asm/kasan.h                  |  32 ++
>  arch/arm/include/asm/kasan_def.h              |  81 +++++
>  arch/arm/include/asm/memory.h                 |   5 +
>  arch/arm/include/asm/pgalloc.h                |   8 +-
>  arch/arm/include/asm/string.h                 |  21 ++
>  arch/arm/include/asm/thread_info.h            |   8 +
>  arch/arm/include/asm/uaccess-asm.h            |   2 +-
>  arch/arm/kernel/entry-armv.S                  |   3 +-
>  arch/arm/kernel/entry-common.S                |   9 +-
>  arch/arm/kernel/head-common.S                 |   7 +-
>  arch/arm/kernel/setup.c                       |   2 +
>  arch/arm/kernel/unwind.c                      |   6 +-
>  arch/arm/lib/memcpy.S                         |   3 +
>  arch/arm/lib/memmove.S                        |   5 +-
>  arch/arm/lib/memset.S                         |   3 +
>  arch/arm/mm/Makefile                          |   5 +
>  arch/arm/mm/kasan_init.c                      | 288 ++++++++++++++++++
>  arch/arm/mm/mmu.c                             |  18 ++
>  arch/arm/mm/pgd.c                             |  16 +-
>  arch/arm/vdso/Makefile                        |   2 +
>  26 files changed, 551 insertions(+), 14 deletions(-)
>  create mode 100644 arch/arm/include/asm/kasan.h
>  create mode 100644 arch/arm/include/asm/kasan_def.h
>  create mode 100644 arch/arm/mm/kasan_init.c
>
> --
> 2.25.4
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/5 v11] KASan for Arm

[Florian Fainelli]

On 6/30/2020 2:41 PM, Ard Biesheuvel wrote:
> On Tue, 30 Jun 2020 at 15:39, Linus Walleij <linus.walleij@linaro.org> wrote:
>>
>> This is the v11 version of the KASan patches for ARM.
>>
>> The main changes from the v10 version is:
>>
>> - LPAE now compiles and works again, at least Versatile Express
>>   Cortex A15 TC1 in QEMU (which is the LPAE system I have
>>   access to).
>>
>> - Rewrite some of the page directory initialization after
>>   helpful feedback from Mike Rapoport and Russell King.
>>
>> Also minor improvements to commit messages and comments
>> in the code so it is clear (for most cases I hope) why
>> some ifdefs etc are there.
>>
>> All tested platforms from ARMv4 thru ARMv7 work fine. I
>> have not been able to re-test with the Qualcomm DragonBoard
>> APQ8060 yet, but I suspect the problem there is that the
>> DT parser code reaches out into non-kernel memory and
>> needs some de-instrumentation, possibly combined with the
>> memory holding the device tree getting corrupted or reused
>> before we have a chance to parse it.
>>
>> Abbott Liu (1):
>>   ARM: Define the virtual space of KASan's shadow region
>>
>> Andrey Ryabinin (3):
>>   ARM: Disable KASan instrumentation for some code
>>   ARM: Replace string mem* functions for KASan
>>   ARM: Enable KASan for ARM
>>
>> Linus Walleij (1):
>>   ARM: Initialize the mapping of KASan shadow memory
>>
> 
> Hi,
> 
> I needed the changes below to make this work on a 16 core GICv3
> QEMU/KVM vm with 8 GB of RAM
> 
> Without masking start, I get a strange error where kasan_alloc_block()
> runs out of memory, probably because one of the do..while stop
> conditions fails to trigger and we loop until we run out of lowmem.
> 
> The TLB flush is really essential to make any of these page table
> modifications take effect right away, and strange things can happen if
> you don't. I also saw a crash in the DT unflatten code without this
> change, but that is probably because it is simply the code that runs
> immediately after.
> 
> If you see anything like
> 
> Unable to handle kernel paging request at virtual address b744077c
> [b744077c] *pgd=80000040206003, *pmd=6abf5003, *pte=c000006abb471f
> 
> where the CPU faults on an address that appears to have a valid
> mapping at each level, it means that the page table walker was using a
> stale TLB entry to do the translation, triggered a fault and when we
> look at the page tables in software, everything looks like it is
> supposed to.

Thanks Ard, this allows me to boot successfully to a prompt on a BCM7278
system whereas we would have an error before while unflattening the DT.

Now there are still other systems that fail booting with the error log
attached previously, but it is not clear yet to me why this is happening
as it does not seem to depend on the memory ranges only as I initially
thought.
--
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/5 v11] KASan for Arm

[Ard Biesheuvel]

On Wed, 1 Jul 2020 at 06:53, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>
>
> On 6/30/2020 2:41 PM, Ard Biesheuvel wrote:
> > On Tue, 30 Jun 2020 at 15:39, Linus Walleij <linus.walleij@linaro.org> wrote:
> >>
> >> This is the v11 version of the KASan patches for ARM.
> >>
> >> The main changes from the v10 version is:
> >>
> >> - LPAE now compiles and works again, at least Versatile Express
> >>   Cortex A15 TC1 in QEMU (which is the LPAE system I have
> >>   access to).
> >>
> >> - Rewrite some of the page directory initialization after
> >>   helpful feedback from Mike Rapoport and Russell King.
> >>
> >> Also minor improvements to commit messages and comments
> >> in the code so it is clear (for most cases I hope) why
> >> some ifdefs etc are there.
> >>
> >> All tested platforms from ARMv4 thru ARMv7 work fine. I
> >> have not been able to re-test with the Qualcomm DragonBoard
> >> APQ8060 yet, but I suspect the problem there is that the
> >> DT parser code reaches out into non-kernel memory and
> >> needs some de-instrumentation, possibly combined with the
> >> memory holding the device tree getting corrupted or reused
> >> before we have a chance to parse it.
> >>
> >> Abbott Liu (1):
> >>   ARM: Define the virtual space of KASan's shadow region
> >>
> >> Andrey Ryabinin (3):
> >>   ARM: Disable KASan instrumentation for some code
> >>   ARM: Replace string mem* functions for KASan
> >>   ARM: Enable KASan for ARM
> >>
> >> Linus Walleij (1):
> >>   ARM: Initialize the mapping of KASan shadow memory
> >>
> >
> > Hi,
> >
> > I needed the changes below to make this work on a 16 core GICv3
> > QEMU/KVM vm with 8 GB of RAM
> >
> > Without masking start, I get a strange error where kasan_alloc_block()
> > runs out of memory, probably because one of the do..while stop
> > conditions fails to trigger and we loop until we run out of lowmem.
> >
> > The TLB flush is really essential to make any of these page table
> > modifications take effect right away, and strange things can happen if
> > you don't. I also saw a crash in the DT unflatten code without this
> > change, but that is probably because it is simply the code that runs
> > immediately after.
> >
> > If you see anything like
> >
> > Unable to handle kernel paging request at virtual address b744077c
> > [b744077c] *pgd=80000040206003, *pmd=6abf5003, *pte=c000006abb471f
> >
> > where the CPU faults on an address that appears to have a valid
> > mapping at each level, it means that the page table walker was using a
> > stale TLB entry to do the translation, triggered a fault and when we
> > look at the page tables in software, everything looks like it is
> > supposed to.
>
> Thanks Ard, this allows me to boot successfully to a prompt on a BCM7278
> system whereas we would have an error before while unflattening the DT.
>
> Now there are still other systems that fail booting with the error log
> attached previously, but it is not clear yet to me why this is happening
> as it does not seem to depend on the memory ranges only as I initially
> thought.

It seems to me that for LPAE, we are not copying enough of the level 2
early shadow tables: a level 2 table covers 512 MB, which is exactly
the size of the KASAN shadow region for a 4 GB address space. However,
the shadow region is not 512 MB aligned, and so the early shadow
necessarily covers two level 2 tables. Could you try the following
please?

diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
index 535dce42e59d..3c9c37a59b57 100644
--- a/arch/arm/mm/kasan_init.c
+++ b/arch/arm/mm/kasan_init.c
@@ -27,7 +27,7 @@

 static pgd_t tmp_pgd_table[PTRS_PER_PGD] __initdata __aligned(PGD_SIZE);

-pmd_t tmp_pmd_table[PTRS_PER_PMD] __page_aligned_bss;
+static pmd_t tmp_pmd_table[2][PTRS_PER_PMD] __page_aligned_bss;

 static __init void *kasan_alloc_block(size_t size, int node)
 {
@@ -231,13 +231,15 @@ void __init kasan_init(void)
         * to the proper swapper_pg_dir.
         */
        memcpy(tmp_pgd_table, swapper_pg_dir, sizeof(tmp_pgd_table));
-#ifdef CONFIG_ARM_LPAE
-       memcpy(tmp_pmd_table,
-              pgd_page_vaddr(*pgd_offset_k(KASAN_SHADOW_START)),
-              sizeof(tmp_pmd_table));
-       set_pgd(&tmp_pgd_table[pgd_index(KASAN_SHADOW_START)],
-               __pgd(__pa(tmp_pmd_table) | PMD_TYPE_TABLE | L_PGD_SWAPPER));
-#endif
+       if (IS_ENABLED(CONFIG_ARM_LPAE)) {
+               memcpy(tmp_pmd_table,
+                      pgd_page_vaddr(*pgd_offset_k(KASAN_SHADOW_START)),
+                      sizeof(tmp_pmd_table));
+               set_pgd(&tmp_pgd_table[pgd_index(KASAN_SHADOW_START)],
+                       __pgd(__pa(&tmp_pmd_table[0]) | PMD_TYPE_TABLE
| L_PGD_SWAPPER));
+               set_pgd(&tmp_pgd_table[pgd_index(KASAN_SHADOW_START) + 1],
+                       __pgd(__pa(&tmp_pmd_table[1]) | PMD_TYPE_TABLE
| L_PGD_SWAPPER));
+       }
        cpu_switch_mm(tmp_pgd_table, &init_mm);
        clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/5 v11] KASan for Arm

[Ard Biesheuvel]

On Wed, 1 Jul 2020 at 09:43, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Wed, 1 Jul 2020 at 06:53, Florian Fainelli <f.fainelli@gmail.com> wrote:
> >
> >
> >
> > On 6/30/2020 2:41 PM, Ard Biesheuvel wrote:
> > > On Tue, 30 Jun 2020 at 15:39, Linus Walleij <linus.walleij@linaro.org> wrote:
> > >>
> > >> This is the v11 version of the KASan patches for ARM.
> > >>
> > >> The main changes from the v10 version is:
> > >>
> > >> - LPAE now compiles and works again, at least Versatile Express
> > >>   Cortex A15 TC1 in QEMU (which is the LPAE system I have
> > >>   access to).
> > >>
> > >> - Rewrite some of the page directory initialization after
> > >>   helpful feedback from Mike Rapoport and Russell King.
> > >>
> > >> Also minor improvements to commit messages and comments
> > >> in the code so it is clear (for most cases I hope) why
> > >> some ifdefs etc are there.
> > >>
> > >> All tested platforms from ARMv4 thru ARMv7 work fine. I
> > >> have not been able to re-test with the Qualcomm DragonBoard
> > >> APQ8060 yet, but I suspect the problem there is that the
> > >> DT parser code reaches out into non-kernel memory and
> > >> needs some de-instrumentation, possibly combined with the
> > >> memory holding the device tree getting corrupted or reused
> > >> before we have a chance to parse it.
> > >>
> > >> Abbott Liu (1):
> > >>   ARM: Define the virtual space of KASan's shadow region
> > >>
> > >> Andrey Ryabinin (3):
> > >>   ARM: Disable KASan instrumentation for some code
> > >>   ARM: Replace string mem* functions for KASan
> > >>   ARM: Enable KASan for ARM
> > >>
> > >> Linus Walleij (1):
> > >>   ARM: Initialize the mapping of KASan shadow memory
> > >>
> > >
> > > Hi,
> > >
> > > I needed the changes below to make this work on a 16 core GICv3
> > > QEMU/KVM vm with 8 GB of RAM
> > >
> > > Without masking start, I get a strange error where kasan_alloc_block()
> > > runs out of memory, probably because one of the do..while stop
> > > conditions fails to trigger and we loop until we run out of lowmem.
> > >
> > > The TLB flush is really essential to make any of these page table
> > > modifications take effect right away, and strange things can happen if
> > > you don't. I also saw a crash in the DT unflatten code without this
> > > change, but that is probably because it is simply the code that runs
> > > immediately after.
> > >
> > > If you see anything like
> > >
> > > Unable to handle kernel paging request at virtual address b744077c
> > > [b744077c] *pgd=80000040206003, *pmd=6abf5003, *pte=c000006abb471f
> > >
> > > where the CPU faults on an address that appears to have a valid
> > > mapping at each level, it means that the page table walker was using a
> > > stale TLB entry to do the translation, triggered a fault and when we
> > > look at the page tables in software, everything looks like it is
> > > supposed to.
> >
> > Thanks Ard, this allows me to boot successfully to a prompt on a BCM7278
> > system whereas we would have an error before while unflattening the DT.
> >
> > Now there are still other systems that fail booting with the error log
> > attached previously, but it is not clear yet to me why this is happening
> > as it does not seem to depend on the memory ranges only as I initially
> > thought.
>
> It seems to me that for LPAE, we are not copying enough of the level 2
> early shadow tables: a level 2 table covers 512 MB, which is exactly
> the size of the KASAN shadow region for a 4 GB address space. However,
> the shadow region is not 512 MB aligned, and so the early shadow
> necessarily covers two level 2 tables. Could you try the following
> please?
>
> diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
> index 535dce42e59d..3c9c37a59b57 100644
> --- a/arch/arm/mm/kasan_init.c
> +++ b/arch/arm/mm/kasan_init.c
> @@ -27,7 +27,7 @@
>
>  static pgd_t tmp_pgd_table[PTRS_PER_PGD] __initdata __aligned(PGD_SIZE);
>
> -pmd_t tmp_pmd_table[PTRS_PER_PMD] __page_aligned_bss;
> +static pmd_t tmp_pmd_table[2][PTRS_PER_PMD] __page_aligned_bss;
>
>  static __init void *kasan_alloc_block(size_t size, int node)
>  {
> @@ -231,13 +231,15 @@ void __init kasan_init(void)
>          * to the proper swapper_pg_dir.
>          */
>         memcpy(tmp_pgd_table, swapper_pg_dir, sizeof(tmp_pgd_table));
> -#ifdef CONFIG_ARM_LPAE
> -       memcpy(tmp_pmd_table,
> -              pgd_page_vaddr(*pgd_offset_k(KASAN_SHADOW_START)),
> -              sizeof(tmp_pmd_table));
> -       set_pgd(&tmp_pgd_table[pgd_index(KASAN_SHADOW_START)],
> -               __pgd(__pa(tmp_pmd_table) | PMD_TYPE_TABLE | L_PGD_SWAPPER));
> -#endif
> +       if (IS_ENABLED(CONFIG_ARM_LPAE)) {
> +               memcpy(tmp_pmd_table,
> +                      pgd_page_vaddr(*pgd_offset_k(KASAN_SHADOW_START)),
> +                      sizeof(tmp_pmd_table));
> +               set_pgd(&tmp_pgd_table[pgd_index(KASAN_SHADOW_START)],
> +                       __pgd(__pa(&tmp_pmd_table[0]) | PMD_TYPE_TABLE
> | L_PGD_SWAPPER));
> +               set_pgd(&tmp_pgd_table[pgd_index(KASAN_SHADOW_START) + 1],
> +                       __pgd(__pa(&tmp_pmd_table[1]) | PMD_TYPE_TABLE
> | L_PGD_SWAPPER));
> +       }
>         cpu_switch_mm(tmp_pgd_table, &init_mm);
>         clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);

Hum maybe not. KASAN_SHADOW_START != KASAN_SHADOW_OFFSET in this case,
and AIUI, the kernel's KASAN shadow region is [b6e00000, bf000000),
which falls entirely inside a naturally aligned 512 MB region. IOW,
pgd_index(KASAN_SHADOW_START) == pgd_index(KASAN_SHADOW_END), and we
should probably add a build_bug_on() there to ensure that this remains
the case.

However, your crash log does suggest that no early shadow mapping
exists for address 0xecff0000 (shadowed at 0xbc9ffe00), and I suspect
that the clear_pgds() call is implicated in this, but I am not sure
how exactly.

In any case, I found another issue:

[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000040000000-0x00000000ffab1fff]
[    0.000000]   node   0: [mem 0x00000000ffab2000-0x00000000ffc73fff]
[    0.000000]   node   0: [mem 0x00000000ffc74000-0x00000000ffffffff]
...
[    0.000000] kasan: populating shadow for b7000000, bd000000
[    0.000000] kasan: populating shadow for aef56400, bd000000
[    0.000000] kasan: populating shadow for aef8e800, bd000000
[    0.000000] kasan: populating shadow for b6f00000, b7000000

i.e., the two highmem ranges are not disregarded as they should, due
to the bogus __va() translations and the truncation by the (void *)
casts.


Fix below:

diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
index 535dce42e59d..d8b2b93cfee5 100644
--- a/arch/arm/mm/kasan_init.c
+++ b/arch/arm/mm/kasan_init.c
@@ -248,10 +248,12 @@ void __init kasan_init(void)
                void *start = __va(reg->base);
                void *end = __va(reg->base + reg->size);

+               if (reg->base > arm_lowmem_limit)
+                       continue;
                if (reg->base + reg->size > arm_lowmem_limit)
                        end = __va(arm_lowmem_limit);
                if (start >= end)
-                       break;
+                       continue;

                create_mapping((unsigned long)kasan_mem_to_shadow(start),
                        (unsigned long)kasan_mem_to_shadow(end),

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/5 v11] KASan for Arm

[Ard Biesheuvel]

On Wed, 1 Jul 2020 at 10:32, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Wed, 1 Jul 2020 at 09:43, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Wed, 1 Jul 2020 at 06:53, Florian Fainelli <f.fainelli@gmail.com> wrote:
> > >
> > >
> > >
> > > On 6/30/2020 2:41 PM, Ard Biesheuvel wrote:
> > > > On Tue, 30 Jun 2020 at 15:39, Linus Walleij <linus.walleij@linaro.org> wrote:
> > > >>
> > > >> This is the v11 version of the KASan patches for ARM.
> > > >>
> > > >> The main changes from the v10 version is:
> > > >>
> > > >> - LPAE now compiles and works again, at least Versatile Express
> > > >>   Cortex A15 TC1 in QEMU (which is the LPAE system I have
> > > >>   access to).
> > > >>
> > > >> - Rewrite some of the page directory initialization after
> > > >>   helpful feedback from Mike Rapoport and Russell King.
> > > >>
> > > >> Also minor improvements to commit messages and comments
> > > >> in the code so it is clear (for most cases I hope) why
> > > >> some ifdefs etc are there.
> > > >>
> > > >> All tested platforms from ARMv4 thru ARMv7 work fine. I
> > > >> have not been able to re-test with the Qualcomm DragonBoard
> > > >> APQ8060 yet, but I suspect the problem there is that the
> > > >> DT parser code reaches out into non-kernel memory and
> > > >> needs some de-instrumentation, possibly combined with the
> > > >> memory holding the device tree getting corrupted or reused
> > > >> before we have a chance to parse it.
> > > >>
> > > >> Abbott Liu (1):
> > > >>   ARM: Define the virtual space of KASan's shadow region
> > > >>
> > > >> Andrey Ryabinin (3):
> > > >>   ARM: Disable KASan instrumentation for some code
> > > >>   ARM: Replace string mem* functions for KASan
> > > >>   ARM: Enable KASan for ARM
> > > >>
> > > >> Linus Walleij (1):
> > > >>   ARM: Initialize the mapping of KASan shadow memory
> > > >>
> > > >
> > > > Hi,
> > > >
> > > > I needed the changes below to make this work on a 16 core GICv3
> > > > QEMU/KVM vm with 8 GB of RAM
> > > >
> > > > Without masking start, I get a strange error where kasan_alloc_block()
> > > > runs out of memory, probably because one of the do..while stop
> > > > conditions fails to trigger and we loop until we run out of lowmem.
> > > >
> > > > The TLB flush is really essential to make any of these page table
> > > > modifications take effect right away, and strange things can happen if
> > > > you don't. I also saw a crash in the DT unflatten code without this
> > > > change, but that is probably because it is simply the code that runs
> > > > immediately after.
> > > >
> > > > If you see anything like
> > > >
> > > > Unable to handle kernel paging request at virtual address b744077c
> > > > [b744077c] *pgd=80000040206003, *pmd=6abf5003, *pte=c000006abb471f
> > > >
> > > > where the CPU faults on an address that appears to have a valid
> > > > mapping at each level, it means that the page table walker was using a
> > > > stale TLB entry to do the translation, triggered a fault and when we
> > > > look at the page tables in software, everything looks like it is
> > > > supposed to.
> > >
> > > Thanks Ard, this allows me to boot successfully to a prompt on a BCM7278
> > > system whereas we would have an error before while unflattening the DT.
> > >
> > > Now there are still other systems that fail booting with the error log
> > > attached previously, but it is not clear yet to me why this is happening
> > > as it does not seem to depend on the memory ranges only as I initially
> > > thought.
> >
> > It seems to me that for LPAE, we are not copying enough of the level 2
> > early shadow tables: a level 2 table covers 512 MB, which is exactly
> > the size of the KASAN shadow region for a 4 GB address space. However,
> > the shadow region is not 512 MB aligned, and so the early shadow
> > necessarily covers two level 2 tables. Could you try the following
> > please?
> >
> > diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
> > index 535dce42e59d..3c9c37a59b57 100644
> > --- a/arch/arm/mm/kasan_init.c
> > +++ b/arch/arm/mm/kasan_init.c
> > @@ -27,7 +27,7 @@
> >
> >  static pgd_t tmp_pgd_table[PTRS_PER_PGD] __initdata __aligned(PGD_SIZE);
> >
> > -pmd_t tmp_pmd_table[PTRS_PER_PMD] __page_aligned_bss;
> > +static pmd_t tmp_pmd_table[2][PTRS_PER_PMD] __page_aligned_bss;
> >
> >  static __init void *kasan_alloc_block(size_t size, int node)
> >  {
> > @@ -231,13 +231,15 @@ void __init kasan_init(void)
> >          * to the proper swapper_pg_dir.
> >          */
> >         memcpy(tmp_pgd_table, swapper_pg_dir, sizeof(tmp_pgd_table));
> > -#ifdef CONFIG_ARM_LPAE
> > -       memcpy(tmp_pmd_table,
> > -              pgd_page_vaddr(*pgd_offset_k(KASAN_SHADOW_START)),
> > -              sizeof(tmp_pmd_table));
> > -       set_pgd(&tmp_pgd_table[pgd_index(KASAN_SHADOW_START)],
> > -               __pgd(__pa(tmp_pmd_table) | PMD_TYPE_TABLE | L_PGD_SWAPPER));
> > -#endif
> > +       if (IS_ENABLED(CONFIG_ARM_LPAE)) {
> > +               memcpy(tmp_pmd_table,
> > +                      pgd_page_vaddr(*pgd_offset_k(KASAN_SHADOW_START)),
> > +                      sizeof(tmp_pmd_table));
> > +               set_pgd(&tmp_pgd_table[pgd_index(KASAN_SHADOW_START)],
> > +                       __pgd(__pa(&tmp_pmd_table[0]) | PMD_TYPE_TABLE
> > | L_PGD_SWAPPER));
> > +               set_pgd(&tmp_pgd_table[pgd_index(KASAN_SHADOW_START) + 1],
> > +                       __pgd(__pa(&tmp_pmd_table[1]) | PMD_TYPE_TABLE
> > | L_PGD_SWAPPER));
> > +       }
> >         cpu_switch_mm(tmp_pgd_table, &init_mm);
> >         clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);
>
> Hum maybe not. KASAN_SHADOW_START != KASAN_SHADOW_OFFSET in this case,
> and AIUI, the kernel's KASAN shadow region is [b6e00000, bf000000),
> which falls entirely inside a naturally aligned 512 MB region. IOW,
> pgd_index(KASAN_SHADOW_START) == pgd_index(KASAN_SHADOW_END), and we
> should probably add a build_bug_on() there to ensure that this remains
> the case.
>
> However, your crash log does suggest that no early shadow mapping
> exists for address 0xecff0000 (shadowed at 0xbc9ffe00), and I suspect
> that the clear_pgds() call is implicated in this, but I am not sure
> how exactly.
>
> In any case, I found another issue:
>
> [    0.000000] Early memory node ranges
> [    0.000000]   node   0: [mem 0x0000000040000000-0x00000000ffab1fff]
> [    0.000000]   node   0: [mem 0x00000000ffab2000-0x00000000ffc73fff]
> [    0.000000]   node   0: [mem 0x00000000ffc74000-0x00000000ffffffff]
> ...
> [    0.000000] kasan: populating shadow for b7000000, bd000000
> [    0.000000] kasan: populating shadow for aef56400, bd000000
> [    0.000000] kasan: populating shadow for aef8e800, bd000000
> [    0.000000] kasan: populating shadow for b6f00000, b7000000
>
> i.e., the two highmem ranges are not disregarded as they should, due
> to the bogus __va() translations and the truncation by the (void *)
> casts.
>
>
> Fix below:


I pushed these changes and a few more to

https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-kasan-v11

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/5 v11] KASan for Arm

[Florian Fainelli]

[-- Attachment #1: Type: text/plain, Size: 330 bytes --]



On 7/1/2020 5:09 AM, Ard Biesheuvel wrote:
> 
> I pushed these changes and a few more to
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-kasan-v11

This branch works a bit better however I am still seeing some boot
errors (some sample logs attached) similar to Linus' branch.

Thanks!
-- 
Florian

[-- Attachment #2: 7250-bselinux-rack-20.log --]
[-- Type: text/plain, Size: 7780 bytes --]

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.8.0-rc3-gd06ab87ec507 (fainelli@fainelli-desktop) (arm-linux-gcc (GCC) 8.3.0, GNU ld (GNU Binutils) 2.32) #4 SMP Wed Jul 1 13:02:00 PDT 2020
[    0.000000] CPU: ARMv7 Processor [420f00f3] revision 3 (ARMv7), cr=30c5387d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] OF: fdt: Machine model: BCM97250SV
[    0.000000] earlycon: ns16550a0 at MMIO32 0x00000000f040b400 (options '115200')
[    0.000000] printk: bootconsole [ns16550a0] enabled
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] cma: Reserved 16 MiB at 0x000000003cc00000
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000000000-0x000000002fffffff]
[    0.000000]   Normal   empty
[    0.000000]   HighMem  [mem 0x0000000030000000-0x000000003dffefff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x000000003dffefff]
[    0.000000] Zeroed struct page in unavailable ranges: 1 pages
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000003dffefff]
[    0.000000] kasan: populating shadow for b7000000, bd000000
[    0.000000] 8<--- cut here ---
[    0.000000] Unable to handle kernel paging request at virtual address bcdffe00
[    0.000000] pgd = (ptrval)
[    0.000000] [bcdffe00] *pgd=80000000006003, *pmd=00000000
[    0.000000] Internal error: Oops: 206 [#1] SMP ARM
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.8.0-rc3-gd06ab87ec507 #4
[    0.000000] Hardware name: Broadcom STB (Flattened Device Tree)
[    0.000000] PC is at check_memory_region+0x54/0x1c8
[    0.000000] LR is at 0x40
[    0.000000] pc : [<c044f528>]    lr : [<00000040>]    psr: 600000d3
[    0.000000] sp : c2603b80  ip : bcdffe00  fp : c2603bac
[    0.000000] r10: 00000000  r9 : 00001000  r8 : bce00000
[    0.000000] r7 : bcdfffff  r6 : eeffffff  r5 : eefff000  r4 : 00000000
[    0.000000] r3 : c181f114  r2 : 00000001  r1 : 00001000  r0 : eefff000
[    0.000000] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment user
[    0.000000] Control: 30c5387d  Table: 01877100  DAC: fffffffd
[    0.000000] Process swapper (pid: 0, stack limit = 0x(ptrval))
[    0.000000] Stack: (0xc2603b80 to 0xc2604000)
[    0.000000] 3b80: c181f114 00001000 eefff000 00000000 00000000 c2606d48 00001000 00000000
[    0.000000] 3ba0: c2603bcc c2603bb0 c044d32c c044f4e0 b74c0780 00000000 eefff000 00000000
[    0.000000] 3bc0: c2603cd4 c2603bd0 c181f114 c044d310 3fffffff 00000000 00000001 00000000
[    0.000000] 3be0: ffffffff 00000000 00000019 00000000 00000019 00000000 c2970ce0 c2970ce0
[    0.000000] 3c00: 41b58ab3 c1672d28 c181efdc 00000001 600000d3 0000002f c2603c6c c2603c28
[    0.000000] 3c20: 3fffffff 00000000 c165c838 c2603d54 00000001 00000001 00000018 00000000
[    0.000000] 3c40: 00000000 c250d3ec 00000000 c165c838 c2603d54 00000000 b7000000 c18750d8
[    0.000000] 3c60: 00000001 00000000 c02b2e58 c02b2ba4 c165c838 c2603d54 c2603cb4 c2603c88
[    0.000000] 3c80: c02b447c c02b2e34 c2603cd4 c2603c98 c10ae5a4 b74c0798 c2606d48 c2994d58
[    0.000000] 3ca0: fffff000 00000000 c2603d4c 00000001 00000000 b7600000 ef474fa0 c0006dd8
[    0.000000] 3cc0: c16d1084 b75f4000 c2603d04 c2603cd8 c180d608 c181efe8 3fffffff 00000000
[    0.000000] 3ce0: 00000001 00000000 ffffffff beffffff 2f00071f c296c4d8 c2603d5c c2603d08
[    0.000000] 3d00: c180d7a0 c180d590 2f00071f 00c00000 c2603d5c bd000000 c26a2ee0 0000296a
[    0.000000] 3d20: c260a284 c0003010 00000000 bd000000 c180b40c c16d1084 c26a3140 c2994d58
[    0.000000] 3d40: fffff000 3dfff000 b7000000 c18750d8 c2603dac c2603d60 c180db04 c180d61c
[    0.000000] 3d60: 00000000 00000000 c1809028 bd000000 c165c838 c16d1000 3dfff000 00000000
[    0.000000] 3d80: c2603dac c26a2ee0 c2dd0b80 c1873a48 c0008000 e12fff1e c02269e8 c1861a70
[    0.000000] 3da0: c2603ee4 c2603db0 c1805d38 c180d8f8 0000006c 30c5387d 00000001 00000001
[    0.000000] 3dc0: 00000001 00000000 c02b2e58 c16d1084 c187702c 184c07c0 c2603edc 00000000
[    0.000000] 3de0: 420f00f3 30c5387d c2603e0c c2603df8 c2603f40 c2603ea0 c1200740 c2603edc
[    0.000000] 3e00: 41b58ab3 c165ac04 c180550c c02b2e34 c02b3a10 c02b43f0 00000000 b74c07cc
[    0.000000] 3e20: c2606d48 c2606d40 c2606d48 c296b440 c2603ed4 c2603e40 c02b3a10 c02b43f0
[    0.000000] 3e40: c2603eb4 00000000 c2603e74 c2603e58 c2603e74 c2603e60 c0299010 c044f034
[    0.000000] 3e60: 41b58ab3 c165d1c4 c02b3980 c2603e78 c031dc2c c044f034 00000000 c2665ff8
[    0.000000] 3e80: c2603edc c2665ea0 c1877270 c266606c c2665eb0 0781a000 c29915c0 0000007b
[    0.000000] 3ea0: 00000000 c2606d48 c2603ec4 c2603eb8 c044f094 00000000 c2603ee4 b74c07e4
[    0.000000] 3ec0: c2603fc0 c2606d40 c2606d48 c296b440 420f00f3 30c5387d c2603ff4 c2603ee8
[    0.000000] 3ee0: c1800e1c c1805518 00000000 00000000 00000000 00000000 00000000 00000000
[    0.000000] 3f00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    0.000000] 3f20: 41b58ab3 c1659ce4 c1800d40 00000000 00000000 00000000 00000000 00000000
[    0.000000] 3f40: c1873a48 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    0.000000] 3f60: 00000000 00000000 00000000 c180d840 00000000 00000000 0296a403 c296c4d8
[    0.000000] 3f80: c2603fe4 c2603f90 c180d840 c0223c5c 0296a403 00c00000 00000000 bf000000
[    0.000000] 3fa0: c26a2ee0 0000296a c260a284 c0003010 00000001 bf000000 00000000 c1800334
[    0.000000] 3fc0: 00000000 00000000 ffffffff c1800334 00000000 30c0387d ffffffff 0781a000
[    0.000000] 3fe0: 420f00f3 30c5387d 00000000 c2603ff8 00000000 c1800d4c 00000000 00000000
[    0.000000] Backtrace: 
[    0.000000] [<c044f4d4>] (check_memory_region) from [<c044d32c>] (memset+0x28/0x44)
[    0.000000]  r10:00000000 r9:00001000 r8:c2606d48 r7:00000000 r6:00000000 r5:eefff000
[    0.000000]  r4:00001000 r3:c181f114
[    0.000000] [<c044d304>] (memset) from [<c181f114>] (memblock_alloc_try_nid+0x138/0x170)
[    0.000000]  r7:00000000 r6:eefff000 r5:00000000 r4:b74c0780
[    0.000000] [<c181efdc>] (memblock_alloc_try_nid) from [<c180d608>] (kasan_alloc_block.constprop.5+0x84/0x8c)
[    0.000000]  r10:b75f4000 r9:c16d1084 r8:c0006dd8 r7:ef474fa0 r6:b7600000 r5:00000000
[    0.000000]  r4:00000001
[    0.000000] [<c180d584>] (kasan_alloc_block.constprop.5) from [<c180d7a0>] (kasan_pgd_populate.constprop.2+0x190/0x274)
[    0.000000]  r5:c296c4d8 r4:2f00071f
[    0.000000] [<c180d610>] (kasan_pgd_populate.constprop.2) from [<c180db04>] (kasan_init+0x218/0x354)
[    0.000000]  r10:c18750d8 r9:b7000000 r8:3dfff000 r7:fffff000 r6:c2994d58 r5:c26a3140
[    0.000000]  r4:c16d1084
[    0.000000] [<c180d8ec>] (kasan_init) from [<c1805d38>] (setup_arch+0x82c/0x1000)
[    0.000000]  r10:c1861a70 r9:c02269e8 r8:e12fff1e r7:c0008000 r6:c1873a48 r5:c2dd0b80
[    0.000000]  r4:c26a2ee0
[    0.000000] [<c180550c>] (setup_arch) from [<c1800e1c>] (start_kernel+0xdc/0x6d0)
[    0.000000]  r10:30c5387d r9:420f00f3 r8:c296b440 r7:c2606d48 r6:c2606d40 r5:c2603fc0
[    0.000000]  r4:b74c07e4
[    0.000000] [<c1800d40>] (start_kernel) from [<00000000>] (0x0)
[    0.000000]  r10:30c5387d r9:420f00f3 r8:0781a000 r7:ffffffff r6:30c0387d r5:00000000
[    0.000000]  r4:c1800334
[    0.000000] Code: da00001a e21c4007 1a000028 e1a0e1ce (e1cc40d0) 
[    0.000000] random: get_random_bytes called from print_oops_end_marker+0x30/0x5c with crng_init=0
[    0.000000] ---[ end trace b55bf0586ef7ce68 ]---
[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[    0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---

[-- Attachment #3: 7364-bselinux-rack-17.log --]
[-- Type: text/plain, Size: 7780 bytes --]

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.8.0-rc3-gd06ab87ec507 (fainelli@fainelli-desktop) (arm-linux-gcc (GCC) 8.3.0, GNU ld (GNU Binutils) 2.32) #4 SMP Wed Jul 1 13:02:00 PDT 2020
[    0.000000] CPU: ARMv7 Processor [420f00f3] revision 3 (ARMv7), cr=30c5387d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] OF: fdt: Machine model: BCM97364SV
[    0.000000] earlycon: ns16550a0 at MMIO32 0x00000000f040b000 (options '115200')
[    0.000000] printk: bootconsole [ns16550a0] enabled
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] cma: Reserved 16 MiB at 0x000000003cc00000
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000000000-0x000000002fffffff]
[    0.000000]   Normal   empty
[    0.000000]   HighMem  [mem 0x0000000030000000-0x000000003dffefff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x000000003dffefff]
[    0.000000] Zeroed struct page in unavailable ranges: 1 pages
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000003dffefff]
[    0.000000] kasan: populating shadow for b7000000, bd000000
[    0.000000] 8<--- cut here ---
[    0.000000] Unable to handle kernel paging request at virtual address bcdffe00
[    0.000000] pgd = (ptrval)
[    0.000000] [bcdffe00] *pgd=80000000006003, *pmd=00000000
[    0.000000] Internal error: Oops: 206 [#1] SMP ARM
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.8.0-rc3-gd06ab87ec507 #4
[    0.000000] Hardware name: Broadcom STB (Flattened Device Tree)
[    0.000000] PC is at check_memory_region+0x54/0x1c8
[    0.000000] LR is at 0x40
[    0.000000] pc : [<c044f528>]    lr : [<00000040>]    psr: 600000d3
[    0.000000] sp : c2603b80  ip : bcdffe00  fp : c2603bac
[    0.000000] r10: 00000000  r9 : 00001000  r8 : bce00000
[    0.000000] r7 : bcdfffff  r6 : eeffffff  r5 : eefff000  r4 : 00000000
[    0.000000] r3 : c181f114  r2 : 00000001  r1 : 00001000  r0 : eefff000
[    0.000000] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment user
[    0.000000] Control: 30c5387d  Table: 01877100  DAC: fffffffd
[    0.000000] Process swapper (pid: 0, stack limit = 0x(ptrval))
[    0.000000] Stack: (0xc2603b80 to 0xc2604000)
[    0.000000] 3b80: c181f114 00001000 eefff000 00000000 00000000 c2606d48 00001000 00000000
[    0.000000] 3ba0: c2603bcc c2603bb0 c044d32c c044f4e0 b74c0780 00000000 eefff000 00000000
[    0.000000] 3bc0: c2603cd4 c2603bd0 c181f114 c044d310 3fffffff 00000000 00000001 00000000
[    0.000000] 3be0: ffffffff 00000000 00000019 00000000 00000019 00000000 c2970ce0 c2970ce0
[    0.000000] 3c00: 41b58ab3 c1672d28 c181efdc 00000001 600000d3 0000002f c2603c6c c2603c28
[    0.000000] 3c20: 3fffffff 00000000 c165c838 c2603d54 00000001 00000001 00000018 00000000
[    0.000000] 3c40: 00000000 c250d3ec 00000000 c165c838 c2603d54 00000000 b7000000 c18750d8
[    0.000000] 3c60: 00000001 00000000 c02b2e58 c02b2ba4 c165c838 c2603d54 c2603cb4 c2603c88
[    0.000000] 3c80: c02b447c c02b2e34 c2603cd4 c2603c98 c10ae5a4 b74c0798 c2606d48 c2994d58
[    0.000000] 3ca0: fffff000 00000000 c2603d4c 00000001 00000000 b7600000 ef474fa0 c0006dd8
[    0.000000] 3cc0: c16d1084 b75f4000 c2603d04 c2603cd8 c180d608 c181efe8 3fffffff 00000000
[    0.000000] 3ce0: 00000001 00000000 ffffffff beffffff 2f00071f c296c4d8 c2603d5c c2603d08
[    0.000000] 3d00: c180d7a0 c180d590 2f00071f 00c00000 c2603d5c bd000000 c26a2ee0 0000296a
[    0.000000] 3d20: c260a284 c0003010 00000000 bd000000 c180b40c c16d1084 c26a3140 c2994d58
[    0.000000] 3d40: fffff000 3dfff000 b7000000 c18750d8 c2603dac c2603d60 c180db04 c180d61c
[    0.000000] 3d60: 00000000 00000000 c1809028 bd000000 c165c838 c16d1000 3dfff000 00000000
[    0.000000] 3d80: c2603dac c26a2ee0 c2dd0b80 c1873a48 c0008000 e12fff1e c02269e8 c1861a70
[    0.000000] 3da0: c2603ee4 c2603db0 c1805d38 c180d8f8 0000006c 30c5387d 00000001 00000001
[    0.000000] 3dc0: 00000001 00000000 c02b2e58 c16d1084 c187702c 184c07c0 c2603edc 00000000
[    0.000000] 3de0: 420f00f3 30c5387d c2603e0c c2603df8 c2603f40 c2603ea0 c1200740 c2603edc
[    0.000000] 3e00: 41b58ab3 c165ac04 c180550c c02b2e34 c02b3a10 c02b43f0 00000000 b74c07cc
[    0.000000] 3e20: c2606d48 c2606d40 c2606d48 c296b440 c2603ed4 c2603e40 c02b3a10 c02b43f0
[    0.000000] 3e40: c2603eb4 00000000 c2603e74 c2603e58 c2603e74 c2603e60 c0299010 c044f034
[    0.000000] 3e60: 41b58ab3 c165d1c4 c02b3980 c2603e78 c031dc2c c044f034 00000000 c2665ff8
[    0.000000] 3e80: c2603edc c2665ea0 c1877270 c266606c c2665eb0 07819000 c29915c0 0000007b
[    0.000000] 3ea0: 00000000 c2606d48 c2603ec4 c2603eb8 c044f094 00000000 c2603ee4 b74c07e4
[    0.000000] 3ec0: c2603fc0 c2606d40 c2606d48 c296b440 420f00f3 30c5387d c2603ff4 c2603ee8
[    0.000000] 3ee0: c1800e1c c1805518 00000000 00000000 00000000 00000000 00000000 00000000
[    0.000000] 3f00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    0.000000] 3f20: 41b58ab3 c1659ce4 c1800d40 00000000 00000000 00000000 00000000 00000000
[    0.000000] 3f40: c1873a48 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    0.000000] 3f60: 00000000 00000000 00000000 c180d840 00000000 00000000 0296a403 c296c4d8
[    0.000000] 3f80: c2603fe4 c2603f90 c180d840 c0223c5c 0296a403 00c00000 00000000 bf000000
[    0.000000] 3fa0: c26a2ee0 0000296a c260a284 c0003010 00000001 bf000000 00000000 c1800334
[    0.000000] 3fc0: 00000000 00000000 ffffffff c1800334 00000000 30c0387d ffffffff 07819000
[    0.000000] 3fe0: 420f00f3 30c5387d 00000000 c2603ff8 00000000 c1800d4c 00000000 00000000
[    0.000000] Backtrace: 
[    0.000000] [<c044f4d4>] (check_memory_region) from [<c044d32c>] (memset+0x28/0x44)
[    0.000000]  r10:00000000 r9:00001000 r8:c2606d48 r7:00000000 r6:00000000 r5:eefff000
[    0.000000]  r4:00001000 r3:c181f114
[    0.000000] [<c044d304>] (memset) from [<c181f114>] (memblock_alloc_try_nid+0x138/0x170)
[    0.000000]  r7:00000000 r6:eefff000 r5:00000000 r4:b74c0780
[    0.000000] [<c181efdc>] (memblock_alloc_try_nid) from [<c180d608>] (kasan_alloc_block.constprop.5+0x84/0x8c)
[    0.000000]  r10:b75f4000 r9:c16d1084 r8:c0006dd8 r7:ef474fa0 r6:b7600000 r5:00000000
[    0.000000]  r4:00000001
[    0.000000] [<c180d584>] (kasan_alloc_block.constprop.5) from [<c180d7a0>] (kasan_pgd_populate.constprop.2+0x190/0x274)
[    0.000000]  r5:c296c4d8 r4:2f00071f
[    0.000000] [<c180d610>] (kasan_pgd_populate.constprop.2) from [<c180db04>] (kasan_init+0x218/0x354)
[    0.000000]  r10:c18750d8 r9:b7000000 r8:3dfff000 r7:fffff000 r6:c2994d58 r5:c26a3140
[    0.000000]  r4:c16d1084
[    0.000000] [<c180d8ec>] (kasan_init) from [<c1805d38>] (setup_arch+0x82c/0x1000)
[    0.000000]  r10:c1861a70 r9:c02269e8 r8:e12fff1e r7:c0008000 r6:c1873a48 r5:c2dd0b80
[    0.000000]  r4:c26a2ee0
[    0.000000] [<c180550c>] (setup_arch) from [<c1800e1c>] (start_kernel+0xdc/0x6d0)
[    0.000000]  r10:30c5387d r9:420f00f3 r8:c296b440 r7:c2606d48 r6:c2606d40 r5:c2603fc0
[    0.000000]  r4:b74c07e4
[    0.000000] [<c1800d40>] (start_kernel) from [<00000000>] (0x0)
[    0.000000]  r10:30c5387d r9:420f00f3 r8:07819000 r7:ffffffff r6:30c0387d r5:00000000
[    0.000000]  r4:c1800334
[    0.000000] Code: da00001a e21c4007 1a000028 e1a0e1ce (e1cc40d0) 
[    0.000000] random: get_random_bytes called from print_oops_end_marker+0x30/0x5c with crng_init=0
[    0.000000] ---[ end trace b6a58a67e72a9f5c ]---
[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[    0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---

[-- Attachment #4: 7439-bselinux-rack-05.log --]
[-- Type: text/plain, Size: 7927 bytes --]

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.8.0-rc3-gd06ab87ec507 (fainelli@fainelli-desktop) (arm-linux-gcc (GCC) 8.3.0, GNU ld (GNU Binutils) 2.32) #4 SMP Wed Jul 1 13:02:00 PDT 2020
[    0.000000] CPU: ARMv7 Processor [420f00f3] revision 3 (ARMv7), cr=30c5387d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] OF: fdt: Machine model: BCM97449SSV_4GB
[    0.000000] earlycon: ns16550a0 at MMIO32 0x00000000f040a900 (options '115200')
[    0.000000] printk: bootconsole [ns16550a0] enabled
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] cma: Reserved 16 MiB at 0x00000000bec00000
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000000000-0x000000002fffffff]
[    0.000000]   Normal   empty
[    0.000000]   HighMem  [mem 0x0000000030000000-0x000000033fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x000000007dffffff]
[    0.000000]   node   0: [mem 0x0000000080000000-0x00000000bfffefff]
[    0.000000]   node   0: [mem 0x0000000300000000-0x000000033fffffff]
[    0.000000] Zeroed struct page in unavailable ranges: 1 pages
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000033fffffff]
[    0.000000] kasan: populating shadow for b7000000, bd000000
[    0.000000] 8<--- cut here ---
[    0.000000] Unable to handle kernel paging request at virtual address bc9ffe00
[    0.000000] pgd = (ptrval)
[    0.000000] [bc9ffe00] *pgd=80000000006003, *pmd=00000000
[    0.000000] Internal error: Oops: 206 [#1] SMP ARM
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.8.0-rc3-gd06ab87ec507 #4
[    0.000000] Hardware name: Broadcom STB (Flattened Device Tree)
[    0.000000] PC is at check_memory_region+0x54/0x1c8
[    0.000000] LR is at 0x40
[    0.000000] pc : [<c044f528>]    lr : [<00000040>]    psr: 600000d3
[    0.000000] sp : c2603b80  ip : bc9ffe00  fp : c2603bac
[    0.000000] r10: 00000000  r9 : 00001000  r8 : bca00000
[    0.000000] r7 : bc9fffff  r6 : ecffffff  r5 : ecfff000  r4 : 00000000
[    0.000000] r3 : c181f114  r2 : 00000001  r1 : 00001000  r0 : ecfff000
[    0.000000] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment user
[    0.000000] Control: 30c5387d  Table: 01877100  DAC: fffffffd
[    0.000000] Process swapper (pid: 0, stack limit = 0x(ptrval))
[    0.000000] Stack: (0xc2603b80 to 0xc2604000)
[    0.000000] 3b80: c181f114 00001000 ecfff000 00000000 00000000 c2606d48 00001000 00000000
[    0.000000] 3ba0: c2603bcc c2603bb0 c044d32c c044f4e0 b74c0780 00000000 ecfff000 00000000
[    0.000000] 3bc0: c2603cd4 c2603bd0 c181f114 c044d310 3fffffff 00000000 00000001 00000000
[    0.000000] 3be0: ffffffff 00000000 0000001b 00000000 0000001b 00000000 c2970ce0 c2970ce0
[    0.000000] 3c00: 41b58ab3 c1672d28 c181efdc 00000001 600000d3 0000002f c2603c6c c2603c28
[    0.000000] 3c20: 3fffffff 00000000 c165c838 c2603d54 00000001 00000001 0000001a 00000000
[    0.000000] 3c40: 00000000 c250d3ec 00000000 c165c838 c2603d54 00000000 b7000000 c18750d8
[    0.000000] 3c60: 00000001 00000000 c02b2e58 c02b2ba4 c165c838 c2603d54 c2603cb4 c2603c88
[    0.000000] 3c80: c02b447c c02b2e34 c2603cd4 c2603c98 c10ae5a4 b74c0798 c2606d48 c2994d58
[    0.000000] 3ca0: fffff000 00000000 c2603d4c 00000001 00000000 b7800000 ed1f3f98 c0006de0
[    0.000000] 3cc0: c16d1084 b77f3000 c2603d04 c2603cd8 c180d608 c181efe8 3fffffff 00000000
[    0.000000] 3ce0: 00000001 00000000 ffffffff beffffff 2d00071f c296c4d8 c2603d5c c2603d08
[    0.000000] 3d00: c180d7a0 c180d590 2d00071f 00c00000 c2603d5c bd000000 c26a2ee0 0000296a
[    0.000000] 3d20: c260a284 c0003010 00000000 bd000000 c180b40c c16d1084 c26a3140 c2994d58
[    0.000000] 3d40: fffff000 7e000000 b7000000 c18750d8 c2603dac c2603d60 c180db04 c180d61c
[    0.000000] 3d60: 80000000 00000000 c1809028 bd000000 c165c838 c16d1000 7e000000 00000000
[    0.000000] 3d80: c2603dac c26a2ee0 c2dd0b80 c1873a48 c0008000 e12fff1e c02269e8 c1861a70
[    0.000000] 3da0: c2603ee4 c2603db0 c1805d38 c180d8f8 0000006c 30c5387d 00000001 00000001
[    0.000000] 3dc0: 00000001 00000000 c02b2e58 c16d1084 c187702c 184c07c0 c2603edc 00000000
[    0.000000] 3de0: 420f00f3 30c5387d c2603e0c c2603df8 c2603f40 c2603ea0 c1200740 c2603edc
[    0.000000] 3e00: 41b58ab3 c165ac04 c180550c c02b2e34 c02b3a10 c02b43f0 00000000 b74c07cc
[    0.000000] 3e20: c2606d48 c2606d40 c2606d48 c296b440 c2603ed4 c2603e40 c02b3a10 c02b43f0
[    0.000000] 3e40: c2603eb4 00000000 c2603e74 c2603e58 c2603e74 c2603e60 c0299010 c044f034
[    0.000000] 3e60: 41b58ab3 c165d1c4 c02b3980 c2603e78 c031dc2c c044f034 00000000 c2665ff8
[    0.000000] 3e80: c2603edc c2665ea0 c1877270 c266606c c2665eb0 07822000 c29915c0 0000007b
[    0.000000] 3ea0: 00000000 c2606d48 c2603ec4 c2603eb8 c044f094 00000000 c2603ee4 b74c07e4
[    0.000000] 3ec0: c2603fc0 c2606d40 c2606d48 c296b440 420f00f3 30c5387d c2603ff4 c2603ee8
[    0.000000] 3ee0: c1800e1c c1805518 00000000 00000000 00000000 00000000 00000000 00000000
[    0.000000] 3f00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    0.000000] 3f20: 41b58ab3 c1659ce4 c1800d40 00000000 00000000 00000000 00000000 00000000
[    0.000000] 3f40: c1873a48 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    0.000000] 3f60: 00000000 00000000 00000000 c180d840 00000000 00000000 0296a403 c296c4d8
[    0.000000] 3f80: c2603fe4 c2603f90 c180d840 c0223c5c 0296a403 00c00000 00000000 bf000000
[    0.000000] 3fa0: c26a2ee0 0000296a c260a284 c0003010 00000001 bf000000 00000000 c1800334
[    0.000000] 3fc0: 00000000 00000000 ffffffff c1800334 00000000 30c0387d ffffffff 07822000
[    0.000000] 3fe0: 420f00f3 30c5387d 00000000 c2603ff8 00000000 c1800d4c 00000000 00000000
[    0.000000] Backtrace: 
[    0.000000] [<c044f4d4>] (check_memory_region) from [<c044d32c>] (memset+0x28/0x44)
[    0.000000]  r10:00000000 r9:00001000 r8:c2606d48 r7:00000000 r6:00000000 r5:ecfff000
[    0.000000]  r4:00001000 r3:c181f114
[    0.000000] [<c044d304>] (memset) from [<c181f114>] (memblock_alloc_try_nid+0x138/0x170)
[    0.000000]  r7:00000000 r6:ecfff000 r5:00000000 r4:b74c0780
[    0.000000] [<c181efdc>] (memblock_alloc_try_nid) from [<c180d608>] (kasan_alloc_block.constprop.5+0x84/0x8c)
[    0.000000]  r10:b77f3000 r9:c16d1084 r8:c0006de0 r7:ed1f3f98 r6:b7800000 r5:00000000
[    0.000000]  r4:00000001
[    0.000000] [<c180d584>] (kasan_alloc_block.constprop.5) from [<c180d7a0>] (kasan_pgd_populate.constprop.2+0x190/0x274)
[    0.000000]  r5:c296c4d8 r4:2d00071f
[    0.000000] [<c180d610>] (kasan_pgd_populate.constprop.2) from [<c180db04>] (kasan_init+0x218/0x354)
[    0.000000]  r10:c18750d8 r9:b7000000 r8:7e000000 r7:fffff000 r6:c2994d58 r5:c26a3140
[    0.000000]  r4:c16d1084
[    0.000000] [<c180d8ec>] (kasan_init) from [<c1805d38>] (setup_arch+0x82c/0x1000)
[    0.000000]  r10:c1861a70 r9:c02269e8 r8:e12fff1e r7:c0008000 r6:c1873a48 r5:c2dd0b80
[    0.000000]  r4:c26a2ee0
[    0.000000] [<c180550c>] (setup_arch) from [<c1800e1c>] (start_kernel+0xdc/0x6d0)
[    0.000000]  r10:30c5387d r9:420f00f3 r8:c296b440 r7:c2606d48 r6:c2606d40 r5:c2603fc0
[    0.000000]  r4:b74c07e4
[    0.000000] [<c1800d40>] (start_kernel) from [<00000000>] (0x0)
[    0.000000]  r10:30c5387d r9:420f00f3 r8:07822000 r7:ffffffff r6:30c0387d r5:00000000
[    0.000000]  r4:c1800334
[    0.000000] Code: da00001a e21c4007 1a000028 e1a0e1ce (e1cc40d0) 
[    0.000000] random: get_random_bytes called from print_oops_end_marker+0x30/0x5c with crng_init=0
[    0.000000] ---[ end trace ddc8d41b0f5a666c ]---
[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[    0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---

[-- Attachment #5: 72112-bselinux-rack-03.log --]
[-- Type: text/plain, Size: 7911 bytes --]

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.8.0-rc3-gd06ab87ec507 (fainelli@fainelli-desktop) (arm-linux-gcc (GCC) 8.3.0, GNU ld (GNU Binutils) 2.32) #4 SMP Wed Jul 1 13:02:00 PDT 2020
[    0.000000] CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), cr=30c5383d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] OF: fdt: Machine model: BCM972112SV
[    0.000000] earlycon: pl11 at MMIO 0x000000047e201000 (options '115200')
[    0.000000] printk: bootconsole [pl11] enabled
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] cma: Reserved 16 MiB at 0x000000007f000000
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000000000-0x000000002fffffff]
[    0.000000]   Normal   empty
[    0.000000]   HighMem  [mem 0x0000000030000000-0x000000007fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x00000000063fdfff]
[    0.000000]   node   0: [mem 0x0000000006400000-0x000000000fffffff]
[    0.000000]   node   0: [mem 0x0000000010400000-0x000000007fffffff]
[    0.000000] Zeroed struct page in unavailable ranges: 2 pages
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000007fffffff]
[    0.000000] kasan: populating shadow for b7000000, b7c7fc00
[    0.000000] 8<--- cut here ---
[    0.000000] Unable to handle kernel paging request at virtual address bcbffe00
[    0.000000] pgd = (ptrval)
[    0.000000] [bcbffe00] *pgd=80000000006003, *pmd=00000000
[    0.000000] Internal error: Oops: 206 [#1] SMP ARM
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.8.0-rc3-gd06ab87ec507 #4
[    0.000000] Hardware name: Broadcom STB (Flattened Device Tree)
[    0.000000] PC is at check_memory_region+0x54/0x1c8
[    0.000000] LR is at 0x40
[    0.000000] pc : [<c044f528>]    lr : [<00000040>]    psr: 600000d3
[    0.000000] sp : c2603b80  ip : bcbffe00  fp : c2603bac
[    0.000000] r10: 00000000  r9 : 00001000  r8 : bcc00000
[    0.000000] r7 : bcbfffff  r6 : edffffff  r5 : edfff000  r4 : 00000000
[    0.000000] r3 : c181f114  r2 : 00000001  r1 : 00001000  r0 : edfff000
[    0.000000] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment user
[    0.000000] Control: 30c5383d  Table: 01877100  DAC: fffffffd
[    0.000000] Process swapper (pid: 0, stack limit = 0x(ptrval))
[    0.000000] Stack: (0xc2603b80 to 0xc2604000)
[    0.000000] 3b80: c181f114 00001000 edfff000 00000000 00000000 c2606d48 00001000 00000000
[    0.000000] 3ba0: c2603bcc c2603bb0 c044d32c c044f4e0 b74c0780 00000000 edfff000 00000000
[    0.000000] 3bc0: c2603cd4 c2603bd0 c181f114 c044d310 3fffffff 00000000 00000001 00000000
[    0.000000] 3be0: ffffffff 00000000 0000001b 00000000 0000001b 00000000 c2970ce0 c2970ce0
[    0.000000] 3c00: 41b58ab3 c1672d28 c181efdc 00000001 600000d3 0000002f c2603c6c c2603c28
[    0.000000] 3c20: 3fffffff 00000000 c165c838 c2603d54 00000001 00000001 0000001a 00000000
[    0.000000] 3c40: 00000000 c250d3ec 00000000 c165c838 c2603d54 00000000 b7000000 c18750d8
[    0.000000] 3c60: 00000001 00000000 c02b2e58 c02b2ba4 c165c838 c2603d54 c2603cb4 c2603c88
[    0.000000] 3c80: c02b447c c02b2e34 c2603cd4 c2603c98 c10ae5a4 b74c0798 c2606d48 c2994d58
[    0.000000] 3ca0: fffff000 00000000 c2603d4c 00000001 00000000 b7c00000 ee1f2f90 c0006df0
[    0.000000] 3cc0: c16d1084 b7bf2000 c2603d04 c2603cd8 c180d608 c181efe8 3fffffff 00000000
[    0.000000] 3ce0: 00000001 00000000 ffffffff beffffff 2e00071f c296c4d8 c2603d5c c2603d08
[    0.000000] 3d00: c180d7a0 c180d590 2e00071f 00c00000 c2603d5c b7c7fc00 c26a2ee0 0000296a
[    0.000000] 3d20: c260a284 c0003010 00000000 b7c7fc00 c180b40c c16d1084 c26a3140 c2994d58
[    0.000000] 3d40: fffff000 063fe000 b7000000 c18750d8 c2603dac c2603d60 c180db04 c180d61c
[    0.000000] 3d60: 10400000 00000000 c1809028 b7c7fc00 c165c838 c16d1000 063fe000 00000000
[    0.000000] 3d80: c2603dac c26a2ee0 c2dd0b80 c1873a48 c0008000 e12fff1e c02269e8 c1861a70
[    0.000000] 3da0: c2603ee4 c2603db0 c1805d38 c180d8f8 0000006c 30c5383d 00000001 00000001
[    0.000000] 3dc0: 00000001 00000000 c02b2e58 c16d1084 c1877000 184c07c0 c2603edc 00000000
[    0.000000] 3de0: 410fd083 30c5387d c2603e0c c2603df8 c2603f40 c2603ea0 c1200740 c2603edc
[    0.000000] 3e00: 41b58ab3 c165ac04 c180550c c02b2e34 c02b3a10 c02b43f0 00000000 b74c07cc
[    0.000000] 3e20: c2606d48 c2606d40 c2606d48 c296b440 c2603ed4 c2603e40 c02b3a10 c02b43f0
[    0.000000] 3e40: c2603eb4 00000000 c2603e74 c2603e58 c2603e74 c2603e60 c0299010 c044f034
[    0.000000] 3e60: 41b58ab3 c165d1c4 c02b3980 c2603e78 c031dc2c c044f034 00000000 c2665ff8
[    0.000000] 3e80: c2603edc c2665ea0 c1877270 c266606c c2665eb0 0e415000 c29915c0 0000007b
[    0.000000] 3ea0: 00000000 c2606d48 c2603ec4 c2603eb8 c044f094 00000000 c2603ee4 b74c07e4
[    0.000000] 3ec0: c2603fc0 c2606d40 c2606d48 c296b440 410fd083 30c5387d c2603ff4 c2603ee8
[    0.000000] 3ee0: c1800e1c c1805518 00000000 00000000 00000000 00000000 00000000 00000000
[    0.000000] 3f00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    0.000000] 3f20: 41b58ab3 c1659ce4 c1800d40 00000000 00000000 00000000 00000000 00000000
[    0.000000] 3f40: c1873a48 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    0.000000] 3f60: 00000000 00000000 00000000 c180d840 00000000 00000000 0296a403 c296c4d8
[    0.000000] 3f80: c2603fe4 c2603f90 c180d840 c0223c5c 0296a403 00c00000 00000000 bf000000
[    0.000000] 3fa0: c26a2ee0 0000296a c260a284 c0003010 00000001 bf000000 00000000 c1800334
[    0.000000] 3fc0: 00000000 00000000 ffffffff c1800334 00000000 30c0387d ffffffff 0e415000
[    0.000000] 3fe0: 410fd083 30c5387d 00000000 c2603ff8 00000000 c1800d4c 00000000 00000000
[    0.000000] Backtrace: 
[    0.000000] [<c044f4d4>] (check_memory_region) from [<c044d32c>] (memset+0x28/0x44)
[    0.000000]  r10:00000000 r9:00001000 r8:c2606d48 r7:00000000 r6:00000000 r5:edfff000
[    0.000000]  r4:00001000 r3:c181f114
[    0.000000] [<c044d304>] (memset) from [<c181f114>] (memblock_alloc_try_nid+0x138/0x170)
[    0.000000]  r7:00000000 r6:edfff000 r5:00000000 r4:b74c0780
[    0.000000] [<c181efdc>] (memblock_alloc_try_nid) from [<c180d608>] (kasan_alloc_block.constprop.5+0x84/0x8c)
[    0.000000]  r10:b7bf2000 r9:c16d1084 r8:c0006df0 r7:ee1f2f90 r6:b7c00000 r5:00000000
[    0.000000]  r4:00000001
[    0.000000] [<c180d584>] (kasan_alloc_block.constprop.5) from [<c180d7a0>] (kasan_pgd_populate.constprop.2+0x190/0x274)
[    0.000000]  r5:c296c4d8 r4:2e00071f
[    0.000000] [<c180d610>] (kasan_pgd_populate.constprop.2) from [<c180db04>] (kasan_init+0x218/0x354)
[    0.000000]  r10:c18750d8 r9:b7000000 r8:063fe000 r7:fffff000 r6:c2994d58 r5:c26a3140
[    0.000000]  r4:c16d1084
[    0.000000] [<c180d8ec>] (kasan_init) from [<c1805d38>] (setup_arch+0x82c/0x1000)
[    0.000000]  r10:c1861a70 r9:c02269e8 r8:e12fff1e r7:c0008000 r6:c1873a48 r5:c2dd0b80
[    0.000000]  r4:c26a2ee0
[    0.000000] [<c180550c>] (setup_arch) from [<c1800e1c>] (start_kernel+0xdc/0x6d0)
[    0.000000]  r10:30c5387d r9:410fd083 r8:c296b440 r7:c2606d48 r6:c2606d40 r5:c2603fc0
[    0.000000]  r4:b74c07e4
[    0.000000] [<c1800d40>] (start_kernel) from [<00000000>] (0x0)
[    0.000000]  r10:30c5387d r9:410fd083 r8:0e415000 r7:ffffffff r6:30c0387d r5:00000000
[    0.000000]  r4:c1800334
[    0.000000] Code: da00001a e21c4007 1a000028 e1a0e1ce (e1cc40d0) 
[    0.000000] random: get_random_bytes called from print_oops_end_marker+0x30/0x5c with crng_init=0
[    0.000000] ---[ end trace 01ab1b5825cf68d0 ]---
[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[    0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---

[-- Attachment #6: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/5 v11] KASan for Arm

[Ard Biesheuvel]

On Wed, 1 Jul 2020 at 22:16, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>
>
> On 7/1/2020 5:09 AM, Ard Biesheuvel wrote:
> >
> > I pushed these changes and a few more to
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-kasan-v11
>
> This branch works a bit better however I am still seeing some boot
> errors (some sample logs attached) similar to Linus' branch.
>

These crashes are all identical, they all crash on the bc9ffe00 shadow
address not being backed by early shadow memory.

That value has all bits PTE index bits set to 1, and given how
memblock usually allocates top down, it means we are allocating page
by page and calling check_memory_region() on it during the memset()
until the point where we hit a PMD that is not set, covering the
window bc800000-bc9fffff

Are there any memory reservations in the range ec000000-ecffffff ? Are
you using the default vmalloc range? Any other peculiarities in the
memory layout?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/5 v11] KASan for Arm

[Florian Fainelli]

On 7/1/2020 2:41 PM, Ard Biesheuvel wrote:
> On Wed, 1 Jul 2020 at 22:16, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>
>>
>>
>> On 7/1/2020 5:09 AM, Ard Biesheuvel wrote:
>>>
>>> I pushed these changes and a few more to
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-kasan-v11
>>
>> This branch works a bit better however I am still seeing some boot
>> errors (some sample logs attached) similar to Linus' branch.
>>
> 
> These crashes are all identical, they all crash on the bc9ffe00 shadow
> address not being backed by early shadow memory.
> 
> That value has all bits PTE index bits set to 1, and given how
> memblock usually allocates top down, it means we are allocating page
> by page and calling check_memory_region() on it during the memset()
> until the point where we hit a PMD that is not set, covering the
> window bc800000-bc9fffff
> 
> Are there any memory reservations in the range ec000000-ecffffff ?

Not that I can see according to memblock=debug:

[    0.000000]  reserved.cnt  = 0x6
[    0.000000]  reserved[0x0]   [0x0000000000000000-0x0000000000000fff],
0x0000000000001000 bytes flags: 0x0
[    0.000000]  reserved[0x1]   [0x0000000000003000-0x0000000000007fff],
0x0000000000005000 bytes flags: 0x0
[    0.000000]  reserved[0x2]   [0x0000000000200000-0x0000000002dd0b7f],
0x0000000002bd0b80 bytes flags: 0x0
[    0.000000]  reserved[0x3]   [0x0000000006400000-0x00000000065fffff],
0x0000000000200000 bytes flags: 0x0
[    0.000000]  reserved[0x4]   [0x000000000e415000-0x000000000e41960b],
0x000000000000460c bytes flags: 0x0
[    0.000000]  reserved[0x5]   [0x000000007f000000-0x000000007fffffff],
0x0000000001000000 bytes flags: 0x0

[    0.000000]  reserved.cnt  = 0x7
[    0.000000]  reserved[0x0]   [0x0000000000000000-0x0000000000000fff],
0x0000000000001000 bytes flags: 0x0
[    0.000000]  reserved[0x1]   [0x0000000000003000-0x0000000000007fff],
0x0000000000005000 bytes flags: 0x0
[    0.000000]  reserved[0x2]   [0x0000000000200000-0x0000000002dd0b7f],
0x0000000002bd0b80 bytes flags: 0x0
[    0.000000]  reserved[0x3]   [0x0000000006400000-0x00000000064fffff],
0x0000000000100000 bytes flags: 0x0
[    0.000000]  reserved[0x4]   [0x0000000007008000-0x000000000700ffff],
0x0000000000008000 bytes flags: 0x0
[    0.000000]  reserved[0x5]   [0x0000000007819000-0x000000000781e5cf],
0x00000000000055d0 bytes flags: 0x0
[    0.000000]  reserved[0x6]   [0x000000003cc00000-0x000000003dbfffff],
0x0000000001000000 bytes flags: 0x0


> Are you using the default vmalloc range?

Yes.

> Any other peculiarities in the memory layout?

Not that I can think of, the memory is mapped at PA 0x0000_0000 all the
way to 0xbfff_ffff and then all other memory is mapped at PA
0x1_0000_0000 and aboved.
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/5 v11] KASan for Arm

[Ard Biesheuvel]

On Thu, 2 Jul 2020 at 00:28, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>
>
> On 7/1/2020 2:41 PM, Ard Biesheuvel wrote:
> > On Wed, 1 Jul 2020 at 22:16, Florian Fainelli <f.fainelli@gmail.com> wrote:
> >>
> >>
> >>
> >> On 7/1/2020 5:09 AM, Ard Biesheuvel wrote:
> >>>
> >>> I pushed these changes and a few more to
> >>>
> >>> https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-kasan-v11
> >>
> >> This branch works a bit better however I am still seeing some boot
> >> errors (some sample logs attached) similar to Linus' branch.
> >>
> >
> > These crashes are all identical, they all crash on the bc9ffe00 shadow
> > address not being backed by early shadow memory.
> >
> > That value has all bits PTE index bits set to 1, and given how
> > memblock usually allocates top down, it means we are allocating page
> > by page and calling check_memory_region() on it during the memset()
> > until the point where we hit a PMD that is not set, covering the
> > window bc800000-bc9fffff
> >
> > Are there any memory reservations in the range ec000000-ecffffff ?
>
> Not that I can see according to memblock=debug:
>

Yeah I actually meant the PA equivalent of that, i.e., 2c000000-2cffffff

> [    0.000000]  reserved.cnt  = 0x6
> [    0.000000]  reserved[0x0]   [0x0000000000000000-0x0000000000000fff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  reserved[0x1]   [0x0000000000003000-0x0000000000007fff],
> 0x0000000000005000 bytes flags: 0x0
> [    0.000000]  reserved[0x2]   [0x0000000000200000-0x0000000002dd0b7f],
> 0x0000000002bd0b80 bytes flags: 0x0
> [    0.000000]  reserved[0x3]   [0x0000000006400000-0x00000000065fffff],
> 0x0000000000200000 bytes flags: 0x0
> [    0.000000]  reserved[0x4]   [0x000000000e415000-0x000000000e41960b],
> 0x000000000000460c bytes flags: 0x0
> [    0.000000]  reserved[0x5]   [0x000000007f000000-0x000000007fffffff],
> 0x0000000001000000 bytes flags: 0x0
>
> [    0.000000]  reserved.cnt  = 0x7
> [    0.000000]  reserved[0x0]   [0x0000000000000000-0x0000000000000fff],
> 0x0000000000001000 bytes flags: 0x0
> [    0.000000]  reserved[0x1]   [0x0000000000003000-0x0000000000007fff],
> 0x0000000000005000 bytes flags: 0x0
> [    0.000000]  reserved[0x2]   [0x0000000000200000-0x0000000002dd0b7f],
> 0x0000000002bd0b80 bytes flags: 0x0
> [    0.000000]  reserved[0x3]   [0x0000000006400000-0x00000000064fffff],
> 0x0000000000100000 bytes flags: 0x0
> [    0.000000]  reserved[0x4]   [0x0000000007008000-0x000000000700ffff],
> 0x0000000000008000 bytes flags: 0x0
> [    0.000000]  reserved[0x5]   [0x0000000007819000-0x000000000781e5cf],
> 0x00000000000055d0 bytes flags: 0x0
> [    0.000000]  reserved[0x6]   [0x000000003cc00000-0x000000003dbfffff],
> 0x0000000001000000 bytes flags: 0x0
>
>
> > Are you using the default vmalloc range?
>
> Yes.
>
> > Any other peculiarities in the memory layout?
>
> Not that I can think of, the memory is mapped at PA 0x0000_0000 all the
> way to 0xbfff_ffff and then all other memory is mapped at PA
> 0x1_0000_0000 and aboved.

OK, so assuming kasan_early_init() backs the entire shadow region with
zero pages correctly, we are losing the mapping somewhere between
there and kasan_init(), and there are quite a number of
create_mapping() calls in the meantime.

So if you have cycles to spend on this, do you mind instrumenting
create_mapping() and see whether any of the ranges that are
(re`)mapped come within 2 MB of bc800000-bc9fffff?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/5 v11] KASan for Arm

[Florian Fainelli]

[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]



On 7/1/2020 4:03 PM, Ard Biesheuvel wrote
> OK, so assuming kasan_early_init() backs the entire shadow region with
> zero pages correctly, we are losing the mapping somewhere between
> there and kasan_init(), and there are quite a number of
> create_mapping() calls in the meantime.
> 
> So if you have cycles to spend on this, do you mind instrumenting
> create_mapping() and see whether any of the ranges that are
> (re`)mapped come within 2 MB of bc800000-bc9fffff?

It does not look like we can go that far, the last debug prints I can
get are:

[    0.000000] kasan: kasan_pte_populate: p: ee002000, addr: 0xb7bef000
[    0.000000] kasan: kasan_pte_populate: memset done
[    0.000000] kasan: kasan_pte_populate: entry: 0xc000002e00271f
[    0.000000] kasan: kasan_pte_populate: p: ee001000, addr: 0xb7bf0000
[    0.000000] kasan: kasan_pte_populate: memset done
[    0.000000] kasan: kasan_pte_populate: entry: 0xc000002e00171f
[    0.000000] kasan: kasan_pte_populate: p: ee000000, addr: 0xb7bf1000
[    0.000000] kasan: kasan_pte_populate: memset done
[    0.000000] kasan: kasan_pte_populate: entry: 0xc000002e00071f
[    0.000000] 8<--- cut here ---
[    0.000000] Unable to handle kernel paging request at virtual address
bcbffe00
[    0.000000] pgd = (ptrval)
[    0.000000] [bcbffe00] *pgd=80000000006003, *pmd=00000000
[    0.000000] Internal error: Oops: 206 [#1] SMP ARM

The next one would be 0xb7bf2000 which is ~79MB lower than 0xbc800000.
Full log is attached.
--
Florian

[-- Attachment #2: kasan.log.gz --]
[-- Type: application/x-gzip, Size: 29282 bytes --]

[-- Attachment #3: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/5 v11] KASan for Arm

[Ard Biesheuvel]

On Fri, 3 Jul 2020 at 05:36, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>
>
> On 7/1/2020 4:03 PM, Ard Biesheuvel wrote
> > OK, so assuming kasan_early_init() backs the entire shadow region with
> > zero pages correctly, we are losing the mapping somewhere between
> > there and kasan_init(), and there are quite a number of
> > create_mapping() calls in the meantime.
> >
> > So if you have cycles to spend on this, do you mind instrumenting
> > create_mapping() and see whether any of the ranges that are
> > (re`)mapped come within 2 MB of bc800000-bc9fffff?
>
> It does not look like we can go that far, the last debug prints I can
> get are:
>
> [    0.000000] kasan: kasan_pte_populate: p: ee002000, addr: 0xb7bef000
> [    0.000000] kasan: kasan_pte_populate: memset done
> [    0.000000] kasan: kasan_pte_populate: entry: 0xc000002e00271f
> [    0.000000] kasan: kasan_pte_populate: p: ee001000, addr: 0xb7bf0000
> [    0.000000] kasan: kasan_pte_populate: memset done
> [    0.000000] kasan: kasan_pte_populate: entry: 0xc000002e00171f
> [    0.000000] kasan: kasan_pte_populate: p: ee000000, addr: 0xb7bf1000
> [    0.000000] kasan: kasan_pte_populate: memset done
> [    0.000000] kasan: kasan_pte_populate: entry: 0xc000002e00071f
> [    0.000000] 8<--- cut here ---
> [    0.000000] Unable to handle kernel paging request at virtual address
> bcbffe00
> [    0.000000] pgd = (ptrval)
> [    0.000000] [bcbffe00] *pgd=80000000006003, *pmd=00000000
> [    0.000000] Internal error: Oops: 206 [#1] SMP ARM
>
> The next one would be 0xb7bf2000 which is ~79MB lower than 0xbc800000.
> Full log is attached.

Thanks.

So it does not look like kasan_init() is the culprit here, given that
it does not touch that region at all.

Could you try reading from that faulting address at entry, but behind
Kasan's back? E.g.,

asm volatile ("ldr %0, [%0]" ::"r"(0xbcbffe00));

If that already crashes, you could try working your way back through
setup_arch() to see where it starts breaking.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/5 v11] KASan for Arm

[Linus Walleij]

On Thu, Jul 2, 2020 at 1:03 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> Florian:
> > Not that I can think of, the memory is mapped at PA 0x0000_0000 all the
> > way to 0xbfff_ffff and then all other memory is mapped at PA
> > 0x1_0000_0000 and aboved.
>
> OK, so assuming kasan_early_init() backs the entire shadow region with
> zero pages correctly, we are losing the mapping somewhere between
> there and kasan_init(), and there are quite a number of
> create_mapping() calls in the meantime.
>
> So if you have cycles to spend on this, do you mind instrumenting
> create_mapping() and see whether any of the ranges that are
> (re`)mapped come within 2 MB of bc800000-bc9fffff?

Hm. What I can think of is this code I have introduced in one
of the patches:

+#ifdef CONFIG_KASAN
+       /*
+        * KASan's shadow memory inserts itself between the TASK_SIZE
+        * and MODULES_VADDR. Do not clear the KASan shadow memory mappings.
+        */
+       for (addr = 0; addr < KASAN_SHADOW_START; addr += PMD_SIZE)
+               pmd_clear(pmd_off_k(addr));
+       /*
+        * Skip over the KASan shadow area. KASAN_SHADOW_END is sometimes
+        * equal to MODULES_VADDR and then we exit the pmd clearing. If we
+        * are using a thumb-compiled kernel, there there will be 8MB more
+        * to clear as KASan always offset to 16 MB below MODULES_VADDR.
+        */
+       for (addr = KASAN_SHADOW_END; addr < MODULES_VADDR; addr += PMD_SIZE)
+               pmd_clear(pmd_off_k(addr));
+#else
        for (addr = 0; addr < MODULES_VADDR; addr += PMD_SIZE)
                pmd_clear(pmd_off_k(addr));
+#endif

If you just augment this to clear the pmd:s for all the memory including the
8 MB not utilized when using thumb, what happens?

I.e. just delete the special case for CONFIG_KASAN with al ifdef and else
endif and have it be:

       for (addr = 0; addr < MODULES_VADDR; addr += PMD_SIZE)
               pmd_clear(pmd_off_k(addr));

This is what the patch used to look like but I introduced that this "hole" be
skipped over, maybe something is using it?

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/5 v11] KASan for Arm

[Linus Walleij]

Hi Florian, Ard,

I have managed to get closer to the problem I am seeing on the Qualcomm
board. I have some idea of what might be wrong.

On Wed, Jul 1, 2020 at 10:16 PM Florian Fainelli <f.fainelli@gmail.com> wrote:

> This branch works a bit better however I am still seeing some boot
> errors (some sample logs attached) similar to Linus' branch.

Can you instrument the code in arch/arm/mm/mmu.c something
like this:

@@ -1296,13 +1300,23 @@ static inline void prepare_page_table(void)
         * Find the end of the first block of lowmem.
         */
        end = memblock.memory.regions[0].base + memblock.memory.regions[0].size;
-       if (end >= arm_lowmem_limit)
+       if (end >= arm_lowmem_limit) {
+               pr_info("Memblock end is above arm_lowmem_limit (0x%08x)\n",
+                       arm_lowmem_limit);
                end = arm_lowmem_limit;
+       }
+       pr_info("Memblock[0].base: 0x%08x size: 0x%08x, end: 0x%08x\n",
+               memblock.memory.regions[0].base,
+               memblock.memory.regions[0].size,
+               end);

        /*
         * Clear out all the kernel space mappings, except for the first
         * memory bank, up to the vmalloc region.
         */
+       pr_info("Clear PMDs from 0x%08lx to 0x%08lx (lowmem)\n",
+               __phys_to_virt(end),
+               VMALLOC_START);
        for (addr = __phys_to_virt(end);
             addr < VMALLOC_START; addr += PMD_SIZE)
                pmd_clear(pmd_off_k(addr));

And then look what addresses this clears. What I noticed with the
APQ8060 board was that the FDT I could not access was under some
circumstances inside the lowmem that gets its PMDs cleared
in prepare_page_table() and that is why paging fails.

So when you get a crash like this:
Unable to handle kernel paging request at virtual address bcdffe00

That can be inside a memory block that the kernel has now designated
as the first block of lowmem.

I am not entirely sure why this happens, but it seems unrelated to
the KASan shadow memory, and seems to be a side effect of
the fact that the kernel vmlinux size grows when using KASan
so when the kernel is loaded in certain locations the kernel
is so big that it actually doesn't fit into the first memory block
and runs into the lowmem. I get the impression that the kernel
binary *must* fit into the first memblock.

If this is the root cause, what we need to to is to properly identify
this case and print an error if it happens.

Here is how it looks on the Qualcomm APQ8060:

I add prints for which address ranges get their PMDs get cleared
in arch/arm/mm/mmu.c, function prepare_page_table(), and print
out where the early FDT parser looks for the attached device tree.

I see the area above MODULES_VADDR getting cleared (in the case
of KASan the shadow memory is skipped over) and then the first
memblock is inspected to locate the start of the first block
of lowmem. This is memblock[0].

I then test to load the kernel to both 0x40200000 and 0x50000000
since the latter always works - something must be funny with
the way the kernel handles the odd memory blocks. Indeed:

Mainline load kernel at 0x40200000 works:

Memblock[0].base: 0x40200000 size: 0x02c00000, end: 0x42e00000
Clear PMDs from 0xc2e00000 to 0xe0800000 (lowmem)
(...)
OF: fdt: unflatten_and_copy_device_tree initial boot params at c22e3d88
OF: fdt: unflatten_and_copy_device_tree: totalsize: 21058

Mainline load kernel at 0x50000000 works:

fdt: Ignoring memory block 0x40200000 - 0x42e00000
fdt: Ignoring memory range 0x48000000 - 0x50000000
(...)
Memblock end is above arm_lowmem_limit (0x60000000)
Memblock[0].base: 0x50000000 size: 0x10000000, end: 0x60000000
Clear PMDs from 0xd0000000 to 0xd0800000 (lowmem)
(...)
OF: fdt: unflatten_and_copy_device_tree initial boot params at c22e3d88
OF: fdt: unflatten_and_copy_device_tree: totalsize: 21090


KASan-enabled, load kernel at 0x40200000 bugs:

Memblock[0].base: 0x40200000 size: 0x02c00000, end: 0x42e00000
Clear PMDs from 0xc2e00000 to 0xe0800000 (lowmem)
(...)
OF: fdt: unflatten_and_copy_device_tree initial boot params at c3078710
Unable to handle kernel paging request at virtual address c3078714
(crash)


KASan-enabled, load kernel at 0x50000000 works:

fdt: Ignoring memory block 0x40200000 - 0x42e00000
fdt: Ignoring memory range 0x48000000 - 0x50000000
(...)
Memblock end is above arm_lowmem_limit (0x60000000)
Memblock[0].base: 0x50000000 size: 0x10000000, end: 0x60000000
Clear PMDs from 0xd0000000 to 0xd0800000 (lowmem)
(...)
OF: fdt: unflatten_and_copy_device_tree initial boot params at c3078710
OF: fdt: unflatten_and_copy_device_tree: totalsize: 21090


Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel