[PATCH 0/5 v16] KASan for Arm

[PATCH 0/5 v16] KASan for Arm

[Linus Walleij]

This is the 16th and final (knock on wood) version of
KASan for ARM32.

Changes since v15:

- Things now work on all boards we have tested on including
  Broadcom and i.MX6Q.

- Folded in a fix from Ard to PAGE_ALIGN() the end of
  mappings making everything work on all Broadcom board.

- Folded in a fix from Ahmad Fatoum making things work
  with fortify on i.MX6Q.

- Testing and testing and testing on build servers.

- We are good to go.

I will now put this in Russell's patch tracker for v5.11.

There is a git branch you can pull in:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kasan

This branch includes Ard's two patches already in Russell's
patch tracker.


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                  |  33 ++
 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                 |  26 ++
 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                      | 292 ++++++++++++++++++
 arch/arm/mm/mmu.c                             |  18 ++
 arch/arm/mm/pgd.c                             |  16 +-
 arch/arm/vdso/Makefile                        |   2 +
 26 files changed, 561 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.26.2


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

[PATCH 1/5 v16] 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
Tested-by: Florian Fainelli <f.fainelli@gmail.com> # Brahma SoCs
Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # i.MX6Q
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 v15->v16:
- Collect Florian's Tested-by
- Resend with the other patches
ChangeLog v14->v15:
- Resend with the other patches
ChangeLog v13->v14:
- Resend with the other patches
ChangeLog v12->v13:
- Rebase on kernel v5.9-rc1
ChangeLog v11->v12:
- Resend with the other changes.
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 b1147b7f2c8d..362e17e37398 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 a54f70731d9f..171c3dcb5242 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.26.2


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

[PATCH 2/5 v16] 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
Tested-by: Florian Fainelli <f.fainelli@gmail.com> # Brahma SoCs
Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # i.MX6Q
Reported-by: Russell King - ARM Linux <linux@armlinux.org.uk>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
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 v15->v16:
- Fold in Ahmad Fatoum's fixup for fortify
- Collect Florian's Tested-by
- Resend with the other patches
ChangeLog v14->v15:
- Resend with the other patches
ChangeLog v13->v14:
- Resend with the other patches
ChangeLog v12->v13:
- Rebase on kernel v5.9-rc1
ChangeLog v11->v12:
- Resend with the other changes.
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     | 26 ++++++++++++++++++++++++++
 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, 57 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..6c607c68f3ad 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,24 @@ 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)
+
+#ifndef __NO_FORTIFY
+#define __NO_FORTIFY /* FORTIFY_SOURCE uses __builtin_memcpy, etc. */
+#endif
+
+#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.26.2


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

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

[Naresh Kamboju]

On Mon, 19 Oct 2020 at 14:14, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> 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
> Tested-by: Florian Fainelli <f.fainelli@gmail.com> # Brahma SoCs
> Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # i.MX6Q
> Reported-by: Russell King - ARM Linux <linux@armlinux.org.uk>
> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> 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 v15->v16:
> - Fold in Ahmad Fatoum's fixup for fortify
> - Collect Florian's Tested-by
> - Resend with the other patches
> ChangeLog v14->v15:
> - Resend with the other patches
> ChangeLog v13->v14:
> - Resend with the other patches
> ChangeLog v12->v13:
> - Rebase on kernel v5.9-rc1
> ChangeLog v11->v12:
> - Resend with the other changes.
> 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     | 26 ++++++++++++++++++++++++++
>  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, 57 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)

arm KASAN build failure noticed on linux next 20201106 tag.
gcc: 9.x

Build error:
---------------
arch/arm/boot/compressed/string.c:24:1: error: attribute 'alias'
argument not a string
   24 | void *__memcpy(void *__dest, __const void *__src, size_t __n)
__alias(memcpy);
      | ^~~~
arch/arm/boot/compressed/string.c:25:1: error: attribute 'alias'
argument not a string
   25 | void *__memmove(void *__dest, __const void *__src, size_t
count) __alias(memmove);
      | ^~~~
arch/arm/boot/compressed/string.c:26:1: error: attribute 'alias'
argument not a string
   26 | void *__memset(void *s, int c, size_t count) __alias(memset);
      | ^~~~

Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>

Build details link,
https://builds.tuxbuild.com/1juBs4tXRA6Cwhd1Qnhh4vzCtDx/

-- 
Linaro LKFT
https://lkft.linaro.org

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

[Naresh Kamboju]

On Mon, 19 Oct 2020 at 14:14, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> 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
> Tested-by: Florian Fainelli <f.fainelli@gmail.com> # Brahma SoCs
> Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # i.MX6Q
> Reported-by: Russell King - ARM Linux <linux@armlinux.org.uk>
> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> 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 v15->v16:
> - Fold in Ahmad Fatoum's fixup for fortify
> - Collect Florian's Tested-by
> - Resend with the other patches
> ChangeLog v14->v15:
> - Resend with the other patches
> ChangeLog v13->v14:
> - Resend with the other patches
> ChangeLog v12->v13:
> - Rebase on kernel v5.9-rc1
> ChangeLog v11->v12:
> - Resend with the other changes.
> 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     | 26 ++++++++++++++++++++++++++
>  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, 57 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)

arm KASAN build failure noticed on linux next 20201106 tag.
gcc: 9.x

Build error:
---------------
arch/arm/boot/compressed/string.c:24:1: error: attribute 'alias'
argument not a string
   24 | void *__memcpy(void *__dest, __const void *__src, size_t __n)
__alias(memcpy);
      | ^~~~
arch/arm/boot/compressed/string.c:25:1: error: attribute 'alias'
argument not a string
   25 | void *__memmove(void *__dest, __const void *__src, size_t
count) __alias(memmove);
      | ^~~~
arch/arm/boot/compressed/string.c:26:1: error: attribute 'alias'
argument not a string
   26 | void *__memset(void *s, int c, size_t count) __alias(memset);
      | ^~~~

Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>

Build details link,
https://builds.tuxbuild.com/1juBs4tXRA6Cwhd1Qnhh4vzCtDx/

-- 
Linaro LKFT
https://lkft.linaro.org

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

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

[Linus Walleij]

On Fri, Nov 6, 2020 at 8:49 AM Naresh Kamboju <naresh.kamboju@linaro.org> wrote:

> arm KASAN build failure noticed on linux next 20201106 tag.
> gcc: 9.x
>
> Build error:
> ---------------
> arch/arm/boot/compressed/string.c:24:1: error: attribute 'alias'
> argument not a string
>    24 | void *__memcpy(void *__dest, __const void *__src, size_t __n)
> __alias(memcpy);
>       | ^~~~
> arch/arm/boot/compressed/string.c:25:1: error: attribute 'alias'
> argument not a string
>    25 | void *__memmove(void *__dest, __const void *__src, size_t
> count) __alias(memmove);
>       | ^~~~
> arch/arm/boot/compressed/string.c:26:1: error: attribute 'alias'
> argument not a string
>    26 | void *__memset(void *s, int c, size_t count) __alias(memset);
>       | ^~~~
>
> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
>
> Build details link,
> https://builds.tuxbuild.com/1juBs4tXRA6Cwhd1Qnhh4vzCtDx/

This looks like a randconfig build.

Please drill down and try to report which combination of config
options that give rise to this problem so we have a chance of
amending it.

Yours,
Linus Walleij

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

[Linus Walleij]

On Fri, Nov 6, 2020 at 8:49 AM Naresh Kamboju <naresh.kamboju@linaro.org> wrote:

> arm KASAN build failure noticed on linux next 20201106 tag.
> gcc: 9.x
>
> Build error:
> ---------------
> arch/arm/boot/compressed/string.c:24:1: error: attribute 'alias'
> argument not a string
>    24 | void *__memcpy(void *__dest, __const void *__src, size_t __n)
> __alias(memcpy);
>       | ^~~~
> arch/arm/boot/compressed/string.c:25:1: error: attribute 'alias'
> argument not a string
>    25 | void *__memmove(void *__dest, __const void *__src, size_t
> count) __alias(memmove);
>       | ^~~~
> arch/arm/boot/compressed/string.c:26:1: error: attribute 'alias'
> argument not a string
>    26 | void *__memset(void *s, int c, size_t count) __alias(memset);
>       | ^~~~
>
> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
>
> Build details link,
> https://builds.tuxbuild.com/1juBs4tXRA6Cwhd1Qnhh4vzCtDx/

This looks like a randconfig build.

Please drill down and try to report which combination of config
options that give rise to this problem so we have a chance of
amending 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 2/5 v16] ARM: Replace string mem* functions for KASan

[Ard Biesheuvel]

On Fri, 6 Nov 2020 at 09:26, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Fri, Nov 6, 2020 at 8:49 AM Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
>
> > arm KASAN build failure noticed on linux next 20201106 tag.
> > gcc: 9.x
> >
> > Build error:
> > ---------------
> > arch/arm/boot/compressed/string.c:24:1: error: attribute 'alias'
> > argument not a string
> >    24 | void *__memcpy(void *__dest, __const void *__src, size_t __n)
> > __alias(memcpy);
> >       | ^~~~
> > arch/arm/boot/compressed/string.c:25:1: error: attribute 'alias'
> > argument not a string
> >    25 | void *__memmove(void *__dest, __const void *__src, size_t
> > count) __alias(memmove);
> >       | ^~~~
> > arch/arm/boot/compressed/string.c:26:1: error: attribute 'alias'
> > argument not a string
> >    26 | void *__memset(void *s, int c, size_t count) __alias(memset);
> >       | ^~~~
> >
> > Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> >
> > Build details link,
> > https://builds.tuxbuild.com/1juBs4tXRA6Cwhd1Qnhh4vzCtDx/
>
> This looks like a randconfig build.
>
> Please drill down and try to report which combination of config
> options that give rise to this problem so we have a chance of
> amending it.
>

AFAIK there is an incompatible change in -next to change the
definition of the __alias() macro

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

[Ard Biesheuvel]

On Fri, 6 Nov 2020 at 09:26, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Fri, Nov 6, 2020 at 8:49 AM Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
>
> > arm KASAN build failure noticed on linux next 20201106 tag.
> > gcc: 9.x
> >
> > Build error:
> > ---------------
> > arch/arm/boot/compressed/string.c:24:1: error: attribute 'alias'
> > argument not a string
> >    24 | void *__memcpy(void *__dest, __const void *__src, size_t __n)
> > __alias(memcpy);
> >       | ^~~~
> > arch/arm/boot/compressed/string.c:25:1: error: attribute 'alias'
> > argument not a string
> >    25 | void *__memmove(void *__dest, __const void *__src, size_t
> > count) __alias(memmove);
> >       | ^~~~
> > arch/arm/boot/compressed/string.c:26:1: error: attribute 'alias'
> > argument not a string
> >    26 | void *__memset(void *s, int c, size_t count) __alias(memset);
> >       | ^~~~
> >
> > Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> >
> > Build details link,
> > https://builds.tuxbuild.com/1juBs4tXRA6Cwhd1Qnhh4vzCtDx/
>
> This looks like a randconfig build.
>
> Please drill down and try to report which combination of config
> options that give rise to this problem so we have a chance of
> amending it.
>

AFAIK there is an incompatible change in -next to change the
definition of the __alias() macro

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

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

[Nathan Chancellor]

On Fri, Nov 06, 2020 at 09:28:09AM +0100, Ard Biesheuvel wrote:
> On Fri, 6 Nov 2020 at 09:26, Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > On Fri, Nov 6, 2020 at 8:49 AM Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> >
> > > arm KASAN build failure noticed on linux next 20201106 tag.
> > > gcc: 9.x
> > >
> > > Build error:
> > > ---------------
> > > arch/arm/boot/compressed/string.c:24:1: error: attribute 'alias'
> > > argument not a string
> > >    24 | void *__memcpy(void *__dest, __const void *__src, size_t __n)
> > > __alias(memcpy);
> > >       | ^~~~
> > > arch/arm/boot/compressed/string.c:25:1: error: attribute 'alias'
> > > argument not a string
> > >    25 | void *__memmove(void *__dest, __const void *__src, size_t
> > > count) __alias(memmove);
> > >       | ^~~~
> > > arch/arm/boot/compressed/string.c:26:1: error: attribute 'alias'
> > > argument not a string
> > >    26 | void *__memset(void *s, int c, size_t count) __alias(memset);
> > >       | ^~~~
> > >
> > > Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> > >
> > > Build details link,
> > > https://builds.tuxbuild.com/1juBs4tXRA6Cwhd1Qnhh4vzCtDx/
> >
> > This looks like a randconfig build.
> >
> > Please drill down and try to report which combination of config
> > options that give rise to this problem so we have a chance of
> > amending it.
> >
> 
> AFAIK there is an incompatible change in -next to change the
> definition of the __alias() macro

Indeed. The following diff needs to be applied as a fixup to
treewide-remove-stringification-from-__alias-macro-definition.patch in
mmotm.

Cheers,
Nathan

diff --git a/arch/arm/boot/compressed/string.c b/arch/arm/boot/compressed/string.c
index 8c0fa276d994..cc6198f8a348 100644
--- a/arch/arm/boot/compressed/string.c
+++ b/arch/arm/boot/compressed/string.c
@@ -21,9 +21,9 @@
 #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);
+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)

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

[Nathan Chancellor]

On Fri, Nov 06, 2020 at 09:28:09AM +0100, Ard Biesheuvel wrote:
> On Fri, 6 Nov 2020 at 09:26, Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > On Fri, Nov 6, 2020 at 8:49 AM Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> >
> > > arm KASAN build failure noticed on linux next 20201106 tag.
> > > gcc: 9.x
> > >
> > > Build error:
> > > ---------------
> > > arch/arm/boot/compressed/string.c:24:1: error: attribute 'alias'
> > > argument not a string
> > >    24 | void *__memcpy(void *__dest, __const void *__src, size_t __n)
> > > __alias(memcpy);
> > >       | ^~~~
> > > arch/arm/boot/compressed/string.c:25:1: error: attribute 'alias'
> > > argument not a string
> > >    25 | void *__memmove(void *__dest, __const void *__src, size_t
> > > count) __alias(memmove);
> > >       | ^~~~
> > > arch/arm/boot/compressed/string.c:26:1: error: attribute 'alias'
> > > argument not a string
> > >    26 | void *__memset(void *s, int c, size_t count) __alias(memset);
> > >       | ^~~~
> > >
> > > Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> > >
> > > Build details link,
> > > https://builds.tuxbuild.com/1juBs4tXRA6Cwhd1Qnhh4vzCtDx/
> >
> > This looks like a randconfig build.
> >
> > Please drill down and try to report which combination of config
> > options that give rise to this problem so we have a chance of
> > amending it.
> >
> 
> AFAIK there is an incompatible change in -next to change the
> definition of the __alias() macro

Indeed. The following diff needs to be applied as a fixup to
treewide-remove-stringification-from-__alias-macro-definition.patch in
mmotm.

Cheers,
Nathan

diff --git a/arch/arm/boot/compressed/string.c b/arch/arm/boot/compressed/string.c
index 8c0fa276d994..cc6198f8a348 100644
--- a/arch/arm/boot/compressed/string.c
+++ b/arch/arm/boot/compressed/string.c
@@ -21,9 +21,9 @@
 #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);
+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)

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

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

[Linus Walleij]

On Fri, Nov 6, 2020 at 10:44 AM Nathan Chancellor
<natechancellor@gmail.com> wrote:
> On Fri, Nov 06, 2020 at 09:28:09AM +0100, Ard Biesheuvel wrote:

> > AFAIK there is an incompatible change in -next to change the
> > definition of the __alias() macro
>
> Indeed. The following diff needs to be applied as a fixup to
> treewide-remove-stringification-from-__alias-macro-definition.patch in
> mmotm.
>
> Cheers,
> Nathan
>
> diff --git a/arch/arm/boot/compressed/string.c b/arch/arm/boot/compressed/string.c
> index 8c0fa276d994..cc6198f8a348 100644
> --- a/arch/arm/boot/compressed/string.c
> +++ b/arch/arm/boot/compressed/string.c
> @@ -21,9 +21,9 @@
>  #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);
> +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)

Aha. So shall we submit this to Russell? I figure that his git will not
build *without* the changes from mmotm?

That tree isn't using git either is it?

Is this one of those cases where we should ask Stephen R
to carry this patch on top of -next until the merge window?

Yours,
Linus Walleij

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

[Linus Walleij]

On Fri, Nov 6, 2020 at 10:44 AM Nathan Chancellor
<natechancellor@gmail.com> wrote:
> On Fri, Nov 06, 2020 at 09:28:09AM +0100, Ard Biesheuvel wrote:

> > AFAIK there is an incompatible change in -next to change the
> > definition of the __alias() macro
>
> Indeed. The following diff needs to be applied as a fixup to
> treewide-remove-stringification-from-__alias-macro-definition.patch in
> mmotm.
>
> Cheers,
> Nathan
>
> diff --git a/arch/arm/boot/compressed/string.c b/arch/arm/boot/compressed/string.c
> index 8c0fa276d994..cc6198f8a348 100644
> --- a/arch/arm/boot/compressed/string.c
> +++ b/arch/arm/boot/compressed/string.c
> @@ -21,9 +21,9 @@
>  #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);
> +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)

Aha. So shall we submit this to Russell? I figure that his git will not
build *without* the changes from mmotm?

That tree isn't using git either is it?

Is this one of those cases where we should ask Stephen R
to carry this patch on top of -next until the merge window?

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 2/5 v16] ARM: Replace string mem* functions for KASan

[Russell King - ARM Linux admin]

On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> On Fri, Nov 6, 2020 at 10:44 AM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> > On Fri, Nov 06, 2020 at 09:28:09AM +0100, Ard Biesheuvel wrote:
> 
> > > AFAIK there is an incompatible change in -next to change the
> > > definition of the __alias() macro
> >
> > Indeed. The following diff needs to be applied as a fixup to
> > treewide-remove-stringification-from-__alias-macro-definition.patch in
> > mmotm.
> >
> > Cheers,
> > Nathan
> >
> > diff --git a/arch/arm/boot/compressed/string.c b/arch/arm/boot/compressed/string.c
> > index 8c0fa276d994..cc6198f8a348 100644
> > --- a/arch/arm/boot/compressed/string.c
> > +++ b/arch/arm/boot/compressed/string.c
> > @@ -21,9 +21,9 @@
> >  #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);
> > +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)
> 
> Aha. So shall we submit this to Russell? I figure that his git will not
> build *without* the changes from mmotm?
> 
> That tree isn't using git either is it?
> 
> Is this one of those cases where we should ask Stephen R
> to carry this patch on top of -next until the merge window?

Another solution would be to drop 9017/2 ("Enable KASan for ARM")
until the following merge window, and queue up the non-conflicing
ARM KASan fixes in my "misc" branch along with the rest of KASan,
and the conflicting patches along with 9017/2 in the following
merge window.

That means delaying KASan enablement another three months or so,
but should result in less headaches about how to avoid build
breakage with different bits going through different trees.

Comments?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

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

[Russell King - ARM Linux admin]

On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> On Fri, Nov 6, 2020 at 10:44 AM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> > On Fri, Nov 06, 2020 at 09:28:09AM +0100, Ard Biesheuvel wrote:
> 
> > > AFAIK there is an incompatible change in -next to change the
> > > definition of the __alias() macro
> >
> > Indeed. The following diff needs to be applied as a fixup to
> > treewide-remove-stringification-from-__alias-macro-definition.patch in
> > mmotm.
> >
> > Cheers,
> > Nathan
> >
> > diff --git a/arch/arm/boot/compressed/string.c b/arch/arm/boot/compressed/string.c
> > index 8c0fa276d994..cc6198f8a348 100644
> > --- a/arch/arm/boot/compressed/string.c
> > +++ b/arch/arm/boot/compressed/string.c
> > @@ -21,9 +21,9 @@
> >  #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);
> > +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)
> 
> Aha. So shall we submit this to Russell? I figure that his git will not
> build *without* the changes from mmotm?
> 
> That tree isn't using git either is it?
> 
> Is this one of those cases where we should ask Stephen R
> to carry this patch on top of -next until the merge window?

Another solution would be to drop 9017/2 ("Enable KASan for ARM")
until the following merge window, and queue up the non-conflicing
ARM KASan fixes in my "misc" branch along with the rest of KASan,
and the conflicting patches along with 9017/2 in the following
merge window.

That means delaying KASan enablement another three months or so,
but should result in less headaches about how to avoid build
breakage with different bits going through different trees.

Comments?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

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

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

[Ard Biesheuvel]

On Fri, 6 Nov 2020 at 16:16, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> > On Fri, Nov 6, 2020 at 10:44 AM Nathan Chancellor
> > <natechancellor@gmail.com> wrote:
> > > On Fri, Nov 06, 2020 at 09:28:09AM +0100, Ard Biesheuvel wrote:
> >
> > > > AFAIK there is an incompatible change in -next to change the
> > > > definition of the __alias() macro
> > >
> > > Indeed. The following diff needs to be applied as a fixup to
> > > treewide-remove-stringification-from-__alias-macro-definition.patch in
> > > mmotm.
> > >
> > > Cheers,
> > > Nathan
> > >
> > > diff --git a/arch/arm/boot/compressed/string.c b/arch/arm/boot/compressed/string.c
> > > index 8c0fa276d994..cc6198f8a348 100644
> > > --- a/arch/arm/boot/compressed/string.c
> > > +++ b/arch/arm/boot/compressed/string.c
> > > @@ -21,9 +21,9 @@
> > >  #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);
> > > +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)
> >
> > Aha. So shall we submit this to Russell? I figure that his git will not
> > build *without* the changes from mmotm?
> >
> > That tree isn't using git either is it?
> >
> > Is this one of those cases where we should ask Stephen R
> > to carry this patch on top of -next until the merge window?
>
> Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> until the following merge window, and queue up the non-conflicing
> ARM KASan fixes in my "misc" branch along with the rest of KASan,
> and the conflicting patches along with 9017/2 in the following
> merge window.
>
> That means delaying KASan enablement another three months or so,
> but should result in less headaches about how to avoid build
> breakage with different bits going through different trees.
>
> Comments?
>

Alternatively, we could simply switch these to the bare
__attribute__((alias(".."))) syntax now, and revert that change again
one cycle later.

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

[Ard Biesheuvel]

On Fri, 6 Nov 2020 at 16:16, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> > On Fri, Nov 6, 2020 at 10:44 AM Nathan Chancellor
> > <natechancellor@gmail.com> wrote:
> > > On Fri, Nov 06, 2020 at 09:28:09AM +0100, Ard Biesheuvel wrote:
> >
> > > > AFAIK there is an incompatible change in -next to change the
> > > > definition of the __alias() macro
> > >
> > > Indeed. The following diff needs to be applied as a fixup to
> > > treewide-remove-stringification-from-__alias-macro-definition.patch in
> > > mmotm.
> > >
> > > Cheers,
> > > Nathan
> > >
> > > diff --git a/arch/arm/boot/compressed/string.c b/arch/arm/boot/compressed/string.c
> > > index 8c0fa276d994..cc6198f8a348 100644
> > > --- a/arch/arm/boot/compressed/string.c
> > > +++ b/arch/arm/boot/compressed/string.c
> > > @@ -21,9 +21,9 @@
> > >  #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);
> > > +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)
> >
> > Aha. So shall we submit this to Russell? I figure that his git will not
> > build *without* the changes from mmotm?
> >
> > That tree isn't using git either is it?
> >
> > Is this one of those cases where we should ask Stephen R
> > to carry this patch on top of -next until the merge window?
>
> Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> until the following merge window, and queue up the non-conflicing
> ARM KASan fixes in my "misc" branch along with the rest of KASan,
> and the conflicting patches along with 9017/2 in the following
> merge window.
>
> That means delaying KASan enablement another three months or so,
> but should result in less headaches about how to avoid build
> breakage with different bits going through different trees.
>
> Comments?
>

Alternatively, we could simply switch these to the bare
__attribute__((alias(".."))) syntax now, and revert that change again
one cycle later.

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

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

[Nathan Chancellor]

On Fri, Nov 06, 2020 at 03:15:54PM +0000, Russell King - ARM Linux admin wrote:
> On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> > On Fri, Nov 6, 2020 at 10:44 AM Nathan Chancellor
> > <natechancellor@gmail.com> wrote:
> > > On Fri, Nov 06, 2020 at 09:28:09AM +0100, Ard Biesheuvel wrote:
> > 
> > > > AFAIK there is an incompatible change in -next to change the
> > > > definition of the __alias() macro
> > >
> > > Indeed. The following diff needs to be applied as a fixup to
> > > treewide-remove-stringification-from-__alias-macro-definition.patch in
> > > mmotm.
> > >
> > > Cheers,
> > > Nathan
> > >
> > > diff --git a/arch/arm/boot/compressed/string.c b/arch/arm/boot/compressed/string.c
> > > index 8c0fa276d994..cc6198f8a348 100644
> > > --- a/arch/arm/boot/compressed/string.c
> > > +++ b/arch/arm/boot/compressed/string.c
> > > @@ -21,9 +21,9 @@
> > >  #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);
> > > +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)
> > 
> > Aha. So shall we submit this to Russell? I figure that his git will not
> > build *without* the changes from mmotm?

Yeah, I do not think that you can apply that diff to Russell's tree
without the patch from -mm.

> > That tree isn't using git either is it?
> > 
> > Is this one of those cases where we should ask Stephen R
> > to carry this patch on top of -next until the merge window?

I believe so, I do not think Stephen has any issues with carrying that
diff to keep everything building properly (although I won't speak for
him heh).

> Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> until the following merge window, and queue up the non-conflicing
> ARM KASan fixes in my "misc" branch along with the rest of KASan,
> and the conflicting patches along with 9017/2 in the following
> merge window.
> 
> That means delaying KASan enablement another three months or so,
> but should result in less headaches about how to avoid build
> breakage with different bits going through different trees.
> 
> Comments?

That could certainly work but as far as I am aware, that is really the
only breakage. In theory, Andrew could just hold off on sending that
patch until after yours is merged into Linus' tree so that it could be
added to that patch and everything stays building properly. Requires a
minor amount of coordination but that would avoid delaying KASAN
enablement for three months. I do not have any preference since this is
not my code.

Cheers,
Nathan

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

[Nathan Chancellor]

On Fri, Nov 06, 2020 at 03:15:54PM +0000, Russell King - ARM Linux admin wrote:
> On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> > On Fri, Nov 6, 2020 at 10:44 AM Nathan Chancellor
> > <natechancellor@gmail.com> wrote:
> > > On Fri, Nov 06, 2020 at 09:28:09AM +0100, Ard Biesheuvel wrote:
> > 
> > > > AFAIK there is an incompatible change in -next to change the
> > > > definition of the __alias() macro
> > >
> > > Indeed. The following diff needs to be applied as a fixup to
> > > treewide-remove-stringification-from-__alias-macro-definition.patch in
> > > mmotm.
> > >
> > > Cheers,
> > > Nathan
> > >
> > > diff --git a/arch/arm/boot/compressed/string.c b/arch/arm/boot/compressed/string.c
> > > index 8c0fa276d994..cc6198f8a348 100644
> > > --- a/arch/arm/boot/compressed/string.c
> > > +++ b/arch/arm/boot/compressed/string.c
> > > @@ -21,9 +21,9 @@
> > >  #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);
> > > +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)
> > 
> > Aha. So shall we submit this to Russell? I figure that his git will not
> > build *without* the changes from mmotm?

Yeah, I do not think that you can apply that diff to Russell's tree
without the patch from -mm.

> > That tree isn't using git either is it?
> > 
> > Is this one of those cases where we should ask Stephen R
> > to carry this patch on top of -next until the merge window?

I believe so, I do not think Stephen has any issues with carrying that
diff to keep everything building properly (although I won't speak for
him heh).

> Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> until the following merge window, and queue up the non-conflicing
> ARM KASan fixes in my "misc" branch along with the rest of KASan,
> and the conflicting patches along with 9017/2 in the following
> merge window.
> 
> That means delaying KASan enablement another three months or so,
> but should result in less headaches about how to avoid build
> breakage with different bits going through different trees.
> 
> Comments?

That could certainly work but as far as I am aware, that is really the
only breakage. In theory, Andrew could just hold off on sending that
patch until after yours is merged into Linus' tree so that it could be
added to that patch and everything stays building properly. Requires a
minor amount of coordination but that would avoid delaying KASAN
enablement for three months. I do not have any preference since this is
not my code.

Cheers,
Nathan

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

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

[Linus Walleij]

On Fri, Nov 6, 2020 at 4:16 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
> On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:

> > Aha. So shall we submit this to Russell? I figure that his git will not
> > build *without* the changes from mmotm?
> >
> > That tree isn't using git either is it?
> >
> > Is this one of those cases where we should ask Stephen R
> > to carry this patch on top of -next until the merge window?
>
> Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> until the following merge window, and queue up the non-conflicing
> ARM KASan fixes in my "misc" branch along with the rest of KASan,
> and the conflicting patches along with 9017/2 in the following
> merge window.
>
> That means delaying KASan enablement another three months or so,
> but should result in less headaches about how to avoid build
> breakage with different bits going through different trees.
>
> Comments?

I suppose I would survive deferring it. Or we could merge the
smaller enablement patch towards the end of the merge
window once the MM changes are in.

If it is just *one* patch in the MM tree I suppose we could also
just apply that one patch also to the ARM tree, and then this
fixup on top. It does look a bit convoluted in the git history with
two hashes and the same patch twice, but it's what I've done
at times when there was no other choice that doing that or
deferring development. It works as long as the patches are
textually identical: git will cope.
If there is a risk that the patch in MM changes this latter
approach is a no-go.

Yours,
Linus Walleij

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

[Linus Walleij]

On Fri, Nov 6, 2020 at 4:16 PM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
> On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:

> > Aha. So shall we submit this to Russell? I figure that his git will not
> > build *without* the changes from mmotm?
> >
> > That tree isn't using git either is it?
> >
> > Is this one of those cases where we should ask Stephen R
> > to carry this patch on top of -next until the merge window?
>
> Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> until the following merge window, and queue up the non-conflicing
> ARM KASan fixes in my "misc" branch along with the rest of KASan,
> and the conflicting patches along with 9017/2 in the following
> merge window.
>
> That means delaying KASan enablement another three months or so,
> but should result in less headaches about how to avoid build
> breakage with different bits going through different trees.
>
> Comments?

I suppose I would survive deferring it. Or we could merge the
smaller enablement patch towards the end of the merge
window once the MM changes are in.

If it is just *one* patch in the MM tree I suppose we could also
just apply that one patch also to the ARM tree, and then this
fixup on top. It does look a bit convoluted in the git history with
two hashes and the same patch twice, but it's what I've done
at times when there was no other choice that doing that or
deferring development. It works as long as the patches are
textually identical: git will cope.
If there is a risk that the patch in MM changes this latter
approach is a no-go.

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 2/5 v16] ARM: Replace string mem* functions for KASan

[Russell King - ARM Linux admin]

On Mon, Nov 09, 2020 at 05:02:09PM +0100, Linus Walleij wrote:
> On Fri, Nov 6, 2020 at 4:16 PM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> > On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> 
> > > Aha. So shall we submit this to Russell? I figure that his git will not
> > > build *without* the changes from mmotm?
> > >
> > > That tree isn't using git either is it?
> > >
> > > Is this one of those cases where we should ask Stephen R
> > > to carry this patch on top of -next until the merge window?
> >
> > Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> > until the following merge window, and queue up the non-conflicing
> > ARM KASan fixes in my "misc" branch along with the rest of KASan,
> > and the conflicting patches along with 9017/2 in the following
> > merge window.
> >
> > That means delaying KASan enablement another three months or so,
> > but should result in less headaches about how to avoid build
> > breakage with different bits going through different trees.
> >
> > Comments?
> 
> I suppose I would survive deferring it. Or we could merge the
> smaller enablement patch towards the end of the merge
> window once the MM changes are in.
> 
> If it is just *one* patch in the MM tree I suppose we could also
> just apply that one patch also to the ARM tree, and then this
> fixup on top. It does look a bit convoluted in the git history with
> two hashes and the same patch twice, but it's what I've done
> at times when there was no other choice that doing that or
> deferring development. It works as long as the patches are
> textually identical: git will cope.

I thought there was a problem that if I applied the fix then my tree
no longer builds without the changes in -mm?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

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

[Russell King - ARM Linux admin]

On Mon, Nov 09, 2020 at 05:02:09PM +0100, Linus Walleij wrote:
> On Fri, Nov 6, 2020 at 4:16 PM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> > On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> 
> > > Aha. So shall we submit this to Russell? I figure that his git will not
> > > build *without* the changes from mmotm?
> > >
> > > That tree isn't using git either is it?
> > >
> > > Is this one of those cases where we should ask Stephen R
> > > to carry this patch on top of -next until the merge window?
> >
> > Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> > until the following merge window, and queue up the non-conflicing
> > ARM KASan fixes in my "misc" branch along with the rest of KASan,
> > and the conflicting patches along with 9017/2 in the following
> > merge window.
> >
> > That means delaying KASan enablement another three months or so,
> > but should result in less headaches about how to avoid build
> > breakage with different bits going through different trees.
> >
> > Comments?
> 
> I suppose I would survive deferring it. Or we could merge the
> smaller enablement patch towards the end of the merge
> window once the MM changes are in.
> 
> If it is just *one* patch in the MM tree I suppose we could also
> just apply that one patch also to the ARM tree, and then this
> fixup on top. It does look a bit convoluted in the git history with
> two hashes and the same patch twice, but it's what I've done
> at times when there was no other choice that doing that or
> deferring development. It works as long as the patches are
> textually identical: git will cope.

I thought there was a problem that if I applied the fix then my tree
no longer builds without the changes in -mm?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

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

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

[Ard Biesheuvel]

On Mon, 9 Nov 2020 at 17:07, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Mon, Nov 09, 2020 at 05:02:09PM +0100, Linus Walleij wrote:
> > On Fri, Nov 6, 2020 at 4:16 PM Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > > On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> >
> > > > Aha. So shall we submit this to Russell? I figure that his git will not
> > > > build *without* the changes from mmotm?
> > > >
> > > > That tree isn't using git either is it?
> > > >
> > > > Is this one of those cases where we should ask Stephen R
> > > > to carry this patch on top of -next until the merge window?
> > >
> > > Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> > > until the following merge window, and queue up the non-conflicing
> > > ARM KASan fixes in my "misc" branch along with the rest of KASan,
> > > and the conflicting patches along with 9017/2 in the following
> > > merge window.
> > >
> > > That means delaying KASan enablement another three months or so,
> > > but should result in less headaches about how to avoid build
> > > breakage with different bits going through different trees.
> > >
> > > Comments?
> >
> > I suppose I would survive deferring it. Or we could merge the
> > smaller enablement patch towards the end of the merge
> > window once the MM changes are in.
> >
> > If it is just *one* patch in the MM tree I suppose we could also
> > just apply that one patch also to the ARM tree, and then this
> > fixup on top. It does look a bit convoluted in the git history with
> > two hashes and the same patch twice, but it's what I've done
> > at times when there was no other choice that doing that or
> > deferring development. It works as long as the patches are
> > textually identical: git will cope.
>
> I thought there was a problem that if I applied the fix then my tree
> no longer builds without the changes in -mm?
>

Indeed. Someone is changing the __alias() wrappers [for no good reason
afaict] in a way that does not allow for new users of those wrappers
to come in concurrently.

Hency my suggestion to switch to the raw __attribute__((alias("..")))
notation for the time being, and switch back to __alias() somewhere
after v5.11-rc1.

Or we might add this to the file in question

#undef __alias
#define __alias(symbol) __attribute__((__alias__(symbol)))

and switch to the quoted versions of the identifier. Then we can just
drop these two lines again later, after v5.11-rc1

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

[Ard Biesheuvel]

On Mon, 9 Nov 2020 at 17:07, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Mon, Nov 09, 2020 at 05:02:09PM +0100, Linus Walleij wrote:
> > On Fri, Nov 6, 2020 at 4:16 PM Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > > On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> >
> > > > Aha. So shall we submit this to Russell? I figure that his git will not
> > > > build *without* the changes from mmotm?
> > > >
> > > > That tree isn't using git either is it?
> > > >
> > > > Is this one of those cases where we should ask Stephen R
> > > > to carry this patch on top of -next until the merge window?
> > >
> > > Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> > > until the following merge window, and queue up the non-conflicing
> > > ARM KASan fixes in my "misc" branch along with the rest of KASan,
> > > and the conflicting patches along with 9017/2 in the following
> > > merge window.
> > >
> > > That means delaying KASan enablement another three months or so,
> > > but should result in less headaches about how to avoid build
> > > breakage with different bits going through different trees.
> > >
> > > Comments?
> >
> > I suppose I would survive deferring it. Or we could merge the
> > smaller enablement patch towards the end of the merge
> > window once the MM changes are in.
> >
> > If it is just *one* patch in the MM tree I suppose we could also
> > just apply that one patch also to the ARM tree, and then this
> > fixup on top. It does look a bit convoluted in the git history with
> > two hashes and the same patch twice, but it's what I've done
> > at times when there was no other choice that doing that or
> > deferring development. It works as long as the patches are
> > textually identical: git will cope.
>
> I thought there was a problem that if I applied the fix then my tree
> no longer builds without the changes in -mm?
>

Indeed. Someone is changing the __alias() wrappers [for no good reason
afaict] in a way that does not allow for new users of those wrappers
to come in concurrently.

Hency my suggestion to switch to the raw __attribute__((alias("..")))
notation for the time being, and switch back to __alias() somewhere
after v5.11-rc1.

Or we might add this to the file in question

#undef __alias
#define __alias(symbol) __attribute__((__alias__(symbol)))

and switch to the quoted versions of the identifier. Then we can just
drop these two lines again later, after v5.11-rc1

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

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

[Linus Walleij]

On Tue, Nov 10, 2020 at 1:05 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> On Mon, 9 Nov 2020 at 17:07, Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > On Mon, Nov 09, 2020 at 05:02:09PM +0100, Linus Walleij wrote:
> > > On Fri, Nov 6, 2020 at 4:16 PM Russell King - ARM Linux admin
> > > <linux@armlinux.org.uk> wrote:
> > > > On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> > >
> > > > > Aha. So shall we submit this to Russell? I figure that his git will not
> > > > > build *without* the changes from mmotm?
> > > > >
> > > > > That tree isn't using git either is it?
> > > > >
> > > > > Is this one of those cases where we should ask Stephen R
> > > > > to carry this patch on top of -next until the merge window?
> > > >
> > > > Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> > > > until the following merge window, and queue up the non-conflicing
> > > > ARM KASan fixes in my "misc" branch along with the rest of KASan,
> > > > and the conflicting patches along with 9017/2 in the following
> > > > merge window.
> > > >
> > > > That means delaying KASan enablement another three months or so,
> > > > but should result in less headaches about how to avoid build
> > > > breakage with different bits going through different trees.
> > > >
> > > > Comments?
> > >
> > > I suppose I would survive deferring it. Or we could merge the
> > > smaller enablement patch towards the end of the merge
> > > window once the MM changes are in.
> > >
> > > If it is just *one* patch in the MM tree I suppose we could also
> > > just apply that one patch also to the ARM tree, and then this
> > > fixup on top. It does look a bit convoluted in the git history with
> > > two hashes and the same patch twice, but it's what I've done
> > > at times when there was no other choice that doing that or
> > > deferring development. It works as long as the patches are
> > > textually identical: git will cope.
> >
> > I thought there was a problem that if I applied the fix then my tree
> > no longer builds without the changes in -mm?
> >
>
> Indeed. Someone is changing the __alias() wrappers [for no good reason
> afaict] in a way that does not allow for new users of those wrappers
> to come in concurrently.
>
> Hency my suggestion to switch to the raw __attribute__((alias("..")))
> notation for the time being, and switch back to __alias() somewhere
> after v5.11-rc1.
>
> Or we might add this to the file in question
>
> #undef __alias
> #define __alias(symbol) __attribute__((__alias__(symbol)))
>
> and switch to the quoted versions of the identifier. Then we can just
> drop these two lines again later, after v5.11-rc1

I was under the impression that there was some "post-next"
trick that mmot apply this patch after -next has been merged
so it's solved now?

Yours,
Linus Walleij

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

[Linus Walleij]

On Tue, Nov 10, 2020 at 1:05 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> On Mon, 9 Nov 2020 at 17:07, Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > On Mon, Nov 09, 2020 at 05:02:09PM +0100, Linus Walleij wrote:
> > > On Fri, Nov 6, 2020 at 4:16 PM Russell King - ARM Linux admin
> > > <linux@armlinux.org.uk> wrote:
> > > > On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> > >
> > > > > Aha. So shall we submit this to Russell? I figure that his git will not
> > > > > build *without* the changes from mmotm?
> > > > >
> > > > > That tree isn't using git either is it?
> > > > >
> > > > > Is this one of those cases where we should ask Stephen R
> > > > > to carry this patch on top of -next until the merge window?
> > > >
> > > > Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> > > > until the following merge window, and queue up the non-conflicing
> > > > ARM KASan fixes in my "misc" branch along with the rest of KASan,
> > > > and the conflicting patches along with 9017/2 in the following
> > > > merge window.
> > > >
> > > > That means delaying KASan enablement another three months or so,
> > > > but should result in less headaches about how to avoid build
> > > > breakage with different bits going through different trees.
> > > >
> > > > Comments?
> > >
> > > I suppose I would survive deferring it. Or we could merge the
> > > smaller enablement patch towards the end of the merge
> > > window once the MM changes are in.
> > >
> > > If it is just *one* patch in the MM tree I suppose we could also
> > > just apply that one patch also to the ARM tree, and then this
> > > fixup on top. It does look a bit convoluted in the git history with
> > > two hashes and the same patch twice, but it's what I've done
> > > at times when there was no other choice that doing that or
> > > deferring development. It works as long as the patches are
> > > textually identical: git will cope.
> >
> > I thought there was a problem that if I applied the fix then my tree
> > no longer builds without the changes in -mm?
> >
>
> Indeed. Someone is changing the __alias() wrappers [for no good reason
> afaict] in a way that does not allow for new users of those wrappers
> to come in concurrently.
>
> Hency my suggestion to switch to the raw __attribute__((alias("..")))
> notation for the time being, and switch back to __alias() somewhere
> after v5.11-rc1.
>
> Or we might add this to the file in question
>
> #undef __alias
> #define __alias(symbol) __attribute__((__alias__(symbol)))
>
> and switch to the quoted versions of the identifier. Then we can just
> drop these two lines again later, after v5.11-rc1

I was under the impression that there was some "post-next"
trick that mmot apply this patch after -next has been merged
so it's solved now?

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 2/5 v16] ARM: Replace string mem* functions for KASan

[Ard Biesheuvel]

On Thu, 12 Nov 2020 at 14:51, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Tue, Nov 10, 2020 at 1:05 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > On Mon, 9 Nov 2020 at 17:07, Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > >
> > > On Mon, Nov 09, 2020 at 05:02:09PM +0100, Linus Walleij wrote:
> > > > On Fri, Nov 6, 2020 at 4:16 PM Russell King - ARM Linux admin
> > > > <linux@armlinux.org.uk> wrote:
> > > > > On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> > > >
> > > > > > Aha. So shall we submit this to Russell? I figure that his git will not
> > > > > > build *without* the changes from mmotm?
> > > > > >
> > > > > > That tree isn't using git either is it?
> > > > > >
> > > > > > Is this one of those cases where we should ask Stephen R
> > > > > > to carry this patch on top of -next until the merge window?
> > > > >
> > > > > Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> > > > > until the following merge window, and queue up the non-conflicing
> > > > > ARM KASan fixes in my "misc" branch along with the rest of KASan,
> > > > > and the conflicting patches along with 9017/2 in the following
> > > > > merge window.
> > > > >
> > > > > That means delaying KASan enablement another three months or so,
> > > > > but should result in less headaches about how to avoid build
> > > > > breakage with different bits going through different trees.
> > > > >
> > > > > Comments?
> > > >
> > > > I suppose I would survive deferring it. Or we could merge the
> > > > smaller enablement patch towards the end of the merge
> > > > window once the MM changes are in.
> > > >
> > > > If it is just *one* patch in the MM tree I suppose we could also
> > > > just apply that one patch also to the ARM tree, and then this
> > > > fixup on top. It does look a bit convoluted in the git history with
> > > > two hashes and the same patch twice, but it's what I've done
> > > > at times when there was no other choice that doing that or
> > > > deferring development. It works as long as the patches are
> > > > textually identical: git will cope.
> > >
> > > I thought there was a problem that if I applied the fix then my tree
> > > no longer builds without the changes in -mm?
> > >
> >
> > Indeed. Someone is changing the __alias() wrappers [for no good reason
> > afaict] in a way that does not allow for new users of those wrappers
> > to come in concurrently.
> >
> > Hency my suggestion to switch to the raw __attribute__((alias("..")))
> > notation for the time being, and switch back to __alias() somewhere
> > after v5.11-rc1.
> >
> > Or we might add this to the file in question
> >
> > #undef __alias
> > #define __alias(symbol) __attribute__((__alias__(symbol)))
> >
> > and switch to the quoted versions of the identifier. Then we can just
> > drop these two lines again later, after v5.11-rc1
>
> I was under the impression that there was some "post-next"
> trick that mmot apply this patch after -next has been merged
> so it's solved now?
>

Yes, it appears that [0] has been picked up, I guess we weren't cc'ed
on the version that was sent to akpm [which is fine btw, although a
followup reply here that things are all good now would have been
appreciated]


https://lore.kernel.org/linux-arm-kernel/20201109001712.3384097-1-natechancellor@gmail.com/

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

[Ard Biesheuvel]

On Thu, 12 Nov 2020 at 14:51, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Tue, Nov 10, 2020 at 1:05 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > On Mon, 9 Nov 2020 at 17:07, Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > >
> > > On Mon, Nov 09, 2020 at 05:02:09PM +0100, Linus Walleij wrote:
> > > > On Fri, Nov 6, 2020 at 4:16 PM Russell King - ARM Linux admin
> > > > <linux@armlinux.org.uk> wrote:
> > > > > On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> > > >
> > > > > > Aha. So shall we submit this to Russell? I figure that his git will not
> > > > > > build *without* the changes from mmotm?
> > > > > >
> > > > > > That tree isn't using git either is it?
> > > > > >
> > > > > > Is this one of those cases where we should ask Stephen R
> > > > > > to carry this patch on top of -next until the merge window?
> > > > >
> > > > > Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> > > > > until the following merge window, and queue up the non-conflicing
> > > > > ARM KASan fixes in my "misc" branch along with the rest of KASan,
> > > > > and the conflicting patches along with 9017/2 in the following
> > > > > merge window.
> > > > >
> > > > > That means delaying KASan enablement another three months or so,
> > > > > but should result in less headaches about how to avoid build
> > > > > breakage with different bits going through different trees.
> > > > >
> > > > > Comments?
> > > >
> > > > I suppose I would survive deferring it. Or we could merge the
> > > > smaller enablement patch towards the end of the merge
> > > > window once the MM changes are in.
> > > >
> > > > If it is just *one* patch in the MM tree I suppose we could also
> > > > just apply that one patch also to the ARM tree, and then this
> > > > fixup on top. It does look a bit convoluted in the git history with
> > > > two hashes and the same patch twice, but it's what I've done
> > > > at times when there was no other choice that doing that or
> > > > deferring development. It works as long as the patches are
> > > > textually identical: git will cope.
> > >
> > > I thought there was a problem that if I applied the fix then my tree
> > > no longer builds without the changes in -mm?
> > >
> >
> > Indeed. Someone is changing the __alias() wrappers [for no good reason
> > afaict] in a way that does not allow for new users of those wrappers
> > to come in concurrently.
> >
> > Hency my suggestion to switch to the raw __attribute__((alias("..")))
> > notation for the time being, and switch back to __alias() somewhere
> > after v5.11-rc1.
> >
> > Or we might add this to the file in question
> >
> > #undef __alias
> > #define __alias(symbol) __attribute__((__alias__(symbol)))
> >
> > and switch to the quoted versions of the identifier. Then we can just
> > drop these two lines again later, after v5.11-rc1
>
> I was under the impression that there was some "post-next"
> trick that mmot apply this patch after -next has been merged
> so it's solved now?
>

Yes, it appears that [0] has been picked up, I guess we weren't cc'ed
on the version that was sent to akpm [which is fine btw, although a
followup reply here that things are all good now would have been
appreciated]


https://lore.kernel.org/linux-arm-kernel/20201109001712.3384097-1-natechancellor@gmail.com/

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

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

[Nathan Chancellor]

On Thu, Nov 12, 2020 at 04:05:52PM +0100, Ard Biesheuvel wrote:
> On Thu, 12 Nov 2020 at 14:51, Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > On Tue, Nov 10, 2020 at 1:05 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > On Mon, 9 Nov 2020 at 17:07, Russell King - ARM Linux admin
> > > <linux@armlinux.org.uk> wrote:
> > > >
> > > > On Mon, Nov 09, 2020 at 05:02:09PM +0100, Linus Walleij wrote:
> > > > > On Fri, Nov 6, 2020 at 4:16 PM Russell King - ARM Linux admin
> > > > > <linux@armlinux.org.uk> wrote:
> > > > > > On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> > > > >
> > > > > > > Aha. So shall we submit this to Russell? I figure that his git will not
> > > > > > > build *without* the changes from mmotm?
> > > > > > >
> > > > > > > That tree isn't using git either is it?
> > > > > > >
> > > > > > > Is this one of those cases where we should ask Stephen R
> > > > > > > to carry this patch on top of -next until the merge window?
> > > > > >
> > > > > > Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> > > > > > until the following merge window, and queue up the non-conflicing
> > > > > > ARM KASan fixes in my "misc" branch along with the rest of KASan,
> > > > > > and the conflicting patches along with 9017/2 in the following
> > > > > > merge window.
> > > > > >
> > > > > > That means delaying KASan enablement another three months or so,
> > > > > > but should result in less headaches about how to avoid build
> > > > > > breakage with different bits going through different trees.
> > > > > >
> > > > > > Comments?
> > > > >
> > > > > I suppose I would survive deferring it. Or we could merge the
> > > > > smaller enablement patch towards the end of the merge
> > > > > window once the MM changes are in.
> > > > >
> > > > > If it is just *one* patch in the MM tree I suppose we could also
> > > > > just apply that one patch also to the ARM tree, and then this
> > > > > fixup on top. It does look a bit convoluted in the git history with
> > > > > two hashes and the same patch twice, but it's what I've done
> > > > > at times when there was no other choice that doing that or
> > > > > deferring development. It works as long as the patches are
> > > > > textually identical: git will cope.
> > > >
> > > > I thought there was a problem that if I applied the fix then my tree
> > > > no longer builds without the changes in -mm?
> > > >
> > >
> > > Indeed. Someone is changing the __alias() wrappers [for no good reason
> > > afaict] in a way that does not allow for new users of those wrappers
> > > to come in concurrently.
> > >
> > > Hency my suggestion to switch to the raw __attribute__((alias("..")))
> > > notation for the time being, and switch back to __alias() somewhere
> > > after v5.11-rc1.
> > >
> > > Or we might add this to the file in question
> > >
> > > #undef __alias
> > > #define __alias(symbol) __attribute__((__alias__(symbol)))
> > >
> > > and switch to the quoted versions of the identifier. Then we can just
> > > drop these two lines again later, after v5.11-rc1
> >
> > I was under the impression that there was some "post-next"
> > trick that mmot apply this patch after -next has been merged
> > so it's solved now?
> >
> 
> Yes, it appears that [0] has been picked up, I guess we weren't cc'ed
> on the version that was sent to akpm [which is fine btw, although a
> followup reply here that things are all good now would have been
> appreciated]
> 
> 
> https://lore.kernel.org/linux-arm-kernel/20201109001712.3384097-1-natechancellor@gmail.com/

Hi Ard,

Odd, you were on the list of people to receive that patch and you acked
it but it seems that Andrew did not CC you when he actually applied the
patch:

https://lore.kernel.org/mm-commits/20201110212436.yGYhesom8%25akpm@linux-foundation.org/

My apologies for not following up, we appear to be all good now for the
time being (aside from the futex issue that I reported earlier).

Cheers,
Nathan

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

[Nathan Chancellor]

On Thu, Nov 12, 2020 at 04:05:52PM +0100, Ard Biesheuvel wrote:
> On Thu, 12 Nov 2020 at 14:51, Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > On Tue, Nov 10, 2020 at 1:05 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > On Mon, 9 Nov 2020 at 17:07, Russell King - ARM Linux admin
> > > <linux@armlinux.org.uk> wrote:
> > > >
> > > > On Mon, Nov 09, 2020 at 05:02:09PM +0100, Linus Walleij wrote:
> > > > > On Fri, Nov 6, 2020 at 4:16 PM Russell King - ARM Linux admin
> > > > > <linux@armlinux.org.uk> wrote:
> > > > > > On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> > > > >
> > > > > > > Aha. So shall we submit this to Russell? I figure that his git will not
> > > > > > > build *without* the changes from mmotm?
> > > > > > >
> > > > > > > That tree isn't using git either is it?
> > > > > > >
> > > > > > > Is this one of those cases where we should ask Stephen R
> > > > > > > to carry this patch on top of -next until the merge window?
> > > > > >
> > > > > > Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> > > > > > until the following merge window, and queue up the non-conflicing
> > > > > > ARM KASan fixes in my "misc" branch along with the rest of KASan,
> > > > > > and the conflicting patches along with 9017/2 in the following
> > > > > > merge window.
> > > > > >
> > > > > > That means delaying KASan enablement another three months or so,
> > > > > > but should result in less headaches about how to avoid build
> > > > > > breakage with different bits going through different trees.
> > > > > >
> > > > > > Comments?
> > > > >
> > > > > I suppose I would survive deferring it. Or we could merge the
> > > > > smaller enablement patch towards the end of the merge
> > > > > window once the MM changes are in.
> > > > >
> > > > > If it is just *one* patch in the MM tree I suppose we could also
> > > > > just apply that one patch also to the ARM tree, and then this
> > > > > fixup on top. It does look a bit convoluted in the git history with
> > > > > two hashes and the same patch twice, but it's what I've done
> > > > > at times when there was no other choice that doing that or
> > > > > deferring development. It works as long as the patches are
> > > > > textually identical: git will cope.
> > > >
> > > > I thought there was a problem that if I applied the fix then my tree
> > > > no longer builds without the changes in -mm?
> > > >
> > >
> > > Indeed. Someone is changing the __alias() wrappers [for no good reason
> > > afaict] in a way that does not allow for new users of those wrappers
> > > to come in concurrently.
> > >
> > > Hency my suggestion to switch to the raw __attribute__((alias("..")))
> > > notation for the time being, and switch back to __alias() somewhere
> > > after v5.11-rc1.
> > >
> > > Or we might add this to the file in question
> > >
> > > #undef __alias
> > > #define __alias(symbol) __attribute__((__alias__(symbol)))
> > >
> > > and switch to the quoted versions of the identifier. Then we can just
> > > drop these two lines again later, after v5.11-rc1
> >
> > I was under the impression that there was some "post-next"
> > trick that mmot apply this patch after -next has been merged
> > so it's solved now?
> >
> 
> Yes, it appears that [0] has been picked up, I guess we weren't cc'ed
> on the version that was sent to akpm [which is fine btw, although a
> followup reply here that things are all good now would have been
> appreciated]
> 
> 
> https://lore.kernel.org/linux-arm-kernel/20201109001712.3384097-1-natechancellor@gmail.com/

Hi Ard,

Odd, you were on the list of people to receive that patch and you acked
it but it seems that Andrew did not CC you when he actually applied the
patch:

https://lore.kernel.org/mm-commits/20201110212436.yGYhesom8%25akpm@linux-foundation.org/

My apologies for not following up, we appear to be all good now for the
time being (aside from the futex issue that I reported earlier).

Cheers,
Nathan

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

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

[Ard Biesheuvel]

On Thu, 12 Nov 2020 at 18:52, Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> On Thu, Nov 12, 2020 at 04:05:52PM +0100, Ard Biesheuvel wrote:
> > On Thu, 12 Nov 2020 at 14:51, Linus Walleij <linus.walleij@linaro.org> wrote:
> > >
> > > On Tue, Nov 10, 2020 at 1:05 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > > On Mon, 9 Nov 2020 at 17:07, Russell King - ARM Linux admin
> > > > <linux@armlinux.org.uk> wrote:
> > > > >
> > > > > On Mon, Nov 09, 2020 at 05:02:09PM +0100, Linus Walleij wrote:
> > > > > > On Fri, Nov 6, 2020 at 4:16 PM Russell King - ARM Linux admin
> > > > > > <linux@armlinux.org.uk> wrote:
> > > > > > > On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> > > > > >
> > > > > > > > Aha. So shall we submit this to Russell? I figure that his git will not
> > > > > > > > build *without* the changes from mmotm?
> > > > > > > >
> > > > > > > > That tree isn't using git either is it?
> > > > > > > >
> > > > > > > > Is this one of those cases where we should ask Stephen R
> > > > > > > > to carry this patch on top of -next until the merge window?
> > > > > > >
> > > > > > > Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> > > > > > > until the following merge window, and queue up the non-conflicing
> > > > > > > ARM KASan fixes in my "misc" branch along with the rest of KASan,
> > > > > > > and the conflicting patches along with 9017/2 in the following
> > > > > > > merge window.
> > > > > > >
> > > > > > > That means delaying KASan enablement another three months or so,
> > > > > > > but should result in less headaches about how to avoid build
> > > > > > > breakage with different bits going through different trees.
> > > > > > >
> > > > > > > Comments?
> > > > > >
> > > > > > I suppose I would survive deferring it. Or we could merge the
> > > > > > smaller enablement patch towards the end of the merge
> > > > > > window once the MM changes are in.
> > > > > >
> > > > > > If it is just *one* patch in the MM tree I suppose we could also
> > > > > > just apply that one patch also to the ARM tree, and then this
> > > > > > fixup on top. It does look a bit convoluted in the git history with
> > > > > > two hashes and the same patch twice, but it's what I've done
> > > > > > at times when there was no other choice that doing that or
> > > > > > deferring development. It works as long as the patches are
> > > > > > textually identical: git will cope.
> > > > >
> > > > > I thought there was a problem that if I applied the fix then my tree
> > > > > no longer builds without the changes in -mm?
> > > > >
> > > >
> > > > Indeed. Someone is changing the __alias() wrappers [for no good reason
> > > > afaict] in a way that does not allow for new users of those wrappers
> > > > to come in concurrently.
> > > >
> > > > Hency my suggestion to switch to the raw __attribute__((alias("..")))
> > > > notation for the time being, and switch back to __alias() somewhere
> > > > after v5.11-rc1.
> > > >
> > > > Or we might add this to the file in question
> > > >
> > > > #undef __alias
> > > > #define __alias(symbol) __attribute__((__alias__(symbol)))
> > > >
> > > > and switch to the quoted versions of the identifier. Then we can just
> > > > drop these two lines again later, after v5.11-rc1
> > >
> > > I was under the impression that there was some "post-next"
> > > trick that mmot apply this patch after -next has been merged
> > > so it's solved now?
> > >
> >
> > Yes, it appears that [0] has been picked up, I guess we weren't cc'ed
> > on the version that was sent to akpm [which is fine btw, although a
> > followup reply here that things are all good now would have been
> > appreciated]
> >
> >
> > https://lore.kernel.org/linux-arm-kernel/20201109001712.3384097-1-natechancellor@gmail.com/
>
> Hi Ard,
>
> Odd, you were on the list of people to receive that patch and you acked
> it but it seems that Andrew did not CC you when he actually applied the
> patch:
>
> https://lore.kernel.org/mm-commits/20201110212436.yGYhesom8%25akpm@linux-foundation.org/
>
> My apologies for not following up, we appear to be all good now for the
> time being (aside from the futex issue that I reported earlier).
>

No worries - at least it is fixed now. And KASAN is already shaking
out bugs, so it is great that we finally managed to enable this for
ARM.

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

[Ard Biesheuvel]

On Thu, 12 Nov 2020 at 18:52, Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> On Thu, Nov 12, 2020 at 04:05:52PM +0100, Ard Biesheuvel wrote:
> > On Thu, 12 Nov 2020 at 14:51, Linus Walleij <linus.walleij@linaro.org> wrote:
> > >
> > > On Tue, Nov 10, 2020 at 1:05 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > > On Mon, 9 Nov 2020 at 17:07, Russell King - ARM Linux admin
> > > > <linux@armlinux.org.uk> wrote:
> > > > >
> > > > > On Mon, Nov 09, 2020 at 05:02:09PM +0100, Linus Walleij wrote:
> > > > > > On Fri, Nov 6, 2020 at 4:16 PM Russell King - ARM Linux admin
> > > > > > <linux@armlinux.org.uk> wrote:
> > > > > > > On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> > > > > >
> > > > > > > > Aha. So shall we submit this to Russell? I figure that his git will not
> > > > > > > > build *without* the changes from mmotm?
> > > > > > > >
> > > > > > > > That tree isn't using git either is it?
> > > > > > > >
> > > > > > > > Is this one of those cases where we should ask Stephen R
> > > > > > > > to carry this patch on top of -next until the merge window?
> > > > > > >
> > > > > > > Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> > > > > > > until the following merge window, and queue up the non-conflicing
> > > > > > > ARM KASan fixes in my "misc" branch along with the rest of KASan,
> > > > > > > and the conflicting patches along with 9017/2 in the following
> > > > > > > merge window.
> > > > > > >
> > > > > > > That means delaying KASan enablement another three months or so,
> > > > > > > but should result in less headaches about how to avoid build
> > > > > > > breakage with different bits going through different trees.
> > > > > > >
> > > > > > > Comments?
> > > > > >
> > > > > > I suppose I would survive deferring it. Or we could merge the
> > > > > > smaller enablement patch towards the end of the merge
> > > > > > window once the MM changes are in.
> > > > > >
> > > > > > If it is just *one* patch in the MM tree I suppose we could also
> > > > > > just apply that one patch also to the ARM tree, and then this
> > > > > > fixup on top. It does look a bit convoluted in the git history with
> > > > > > two hashes and the same patch twice, but it's what I've done
> > > > > > at times when there was no other choice that doing that or
> > > > > > deferring development. It works as long as the patches are
> > > > > > textually identical: git will cope.
> > > > >
> > > > > I thought there was a problem that if I applied the fix then my tree
> > > > > no longer builds without the changes in -mm?
> > > > >
> > > >
> > > > Indeed. Someone is changing the __alias() wrappers [for no good reason
> > > > afaict] in a way that does not allow for new users of those wrappers
> > > > to come in concurrently.
> > > >
> > > > Hency my suggestion to switch to the raw __attribute__((alias("..")))
> > > > notation for the time being, and switch back to __alias() somewhere
> > > > after v5.11-rc1.
> > > >
> > > > Or we might add this to the file in question
> > > >
> > > > #undef __alias
> > > > #define __alias(symbol) __attribute__((__alias__(symbol)))
> > > >
> > > > and switch to the quoted versions of the identifier. Then we can just
> > > > drop these two lines again later, after v5.11-rc1
> > >
> > > I was under the impression that there was some "post-next"
> > > trick that mmot apply this patch after -next has been merged
> > > so it's solved now?
> > >
> >
> > Yes, it appears that [0] has been picked up, I guess we weren't cc'ed
> > on the version that was sent to akpm [which is fine btw, although a
> > followup reply here that things are all good now would have been
> > appreciated]
> >
> >
> > https://lore.kernel.org/linux-arm-kernel/20201109001712.3384097-1-natechancellor@gmail.com/
>
> Hi Ard,
>
> Odd, you were on the list of people to receive that patch and you acked
> it but it seems that Andrew did not CC you when he actually applied the
> patch:
>
> https://lore.kernel.org/mm-commits/20201110212436.yGYhesom8%25akpm@linux-foundation.org/
>
> My apologies for not following up, we appear to be all good now for the
> time being (aside from the futex issue that I reported earlier).
>

No worries - at least it is fixed now. And KASAN is already shaking
out bugs, so it is great that we finally managed to enable this for
ARM.

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

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

[Linus Walleij]

On Fri, Nov 6, 2020 at 2:37 PM Linus Walleij <linus.walleij@linaro.org> wrote:

> Is this one of those cases where we should ask Stephen R
> to carry this patch on top of -next until the merge window?

Apparently this is being handled by "post-next" which I have no
idea how it works, seems like a merge quirk path, but if it works
out, I'm happy :D

Yours,
Linus Walleij

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

[Linus Walleij]

On Fri, Nov 6, 2020 at 2:37 PM Linus Walleij <linus.walleij@linaro.org> wrote:

> Is this one of those cases where we should ask Stephen R
> to carry this patch on top of -next until the merge window?

Apparently this is being handled by "post-next" which I have no
idea how it works, seems like a merge quirk path, but if it works
out, I'm happy :D

Yours,
Linus Walleij

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

[PATCH 3/5 v16] 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
Cc: Mike Rapoport <rppt@linux.ibm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G
Tested-by: Florian Fainelli <f.fainelli@gmail.com> # Brahma SoCs
Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # i.MX6Q
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 v15->v16:
- Collect Florian's Tested-by
- Resend with the other patches
ChangeLog v14->v15:
- Resend with the other patches
ChangeLog v13->v14:
- Resend with the other patches
ChangeLog v12->v13:
- Rebase on kernel v5.9-rc1
ChangeLog v11->v12:
- Resend with the other changes.
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 34bb23c44a71..0cb1e2938823 100644
--- a/Documentation/arm/memory.rst
+++ b/Documentation/arm/memory.rst
@@ -77,6 +77,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 e00d94b16658..0489b8d07172 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1324,6 +1324,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 bb79e52aeb90..598dbdca2017 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 a7231d151c63..50ae506a39e1 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -30,6 +30,7 @@
 #include <asm/procinfo.h>
 #include <asm/memory.h>
 #include <asm/pgalloc.h>
+#include <asm/kasan_def.h>
 
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
@@ -1265,8 +1266,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.26.2


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

[PATCH 4/5 v16] 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.

Ard Biesheuvel <ardb@kernel.org>:
- Necessary underlying fixes.
- Crucial bug fixes to the memory set-up code.

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: Andrey Ryabinin <aryabinin@virtuozzo.com>
Co-developed-by: Abbott Liu <liuwenliang@huawei.com>
Co-developed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G
Tested-by: Florian Fainelli <f.fainelli@gmail.com> # Brahma SoCs
Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # i.MX6Q
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: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v15->v16:
- Toss in a PAGE_ALIGN() around the end address in create_mapping()
  to make the last of Florian's systems happy.
- Fix up some debug messages to make more sense. Use %pap
  to print physical addresses.
ChangeLog v14->v15:
- Avoids reallocating KASAN blocks when a range gets
  mapped twice - this occurs when mapping the DTB space explicitly.
- Insert a missing TLB flush.
- Move the cache flush after switching the MM (which makes logical
  sense.
- All these fixes discovered by Ard Bisheuvel.
- Dropped the special mapping around the DTB after using Ard's
  patches for remapping the DTB in a special memory area.
- Add asmlinkage prototype for kasan_early_init() to get
  rid of some compilation warnings.
ChangeLog v13->v14:
- Provide more elaborate prints of how virtual kernel memory
  is mapped to the allocated lowmem pages.
- Make sure to also map the memory around the __atags_pointer:
  this memory is used for the device tree blob (DTB) and will be
  accessed by the device tree parser. We were just lucky that
  this was mostly in some acceptable memory location until now.
ChangeLog v12->v13:
- Rebase on kernel v5.9-rc1
ChangeLog v11->v12:
- Do not try to shadow highmem memory blocks. (Ard)
- Provoke a build bug if the entire shadow memory doesn't fit
  inside a single pgd_index() (Ard)
- Move the pointer to (unsigned long) casts into the create_mapping()
  function. (Ard)
- After setting up the shadow memory make sure to issue
  local_flush_tlb_all() so that we refresh all the global mappings. (Ard)
- Simplify pte_populate() (Ard)
- Skip over pud population as well as p4d. (Ard)
- Drop the stop condition pmd_none(*pmdp) in the pmd population
  loop. (Ard)
- Stop passing around the node (NUMA) parameter in the init code,
  we are not expecting any NUMA architectures to be introduced into
  ARM32 so just hardcode NUMA_NO_NODE when calling
  memblock_alloc_try_nid().
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       |  33 ++++
 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           | 292 +++++++++++++++++++++++++++++
 arch/arm/mm/pgd.c                  |  16 +-
 8 files changed, 363 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..303c35df3135
--- /dev/null
+++ b/arch/arm/include/asm/kasan.h
@@ -0,0 +1,33 @@
+/* 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)
+ */
+
+asmlinkage void kasan_early_init(void);
+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 15f4674715f8..fdee1f04f4f3 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 void pud_populate(struct mm_struct *mm, pud_t *pud, pmd_t *pmd)
 {
@@ -28,14 +29,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 536b6b979f63..56fae7861fd3 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 2a70e4958c14..43d033696e33 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -59,6 +59,7 @@
 #include <asm/unwind.h>
 #include <asm/memblock.h>
 #include <asm/virt.h>
+#include <asm/kasan.h>
 
 #include "atags.h"
 
@@ -1139,6 +1140,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..8afd5c017b7f
--- /dev/null
+++ b/arch/arm/mm/kasan_init.c
@@ -0,0 +1,292 @@
+// 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)
+{
+	return memblock_alloc_try_nid(size, size, __pa(MAX_DMA_ADDRESS),
+				      MEMBLOCK_ALLOC_KASAN, NUMA_NO_NODE);
+}
+
+static void __init kasan_pte_populate(pmd_t *pmdp, unsigned long addr,
+				      unsigned long end, bool early)
+{
+	unsigned long next;
+	pte_t *ptep = pte_offset_kernel(pmdp, addr);
+
+	do {
+		pte_t entry;
+		void *p;
+
+		next = addr + PAGE_SIZE;
+
+		if (!early) {
+			if (!pte_none(READ_ONCE(*ptep)))
+				continue;
+
+			p = kasan_alloc_block(PAGE_SIZE);
+			if (!p) {
+				panic("%s failed to allocate shadow page 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)));
+		} else if (pte_none(READ_ONCE(*ptep))) {
+			/*
+			 * 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.
+			 */
+			entry = pfn_pte(virt_to_pfn(kasan_early_shadow_page),
+					__pgprot(_L_PTE_DEFAULT | L_PTE_DIRTY | L_PTE_XN));
+		} else {
+			/*
+			 * Early shadow mappings are PMD_SIZE aligned, so if the
+			 * first entry is already set, they must all be set.
+			 */
+			return;
+		}
+
+		set_pte_at(&init_mm, addr, ptep, entry);
+	} while (ptep++, addr = next, addr != end);
+}
+
+/*
+ * The pmd (page middle directory) is only used on LPAE
+ */
+static void __init kasan_pmd_populate(pud_t *pudp, unsigned long addr,
+				      unsigned long end, bool early)
+{
+	unsigned long next;
+	pmd_t *pmdp = pmd_offset(pudp, addr);
+
+	do {
+		if (pmd_none(*pmdp)) {
+			/*
+			 * We attempt to allocate a shadow block for the PMDs
+			 * used by the PTEs for this address if it isn't already
+			 * allocated.
+			 */
+			void *p = early ? kasan_early_shadow_pte :
+				kasan_alloc_block(PAGE_SIZE);
+
+			if (!p) {
+				panic("%s failed to allocate shadow block 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, early);
+	} while (pmdp++, addr = next, addr != end);
+}
+
+static void __init kasan_pgd_populate(unsigned long addr, unsigned long end,
+				      bool early)
+{
+	unsigned long next;
+	pgd_t *pgdp;
+	p4d_t *p4dp;
+	pud_t *pudp;
+
+	pgdp = pgd_offset_k(addr);
+
+	do {
+		/*
+		 * Allocate and populate the shadow block of p4d folded into
+		 * pud folded into pmd if it doesn't already exist
+		 */
+		if (!early && pgd_none(*pgdp)) {
+			void *p = kasan_alloc_block(PAGE_SIZE);
+
+			if (!p) {
+				panic("%s failed to allocate shadow block 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 p4d and pud page
+		 * directories since we believe ARM32 will never gain four
+		 * nor five level page tables.
+		 */
+		p4dp = p4d_offset(pgdp, addr);
+		pudp = pud_offset(p4dp, addr);
+
+		kasan_pmd_populate(pudp, addr, next, 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, 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(void *start, void *end)
+{
+	void *shadow_start, *shadow_end;
+
+	shadow_start = kasan_mem_to_shadow(start);
+	shadow_end = kasan_mem_to_shadow(end);
+
+	pr_info("Mapping kernel virtual memory block: %px-%px at shadow: %px-%px\n",
+		start, end, shadow_start, shadow_end);
+
+	kasan_pgd_populate((unsigned long)shadow_start & PAGE_MASK,
+			   PAGE_ALIGN((unsigned long)shadow_end), 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 can'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
+	/* We need to be in the same PGD or this won't work */
+	BUILD_BUG_ON(pgd_index(KASAN_SHADOW_START) !=
+		     pgd_index(KASAN_SHADOW_END));
+	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);
+	local_flush_tlb_all();
+
+	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);
+
+		/* Do not attempt to shadow highmem */
+		if (reg->base >= arm_lowmem_limit) {
+			pr_info("Skip highmem block %pap-%pap\n",
+				&reg->base, &reg->base + reg->size);
+			continue;
+		}
+		if (reg->base + reg->size > arm_lowmem_limit) {
+			pr_info("Truncating shadow for %pap-%pap to lowmem region\n",
+				&reg->base, &reg->base + reg->size);
+			end = __va(arm_lowmem_limit);
+		}
+		if (start >= end) {
+			pr_info("Skipping invalid memory block %px-%px\n",
+				start, end);
+			continue;
+		}
+
+		create_mapping(start, end);
+	}
+
+	/*
+	 * 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((void *)MODULES_VADDR, (void *)(PKMAP_BASE + PMD_SIZE));
+
+	/*
+	 * 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)));
+
+	cpu_switch_mm(swapper_pg_dir, &init_mm);
+	local_flush_tlb_all();
+
+	memset(kasan_early_shadow_page, 0, PAGE_SIZE);
+	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.26.2


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

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

[Ard Biesheuvel]

Hi Linus,

On Mon, 19 Oct 2020 at 10:42, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> 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.
>
> Ard Biesheuvel <ardb@kernel.org>:
> - Necessary underlying fixes.
> - Crucial bug fixes to the memory set-up code.
>
> 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: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Co-developed-by: Abbott Liu <liuwenliang@huawei.com>
> Co-developed-by: Ard Biesheuvel <ardb@kernel.org>
> Acked-by: Mike Rapoport <rppt@linux.ibm.com>
> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
> Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G
> Tested-by: Florian Fainelli <f.fainelli@gmail.com> # Brahma SoCs
> Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # i.MX6Q
> 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: Ard Biesheuvel <ardb@kernel.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
...
> diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
> new file mode 100644
> index 000000000000..8afd5c017b7f
> --- /dev/null
> +++ b/arch/arm/mm/kasan_init.c
> @@ -0,0 +1,292 @@
> +// 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)
> +{
> +       return memblock_alloc_try_nid(size, size, __pa(MAX_DMA_ADDRESS),
> +                                     MEMBLOCK_ALLOC_KASAN, NUMA_NO_NODE);
> +}
> +
> +static void __init kasan_pte_populate(pmd_t *pmdp, unsigned long addr,
> +                                     unsigned long end, bool early)
> +{
> +       unsigned long next;
> +       pte_t *ptep = pte_offset_kernel(pmdp, addr);
> +
> +       do {
> +               pte_t entry;
> +               void *p;
> +
> +               next = addr + PAGE_SIZE;
> +
> +               if (!early) {
> +                       if (!pte_none(READ_ONCE(*ptep)))
> +                               continue;
> +
> +                       p = kasan_alloc_block(PAGE_SIZE);
> +                       if (!p) {
> +                               panic("%s failed to allocate shadow page 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)));
> +               } else if (pte_none(READ_ONCE(*ptep))) {
> +                       /*
> +                        * 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.
> +                        */
> +                       entry = pfn_pte(virt_to_pfn(kasan_early_shadow_page),
> +                                       __pgprot(_L_PTE_DEFAULT | L_PTE_DIRTY | L_PTE_XN));
> +               } else {
> +                       /*
> +                        * Early shadow mappings are PMD_SIZE aligned, so if the
> +                        * first entry is already set, they must all be set.
> +                        */
> +                       return;
> +               }
> +
> +               set_pte_at(&init_mm, addr, ptep, entry);
> +       } while (ptep++, addr = next, addr != end);
> +}
> +
> +/*
> + * The pmd (page middle directory) is only used on LPAE
> + */
> +static void __init kasan_pmd_populate(pud_t *pudp, unsigned long addr,
> +                                     unsigned long end, bool early)
> +{
> +       unsigned long next;
> +       pmd_t *pmdp = pmd_offset(pudp, addr);
> +
> +       do {
> +               if (pmd_none(*pmdp)) {
> +                       /*
> +                        * We attempt to allocate a shadow block for the PMDs
> +                        * used by the PTEs for this address if it isn't already
> +                        * allocated.
> +                        */
> +                       void *p = early ? kasan_early_shadow_pte :
> +                               kasan_alloc_block(PAGE_SIZE);
> +
> +                       if (!p) {
> +                               panic("%s failed to allocate shadow block 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, early);
> +       } while (pmdp++, addr = next, addr != end);
> +}
> +
> +static void __init kasan_pgd_populate(unsigned long addr, unsigned long end,
> +                                     bool early)
> +{
> +       unsigned long next;
> +       pgd_t *pgdp;
> +       p4d_t *p4dp;
> +       pud_t *pudp;
> +
> +       pgdp = pgd_offset_k(addr);
> +
> +       do {
> +               /*
> +                * Allocate and populate the shadow block of p4d folded into
> +                * pud folded into pmd if it doesn't already exist
> +                */
> +               if (!early && pgd_none(*pgdp)) {
> +                       void *p = kasan_alloc_block(PAGE_SIZE);
> +
> +                       if (!p) {
> +                               panic("%s failed to allocate shadow block 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 p4d and pud page
> +                * directories since we believe ARM32 will never gain four
> +                * nor five level page tables.
> +                */
> +               p4dp = p4d_offset(pgdp, addr);
> +               pudp = pud_offset(p4dp, addr);
> +
> +               kasan_pmd_populate(pudp, addr, next, 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, 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(void *start, void *end)
> +{
> +       void *shadow_start, *shadow_end;
> +
> +       shadow_start = kasan_mem_to_shadow(start);
> +       shadow_end = kasan_mem_to_shadow(end);
> +
> +       pr_info("Mapping kernel virtual memory block: %px-%px at shadow: %px-%px\n",
> +               start, end, shadow_start, shadow_end);
> +
> +       kasan_pgd_populate((unsigned long)shadow_start & PAGE_MASK,
> +                          PAGE_ALIGN((unsigned long)shadow_end), 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 can'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
> +       /* We need to be in the same PGD or this won't work */
> +       BUILD_BUG_ON(pgd_index(KASAN_SHADOW_START) !=
> +                    pgd_index(KASAN_SHADOW_END));
> +       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);
> +       local_flush_tlb_all();
> +
> +       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);
> +
> +               /* Do not attempt to shadow highmem */
> +               if (reg->base >= arm_lowmem_limit) {
> +                       pr_info("Skip highmem block %pap-%pap\n",
> +                               &reg->base, &reg->base + reg->size);

Adding reg->size to &reg->base is not going to produce the expected
value here. I think we can just drop it, and only keep the start
address here (same below)

> +                       continue;
> +               }
> +               if (reg->base + reg->size > arm_lowmem_limit) {
> +                       pr_info("Truncating shadow for %pap-%pap to lowmem region\n",
> +                               &reg->base, &reg->base + reg->size);
> +                       end = __va(arm_lowmem_limit);
> +               }
> +               if (start >= end) {
> +                       pr_info("Skipping invalid memory block %px-%px\n",
> +                               start, end);
> +                       continue;
> +               }
> +
> +               create_mapping(start, end);
> +       }
> +
> +       /*
> +        * 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((void *)MODULES_VADDR, (void *)(PKMAP_BASE + PMD_SIZE));
> +
> +       /*
> +        * 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)));
> +
> +       cpu_switch_mm(swapper_pg_dir, &init_mm);
> +       local_flush_tlb_all();
> +
> +       memset(kasan_early_shadow_page, 0, PAGE_SIZE);
> +       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.26.2
>

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

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

[Mike Rapoport]

On Mon, Oct 19, 2020 at 10:41:39AM +0200, Linus Walleij wrote:
> 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.
> 
> Ard Biesheuvel <ardb@kernel.org>:
> - Necessary underlying fixes.
> - Crucial bug fixes to the memory set-up code.
> 
> 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: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Co-developed-by: Abbott Liu <liuwenliang@huawei.com>
> Co-developed-by: Ard Biesheuvel <ardb@kernel.org>
> Acked-by: Mike Rapoport <rppt@linux.ibm.com>
> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
> Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G
> Tested-by: Florian Fainelli <f.fainelli@gmail.com> # Brahma SoCs
> Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # i.MX6Q
> 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: Ard Biesheuvel <ardb@kernel.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---

...

> +	cpu_switch_mm(tmp_pgd_table, &init_mm);
> +	local_flush_tlb_all();
> +
> +	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);
> +

I've killed for_each_memblock() recently and we have now 

	for_each_mem_range(idx, &pa_start, &pa_end)

instead.

> +		/* Do not attempt to shadow highmem */
> +		if (reg->base >= arm_lowmem_limit) {
> +			pr_info("Skip highmem block %pap-%pap\n",
> +				&reg->base, &reg->base + reg->size);
> +			continue;
> +		}
> +		if (reg->base + reg->size > arm_lowmem_limit) {
> +			pr_info("Truncating shadow for %pap-%pap to lowmem region\n",
> +				&reg->base, &reg->base + reg->size);
> +			end = __va(arm_lowmem_limit);
> +		}
> +		if (start >= end) {
> +			pr_info("Skipping invalid memory block %px-%px\n",
> +				start, end);
> +			continue;
> +		}
> +
> +		create_mapping(start, end);
> +	}
> +
> +	/*
> +	 * 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((void *)MODULES_VADDR, (void *)(PKMAP_BASE + PMD_SIZE));
> +
> +	/*
> +	 * 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)));
> +
> +	cpu_switch_mm(swapper_pg_dir, &init_mm);
> +	local_flush_tlb_all();
> +
> +	memset(kasan_early_shadow_page, 0, PAGE_SIZE);
> +	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.26.2
> 

-- 
Sincerely yours,
Mike.

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

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

[Ard Biesheuvel]

On Mon, 19 Oct 2020 at 11:37, Mike Rapoport <rppt@linux.ibm.com> wrote:
>
> On Mon, Oct 19, 2020 at 10:41:39AM +0200, Linus Walleij wrote:
> > 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.
> >
> > Ard Biesheuvel <ardb@kernel.org>:
> > - Necessary underlying fixes.
> > - Crucial bug fixes to the memory set-up code.
> >
> > 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: Andrey Ryabinin <aryabinin@virtuozzo.com>
> > Co-developed-by: Abbott Liu <liuwenliang@huawei.com>
> > Co-developed-by: Ard Biesheuvel <ardb@kernel.org>
> > Acked-by: Mike Rapoport <rppt@linux.ibm.com>
> > Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
> > Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G
> > Tested-by: Florian Fainelli <f.fainelli@gmail.com> # Brahma SoCs
> > Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # i.MX6Q
> > 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: Ard Biesheuvel <ardb@kernel.org>
> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> > ---
>
> ...
>
> > +     cpu_switch_mm(tmp_pgd_table, &init_mm);
> > +     local_flush_tlb_all();
> > +
> > +     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);
> > +
>
> I've killed for_each_memblock() recently and we have now
>
>         for_each_mem_range(idx, &pa_start, &pa_end)
>
> instead.
>

Will the enumeration include NOMAP regions as well? We could actually
omit them here, since they don't need KASAN shadow.

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

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

[Mike Rapoport]

On Mon, Oct 19, 2020 at 11:42:44AM +0200, Ard Biesheuvel wrote:
> On Mon, 19 Oct 2020 at 11:37, Mike Rapoport <rppt@linux.ibm.com> wrote:
> >
> > On Mon, Oct 19, 2020 at 10:41:39AM +0200, Linus Walleij wrote:
> > > 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.
> > >
> > > Ard Biesheuvel <ardb@kernel.org>:
> > > - Necessary underlying fixes.
> > > - Crucial bug fixes to the memory set-up code.
> > >
> > > 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: Andrey Ryabinin <aryabinin@virtuozzo.com>
> > > Co-developed-by: Abbott Liu <liuwenliang@huawei.com>
> > > Co-developed-by: Ard Biesheuvel <ardb@kernel.org>
> > > Acked-by: Mike Rapoport <rppt@linux.ibm.com>
> > > Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
> > > Tested-by: Ard Biesheuvel <ardb@kernel.org> # QEMU/KVM/mach-virt/LPAE/8G
> > > Tested-by: Florian Fainelli <f.fainelli@gmail.com> # Brahma SoCs
> > > Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # i.MX6Q
> > > 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: Ard Biesheuvel <ardb@kernel.org>
> > > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> > > ---
> >
> > ...
> >
> > > +     cpu_switch_mm(tmp_pgd_table, &init_mm);
> > > +     local_flush_tlb_all();
> > > +
> > > +     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);
> > > +
> >
> > I've killed for_each_memblock() recently and we have now
> >
> >         for_each_mem_range(idx, &pa_start, &pa_end)
> >
> > instead.
> >
> 
> Will the enumeration include NOMAP regions as well? We could actually
> omit them here, since they don't need KASAN shadow.

The NOMAP regions are omitted.

-- 
Sincerely yours,
Mike.

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

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

[Linus Walleij]

On Mon, Oct 19, 2020 at 12:05 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
> On Mon, Oct 19, 2020 at 11:42:44AM +0200, Ard Biesheuvel wrote:

> > > > +     for_each_memblock(memory, reg) {
> > > > +             void *start = __va(reg->base);
> > > > +             void *end = __va(reg->base + reg->size);
> > > > +
> > >
> > > I've killed for_each_memblock() recently and we have now
> > >
> > >         for_each_mem_range(idx, &pa_start, &pa_end)
> > >
> > > instead.
> > >
> >
> > Will the enumeration include NOMAP regions as well? We could actually
> > omit them here, since they don't need KASAN shadow.
>
> The NOMAP regions are omitted.

Hm I suppose I need to update the patch series once the merge
window closes on top of v5.10-rc1, then use this nifty facility
in Russell's patch tracker that can update pending patches.

I thought it would be safe to put them in the patch tracker after
16 iterations, haha :D

Yours,
Linus Walleij

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

[PATCH 5/5 v16] 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
Tested-by: Florian Fainelli <f.fainelli@gmail.com> # Brahma SoCs
Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> # i.MX6Q
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 v15->v16:
- Collect Florian's Tested-by
- Resend with the other patches
ChangeLog v14->v15:
- Resend with the other patches
ChangeLog v13->v14:
- Resend with the other patches.
ChangeLog v12->v13:
- Rebase on kernel v5.9-rc1
ChangeLog v11->v12:
- Resend with the other changes.
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 38fd5681fade..050dcd346144 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -18,8 +18,8 @@ out-of-bounds accesses for global variables is only supported since Clang 11.
 
 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 c3fe9b266e7b..b2288dc14b72 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 0489b8d07172..873bd26f5d43 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -66,6 +66,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.26.2


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

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

[Dmitry Osipenko]

19.10.2020 11:41, Linus Walleij пишет:
> This is the 16th and final (knock on wood) version of
> KASan for ARM32.

Hi,

I tried KASAN on NVIDIA Tegra using next-20201029 and getting a (seems)
bogus bug report saying that the bug is in the KASAN code (note
udc_irq() belongs to the ChipIdea USB driver), this problem doesn't
happen using one of older versions of the KASAN patches.

[   27.700859]
==================================================================
[   27.720575] BUG: KASAN: stack-out-of-bounds in save_trace+0xbf/0xf8
[   27.740119] Read of size 4 at addr c4dc7038 by task kworker/0:1H/124

[   27.778724] CPU: 0 PID: 124 Comm: kworker/0:1H Tainted: G        W
     5.10.0-rc1-next-20201029-00144-g367ba7b6ebb4 #4327
[   27.818361] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
[   27.838599] Workqueue: mmc_complete mmc_blk_mq_complete_work
[   27.858795] [<c0111a05>] (unwind_backtrace) from [<c010c26d>]
(show_stack+0x11/0x14)
[   27.879038] [<c010c26d>] (show_stack) from [<c0f42e5b>]
(dump_stack+0x8b/0xa0)
[   27.899374] [<c0f42e5b>] (dump_stack) from [<c031d8f7>]
(print_address_description.constprop.0+0x2b/0x360)
[   27.939249] [<c031d8f7>] (print_address_description.constprop.0) from
[<c031ddab>] (kasan_report+0x103/0x11c)
[   27.979769] [<c031ddab>] (kasan_report) from [<c010bddb>]
(save_trace+0xbf/0xf8)
[   28.000506] [<c010bddb>] (save_trace) from [<c010bd11>]
(walk_stackframe+0x19/0x24)
[   28.021501] [<c010bd11>] (walk_stackframe) from [<c010bf07>]
(__save_stack_trace+0xf3/0xf8)
[   28.042658] [<c010bf07>] (__save_stack_trace) from [<c01b8c4d>]
(stack_trace_save+0x75/0x8c)
[   28.063740] [<c01b8c4d>] (stack_trace_save) from [<c031d019>]
(kasan_save_stack+0x11/0x28)
[   28.084979] [<c031d019>] (kasan_save_stack) from [<c031d04d>]
(kasan_set_track+0x1d/0x20)
[   28.106135] [<c031d04d>] (kasan_set_track) from [<c031e461>]
(kasan_set_free_info+0x19/0x20)
[   28.127351] [<c031e461>] (kasan_set_free_info) from [<c031cfe5>]
(__kasan_slab_free+0xa5/0xc8)
[   28.148491] [<c031cfe5>] (__kasan_slab_free) from [<c0318b7f>]
(kfree+0x7b/0x374)
[   28.169910] [<c0318b7f>] (kfree) from [<c09bbe7f>] (udc_irq+0x477/0xe18)
[   28.191214] [<c09bbe7f>] (udc_irq) from [<c019cb09>]
(__handle_irq_event_percpu+0x71/0x2d4)
[   28.212693] [<c019cb09>] (__handle_irq_event_percpu) from
[<c019cde1>] (handle_irq_event_percpu+0x75/0xb8)
[   28.255076] [<c019cde1>] (handle_irq_event_percpu) from [<c019ce67>]
(handle_irq_event+0x43/0x64)
[   28.277174] [<c019ce67>] (handle_irq_event) from [<c01a1bbb>]
(handle_fasteoi_irq+0xcf/0x18c)
[   28.299436] [<c01a1bbb>] (handle_fasteoi_irq) from [<c019bd4b>]
(generic_handle_irq+0x3b/0x44)
[   28.321825] [<c019bd4b>] (generic_handle_irq) from [<c019c34b>]
(__handle_domain_irq+0x5f/0xa8)
[   28.344383] [<c019c34b>] (__handle_domain_irq) from [<c06b30cf>]
(gic_handle_irq+0x87/0x9c)
[   28.367176] [<c06b30cf>] (gic_handle_irq) from [<c0100b23>]
(__irq_svc+0x63/0xb0)
[   28.390118] Exception stack(0xc4dc6f58 to 0xc4dc6fa0)
[   28.413200] 6f40:
  c1fa88c4 00000000
[   28.436622] 6f60: c1fa88c4 00000000 c5557800 00000000 00000001
c5557808 00000001 c1fa88c0
[   28.460176] 6f80: 00000000 c466c000 b782c97b c4dc6fac c0bdcfa1
c0bdd51e 60070133 ffffffff
[   28.484070] [<c0100b23>] (__irq_svc) from [<c0bdd51e>]
(__qdisc_run+0x6d2/0x7b8)
[   28.508082] [<c0bdd51e>] (__qdisc_run) from [<c0100155>]
(ret_from_fork+0x11/0x1c)
[   28.532185] Exception stack(0xc4dc6ffc to 0xc4dc7044)
[   28.556578] 6fe0:
           00000000
[   28.581249] 7000: c1902d18 c4dc8000 00000000 00000000 00000003
00000000 00000000 00000001
[   28.605909] 7020: 41b58ab3 c1864c40 c0b94e6c 00000800 00000000
c2c01e00 00000001 c09bbe7f
[   28.630740] 7040: fffffff4

[   28.679636] The buggy address belongs to the page:
[   28.704480] page:bc50e6d8 refcount:0 mapcount:0 mapping:00000000
index:0x0 pfn:0x84dc7
[   28.729687] flags: 0x0()
[   28.754372] raw: 00000000 defa7000 defa7000 00000000 00000000
00000000 ffffffff 00000000
[   28.779394] raw: 00000000
[   28.804339] page dumped because: kasan: bad access detected

[   28.854326] addr c4dc7038 is located in stack of task
kworker/0:1H/124 at offset 24 in frame:
[   28.880073]  __dev_queue_xmit+0x0/0x9cc

[   28.931135] this frame has 4 objects:
[   28.956624]  [32, 36) 'rc'
[   28.956638]  [48, 52) 'to_free'
[   28.981922]  [64, 72) '_udphdr'
[   29.007038]  [96, 116) '_tcphdr'

[   29.081989] Memory state around the buggy address:
[   29.106884]  c4dc6f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   29.132106]  c4dc6f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   29.157134] >c4dc7000: 00 00 00 00 f1 f1 f1 f1 04 f2 04 f2 00 f2 f2 f2
[   29.181980]                                 ^
[   29.206867]  c4dc7080: 00 00 04 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00
[   29.231827]  c4dc7100: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04 f3 f3 f3
[   29.257034]
==================================================================

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

[Dmitry Osipenko]

19.10.2020 11:41, Linus Walleij пишет:
> This is the 16th and final (knock on wood) version of
> KASan for ARM32.

Hi,

I tried KASAN on NVIDIA Tegra using next-20201029 and getting a (seems)
bogus bug report saying that the bug is in the KASAN code (note
udc_irq() belongs to the ChipIdea USB driver), this problem doesn't
happen using one of older versions of the KASAN patches.

[   27.700859]
==================================================================
[   27.720575] BUG: KASAN: stack-out-of-bounds in save_trace+0xbf/0xf8
[   27.740119] Read of size 4 at addr c4dc7038 by task kworker/0:1H/124

[   27.778724] CPU: 0 PID: 124 Comm: kworker/0:1H Tainted: G        W
     5.10.0-rc1-next-20201029-00144-g367ba7b6ebb4 #4327
[   27.818361] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
[   27.838599] Workqueue: mmc_complete mmc_blk_mq_complete_work
[   27.858795] [<c0111a05>] (unwind_backtrace) from [<c010c26d>]
(show_stack+0x11/0x14)
[   27.879038] [<c010c26d>] (show_stack) from [<c0f42e5b>]
(dump_stack+0x8b/0xa0)
[   27.899374] [<c0f42e5b>] (dump_stack) from [<c031d8f7>]
(print_address_description.constprop.0+0x2b/0x360)
[   27.939249] [<c031d8f7>] (print_address_description.constprop.0) from
[<c031ddab>] (kasan_report+0x103/0x11c)
[   27.979769] [<c031ddab>] (kasan_report) from [<c010bddb>]
(save_trace+0xbf/0xf8)
[   28.000506] [<c010bddb>] (save_trace) from [<c010bd11>]
(walk_stackframe+0x19/0x24)
[   28.021501] [<c010bd11>] (walk_stackframe) from [<c010bf07>]
(__save_stack_trace+0xf3/0xf8)
[   28.042658] [<c010bf07>] (__save_stack_trace) from [<c01b8c4d>]
(stack_trace_save+0x75/0x8c)
[   28.063740] [<c01b8c4d>] (stack_trace_save) from [<c031d019>]
(kasan_save_stack+0x11/0x28)
[   28.084979] [<c031d019>] (kasan_save_stack) from [<c031d04d>]
(kasan_set_track+0x1d/0x20)
[   28.106135] [<c031d04d>] (kasan_set_track) from [<c031e461>]
(kasan_set_free_info+0x19/0x20)
[   28.127351] [<c031e461>] (kasan_set_free_info) from [<c031cfe5>]
(__kasan_slab_free+0xa5/0xc8)
[   28.148491] [<c031cfe5>] (__kasan_slab_free) from [<c0318b7f>]
(kfree+0x7b/0x374)
[   28.169910] [<c0318b7f>] (kfree) from [<c09bbe7f>] (udc_irq+0x477/0xe18)
[   28.191214] [<c09bbe7f>] (udc_irq) from [<c019cb09>]
(__handle_irq_event_percpu+0x71/0x2d4)
[   28.212693] [<c019cb09>] (__handle_irq_event_percpu) from
[<c019cde1>] (handle_irq_event_percpu+0x75/0xb8)
[   28.255076] [<c019cde1>] (handle_irq_event_percpu) from [<c019ce67>]
(handle_irq_event+0x43/0x64)
[   28.277174] [<c019ce67>] (handle_irq_event) from [<c01a1bbb>]
(handle_fasteoi_irq+0xcf/0x18c)
[   28.299436] [<c01a1bbb>] (handle_fasteoi_irq) from [<c019bd4b>]
(generic_handle_irq+0x3b/0x44)
[   28.321825] [<c019bd4b>] (generic_handle_irq) from [<c019c34b>]
(__handle_domain_irq+0x5f/0xa8)
[   28.344383] [<c019c34b>] (__handle_domain_irq) from [<c06b30cf>]
(gic_handle_irq+0x87/0x9c)
[   28.367176] [<c06b30cf>] (gic_handle_irq) from [<c0100b23>]
(__irq_svc+0x63/0xb0)
[   28.390118] Exception stack(0xc4dc6f58 to 0xc4dc6fa0)
[   28.413200] 6f40:
  c1fa88c4 00000000
[   28.436622] 6f60: c1fa88c4 00000000 c5557800 00000000 00000001
c5557808 00000001 c1fa88c0
[   28.460176] 6f80: 00000000 c466c000 b782c97b c4dc6fac c0bdcfa1
c0bdd51e 60070133 ffffffff
[   28.484070] [<c0100b23>] (__irq_svc) from [<c0bdd51e>]
(__qdisc_run+0x6d2/0x7b8)
[   28.508082] [<c0bdd51e>] (__qdisc_run) from [<c0100155>]
(ret_from_fork+0x11/0x1c)
[   28.532185] Exception stack(0xc4dc6ffc to 0xc4dc7044)
[   28.556578] 6fe0:
           00000000
[   28.581249] 7000: c1902d18 c4dc8000 00000000 00000000 00000003
00000000 00000000 00000001
[   28.605909] 7020: 41b58ab3 c1864c40 c0b94e6c 00000800 00000000
c2c01e00 00000001 c09bbe7f
[   28.630740] 7040: fffffff4

[   28.679636] The buggy address belongs to the page:
[   28.704480] page:bc50e6d8 refcount:0 mapcount:0 mapping:00000000
index:0x0 pfn:0x84dc7
[   28.729687] flags: 0x0()
[   28.754372] raw: 00000000 defa7000 defa7000 00000000 00000000
00000000 ffffffff 00000000
[   28.779394] raw: 00000000
[   28.804339] page dumped because: kasan: bad access detected

[   28.854326] addr c4dc7038 is located in stack of task
kworker/0:1H/124 at offset 24 in frame:
[   28.880073]  __dev_queue_xmit+0x0/0x9cc

[   28.931135] this frame has 4 objects:
[   28.956624]  [32, 36) 'rc'
[   28.956638]  [48, 52) 'to_free'
[   28.981922]  [64, 72) '_udphdr'
[   29.007038]  [96, 116) '_tcphdr'

[   29.081989] Memory state around the buggy address:
[   29.106884]  c4dc6f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   29.132106]  c4dc6f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   29.157134] >c4dc7000: 00 00 00 00 f1 f1 f1 f1 04 f2 04 f2 00 f2 f2 f2
[   29.181980]                                 ^
[   29.206867]  c4dc7080: 00 00 04 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00
[   29.231827]  c4dc7100: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04 f3 f3 f3
[   29.257034]
==================================================================


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

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

[Ard Biesheuvel]

On Thu, 29 Oct 2020 at 18:45, Dmitry Osipenko <digetx@gmail.com> wrote:
>
> 19.10.2020 11:41, Linus Walleij пишет:
> > This is the 16th and final (knock on wood) version of
> > KASan for ARM32.
>
> Hi,
>
> I tried KASAN on NVIDIA Tegra using next-20201029 and getting a (seems)
> bogus bug report saying that the bug is in the KASAN code (note
> udc_irq() belongs to the ChipIdea USB driver), this problem doesn't
> happen using one of older versions of the KASAN patches.
>

That is probably a coincidence. I ran into the same thing:

https://lore.kernel.org/linux-arm-kernel/20201029001753.717-1-ardb@kernel.org/

I am not sure this is the right fix, but it does silence the warning for me.


> [   27.700859]
> ==================================================================
> [   27.720575] BUG: KASAN: stack-out-of-bounds in save_trace+0xbf/0xf8
> [   27.740119] Read of size 4 at addr c4dc7038 by task kworker/0:1H/124
>
> [   27.778724] CPU: 0 PID: 124 Comm: kworker/0:1H Tainted: G        W
>      5.10.0-rc1-next-20201029-00144-g367ba7b6ebb4 #4327
> [   27.818361] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
> [   27.838599] Workqueue: mmc_complete mmc_blk_mq_complete_work
> [   27.858795] [<c0111a05>] (unwind_backtrace) from [<c010c26d>]
> (show_stack+0x11/0x14)
> [   27.879038] [<c010c26d>] (show_stack) from [<c0f42e5b>]
> (dump_stack+0x8b/0xa0)
> [   27.899374] [<c0f42e5b>] (dump_stack) from [<c031d8f7>]
> (print_address_description.constprop.0+0x2b/0x360)
> [   27.939249] [<c031d8f7>] (print_address_description.constprop.0) from
> [<c031ddab>] (kasan_report+0x103/0x11c)
> [   27.979769] [<c031ddab>] (kasan_report) from [<c010bddb>]
> (save_trace+0xbf/0xf8)
> [   28.000506] [<c010bddb>] (save_trace) from [<c010bd11>]
> (walk_stackframe+0x19/0x24)
> [   28.021501] [<c010bd11>] (walk_stackframe) from [<c010bf07>]
> (__save_stack_trace+0xf3/0xf8)
> [   28.042658] [<c010bf07>] (__save_stack_trace) from [<c01b8c4d>]
> (stack_trace_save+0x75/0x8c)
> [   28.063740] [<c01b8c4d>] (stack_trace_save) from [<c031d019>]
> (kasan_save_stack+0x11/0x28)
> [   28.084979] [<c031d019>] (kasan_save_stack) from [<c031d04d>]
> (kasan_set_track+0x1d/0x20)
> [   28.106135] [<c031d04d>] (kasan_set_track) from [<c031e461>]
> (kasan_set_free_info+0x19/0x20)
> [   28.127351] [<c031e461>] (kasan_set_free_info) from [<c031cfe5>]
> (__kasan_slab_free+0xa5/0xc8)
> [   28.148491] [<c031cfe5>] (__kasan_slab_free) from [<c0318b7f>]
> (kfree+0x7b/0x374)
> [   28.169910] [<c0318b7f>] (kfree) from [<c09bbe7f>] (udc_irq+0x477/0xe18)
> [   28.191214] [<c09bbe7f>] (udc_irq) from [<c019cb09>]
> (__handle_irq_event_percpu+0x71/0x2d4)
> [   28.212693] [<c019cb09>] (__handle_irq_event_percpu) from
> [<c019cde1>] (handle_irq_event_percpu+0x75/0xb8)
> [   28.255076] [<c019cde1>] (handle_irq_event_percpu) from [<c019ce67>]
> (handle_irq_event+0x43/0x64)
> [   28.277174] [<c019ce67>] (handle_irq_event) from [<c01a1bbb>]
> (handle_fasteoi_irq+0xcf/0x18c)
> [   28.299436] [<c01a1bbb>] (handle_fasteoi_irq) from [<c019bd4b>]
> (generic_handle_irq+0x3b/0x44)
> [   28.321825] [<c019bd4b>] (generic_handle_irq) from [<c019c34b>]
> (__handle_domain_irq+0x5f/0xa8)
> [   28.344383] [<c019c34b>] (__handle_domain_irq) from [<c06b30cf>]
> (gic_handle_irq+0x87/0x9c)
> [   28.367176] [<c06b30cf>] (gic_handle_irq) from [<c0100b23>]
> (__irq_svc+0x63/0xb0)
> [   28.390118] Exception stack(0xc4dc6f58 to 0xc4dc6fa0)
> [   28.413200] 6f40:
>   c1fa88c4 00000000
> [   28.436622] 6f60: c1fa88c4 00000000 c5557800 00000000 00000001
> c5557808 00000001 c1fa88c0
> [   28.460176] 6f80: 00000000 c466c000 b782c97b c4dc6fac c0bdcfa1
> c0bdd51e 60070133 ffffffff
> [   28.484070] [<c0100b23>] (__irq_svc) from [<c0bdd51e>]
> (__qdisc_run+0x6d2/0x7b8)
> [   28.508082] [<c0bdd51e>] (__qdisc_run) from [<c0100155>]
> (ret_from_fork+0x11/0x1c)
> [   28.532185] Exception stack(0xc4dc6ffc to 0xc4dc7044)
> [   28.556578] 6fe0:
>            00000000
> [   28.581249] 7000: c1902d18 c4dc8000 00000000 00000000 00000003
> 00000000 00000000 00000001
> [   28.605909] 7020: 41b58ab3 c1864c40 c0b94e6c 00000800 00000000
> c2c01e00 00000001 c09bbe7f
> [   28.630740] 7040: fffffff4
>
> [   28.679636] The buggy address belongs to the page:
> [   28.704480] page:bc50e6d8 refcount:0 mapcount:0 mapping:00000000
> index:0x0 pfn:0x84dc7
> [   28.729687] flags: 0x0()
> [   28.754372] raw: 00000000 defa7000 defa7000 00000000 00000000
> 00000000 ffffffff 00000000
> [   28.779394] raw: 00000000
> [   28.804339] page dumped because: kasan: bad access detected
>
> [   28.854326] addr c4dc7038 is located in stack of task
> kworker/0:1H/124 at offset 24 in frame:
> [   28.880073]  __dev_queue_xmit+0x0/0x9cc
>
> [   28.931135] this frame has 4 objects:
> [   28.956624]  [32, 36) 'rc'
> [   28.956638]  [48, 52) 'to_free'
> [   28.981922]  [64, 72) '_udphdr'
> [   29.007038]  [96, 116) '_tcphdr'
>
> [   29.081989] Memory state around the buggy address:
> [   29.106884]  c4dc6f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [   29.132106]  c4dc6f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [   29.157134] >c4dc7000: 00 00 00 00 f1 f1 f1 f1 04 f2 04 f2 00 f2 f2 f2
> [   29.181980]                                 ^
> [   29.206867]  c4dc7080: 00 00 04 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00
> [   29.231827]  c4dc7100: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04 f3 f3 f3
> [   29.257034]
> ==================================================================
>

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

[Ard Biesheuvel]

On Thu, 29 Oct 2020 at 18:45, Dmitry Osipenko <digetx@gmail.com> wrote:
>
> 19.10.2020 11:41, Linus Walleij пишет:
> > This is the 16th and final (knock on wood) version of
> > KASan for ARM32.
>
> Hi,
>
> I tried KASAN on NVIDIA Tegra using next-20201029 and getting a (seems)
> bogus bug report saying that the bug is in the KASAN code (note
> udc_irq() belongs to the ChipIdea USB driver), this problem doesn't
> happen using one of older versions of the KASAN patches.
>

That is probably a coincidence. I ran into the same thing:

https://lore.kernel.org/linux-arm-kernel/20201029001753.717-1-ardb@kernel.org/

I am not sure this is the right fix, but it does silence the warning for me.


> [   27.700859]
> ==================================================================
> [   27.720575] BUG: KASAN: stack-out-of-bounds in save_trace+0xbf/0xf8
> [   27.740119] Read of size 4 at addr c4dc7038 by task kworker/0:1H/124
>
> [   27.778724] CPU: 0 PID: 124 Comm: kworker/0:1H Tainted: G        W
>      5.10.0-rc1-next-20201029-00144-g367ba7b6ebb4 #4327
> [   27.818361] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
> [   27.838599] Workqueue: mmc_complete mmc_blk_mq_complete_work
> [   27.858795] [<c0111a05>] (unwind_backtrace) from [<c010c26d>]
> (show_stack+0x11/0x14)
> [   27.879038] [<c010c26d>] (show_stack) from [<c0f42e5b>]
> (dump_stack+0x8b/0xa0)
> [   27.899374] [<c0f42e5b>] (dump_stack) from [<c031d8f7>]
> (print_address_description.constprop.0+0x2b/0x360)
> [   27.939249] [<c031d8f7>] (print_address_description.constprop.0) from
> [<c031ddab>] (kasan_report+0x103/0x11c)
> [   27.979769] [<c031ddab>] (kasan_report) from [<c010bddb>]
> (save_trace+0xbf/0xf8)
> [   28.000506] [<c010bddb>] (save_trace) from [<c010bd11>]
> (walk_stackframe+0x19/0x24)
> [   28.021501] [<c010bd11>] (walk_stackframe) from [<c010bf07>]
> (__save_stack_trace+0xf3/0xf8)
> [   28.042658] [<c010bf07>] (__save_stack_trace) from [<c01b8c4d>]
> (stack_trace_save+0x75/0x8c)
> [   28.063740] [<c01b8c4d>] (stack_trace_save) from [<c031d019>]
> (kasan_save_stack+0x11/0x28)
> [   28.084979] [<c031d019>] (kasan_save_stack) from [<c031d04d>]
> (kasan_set_track+0x1d/0x20)
> [   28.106135] [<c031d04d>] (kasan_set_track) from [<c031e461>]
> (kasan_set_free_info+0x19/0x20)
> [   28.127351] [<c031e461>] (kasan_set_free_info) from [<c031cfe5>]
> (__kasan_slab_free+0xa5/0xc8)
> [   28.148491] [<c031cfe5>] (__kasan_slab_free) from [<c0318b7f>]
> (kfree+0x7b/0x374)
> [   28.169910] [<c0318b7f>] (kfree) from [<c09bbe7f>] (udc_irq+0x477/0xe18)
> [   28.191214] [<c09bbe7f>] (udc_irq) from [<c019cb09>]
> (__handle_irq_event_percpu+0x71/0x2d4)
> [   28.212693] [<c019cb09>] (__handle_irq_event_percpu) from
> [<c019cde1>] (handle_irq_event_percpu+0x75/0xb8)
> [   28.255076] [<c019cde1>] (handle_irq_event_percpu) from [<c019ce67>]
> (handle_irq_event+0x43/0x64)
> [   28.277174] [<c019ce67>] (handle_irq_event) from [<c01a1bbb>]
> (handle_fasteoi_irq+0xcf/0x18c)
> [   28.299436] [<c01a1bbb>] (handle_fasteoi_irq) from [<c019bd4b>]
> (generic_handle_irq+0x3b/0x44)
> [   28.321825] [<c019bd4b>] (generic_handle_irq) from [<c019c34b>]
> (__handle_domain_irq+0x5f/0xa8)
> [   28.344383] [<c019c34b>] (__handle_domain_irq) from [<c06b30cf>]
> (gic_handle_irq+0x87/0x9c)
> [   28.367176] [<c06b30cf>] (gic_handle_irq) from [<c0100b23>]
> (__irq_svc+0x63/0xb0)
> [   28.390118] Exception stack(0xc4dc6f58 to 0xc4dc6fa0)
> [   28.413200] 6f40:
>   c1fa88c4 00000000
> [   28.436622] 6f60: c1fa88c4 00000000 c5557800 00000000 00000001
> c5557808 00000001 c1fa88c0
> [   28.460176] 6f80: 00000000 c466c000 b782c97b c4dc6fac c0bdcfa1
> c0bdd51e 60070133 ffffffff
> [   28.484070] [<c0100b23>] (__irq_svc) from [<c0bdd51e>]
> (__qdisc_run+0x6d2/0x7b8)
> [   28.508082] [<c0bdd51e>] (__qdisc_run) from [<c0100155>]
> (ret_from_fork+0x11/0x1c)
> [   28.532185] Exception stack(0xc4dc6ffc to 0xc4dc7044)
> [   28.556578] 6fe0:
>            00000000
> [   28.581249] 7000: c1902d18 c4dc8000 00000000 00000000 00000003
> 00000000 00000000 00000001
> [   28.605909] 7020: 41b58ab3 c1864c40 c0b94e6c 00000800 00000000
> c2c01e00 00000001 c09bbe7f
> [   28.630740] 7040: fffffff4
>
> [   28.679636] The buggy address belongs to the page:
> [   28.704480] page:bc50e6d8 refcount:0 mapcount:0 mapping:00000000
> index:0x0 pfn:0x84dc7
> [   28.729687] flags: 0x0()
> [   28.754372] raw: 00000000 defa7000 defa7000 00000000 00000000
> 00000000 ffffffff 00000000
> [   28.779394] raw: 00000000
> [   28.804339] page dumped because: kasan: bad access detected
>
> [   28.854326] addr c4dc7038 is located in stack of task
> kworker/0:1H/124 at offset 24 in frame:
> [   28.880073]  __dev_queue_xmit+0x0/0x9cc
>
> [   28.931135] this frame has 4 objects:
> [   28.956624]  [32, 36) 'rc'
> [   28.956638]  [48, 52) 'to_free'
> [   28.981922]  [64, 72) '_udphdr'
> [   29.007038]  [96, 116) '_tcphdr'
>
> [   29.081989] Memory state around the buggy address:
> [   29.106884]  c4dc6f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [   29.132106]  c4dc6f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [   29.157134] >c4dc7000: 00 00 00 00 f1 f1 f1 f1 04 f2 04 f2 00 f2 f2 f2
> [   29.181980]                                 ^
> [   29.206867]  c4dc7080: 00 00 04 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00
> [   29.231827]  c4dc7100: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04 f3 f3 f3
> [   29.257034]
> ==================================================================
>

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

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

[Dmitry Osipenko]

29.10.2020 21:10, Ard Biesheuvel пишет:
> On Thu, 29 Oct 2020 at 18:45, Dmitry Osipenko <digetx@gmail.com> wrote:
>>
>> 19.10.2020 11:41, Linus Walleij пишет:
>>> This is the 16th and final (knock on wood) version of
>>> KASan for ARM32.
>>
>> Hi,
>>
>> I tried KASAN on NVIDIA Tegra using next-20201029 and getting a (seems)
>> bogus bug report saying that the bug is in the KASAN code (note
>> udc_irq() belongs to the ChipIdea USB driver), this problem doesn't
>> happen using one of older versions of the KASAN patches.
>>
> 
> That is probably a coincidence. I ran into the same thing:
> 
> https://lore.kernel.org/linux-arm-kernel/20201029001753.717-1-ardb@kernel.org/
> 
> I am not sure this is the right fix, but it does silence the warning for me.

Disabling instrumentation for the stacktrace indeed fixes it, thank you.

Now there is another problem.. next-20201029 has the same trouble which
all previous versions of the KASAN series had, where tasks are hanging
in unkillable state, eating 100% CPU.

For example I never managed to get Xorg to work with the ARM32 KASAN,
this is what happens (sometimes it happens during boot, where systemd
services hang):

 INFO: task pool-nm-online:448 can't die for more than 61 seconds.
 task:pool-nm-online  state:R  running task     stack:    0 pid:  448
ppid:     1 flags:0x00000001
 [<c0e30e5f>] (__schedule) from [<c01c3699>]
(get_futex_value_locked+0xa1/0xb8)
 [<c01c3699>] (get_futex_value_locked) from [<c01c4a81>]
(futex_wait_setup+0xc1/0x150)
 [<c01c4a81>] (futex_wait_setup) from [<c01c4bc3>] (futex_wait+0xb3/0x1d0)
 [<c01c4bc3>] (futex_wait) from [<c01c66d7>] (do_futex+0xcf/0xabc)
 [<c01c66d7>] (do_futex) from [<c01c7285>] (sys_futex_time32+0xbd/0x138)
 [<c01c7285>] (sys_futex_time32) from [<c01000a1>]
(ret_fast_syscall+0x1/0x26)
 Exception stack(0xc648bfa8 to 0xc648bff0)
 bfa0:                   00000000 acb09e48 acb09e48 00000080 00000002
00000000
 bfc0: 00000000 acb09e48 acb09e48 000000f0 ad4f0990 7fffffff 00000001
00000000
 bfe0: ad4f0918 ad4f0908 aea1d087 ae924e62
 INFO: task blueman-mechani:279 can't die for more than 61 seconds.
 task:blueman-mechani state:R  running task     stack:    0 pid:  279
ppid:     1 flags:0x00000001
 [<c0e30e5f>] (__schedule) from [<c0e31581>]
(preempt_schedule_common+0x29/0x48)
 [<c0e31581>] (preempt_schedule_common) from [<c01c4a19>]
(futex_wait_setup+0x59/0x150)
 [<c01c4a19>] (futex_wait_setup) from [<c01c4bc3>] (futex_wait+0xb3/0x1d0)
 [<c01c4bc3>] (futex_wait) from [<c01c66d7>] (do_futex+0xcf/0xabc)
 [<c01c66d7>] (do_futex) from [<c01c7285>] (sys_futex_time32+0xbd/0x138)
 [<c01c7285>] (sys_futex_time32) from [<c01000a1>]
(ret_fast_syscall+0x1/0x26)
 Exception stack(0xc300bfa8 to 0xc300bff0)
 bfa0:                   00000000 00538cd0 00538cd0 00000080 00000002
00000000
 bfc0: 00000000 00538cd0 00538cd0 000000f0 b6af1320 7fffffff 00000001
00000000
 bfe0: b6af12a8 b6af1298 ae3e8087 aed00e62
 INFO: task polkitd:292 can't die for more than 61 seconds.
 task:polkitd         state:R  running task     stack:    0 pid:  292
ppid:     1 flags:0x00000001
 [<c0e30e5f>] (__schedule) from [<c0e31581>]
(preempt_schedule_common+0x29/0x48)
 [<c0e31581>] (preempt_schedule_common) from [<c01c4a19>]
(futex_wait_setup+0x59/0x150)
 [<c01c4a19>] (futex_wait_setup) from [<c01c4bc3>] (futex_wait+0xb3/0x1d0)
 [<c01c4bc3>] (futex_wait) from [<c01c66d7>] (do_futex+0xcf/0xabc)
 [<c01c66d7>] (do_futex) from [<c01c7285>] (sys_futex_time32+0xbd/0x138)
 [<c01c7285>] (sys_futex_time32) from [<c01000a1>]
(ret_fast_syscall+0x1/0x26)
 Exception stack(0xc48a3fa8 to 0xc48a3ff0)
 3fa0:                   00000000 0043a788 0043a788 00000080 00000002
00000000
 3fc0: 00000000 0043a788 0043a788 000000f0 b67eac70 7fffffff 00000001
00000000
 3fe0: b67eabf8 b67eabe8 aeadd087 ae936e62
 INFO: task pool-polkitd:315 can't die for more than 61 seconds.
 task:pool-polkitd    state:R  running task     stack:    0 pid:  315
ppid:     1 flags:0x00000001
 [<c0e30e5f>] (__schedule) from [<c0e31b73>]
(preempt_schedule_irq+0x6f/0x12c)
 [<c0e31b73>] (preempt_schedule_irq) from [<c0100b77>]
(svc_preempt+0x7/0x14)
 Exception stack(0xc7b57d30 to 0xc7b57d78)
 7d20:                                     c7b54004 00000000 c7b54004
00000007
 7d40: c7b54000 00000000 c7b54004 c7b57e20 c7b57e40 c7b57e38 c7b54000
c2c28e44
 7d60: c7b54040 c7b57d80 c0e36849 c0e3684e 20030133 ffffffff
 [<c0100b77>] (svc_preempt) from [<c0e3684e>] (_raw_spin_unlock+0x42/0x58)
 [<c0e3684e>] (_raw_spin_unlock) from [<c01c4a19>]
(futex_wait_setup+0x59/0x150)
 [<c01c4a19>] (futex_wait_setup) from [<c01c4bc3>] (futex_wait+0xb3/0x1d0)
 [<c01c4bc3>] (futex_wait) from [<c01c66d7>] (do_futex+0xcf/0xabc)
 [<c01c66d7>] (do_futex) from [<c01c7285>] (sys_futex_time32+0xbd/0x138)
 [<c01c7285>] (sys_futex_time32) from [<c01000a1>]
(ret_fast_syscall+0x1/0x26)
 Exception stack(0xc7b57fa8 to 0xc7b57ff0)
 7fa0:                   0007a120 00000000 0043cd1c 00000080 00000000
add22cec
 7fc0: 0007a120 00000000 00000000 000000f0 0043cd10 0043cd18 aeb529b0
aeb51be0
 7fe0: add22cd0 add22cc0 aeadda45 ae936e62
 INFO: task pool-udisksd:340 can't die for more than 61 seconds.
 task:pool-udisksd    state:R  running task     stack:    0 pid:  340
ppid:     1 flags:0x00000001
 [<c0e30e5f>] (__schedule) from [<c0e31b73>]
(preempt_schedule_irq+0x6f/0x12c)
 [<c0e31b73>] (preempt_schedule_irq) from [<c0100b77>]
(svc_preempt+0x7/0x14)
 Exception stack(0xc6abfd40 to 0xc6abfd88)
 fd40: c6abfe38 00000000 c6abfe38 00000003 c6abfde4 c2c28d00 00546084
c6abfe20
 fd60: c6abfe40 c6abfe38 c6abc000 c2c28d04 c6abc040 c6abfd90 c01c4aa7
c01c4aa6
 fd80: 000b0133 ffffffff
 [<c0100b77>] (svc_preempt) from [<c01c4aa6>] (futex_wait_setup+0xe6/0x150)
 [<c01c4aa6>] (futex_wait_setup) from [<c01c4bc3>] (futex_wait+0xb3/0x1d0)
 [<c01c4bc3>] (futex_wait) from [<c01c66d7>] (do_futex+0xcf/0xabc)
 [<c01c66d7>] (do_futex) from [<c01c7285>] (sys_futex_time32+0xbd/0x138)
 [<c01c7285>] (sys_futex_time32) from [<c01000a1>]
(ret_fast_syscall+0x1/0x26)
 Exception stack(0xc6abffa8 to 0xc6abfff0)
 ffa0:                   0007a120 00000000 00546084 00000080 00000000
ad8fecdc
 ffc0: 0007a120 00000000 00000000 000000f0 00546078 00546080 ae9f79b0
ae9f6be0
 ffe0: ad8fecc0 ad8fecb0 ae982a45 ae889e62
 INFO: task gdbus:433 can't die for more than 61 seconds.
 task:gdbus           state:R  running task     stack:    0 pid:  433
ppid:     1 flags:0x00000001
 [<c0e30e5f>] (__schedule) from [<c0e31581>]
(preempt_schedule_common+0x29/0x48)
 [<c0e31581>] (preempt_schedule_common) from [<c01c4a19>]
(futex_wait_setup+0x59/0x150)
 [<c01c4a19>] (futex_wait_setup) from [<c01c4bc3>] (futex_wait+0xb3/0x1d0)
 [<c01c4bc3>] (futex_wait) from [<c01c66d7>] (do_futex+0xcf/0xabc)
 [<c01c66d7>] (do_futex) from [<c01c7285>] (sys_futex_time32+0xbd/0x138)
 [<c01c7285>] (sys_futex_time32) from [<c01000a1>]
(ret_fast_syscall+0x1/0x26)
 Exception stack(0xc5b03fa8 to 0xc5b03ff0)
 3fa0:                   0054e010 aeb770bc 0054e01c 00000080 00000002
00000000
 3fc0: 0054e010 aeb770bc 0054aef0 000000f0 0054e01c 0055a150 0054aef0
00000000
 3fe0: acefec28 acefec18 ae982087 ae889e62
 INFO: task probing-thread:551 can't die for more than 61 seconds.
 task:probing-thread  state:R  running task     stack:    0 pid:  551
ppid:     1 flags:0x00000001
 [<c0e30e5f>] (__schedule) from [<c0e31b73>]
(preempt_schedule_irq+0x6f/0x12c)
 [<c0e31b73>] (preempt_schedule_irq) from [<c0100b77>]
(svc_preempt+0x7/0x14)
 Exception stack(0xc8cf3d28 to 0xc8cf3d70)
 3d20:                   c8cf0000 c8cf0003 c8cf0000 00000003 c8cf0000
00000000
 3d40: c8cf0004 c8cf3e20 c8cf3e40 c8cf3e38 c8cf0000 c2c2a484 c8cf0040
c8cf3d7c
 3d60: c0e36855 c02f2404 800b0133 ffffffff
 [<c0100b77>] (svc_preempt) from [<c02f2404>] (__asan_load4+0x14/0x60)
 [<c02f2404>] (__asan_load4) from [<c0e36855>] (_raw_spin_unlock+0x49/0x58)
 [<c0e36855>] (_raw_spin_unlock) from [<c01c4a19>]
(futex_wait_setup+0x59/0x150)
 [<c01c4a19>] (futex_wait_setup) from [<c01c4bc3>] (futex_wait+0xb3/0x1d0)
 [<c01c4bc3>] (futex_wait) from [<c01c66d7>] (do_futex+0xcf/0xabc)
 [<c01c66d7>] (do_futex) from [<c01c7285>] (sys_futex_time32+0xbd/0x138)
 [<c01c7285>] (sys_futex_time32) from [<c01000a1>]
(ret_fast_syscall+0x1/0x26)
 Exception stack(0xc8cf3fa8 to 0xc8cf3ff0)
 3fa0:                   00000000 0056410c 0056410c 00000080 00000000
00000000
 3fc0: 00000000 0056410c 00000000 000000f0 00564114 00564108 00000000
b6b5e540
 3fe0: ac2e9cf8 ac2e9ce8 ae982935 ae889e62
 INFO: task pool:364 can't die for more than 61 seconds.
 task:pool            state:R  running task     stack:    0 pid:  364
ppid:     1 flags:0x00000081
 [<c0e30e5f>] (__schedule) from [<c0e31b73>]
(preempt_schedule_irq+0x6f/0x12c)
 [<c0e31b73>] (preempt_schedule_irq) from [<c0100b77>]
(svc_preempt+0x7/0x14)
 Exception stack(0xc73fbd40 to 0xc73fbd88)
 bd40: c2c28fc0 c16084b0 000003ff 00000001 c73fbde4 c2c28fc0 ad609e80
c73fbe20
 bd60: c73fbe40 c73fbe38 c73f8000 c2c28fc4 c73f8040 c73fbd90 c01c3bcf
c01c4a8e
 bd80: 200e0133 ffffffff
 [<c0100b77>] (svc_preempt) from [<c01c4a8e>] (futex_wait_setup+0xce/0x150)
 [<c01c4a8e>] (futex_wait_setup) from [<c01c4bc3>] (futex_wait+0xb3/0x1d0)
 [<c01c4bc3>] (futex_wait) from [<c01c66d7>] (do_futex+0xcf/0xabc)
 [<c01c66d7>] (do_futex) from [<c01c7285>] (sys_futex_time32+0xbd/0x138)
 [<c01c7285>] (sys_futex_time32) from [<c010024b>]
(__sys_trace_return+0x1/0x16)
 Exception stack(0xc73fbfa8 to 0xc73fbff0)
 bfa0:                   00000000 ad609e80 ad609e80 00000080 00000002
00000000
 bfc0: 00000000 ad609e80 ad609e80 000000f0 adf20be0 7fffffff 00000001
00000000
 bfe0: adf20b68 adf20b58 aeb84087 aea48e62
 INFO: task pool-nm-online:448 can't die for more than 122 seconds.
 task:pool-nm-online  state:R  running task     stack:    0 pid:  448
ppid:     1 flags:0x00000001
 [<c0e30e5f>] (__schedule) from [<c0e31b73>]
(preempt_schedule_irq+0x6f/0x12c)
 [<c0e31b73>] (preempt_schedule_irq) from [<c0100b77>]
(svc_preempt+0x7/0x14)
 Exception stack(0xc648bd20 to 0xc648bd68)
 bd20: c648be48 c648be4b c648be48 c648be4d c648bde4 deadcd43 acb09e48
c648be40
 bd40: c648be40 c648be38 c6488000 c2c21404 c6488040 c648bd74 c01c3bbd
c02f2400
 bd60: 80030133 ffffffff
 [<c0100b77>] (svc_preempt) from [<c02f2400>] (__asan_load4+0x10/0x60)
 [<c02f2400>] (__asan_load4) from [<c01c3bbd>] (hash_futex+0x25/0x80)
 [<c01c3bbd>] (hash_futex) from [<c01c4a81>] (futex_wait_setup+0xc1/0x150)
 [<c01c4a81>] (futex_wait_setup) from [<c01c4bc3>] (futex_wait+0xb3/0x1d0)
 [<c01c4bc3>] (futex_wait) from [<c01c66d7>] (do_futex+0xcf/0xabc)
 [<c01c66d7>] (do_futex) from [<c01c7285>] (sys_futex_time32+0xbd/0x138)
 [<c01c7285>] (sys_futex_time32) from [<c01000a1>]
(ret_fast_syscall+0x1/0x26)
 Exception stack(0xc648bfa8 to 0xc648bff0)
 bfa0:                   00000000 acb09e48 acb09e48 00000080 00000002
00000000
 bfc0: 00000000 acb09e48 acb09e48 000000f0 ad4f0990 7fffffff 00000001
00000000
 bfe0: ad4f0918 ad4f0908 aea1d087 ae924e62

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

[Dmitry Osipenko]

29.10.2020 21:10, Ard Biesheuvel пишет:
> On Thu, 29 Oct 2020 at 18:45, Dmitry Osipenko <digetx@gmail.com> wrote:
>>
>> 19.10.2020 11:41, Linus Walleij пишет:
>>> This is the 16th and final (knock on wood) version of
>>> KASan for ARM32.
>>
>> Hi,
>>
>> I tried KASAN on NVIDIA Tegra using next-20201029 and getting a (seems)
>> bogus bug report saying that the bug is in the KASAN code (note
>> udc_irq() belongs to the ChipIdea USB driver), this problem doesn't
>> happen using one of older versions of the KASAN patches.
>>
> 
> That is probably a coincidence. I ran into the same thing:
> 
> https://lore.kernel.org/linux-arm-kernel/20201029001753.717-1-ardb@kernel.org/
> 
> I am not sure this is the right fix, but it does silence the warning for me.

Disabling instrumentation for the stacktrace indeed fixes it, thank you.

Now there is another problem.. next-20201029 has the same trouble which
all previous versions of the KASAN series had, where tasks are hanging
in unkillable state, eating 100% CPU.

For example I never managed to get Xorg to work with the ARM32 KASAN,
this is what happens (sometimes it happens during boot, where systemd
services hang):

 INFO: task pool-nm-online:448 can't die for more than 61 seconds.
 task:pool-nm-online  state:R  running task     stack:    0 pid:  448
ppid:     1 flags:0x00000001
 [<c0e30e5f>] (__schedule) from [<c01c3699>]
(get_futex_value_locked+0xa1/0xb8)
 [<c01c3699>] (get_futex_value_locked) from [<c01c4a81>]
(futex_wait_setup+0xc1/0x150)
 [<c01c4a81>] (futex_wait_setup) from [<c01c4bc3>] (futex_wait+0xb3/0x1d0)
 [<c01c4bc3>] (futex_wait) from [<c01c66d7>] (do_futex+0xcf/0xabc)
 [<c01c66d7>] (do_futex) from [<c01c7285>] (sys_futex_time32+0xbd/0x138)
 [<c01c7285>] (sys_futex_time32) from [<c01000a1>]
(ret_fast_syscall+0x1/0x26)
 Exception stack(0xc648bfa8 to 0xc648bff0)
 bfa0:                   00000000 acb09e48 acb09e48 00000080 00000002
00000000
 bfc0: 00000000 acb09e48 acb09e48 000000f0 ad4f0990 7fffffff 00000001
00000000
 bfe0: ad4f0918 ad4f0908 aea1d087 ae924e62
 INFO: task blueman-mechani:279 can't die for more than 61 seconds.
 task:blueman-mechani state:R  running task     stack:    0 pid:  279
ppid:     1 flags:0x00000001
 [<c0e30e5f>] (__schedule) from [<c0e31581>]
(preempt_schedule_common+0x29/0x48)
 [<c0e31581>] (preempt_schedule_common) from [<c01c4a19>]
(futex_wait_setup+0x59/0x150)
 [<c01c4a19>] (futex_wait_setup) from [<c01c4bc3>] (futex_wait+0xb3/0x1d0)
 [<c01c4bc3>] (futex_wait) from [<c01c66d7>] (do_futex+0xcf/0xabc)
 [<c01c66d7>] (do_futex) from [<c01c7285>] (sys_futex_time32+0xbd/0x138)
 [<c01c7285>] (sys_futex_time32) from [<c01000a1>]
(ret_fast_syscall+0x1/0x26)
 Exception stack(0xc300bfa8 to 0xc300bff0)
 bfa0:                   00000000 00538cd0 00538cd0 00000080 00000002
00000000
 bfc0: 00000000 00538cd0 00538cd0 000000f0 b6af1320 7fffffff 00000001
00000000
 bfe0: b6af12a8 b6af1298 ae3e8087 aed00e62
 INFO: task polkitd:292 can't die for more than 61 seconds.
 task:polkitd         state:R  running task     stack:    0 pid:  292
ppid:     1 flags:0x00000001
 [<c0e30e5f>] (__schedule) from [<c0e31581>]
(preempt_schedule_common+0x29/0x48)
 [<c0e31581>] (preempt_schedule_common) from [<c01c4a19>]
(futex_wait_setup+0x59/0x150)
 [<c01c4a19>] (futex_wait_setup) from [<c01c4bc3>] (futex_wait+0xb3/0x1d0)
 [<c01c4bc3>] (futex_wait) from [<c01c66d7>] (do_futex+0xcf/0xabc)
 [<c01c66d7>] (do_futex) from [<c01c7285>] (sys_futex_time32+0xbd/0x138)
 [<c01c7285>] (sys_futex_time32) from [<c01000a1>]
(ret_fast_syscall+0x1/0x26)
 Exception stack(0xc48a3fa8 to 0xc48a3ff0)
 3fa0:                   00000000 0043a788 0043a788 00000080 00000002
00000000
 3fc0: 00000000 0043a788 0043a788 000000f0 b67eac70 7fffffff 00000001
00000000
 3fe0: b67eabf8 b67eabe8 aeadd087 ae936e62
 INFO: task pool-polkitd:315 can't die for more than 61 seconds.
 task:pool-polkitd    state:R  running task     stack:    0 pid:  315
ppid:     1 flags:0x00000001
 [<c0e30e5f>] (__schedule) from [<c0e31b73>]
(preempt_schedule_irq+0x6f/0x12c)
 [<c0e31b73>] (preempt_schedule_irq) from [<c0100b77>]
(svc_preempt+0x7/0x14)
 Exception stack(0xc7b57d30 to 0xc7b57d78)
 7d20:                                     c7b54004 00000000 c7b54004
00000007
 7d40: c7b54000 00000000 c7b54004 c7b57e20 c7b57e40 c7b57e38 c7b54000
c2c28e44
 7d60: c7b54040 c7b57d80 c0e36849 c0e3684e 20030133 ffffffff
 [<c0100b77>] (svc_preempt) from [<c0e3684e>] (_raw_spin_unlock+0x42/0x58)
 [<c0e3684e>] (_raw_spin_unlock) from [<c01c4a19>]
(futex_wait_setup+0x59/0x150)
 [<c01c4a19>] (futex_wait_setup) from [<c01c4bc3>] (futex_wait+0xb3/0x1d0)
 [<c01c4bc3>] (futex_wait) from [<c01c66d7>] (do_futex+0xcf/0xabc)
 [<c01c66d7>] (do_futex) from [<c01c7285>] (sys_futex_time32+0xbd/0x138)
 [<c01c7285>] (sys_futex_time32) from [<c01000a1>]
(ret_fast_syscall+0x1/0x26)
 Exception stack(0xc7b57fa8 to 0xc7b57ff0)
 7fa0:                   0007a120 00000000 0043cd1c 00000080 00000000
add22cec
 7fc0: 0007a120 00000000 00000000 000000f0 0043cd10 0043cd18 aeb529b0
aeb51be0
 7fe0: add22cd0 add22cc0 aeadda45 ae936e62
 INFO: task pool-udisksd:340 can't die for more than 61 seconds.
 task:pool-udisksd    state:R  running task     stack:    0 pid:  340
ppid:     1 flags:0x00000001
 [<c0e30e5f>] (__schedule) from [<c0e31b73>]
(preempt_schedule_irq+0x6f/0x12c)
 [<c0e31b73>] (preempt_schedule_irq) from [<c0100b77>]
(svc_preempt+0x7/0x14)
 Exception stack(0xc6abfd40 to 0xc6abfd88)
 fd40: c6abfe38 00000000 c6abfe38 00000003 c6abfde4 c2c28d00 00546084
c6abfe20
 fd60: c6abfe40 c6abfe38 c6abc000 c2c28d04 c6abc040 c6abfd90 c01c4aa7
c01c4aa6
 fd80: 000b0133 ffffffff
 [<c0100b77>] (svc_preempt) from [<c01c4aa6>] (futex_wait_setup+0xe6/0x150)
 [<c01c4aa6>] (futex_wait_setup) from [<c01c4bc3>] (futex_wait+0xb3/0x1d0)
 [<c01c4bc3>] (futex_wait) from [<c01c66d7>] (do_futex+0xcf/0xabc)
 [<c01c66d7>] (do_futex) from [<c01c7285>] (sys_futex_time32+0xbd/0x138)
 [<c01c7285>] (sys_futex_time32) from [<c01000a1>]
(ret_fast_syscall+0x1/0x26)
 Exception stack(0xc6abffa8 to 0xc6abfff0)
 ffa0:                   0007a120 00000000 00546084 00000080 00000000
ad8fecdc
 ffc0: 0007a120 00000000 00000000 000000f0 00546078 00546080 ae9f79b0
ae9f6be0
 ffe0: ad8fecc0 ad8fecb0 ae982a45 ae889e62
 INFO: task gdbus:433 can't die for more than 61 seconds.
 task:gdbus           state:R  running task     stack:    0 pid:  433
ppid:     1 flags:0x00000001
 [<c0e30e5f>] (__schedule) from [<c0e31581>]
(preempt_schedule_common+0x29/0x48)
 [<c0e31581>] (preempt_schedule_common) from [<c01c4a19>]
(futex_wait_setup+0x59/0x150)
 [<c01c4a19>] (futex_wait_setup) from [<c01c4bc3>] (futex_wait+0xb3/0x1d0)
 [<c01c4bc3>] (futex_wait) from [<c01c66d7>] (do_futex+0xcf/0xabc)
 [<c01c66d7>] (do_futex) from [<c01c7285>] (sys_futex_time32+0xbd/0x138)
 [<c01c7285>] (sys_futex_time32) from [<c01000a1>]
(ret_fast_syscall+0x1/0x26)
 Exception stack(0xc5b03fa8 to 0xc5b03ff0)
 3fa0:                   0054e010 aeb770bc 0054e01c 00000080 00000002
00000000
 3fc0: 0054e010 aeb770bc 0054aef0 000000f0 0054e01c 0055a150 0054aef0
00000000
 3fe0: acefec28 acefec18 ae982087 ae889e62
 INFO: task probing-thread:551 can't die for more than 61 seconds.
 task:probing-thread  state:R  running task     stack:    0 pid:  551
ppid:     1 flags:0x00000001
 [<c0e30e5f>] (__schedule) from [<c0e31b73>]
(preempt_schedule_irq+0x6f/0x12c)
 [<c0e31b73>] (preempt_schedule_irq) from [<c0100b77>]
(svc_preempt+0x7/0x14)
 Exception stack(0xc8cf3d28 to 0xc8cf3d70)
 3d20:                   c8cf0000 c8cf0003 c8cf0000 00000003 c8cf0000
00000000
 3d40: c8cf0004 c8cf3e20 c8cf3e40 c8cf3e38 c8cf0000 c2c2a484 c8cf0040
c8cf3d7c
 3d60: c0e36855 c02f2404 800b0133 ffffffff
 [<c0100b77>] (svc_preempt) from [<c02f2404>] (__asan_load4+0x14/0x60)
 [<c02f2404>] (__asan_load4) from [<c0e36855>] (_raw_spin_unlock+0x49/0x58)
 [<c0e36855>] (_raw_spin_unlock) from [<c01c4a19>]
(futex_wait_setup+0x59/0x150)
 [<c01c4a19>] (futex_wait_setup) from [<c01c4bc3>] (futex_wait+0xb3/0x1d0)
 [<c01c4bc3>] (futex_wait) from [<c01c66d7>] (do_futex+0xcf/0xabc)
 [<c01c66d7>] (do_futex) from [<c01c7285>] (sys_futex_time32+0xbd/0x138)
 [<c01c7285>] (sys_futex_time32) from [<c01000a1>]
(ret_fast_syscall+0x1/0x26)
 Exception stack(0xc8cf3fa8 to 0xc8cf3ff0)
 3fa0:                   00000000 0056410c 0056410c 00000080 00000000
00000000
 3fc0: 00000000 0056410c 00000000 000000f0 00564114 00564108 00000000
b6b5e540
 3fe0: ac2e9cf8 ac2e9ce8 ae982935 ae889e62
 INFO: task pool:364 can't die for more than 61 seconds.
 task:pool            state:R  running task     stack:    0 pid:  364
ppid:     1 flags:0x00000081
 [<c0e30e5f>] (__schedule) from [<c0e31b73>]
(preempt_schedule_irq+0x6f/0x12c)
 [<c0e31b73>] (preempt_schedule_irq) from [<c0100b77>]
(svc_preempt+0x7/0x14)
 Exception stack(0xc73fbd40 to 0xc73fbd88)
 bd40: c2c28fc0 c16084b0 000003ff 00000001 c73fbde4 c2c28fc0 ad609e80
c73fbe20
 bd60: c73fbe40 c73fbe38 c73f8000 c2c28fc4 c73f8040 c73fbd90 c01c3bcf
c01c4a8e
 bd80: 200e0133 ffffffff
 [<c0100b77>] (svc_preempt) from [<c01c4a8e>] (futex_wait_setup+0xce/0x150)
 [<c01c4a8e>] (futex_wait_setup) from [<c01c4bc3>] (futex_wait+0xb3/0x1d0)
 [<c01c4bc3>] (futex_wait) from [<c01c66d7>] (do_futex+0xcf/0xabc)
 [<c01c66d7>] (do_futex) from [<c01c7285>] (sys_futex_time32+0xbd/0x138)
 [<c01c7285>] (sys_futex_time32) from [<c010024b>]
(__sys_trace_return+0x1/0x16)
 Exception stack(0xc73fbfa8 to 0xc73fbff0)
 bfa0:                   00000000 ad609e80 ad609e80 00000080 00000002
00000000
 bfc0: 00000000 ad609e80 ad609e80 000000f0 adf20be0 7fffffff 00000001
00000000
 bfe0: adf20b68 adf20b58 aeb84087 aea48e62
 INFO: task pool-nm-online:448 can't die for more than 122 seconds.
 task:pool-nm-online  state:R  running task     stack:    0 pid:  448
ppid:     1 flags:0x00000001
 [<c0e30e5f>] (__schedule) from [<c0e31b73>]
(preempt_schedule_irq+0x6f/0x12c)
 [<c0e31b73>] (preempt_schedule_irq) from [<c0100b77>]
(svc_preempt+0x7/0x14)
 Exception stack(0xc648bd20 to 0xc648bd68)
 bd20: c648be48 c648be4b c648be48 c648be4d c648bde4 deadcd43 acb09e48
c648be40
 bd40: c648be40 c648be38 c6488000 c2c21404 c6488040 c648bd74 c01c3bbd
c02f2400
 bd60: 80030133 ffffffff
 [<c0100b77>] (svc_preempt) from [<c02f2400>] (__asan_load4+0x10/0x60)
 [<c02f2400>] (__asan_load4) from [<c01c3bbd>] (hash_futex+0x25/0x80)
 [<c01c3bbd>] (hash_futex) from [<c01c4a81>] (futex_wait_setup+0xc1/0x150)
 [<c01c4a81>] (futex_wait_setup) from [<c01c4bc3>] (futex_wait+0xb3/0x1d0)
 [<c01c4bc3>] (futex_wait) from [<c01c66d7>] (do_futex+0xcf/0xabc)
 [<c01c66d7>] (do_futex) from [<c01c7285>] (sys_futex_time32+0xbd/0x138)
 [<c01c7285>] (sys_futex_time32) from [<c01000a1>]
(ret_fast_syscall+0x1/0x26)
 Exception stack(0xc648bfa8 to 0xc648bff0)
 bfa0:                   00000000 acb09e48 acb09e48 00000080 00000002
00000000
 bfc0: 00000000 acb09e48 acb09e48 000000f0 ad4f0990 7fffffff 00000001
00000000
 bfe0: ad4f0918 ad4f0908 aea1d087 ae924e62

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

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

[Dmitry Osipenko]

29.10.2020 21:10, Ard Biesheuvel пишет:
> On Thu, 29 Oct 2020 at 18:45, Dmitry Osipenko <digetx@gmail.com> wrote:
>>
>> 19.10.2020 11:41, Linus Walleij пишет:
>>> This is the 16th and final (knock on wood) version of
>>> KASan for ARM32.
>>
>> Hi,
>>
>> I tried KASAN on NVIDIA Tegra using next-20201029 and getting a (seems)
>> bogus bug report saying that the bug is in the KASAN code (note
>> udc_irq() belongs to the ChipIdea USB driver), this problem doesn't
>> happen using one of older versions of the KASAN patches.
>>
> 
> That is probably a coincidence. I ran into the same thing:
> 
> https://lore.kernel.org/linux-arm-kernel/20201029001753.717-1-ardb@kernel.org/
> 
> I am not sure this is the right fix, but it does silence the warning for me.

Spotted another similar problem, seems also bogus.

This is what happens on any driver module reload:

==================================================================
BUG: KASAN: global-out-of-bounds in load_module+0xc93/0x2c0c
Write of size 20480 at addr bf819000 by task modprobe/229

CPU: 2 PID: 229 Comm: modprobe Tainted: G        WC
5.10.0-rc1-next-20201102-00072-g37765d4f3395 #4497
Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
[<c01115e5>] (unwind_backtrace) from [<c010c181>] (show_stack+0x11/0x14)
[<c010c181>] (show_stack) from [<c0f38b6b>] (dump_stack+0x8b/0xa0)
[<c0f38b6b>] (dump_stack) from [<c031da9f>]
(print_address_description.constprop.0+0x15f/0x360)
[<c031da9f>] (print_address_description.constprop.0) from [<c031de1f>]
(kasan_report+0x103/0x11c)
[<c031de1f>] (kasan_report) from [<c031e3bb>]
(check_memory_region+0xc3/0x11c)
[<c031e3bb>] (check_memory_region) from [<c031d107>] (memset+0x13/0x24)
[<c031d107>] (memset) from [<c01e001f>] (load_module+0xc93/0x2c0c)
[<c01e001f>] (load_module) from [<c01e220b>] (sys_finit_module+0xd7/0x104)
[<c01e220b>] (sys_finit_module) from [<c01000a1>]
(ret_fast_syscall+0x1/0x24)
Exception stack(0xc377bfa8 to 0xc377bff0)
bfa0:                   0003f3e8 00000001 00000003 0002b744 00000000
b6db4e34
bfc0: 0003f3e8 00000001 6106d000 0000017b 0003f490 00000000 0003f3e8
000401c8
bfe0: b6db4db8 b6db4da8 00022534 aec9f250


Memory state around the buggy address:
 bf81b180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 bf81b200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>bf81b280: 00 00 00 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9
                                            ^
 bf81b300: 00 00 04 f9 f9 f9 f9 f9 00 00 00 00 00 00 05 f9
 bf81b380: f9 f9 f9 f9 07 f9 f9 f9 f9 f9 f9 f9 00 00 05 f9
==================================================================
Disabling lock debugging due to kernel taint

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

[Dmitry Osipenko]

29.10.2020 21:10, Ard Biesheuvel пишет:
> On Thu, 29 Oct 2020 at 18:45, Dmitry Osipenko <digetx@gmail.com> wrote:
>>
>> 19.10.2020 11:41, Linus Walleij пишет:
>>> This is the 16th and final (knock on wood) version of
>>> KASan for ARM32.
>>
>> Hi,
>>
>> I tried KASAN on NVIDIA Tegra using next-20201029 and getting a (seems)
>> bogus bug report saying that the bug is in the KASAN code (note
>> udc_irq() belongs to the ChipIdea USB driver), this problem doesn't
>> happen using one of older versions of the KASAN patches.
>>
> 
> That is probably a coincidence. I ran into the same thing:
> 
> https://lore.kernel.org/linux-arm-kernel/20201029001753.717-1-ardb@kernel.org/
> 
> I am not sure this is the right fix, but it does silence the warning for me.

Spotted another similar problem, seems also bogus.

This is what happens on any driver module reload:

==================================================================
BUG: KASAN: global-out-of-bounds in load_module+0xc93/0x2c0c
Write of size 20480 at addr bf819000 by task modprobe/229

CPU: 2 PID: 229 Comm: modprobe Tainted: G        WC
5.10.0-rc1-next-20201102-00072-g37765d4f3395 #4497
Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
[<c01115e5>] (unwind_backtrace) from [<c010c181>] (show_stack+0x11/0x14)
[<c010c181>] (show_stack) from [<c0f38b6b>] (dump_stack+0x8b/0xa0)
[<c0f38b6b>] (dump_stack) from [<c031da9f>]
(print_address_description.constprop.0+0x15f/0x360)
[<c031da9f>] (print_address_description.constprop.0) from [<c031de1f>]
(kasan_report+0x103/0x11c)
[<c031de1f>] (kasan_report) from [<c031e3bb>]
(check_memory_region+0xc3/0x11c)
[<c031e3bb>] (check_memory_region) from [<c031d107>] (memset+0x13/0x24)
[<c031d107>] (memset) from [<c01e001f>] (load_module+0xc93/0x2c0c)
[<c01e001f>] (load_module) from [<c01e220b>] (sys_finit_module+0xd7/0x104)
[<c01e220b>] (sys_finit_module) from [<c01000a1>]
(ret_fast_syscall+0x1/0x24)
Exception stack(0xc377bfa8 to 0xc377bff0)
bfa0:                   0003f3e8 00000001 00000003 0002b744 00000000
b6db4e34
bfc0: 0003f3e8 00000001 6106d000 0000017b 0003f490 00000000 0003f3e8
000401c8
bfe0: b6db4db8 b6db4da8 00022534 aec9f250


Memory state around the buggy address:
 bf81b180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 bf81b200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>bf81b280: 00 00 00 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9
                                            ^
 bf81b300: 00 00 04 f9 f9 f9 f9 f9 00 00 00 00 00 00 05 f9
 bf81b380: f9 f9 f9 f9 07 f9 f9 f9 f9 f9 f9 f9 00 00 05 f9
==================================================================
Disabling lock debugging due to kernel taint

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

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

[Nathan Chancellor]

On Mon, Oct 19, 2020 at 10:41:35AM +0200, Linus Walleij wrote:
> This is the 16th and final (knock on wood) version of
> KASan for ARM32.
> 
> Changes since v15:
> 
> - Things now work on all boards we have tested on including
>   Broadcom and i.MX6Q.
> 
> - Folded in a fix from Ard to PAGE_ALIGN() the end of
>   mappings making everything work on all Broadcom board.
> 
> - Folded in a fix from Ahmad Fatoum making things work
>   with fortify on i.MX6Q.
> 
> - Testing and testing and testing on build servers.
> 
> - We are good to go.
> 
> I will now put this in Russell's patch tracker for v5.11.
> 
> There is a git branch you can pull in:
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kasan
> 
> This branch includes Ard's two patches already in Russell's
> patch tracker.
> 
> 
> 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                  |  33 ++
>  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                 |  26 ++
>  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                      | 292 ++++++++++++++++++
>  arch/arm/mm/mmu.c                             |  18 ++
>  arch/arm/mm/pgd.c                             |  16 +-
>  arch/arm/vdso/Makefile                        |   2 +
>  26 files changed, 561 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.26.2
> 

After this series was applied and available in -next, ARCH=arm LLVM=1
allyesconfig builds started failing:

$ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- KCONFIG_ALLCONFIG=<(echo CONFIG_CPU_BIG_ENDIAN=n) LLVM=1 distclean allyesconfig vmlinux
...
ld.lld: error: section: .exit.data is not contiguous with other relro sections
...

$ git bisect ld: [3f267ec60b922eff2a5c90d532357a39f155b730] Add linux-next specific files for 20201029
# good: [23859ae44402f4d935b9ee548135dd1e65e2cbf4] Merge tag 'trace-v5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
git bisect start '3f267ec60b922eff2a5c90d532357a39f155b730' '23859ae44402f4d935b9ee548135dd1e65e2cbf4'
# bad: [bfa70a4ea4bfa6f87b58cf8b90b88297389c92b7] Merge remote-tracking branch 'mtd/mtd/next' into master
git bisect bad bfa70a4ea4bfa6f87b58cf8b90b88297389c92b7
# bad: [37a292dcf77532547f335ed5063d9169031c9b08] Merge remote-tracking branch 'sunxi/sunxi/for-next' into master
git bisect bad 37a292dcf77532547f335ed5063d9169031c9b08
# good: [e6d922c77db276a16f0b7933c2a9951dc9c0052c] Merge remote-tracking branch 'drm-misc-fixes/for-linux-next-fixes' into master
git bisect good e6d922c77db276a16f0b7933c2a9951dc9c0052c
# bad: [cbe49fbb8f6c8d29bc1d9a5a9a742ef2c2eb6320] Merge remote-tracking branch 'mvebu/for-next' into master
git bisect bad cbe49fbb8f6c8d29bc1d9a5a9a742ef2c2eb6320
# bad: [d0e12484e7e1ede73c538744cdbe9439f7335d01] Merge remote-tracking branch 'arm-soc/for-next' into master
git bisect bad d0e12484e7e1ede73c538744cdbe9439f7335d01
# good: [24a23387c15f34bad2485a9e1c3b7ac6f0fb35a6] Merge branch 'asm-generic-cleanup' into asm-generic
git bisect good 24a23387c15f34bad2485a9e1c3b7ac6f0fb35a6
# good: [3a8eb4d3421a2ca0f95ac3b1a8f012940d4f0d52] Merge remote-tracking branch 'kbuild/for-next' into master
git bisect good 3a8eb4d3421a2ca0f95ac3b1a8f012940d4f0d52
# bad: [20f96e606509ee5084690179afe1810b95617a92] Merge branches 'fixes' and 'misc' into for-next
git bisect bad 20f96e606509ee5084690179afe1810b95617a92
# good: [d6d51a96c7d63b7450860a3037f2d62388286a52] ARM: 9014/2: Replace string mem* functions for KASan
git bisect good d6d51a96c7d63b7450860a3037f2d62388286a52
# good: [5615f69bc2097452ecc954f5264d784e158d6801] ARM: 9016/2: Initialize the mapping of KASan shadow memory
git bisect good 5615f69bc2097452ecc954f5264d784e158d6801
# bad: [fc2933c133744305236793025b00c2f7d258b687] ARM: 9020/1: mm: use correct section size macro to describe the FDT virtual address
git bisect bad fc2933c133744305236793025b00c2f7d258b687
# bad: [421015713b306e47af95d4d61cdfbd96d462e4cb] ARM: 9017/2: Enable KASan for ARM
git bisect bad 421015713b306e47af95d4d61cdfbd96d462e4cb
# first bad commit: [421015713b306e47af95d4d61cdfbd96d462e4cb] ARM: 9017/2: Enable KASan for ARMog

An allyesconfig kernel compiled with clang does not link properly with
ld.bfd without a workaround [1], which I do not have time to apply and
test now but can later if it is relevant. I have not done any triage on
this yet either but I wanted to get the report out in case there is
anything obvious.

[1]: https://github.com/ClangBuiltLinux/linux/issues/325

Cheers,
Nathan

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

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

[Nick Desaulniers]

On Thu, Oct 29, 2020 at 5:29 PM Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> On Mon, Oct 19, 2020 at 10:41:35AM +0200, Linus Walleij wrote:
> > This is the 16th and final (knock on wood) version of
> > KASan for ARM32.
> >
> > Changes since v15:
> >
> > - Things now work on all boards we have tested on including
> >   Broadcom and i.MX6Q.
> >
> > - Folded in a fix from Ard to PAGE_ALIGN() the end of
> >   mappings making everything work on all Broadcom board.
> >
> > - Folded in a fix from Ahmad Fatoum making things work
> >   with fortify on i.MX6Q.
> >
> > - Testing and testing and testing on build servers.
> >
> > - We are good to go.
> >
> > I will now put this in Russell's patch tracker for v5.11.
> >
> > There is a git branch you can pull in:
> > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kasan
> >
> > This branch includes Ard's two patches already in Russell's
> > patch tracker.
> >
> >
> > 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                  |  33 ++
> >  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                 |  26 ++
> >  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                      | 292 ++++++++++++++++++
> >  arch/arm/mm/mmu.c                             |  18 ++
> >  arch/arm/mm/pgd.c                             |  16 +-
> >  arch/arm/vdso/Makefile                        |   2 +
> >  26 files changed, 561 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.26.2
> >
>
> After this series was applied and available in -next, ARCH=arm LLVM=1
> allyesconfig builds started failing:
>
> $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- KCONFIG_ALLCONFIG=<(echo CONFIG_CPU_BIG_ENDIAN=n) LLVM=1 distclean allyesconfig vmlinux
> ...
> ld.lld: error: section: .exit.data is not contiguous with other relro sections
> ...
>
> $ git bisect ld: [3f267ec60b922eff2a5c90d532357a39f155b730] Add linux-next specific files for 20201029
> # good: [23859ae44402f4d935b9ee548135dd1e65e2cbf4] Merge tag 'trace-v5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
> git bisect start '3f267ec60b922eff2a5c90d532357a39f155b730' '23859ae44402f4d935b9ee548135dd1e65e2cbf4'
> # bad: [bfa70a4ea4bfa6f87b58cf8b90b88297389c92b7] Merge remote-tracking branch 'mtd/mtd/next' into master
> git bisect bad bfa70a4ea4bfa6f87b58cf8b90b88297389c92b7
> # bad: [37a292dcf77532547f335ed5063d9169031c9b08] Merge remote-tracking branch 'sunxi/sunxi/for-next' into master
> git bisect bad 37a292dcf77532547f335ed5063d9169031c9b08
> # good: [e6d922c77db276a16f0b7933c2a9951dc9c0052c] Merge remote-tracking branch 'drm-misc-fixes/for-linux-next-fixes' into master
> git bisect good e6d922c77db276a16f0b7933c2a9951dc9c0052c
> # bad: [cbe49fbb8f6c8d29bc1d9a5a9a742ef2c2eb6320] Merge remote-tracking branch 'mvebu/for-next' into master
> git bisect bad cbe49fbb8f6c8d29bc1d9a5a9a742ef2c2eb6320
> # bad: [d0e12484e7e1ede73c538744cdbe9439f7335d01] Merge remote-tracking branch 'arm-soc/for-next' into master
> git bisect bad d0e12484e7e1ede73c538744cdbe9439f7335d01
> # good: [24a23387c15f34bad2485a9e1c3b7ac6f0fb35a6] Merge branch 'asm-generic-cleanup' into asm-generic
> git bisect good 24a23387c15f34bad2485a9e1c3b7ac6f0fb35a6
> # good: [3a8eb4d3421a2ca0f95ac3b1a8f012940d4f0d52] Merge remote-tracking branch 'kbuild/for-next' into master
> git bisect good 3a8eb4d3421a2ca0f95ac3b1a8f012940d4f0d52
> # bad: [20f96e606509ee5084690179afe1810b95617a92] Merge branches 'fixes' and 'misc' into for-next
> git bisect bad 20f96e606509ee5084690179afe1810b95617a92
> # good: [d6d51a96c7d63b7450860a3037f2d62388286a52] ARM: 9014/2: Replace string mem* functions for KASan
> git bisect good d6d51a96c7d63b7450860a3037f2d62388286a52
> # good: [5615f69bc2097452ecc954f5264d784e158d6801] ARM: 9016/2: Initialize the mapping of KASan shadow memory
> git bisect good 5615f69bc2097452ecc954f5264d784e158d6801
> # bad: [fc2933c133744305236793025b00c2f7d258b687] ARM: 9020/1: mm: use correct section size macro to describe the FDT virtual address
> git bisect bad fc2933c133744305236793025b00c2f7d258b687
> # bad: [421015713b306e47af95d4d61cdfbd96d462e4cb] ARM: 9017/2: Enable KASan for ARM
> git bisect bad 421015713b306e47af95d4d61cdfbd96d462e4cb
> # first bad commit: [421015713b306e47af95d4d61cdfbd96d462e4cb] ARM: 9017/2: Enable KASan for ARMog
>
> An allyesconfig kernel compiled with clang does not link properly with
> ld.bfd without a workaround [1], which I do not have time to apply and
> test now but can later if it is relevant. I have not done any triage on
> this yet either but I wanted to get the report out in case there is
> anything obvious.
>
> [1]: https://github.com/ClangBuiltLinux/linux/issues/325

relro? smells like:
https://lore.kernel.org/lkml/20201016175339.2429280-1-ndesaulniers@google.com/T/#u

-- 
Thanks,
~Nick Desaulniers

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

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

[Nathan Chancellor]

On Thu, Oct 29, 2020 at 05:38:22PM -0700, Nick Desaulniers wrote:
> On Thu, Oct 29, 2020 at 5:29 PM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > On Mon, Oct 19, 2020 at 10:41:35AM +0200, Linus Walleij wrote:
> > > This is the 16th and final (knock on wood) version of
> > > KASan for ARM32.
> > >
> > > Changes since v15:
> > >
> > > - Things now work on all boards we have tested on including
> > >   Broadcom and i.MX6Q.
> > >
> > > - Folded in a fix from Ard to PAGE_ALIGN() the end of
> > >   mappings making everything work on all Broadcom board.
> > >
> > > - Folded in a fix from Ahmad Fatoum making things work
> > >   with fortify on i.MX6Q.
> > >
> > > - Testing and testing and testing on build servers.
> > >
> > > - We are good to go.
> > >
> > > I will now put this in Russell's patch tracker for v5.11.
> > >
> > > There is a git branch you can pull in:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kasan
> > >
> > > This branch includes Ard's two patches already in Russell's
> > > patch tracker.
> > >
> > >
> > > 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                  |  33 ++
> > >  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                 |  26 ++
> > >  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                      | 292 ++++++++++++++++++
> > >  arch/arm/mm/mmu.c                             |  18 ++
> > >  arch/arm/mm/pgd.c                             |  16 +-
> > >  arch/arm/vdso/Makefile                        |   2 +
> > >  26 files changed, 561 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.26.2
> > >
> >
> > After this series was applied and available in -next, ARCH=arm LLVM=1
> > allyesconfig builds started failing:
> >
> > $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- KCONFIG_ALLCONFIG=<(echo CONFIG_CPU_BIG_ENDIAN=n) LLVM=1 distclean allyesconfig vmlinux
> > ...
> > ld.lld: error: section: .exit.data is not contiguous with other relro sections
> > ...
> >
> > $ git bisect ld: [3f267ec60b922eff2a5c90d532357a39f155b730] Add linux-next specific files for 20201029
> > # good: [23859ae44402f4d935b9ee548135dd1e65e2cbf4] Merge tag 'trace-v5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
> > git bisect start '3f267ec60b922eff2a5c90d532357a39f155b730' '23859ae44402f4d935b9ee548135dd1e65e2cbf4'
> > # bad: [bfa70a4ea4bfa6f87b58cf8b90b88297389c92b7] Merge remote-tracking branch 'mtd/mtd/next' into master
> > git bisect bad bfa70a4ea4bfa6f87b58cf8b90b88297389c92b7
> > # bad: [37a292dcf77532547f335ed5063d9169031c9b08] Merge remote-tracking branch 'sunxi/sunxi/for-next' into master
> > git bisect bad 37a292dcf77532547f335ed5063d9169031c9b08
> > # good: [e6d922c77db276a16f0b7933c2a9951dc9c0052c] Merge remote-tracking branch 'drm-misc-fixes/for-linux-next-fixes' into master
> > git bisect good e6d922c77db276a16f0b7933c2a9951dc9c0052c
> > # bad: [cbe49fbb8f6c8d29bc1d9a5a9a742ef2c2eb6320] Merge remote-tracking branch 'mvebu/for-next' into master
> > git bisect bad cbe49fbb8f6c8d29bc1d9a5a9a742ef2c2eb6320
> > # bad: [d0e12484e7e1ede73c538744cdbe9439f7335d01] Merge remote-tracking branch 'arm-soc/for-next' into master
> > git bisect bad d0e12484e7e1ede73c538744cdbe9439f7335d01
> > # good: [24a23387c15f34bad2485a9e1c3b7ac6f0fb35a6] Merge branch 'asm-generic-cleanup' into asm-generic
> > git bisect good 24a23387c15f34bad2485a9e1c3b7ac6f0fb35a6
> > # good: [3a8eb4d3421a2ca0f95ac3b1a8f012940d4f0d52] Merge remote-tracking branch 'kbuild/for-next' into master
> > git bisect good 3a8eb4d3421a2ca0f95ac3b1a8f012940d4f0d52
> > # bad: [20f96e606509ee5084690179afe1810b95617a92] Merge branches 'fixes' and 'misc' into for-next
> > git bisect bad 20f96e606509ee5084690179afe1810b95617a92
> > # good: [d6d51a96c7d63b7450860a3037f2d62388286a52] ARM: 9014/2: Replace string mem* functions for KASan
> > git bisect good d6d51a96c7d63b7450860a3037f2d62388286a52
> > # good: [5615f69bc2097452ecc954f5264d784e158d6801] ARM: 9016/2: Initialize the mapping of KASan shadow memory
> > git bisect good 5615f69bc2097452ecc954f5264d784e158d6801
> > # bad: [fc2933c133744305236793025b00c2f7d258b687] ARM: 9020/1: mm: use correct section size macro to describe the FDT virtual address
> > git bisect bad fc2933c133744305236793025b00c2f7d258b687
> > # bad: [421015713b306e47af95d4d61cdfbd96d462e4cb] ARM: 9017/2: Enable KASan for ARM
> > git bisect bad 421015713b306e47af95d4d61cdfbd96d462e4cb
> > # first bad commit: [421015713b306e47af95d4d61cdfbd96d462e4cb] ARM: 9017/2: Enable KASan for ARMog
> >
> > An allyesconfig kernel compiled with clang does not link properly with
> > ld.bfd without a workaround [1], which I do not have time to apply and
> > test now but can later if it is relevant. I have not done any triage on
> > this yet either but I wanted to get the report out in case there is
> > anything obvious.
> >
> > [1]: https://github.com/ClangBuiltLinux/linux/issues/325
> 
> relro? smells like:
> https://lore.kernel.org/lkml/20201016175339.2429280-1-ndesaulniers@google.com/T/#u
> 

Huh, did not even realize that the error messages were the same, my bad!

This issue is simple enough to produce by just adding CONFIG_KASAN=y to
multi_v7_defconfig. I tried adding '-z norelro' to LDFLAGS_vmlinux in
arch/arm/Makefile and it fixes the build error but the resulting kernel
does not boot in QEMU.

$ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 distclean defconfig

$ scripts/config -e KASAN

$ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 olddefconfig zImage

$ ~/cbl/github/boot-utils/boot-qemu.sh -a arm32_v7 -k .
/home/nathan/cbl/github/boot-utils/images/arm/rootfs.cpio.zst: 3176448 bytes
+ timeout --foreground 3m unbuffer qemu-system-arm -machine virt -no-reboot -append 'console=ttyAMA0 ' -display none -initrd /home/nathan/cbl/github/boot-utils/images/arm/rootfs.cpio -kernel /home/nathan/src/linux-next/arch/arm/boot/zImage -m 512m -nodefaults -serial mon:stdio
+ RET=124
+ set +x

'-z norelro' boots fine without KASAN so I assume there is something up
specifically with KASAN and LLVM for ARM.

Cheers,
Nathan

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

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

[Ard Biesheuvel]

On Fri, 30 Oct 2020 at 02:32, Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> On Thu, Oct 29, 2020 at 05:38:22PM -0700, Nick Desaulniers wrote:
> > On Thu, Oct 29, 2020 at 5:29 PM Nathan Chancellor
> > <natechancellor@gmail.com> wrote:
> > >
> > > On Mon, Oct 19, 2020 at 10:41:35AM +0200, Linus Walleij wrote:
> > > > This is the 16th and final (knock on wood) version of
> > > > KASan for ARM32.
> > > >
> > > > Changes since v15:
> > > >
> > > > - Things now work on all boards we have tested on including
> > > >   Broadcom and i.MX6Q.
> > > >
> > > > - Folded in a fix from Ard to PAGE_ALIGN() the end of
> > > >   mappings making everything work on all Broadcom board.
> > > >
> > > > - Folded in a fix from Ahmad Fatoum making things work
> > > >   with fortify on i.MX6Q.
> > > >
> > > > - Testing and testing and testing on build servers.
> > > >
> > > > - We are good to go.
> > > >
> > > > I will now put this in Russell's patch tracker for v5.11.
> > > >
> > > > There is a git branch you can pull in:
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kasan
> > > >
> > > > This branch includes Ard's two patches already in Russell's
> > > > patch tracker.
> > > >
> > > >
> > > > 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                  |  33 ++
> > > >  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                 |  26 ++
> > > >  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                      | 292 ++++++++++++++++++
> > > >  arch/arm/mm/mmu.c                             |  18 ++
> > > >  arch/arm/mm/pgd.c                             |  16 +-
> > > >  arch/arm/vdso/Makefile                        |   2 +
> > > >  26 files changed, 561 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.26.2
> > > >
> > >
> > > After this series was applied and available in -next, ARCH=arm LLVM=1
> > > allyesconfig builds started failing:
> > >
> > > $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- KCONFIG_ALLCONFIG=<(echo CONFIG_CPU_BIG_ENDIAN=n) LLVM=1 distclean allyesconfig vmlinux
> > > ...
> > > ld.lld: error: section: .exit.data is not contiguous with other relro sections
> > > ...
> > >
> > > $ git bisect ld: [3f267ec60b922eff2a5c90d532357a39f155b730] Add linux-next specific files for 20201029
> > > # good: [23859ae44402f4d935b9ee548135dd1e65e2cbf4] Merge tag 'trace-v5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
> > > git bisect start '3f267ec60b922eff2a5c90d532357a39f155b730' '23859ae44402f4d935b9ee548135dd1e65e2cbf4'
> > > # bad: [bfa70a4ea4bfa6f87b58cf8b90b88297389c92b7] Merge remote-tracking branch 'mtd/mtd/next' into master
> > > git bisect bad bfa70a4ea4bfa6f87b58cf8b90b88297389c92b7
> > > # bad: [37a292dcf77532547f335ed5063d9169031c9b08] Merge remote-tracking branch 'sunxi/sunxi/for-next' into master
> > > git bisect bad 37a292dcf77532547f335ed5063d9169031c9b08
> > > # good: [e6d922c77db276a16f0b7933c2a9951dc9c0052c] Merge remote-tracking branch 'drm-misc-fixes/for-linux-next-fixes' into master
> > > git bisect good e6d922c77db276a16f0b7933c2a9951dc9c0052c
> > > # bad: [cbe49fbb8f6c8d29bc1d9a5a9a742ef2c2eb6320] Merge remote-tracking branch 'mvebu/for-next' into master
> > > git bisect bad cbe49fbb8f6c8d29bc1d9a5a9a742ef2c2eb6320
> > > # bad: [d0e12484e7e1ede73c538744cdbe9439f7335d01] Merge remote-tracking branch 'arm-soc/for-next' into master
> > > git bisect bad d0e12484e7e1ede73c538744cdbe9439f7335d01
> > > # good: [24a23387c15f34bad2485a9e1c3b7ac6f0fb35a6] Merge branch 'asm-generic-cleanup' into asm-generic
> > > git bisect good 24a23387c15f34bad2485a9e1c3b7ac6f0fb35a6
> > > # good: [3a8eb4d3421a2ca0f95ac3b1a8f012940d4f0d52] Merge remote-tracking branch 'kbuild/for-next' into master
> > > git bisect good 3a8eb4d3421a2ca0f95ac3b1a8f012940d4f0d52
> > > # bad: [20f96e606509ee5084690179afe1810b95617a92] Merge branches 'fixes' and 'misc' into for-next
> > > git bisect bad 20f96e606509ee5084690179afe1810b95617a92
> > > # good: [d6d51a96c7d63b7450860a3037f2d62388286a52] ARM: 9014/2: Replace string mem* functions for KASan
> > > git bisect good d6d51a96c7d63b7450860a3037f2d62388286a52
> > > # good: [5615f69bc2097452ecc954f5264d784e158d6801] ARM: 9016/2: Initialize the mapping of KASan shadow memory
> > > git bisect good 5615f69bc2097452ecc954f5264d784e158d6801
> > > # bad: [fc2933c133744305236793025b00c2f7d258b687] ARM: 9020/1: mm: use correct section size macro to describe the FDT virtual address
> > > git bisect bad fc2933c133744305236793025b00c2f7d258b687
> > > # bad: [421015713b306e47af95d4d61cdfbd96d462e4cb] ARM: 9017/2: Enable KASan for ARM
> > > git bisect bad 421015713b306e47af95d4d61cdfbd96d462e4cb
> > > # first bad commit: [421015713b306e47af95d4d61cdfbd96d462e4cb] ARM: 9017/2: Enable KASan for ARMog
> > >
> > > An allyesconfig kernel compiled with clang does not link properly with
> > > ld.bfd without a workaround [1], which I do not have time to apply and
> > > test now but can later if it is relevant. I have not done any triage on
> > > this yet either but I wanted to get the report out in case there is
> > > anything obvious.
> > >
> > > [1]: https://github.com/ClangBuiltLinux/linux/issues/325
> >
> > relro? smells like:
> > https://lore.kernel.org/lkml/20201016175339.2429280-1-ndesaulniers@google.com/T/#u
> >
>
> Huh, did not even realize that the error messages were the same, my bad!
>
> This issue is simple enough to produce by just adding CONFIG_KASAN=y to
> multi_v7_defconfig. I tried adding '-z norelro' to LDFLAGS_vmlinux in
> arch/arm/Makefile and it fixes the build error but the resulting kernel
> does not boot in QEMU.
>
> $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 distclean defconfig
>
> $ scripts/config -e KASAN
>
> $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 olddefconfig zImage
>
> $ ~/cbl/github/boot-utils/boot-qemu.sh -a arm32_v7 -k .
> /home/nathan/cbl/github/boot-utils/images/arm/rootfs.cpio.zst: 3176448 bytes
> + timeout --foreground 3m unbuffer qemu-system-arm -machine virt -no-reboot -append 'console=ttyAMA0 ' -display none -initrd /home/nathan/cbl/github/boot-utils/images/arm/rootfs.cpio -kernel /home/nathan/src/linux-next/arch/arm/boot/zImage -m 512m -nodefaults -serial mon:stdio
> + RET=124
> + set +x
>
> '-z norelro' boots fine without KASAN so I assume there is something up
> specifically with KASAN and LLVM for ARM.
>

How long did you wait for it to boot? Booting a KASAN kernel under
QEMU emulation is going to be *very* slow.

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

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

[Nathan Chancellor]

On Fri, Oct 30, 2020 at 08:52:53AM +0100, Ard Biesheuvel wrote:
> On Fri, 30 Oct 2020 at 02:32, Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > On Thu, Oct 29, 2020 at 05:38:22PM -0700, Nick Desaulniers wrote:
> > > On Thu, Oct 29, 2020 at 5:29 PM Nathan Chancellor
> > > <natechancellor@gmail.com> wrote:
> > > >
> > > > On Mon, Oct 19, 2020 at 10:41:35AM +0200, Linus Walleij wrote:
> > > > > This is the 16th and final (knock on wood) version of
> > > > > KASan for ARM32.
> > > > >
> > > > > Changes since v15:
> > > > >
> > > > > - Things now work on all boards we have tested on including
> > > > >   Broadcom and i.MX6Q.
> > > > >
> > > > > - Folded in a fix from Ard to PAGE_ALIGN() the end of
> > > > >   mappings making everything work on all Broadcom board.
> > > > >
> > > > > - Folded in a fix from Ahmad Fatoum making things work
> > > > >   with fortify on i.MX6Q.
> > > > >
> > > > > - Testing and testing and testing on build servers.
> > > > >
> > > > > - We are good to go.
> > > > >
> > > > > I will now put this in Russell's patch tracker for v5.11.
> > > > >
> > > > > There is a git branch you can pull in:
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kasan
> > > > >
> > > > > This branch includes Ard's two patches already in Russell's
> > > > > patch tracker.
> > > > >
> > > > >
> > > > > 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                  |  33 ++
> > > > >  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                 |  26 ++
> > > > >  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                      | 292 ++++++++++++++++++
> > > > >  arch/arm/mm/mmu.c                             |  18 ++
> > > > >  arch/arm/mm/pgd.c                             |  16 +-
> > > > >  arch/arm/vdso/Makefile                        |   2 +
> > > > >  26 files changed, 561 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.26.2
> > > > >
> > > >
> > > > After this series was applied and available in -next, ARCH=arm LLVM=1
> > > > allyesconfig builds started failing:
> > > >
> > > > $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- KCONFIG_ALLCONFIG=<(echo CONFIG_CPU_BIG_ENDIAN=n) LLVM=1 distclean allyesconfig vmlinux
> > > > ...
> > > > ld.lld: error: section: .exit.data is not contiguous with other relro sections
> > > > ...
> > > >
> > > > $ git bisect ld: [3f267ec60b922eff2a5c90d532357a39f155b730] Add linux-next specific files for 20201029
> > > > # good: [23859ae44402f4d935b9ee548135dd1e65e2cbf4] Merge tag 'trace-v5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
> > > > git bisect start '3f267ec60b922eff2a5c90d532357a39f155b730' '23859ae44402f4d935b9ee548135dd1e65e2cbf4'
> > > > # bad: [bfa70a4ea4bfa6f87b58cf8b90b88297389c92b7] Merge remote-tracking branch 'mtd/mtd/next' into master
> > > > git bisect bad bfa70a4ea4bfa6f87b58cf8b90b88297389c92b7
> > > > # bad: [37a292dcf77532547f335ed5063d9169031c9b08] Merge remote-tracking branch 'sunxi/sunxi/for-next' into master
> > > > git bisect bad 37a292dcf77532547f335ed5063d9169031c9b08
> > > > # good: [e6d922c77db276a16f0b7933c2a9951dc9c0052c] Merge remote-tracking branch 'drm-misc-fixes/for-linux-next-fixes' into master
> > > > git bisect good e6d922c77db276a16f0b7933c2a9951dc9c0052c
> > > > # bad: [cbe49fbb8f6c8d29bc1d9a5a9a742ef2c2eb6320] Merge remote-tracking branch 'mvebu/for-next' into master
> > > > git bisect bad cbe49fbb8f6c8d29bc1d9a5a9a742ef2c2eb6320
> > > > # bad: [d0e12484e7e1ede73c538744cdbe9439f7335d01] Merge remote-tracking branch 'arm-soc/for-next' into master
> > > > git bisect bad d0e12484e7e1ede73c538744cdbe9439f7335d01
> > > > # good: [24a23387c15f34bad2485a9e1c3b7ac6f0fb35a6] Merge branch 'asm-generic-cleanup' into asm-generic
> > > > git bisect good 24a23387c15f34bad2485a9e1c3b7ac6f0fb35a6
> > > > # good: [3a8eb4d3421a2ca0f95ac3b1a8f012940d4f0d52] Merge remote-tracking branch 'kbuild/for-next' into master
> > > > git bisect good 3a8eb4d3421a2ca0f95ac3b1a8f012940d4f0d52
> > > > # bad: [20f96e606509ee5084690179afe1810b95617a92] Merge branches 'fixes' and 'misc' into for-next
> > > > git bisect bad 20f96e606509ee5084690179afe1810b95617a92
> > > > # good: [d6d51a96c7d63b7450860a3037f2d62388286a52] ARM: 9014/2: Replace string mem* functions for KASan
> > > > git bisect good d6d51a96c7d63b7450860a3037f2d62388286a52
> > > > # good: [5615f69bc2097452ecc954f5264d784e158d6801] ARM: 9016/2: Initialize the mapping of KASan shadow memory
> > > > git bisect good 5615f69bc2097452ecc954f5264d784e158d6801
> > > > # bad: [fc2933c133744305236793025b00c2f7d258b687] ARM: 9020/1: mm: use correct section size macro to describe the FDT virtual address
> > > > git bisect bad fc2933c133744305236793025b00c2f7d258b687
> > > > # bad: [421015713b306e47af95d4d61cdfbd96d462e4cb] ARM: 9017/2: Enable KASan for ARM
> > > > git bisect bad 421015713b306e47af95d4d61cdfbd96d462e4cb
> > > > # first bad commit: [421015713b306e47af95d4d61cdfbd96d462e4cb] ARM: 9017/2: Enable KASan for ARMog
> > > >
> > > > An allyesconfig kernel compiled with clang does not link properly with
> > > > ld.bfd without a workaround [1], which I do not have time to apply and
> > > > test now but can later if it is relevant. I have not done any triage on
> > > > this yet either but I wanted to get the report out in case there is
> > > > anything obvious.
> > > >
> > > > [1]: https://github.com/ClangBuiltLinux/linux/issues/325
> > >
> > > relro? smells like:
> > > https://lore.kernel.org/lkml/20201016175339.2429280-1-ndesaulniers@google.com/T/#u
> > >
> >
> > Huh, did not even realize that the error messages were the same, my bad!
> >
> > This issue is simple enough to produce by just adding CONFIG_KASAN=y to
> > multi_v7_defconfig. I tried adding '-z norelro' to LDFLAGS_vmlinux in
> > arch/arm/Makefile and it fixes the build error but the resulting kernel
> > does not boot in QEMU.
> >
> > $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 distclean defconfig
> >
> > $ scripts/config -e KASAN
> >
> > $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 olddefconfig zImage
> >
> > $ ~/cbl/github/boot-utils/boot-qemu.sh -a arm32_v7 -k .
> > /home/nathan/cbl/github/boot-utils/images/arm/rootfs.cpio.zst: 3176448 bytes
> > + timeout --foreground 3m unbuffer qemu-system-arm -machine virt -no-reboot -append 'console=ttyAMA0 ' -display none -initrd /home/nathan/cbl/github/boot-utils/images/arm/rootfs.cpio -kernel /home/nathan/src/linux-next/arch/arm/boot/zImage -m 512m -nodefaults -serial mon:stdio
> > + RET=124
> > + set +x
> >
> > '-z norelro' boots fine without KASAN so I assume there is something up
> > specifically with KASAN and LLVM for ARM.
> >
> 
> How long did you wait for it to boot? Booting a KASAN kernel under
> QEMU emulation is going to be *very* slow.

The timeout command above is 3m and there was no output from the kernel
in that amount of time. What kind of time should I be reasonably
expecting?

Cheers,
Nathan

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

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

[Ard Biesheuvel]

On Fri, 30 Oct 2020 at 08:57, Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> On Fri, Oct 30, 2020 at 08:52:53AM +0100, Ard Biesheuvel wrote:
> > On Fri, 30 Oct 2020 at 02:32, Nathan Chancellor
> > <natechancellor@gmail.com> wrote:
> > >
> > > On Thu, Oct 29, 2020 at 05:38:22PM -0700, Nick Desaulniers wrote:
> > > > On Thu, Oct 29, 2020 at 5:29 PM Nathan Chancellor
> > > > <natechancellor@gmail.com> wrote:
> > > > >
> > > > > On Mon, Oct 19, 2020 at 10:41:35AM +0200, Linus Walleij wrote:
> > > > > > This is the 16th and final (knock on wood) version of
> > > > > > KASan for ARM32.
> > > > > >
> > > > > > Changes since v15:
> > > > > >
> > > > > > - Things now work on all boards we have tested on including
> > > > > >   Broadcom and i.MX6Q.
> > > > > >
> > > > > > - Folded in a fix from Ard to PAGE_ALIGN() the end of
> > > > > >   mappings making everything work on all Broadcom board.
> > > > > >
> > > > > > - Folded in a fix from Ahmad Fatoum making things work
> > > > > >   with fortify on i.MX6Q.
> > > > > >
> > > > > > - Testing and testing and testing on build servers.
> > > > > >
> > > > > > - We are good to go.
> > > > > >
> > > > > > I will now put this in Russell's patch tracker for v5.11.
> > > > > >
> > > > > > There is a git branch you can pull in:
> > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kasan
> > > > > >
> > > > > > This branch includes Ard's two patches already in Russell's
> > > > > > patch tracker.
> > > > > >
> > > > > >
> > > > > > 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                  |  33 ++
> > > > > >  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                 |  26 ++
> > > > > >  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                      | 292 ++++++++++++++++++
> > > > > >  arch/arm/mm/mmu.c                             |  18 ++
> > > > > >  arch/arm/mm/pgd.c                             |  16 +-
> > > > > >  arch/arm/vdso/Makefile                        |   2 +
> > > > > >  26 files changed, 561 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.26.2
> > > > > >
> > > > >
> > > > > After this series was applied and available in -next, ARCH=arm LLVM=1
> > > > > allyesconfig builds started failing:
> > > > >
> > > > > $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- KCONFIG_ALLCONFIG=<(echo CONFIG_CPU_BIG_ENDIAN=n) LLVM=1 distclean allyesconfig vmlinux
> > > > > ...
> > > > > ld.lld: error: section: .exit.data is not contiguous with other relro sections
> > > > > ...
> > > > >
> > > > > $ git bisect ld: [3f267ec60b922eff2a5c90d532357a39f155b730] Add linux-next specific files for 20201029
> > > > > # good: [23859ae44402f4d935b9ee548135dd1e65e2cbf4] Merge tag 'trace-v5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
> > > > > git bisect start '3f267ec60b922eff2a5c90d532357a39f155b730' '23859ae44402f4d935b9ee548135dd1e65e2cbf4'
> > > > > # bad: [bfa70a4ea4bfa6f87b58cf8b90b88297389c92b7] Merge remote-tracking branch 'mtd/mtd/next' into master
> > > > > git bisect bad bfa70a4ea4bfa6f87b58cf8b90b88297389c92b7
> > > > > # bad: [37a292dcf77532547f335ed5063d9169031c9b08] Merge remote-tracking branch 'sunxi/sunxi/for-next' into master
> > > > > git bisect bad 37a292dcf77532547f335ed5063d9169031c9b08
> > > > > # good: [e6d922c77db276a16f0b7933c2a9951dc9c0052c] Merge remote-tracking branch 'drm-misc-fixes/for-linux-next-fixes' into master
> > > > > git bisect good e6d922c77db276a16f0b7933c2a9951dc9c0052c
> > > > > # bad: [cbe49fbb8f6c8d29bc1d9a5a9a742ef2c2eb6320] Merge remote-tracking branch 'mvebu/for-next' into master
> > > > > git bisect bad cbe49fbb8f6c8d29bc1d9a5a9a742ef2c2eb6320
> > > > > # bad: [d0e12484e7e1ede73c538744cdbe9439f7335d01] Merge remote-tracking branch 'arm-soc/for-next' into master
> > > > > git bisect bad d0e12484e7e1ede73c538744cdbe9439f7335d01
> > > > > # good: [24a23387c15f34bad2485a9e1c3b7ac6f0fb35a6] Merge branch 'asm-generic-cleanup' into asm-generic
> > > > > git bisect good 24a23387c15f34bad2485a9e1c3b7ac6f0fb35a6
> > > > > # good: [3a8eb4d3421a2ca0f95ac3b1a8f012940d4f0d52] Merge remote-tracking branch 'kbuild/for-next' into master
> > > > > git bisect good 3a8eb4d3421a2ca0f95ac3b1a8f012940d4f0d52
> > > > > # bad: [20f96e606509ee5084690179afe1810b95617a92] Merge branches 'fixes' and 'misc' into for-next
> > > > > git bisect bad 20f96e606509ee5084690179afe1810b95617a92
> > > > > # good: [d6d51a96c7d63b7450860a3037f2d62388286a52] ARM: 9014/2: Replace string mem* functions for KASan
> > > > > git bisect good d6d51a96c7d63b7450860a3037f2d62388286a52
> > > > > # good: [5615f69bc2097452ecc954f5264d784e158d6801] ARM: 9016/2: Initialize the mapping of KASan shadow memory
> > > > > git bisect good 5615f69bc2097452ecc954f5264d784e158d6801
> > > > > # bad: [fc2933c133744305236793025b00c2f7d258b687] ARM: 9020/1: mm: use correct section size macro to describe the FDT virtual address
> > > > > git bisect bad fc2933c133744305236793025b00c2f7d258b687
> > > > > # bad: [421015713b306e47af95d4d61cdfbd96d462e4cb] ARM: 9017/2: Enable KASan for ARM
> > > > > git bisect bad 421015713b306e47af95d4d61cdfbd96d462e4cb
> > > > > # first bad commit: [421015713b306e47af95d4d61cdfbd96d462e4cb] ARM: 9017/2: Enable KASan for ARMog
> > > > >
> > > > > An allyesconfig kernel compiled with clang does not link properly with
> > > > > ld.bfd without a workaround [1], which I do not have time to apply and
> > > > > test now but can later if it is relevant. I have not done any triage on
> > > > > this yet either but I wanted to get the report out in case there is
> > > > > anything obvious.
> > > > >
> > > > > [1]: https://github.com/ClangBuiltLinux/linux/issues/325
> > > >
> > > > relro? smells like:
> > > > https://lore.kernel.org/lkml/20201016175339.2429280-1-ndesaulniers@google.com/T/#u
> > > >
> > >
> > > Huh, did not even realize that the error messages were the same, my bad!
> > >
> > > This issue is simple enough to produce by just adding CONFIG_KASAN=y to
> > > multi_v7_defconfig. I tried adding '-z norelro' to LDFLAGS_vmlinux in
> > > arch/arm/Makefile and it fixes the build error but the resulting kernel
> > > does not boot in QEMU.
> > >
> > > $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 distclean defconfig
> > >
> > > $ scripts/config -e KASAN
> > >
> > > $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 olddefconfig zImage
> > >
> > > $ ~/cbl/github/boot-utils/boot-qemu.sh -a arm32_v7 -k .
> > > /home/nathan/cbl/github/boot-utils/images/arm/rootfs.cpio.zst: 3176448 bytes
> > > + timeout --foreground 3m unbuffer qemu-system-arm -machine virt -no-reboot -append 'console=ttyAMA0 ' -display none -initrd /home/nathan/cbl/github/boot-utils/images/arm/rootfs.cpio -kernel /home/nathan/src/linux-next/arch/arm/boot/zImage -m 512m -nodefaults -serial mon:stdio
> > > + RET=124
> > > + set +x
> > >
> > > '-z norelro' boots fine without KASAN so I assume there is something up
> > > specifically with KASAN and LLVM for ARM.
> > >
> >
> > How long did you wait for it to boot? Booting a KASAN kernel under
> > QEMU emulation is going to be *very* slow.
>
> The timeout command above is 3m and there was no output from the kernel
> in that amount of time. What kind of time should I be reasonably
> expecting?
>

3 minutes is probably long enough.

Do you see any output with 'earlycon=pl011,0x9000000' added to the
kernel command line?

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

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

[Nathan Chancellor]

On Fri, Oct 30, 2020 at 08:58:20AM +0100, Ard Biesheuvel wrote:
> On Fri, 30 Oct 2020 at 08:57, Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > On Fri, Oct 30, 2020 at 08:52:53AM +0100, Ard Biesheuvel wrote:
> > > On Fri, 30 Oct 2020 at 02:32, Nathan Chancellor
> > > <natechancellor@gmail.com> wrote:
> > > >
> > > > On Thu, Oct 29, 2020 at 05:38:22PM -0700, Nick Desaulniers wrote:
> > > > > On Thu, Oct 29, 2020 at 5:29 PM Nathan Chancellor
> > > > > <natechancellor@gmail.com> wrote:
> > > > > >
> > > > > > On Mon, Oct 19, 2020 at 10:41:35AM +0200, Linus Walleij wrote:
> > > > > > > This is the 16th and final (knock on wood) version of
> > > > > > > KASan for ARM32.
> > > > > > >
> > > > > > > Changes since v15:
> > > > > > >
> > > > > > > - Things now work on all boards we have tested on including
> > > > > > >   Broadcom and i.MX6Q.
> > > > > > >
> > > > > > > - Folded in a fix from Ard to PAGE_ALIGN() the end of
> > > > > > >   mappings making everything work on all Broadcom board.
> > > > > > >
> > > > > > > - Folded in a fix from Ahmad Fatoum making things work
> > > > > > >   with fortify on i.MX6Q.
> > > > > > >
> > > > > > > - Testing and testing and testing on build servers.
> > > > > > >
> > > > > > > - We are good to go.
> > > > > > >
> > > > > > > I will now put this in Russell's patch tracker for v5.11.
> > > > > > >
> > > > > > > There is a git branch you can pull in:
> > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kasan
> > > > > > >
> > > > > > > This branch includes Ard's two patches already in Russell's
> > > > > > > patch tracker.
> > > > > > >
> > > > > > >
> > > > > > > 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                  |  33 ++
> > > > > > >  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                 |  26 ++
> > > > > > >  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                      | 292 ++++++++++++++++++
> > > > > > >  arch/arm/mm/mmu.c                             |  18 ++
> > > > > > >  arch/arm/mm/pgd.c                             |  16 +-
> > > > > > >  arch/arm/vdso/Makefile                        |   2 +
> > > > > > >  26 files changed, 561 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.26.2
> > > > > > >
> > > > > >
> > > > > > After this series was applied and available in -next, ARCH=arm LLVM=1
> > > > > > allyesconfig builds started failing:
> > > > > >
> > > > > > $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- KCONFIG_ALLCONFIG=<(echo CONFIG_CPU_BIG_ENDIAN=n) LLVM=1 distclean allyesconfig vmlinux
> > > > > > ...
> > > > > > ld.lld: error: section: .exit.data is not contiguous with other relro sections
> > > > > > ...
> > > > > >
> > > > > > $ git bisect ld: [3f267ec60b922eff2a5c90d532357a39f155b730] Add linux-next specific files for 20201029
> > > > > > # good: [23859ae44402f4d935b9ee548135dd1e65e2cbf4] Merge tag 'trace-v5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
> > > > > > git bisect start '3f267ec60b922eff2a5c90d532357a39f155b730' '23859ae44402f4d935b9ee548135dd1e65e2cbf4'
> > > > > > # bad: [bfa70a4ea4bfa6f87b58cf8b90b88297389c92b7] Merge remote-tracking branch 'mtd/mtd/next' into master
> > > > > > git bisect bad bfa70a4ea4bfa6f87b58cf8b90b88297389c92b7
> > > > > > # bad: [37a292dcf77532547f335ed5063d9169031c9b08] Merge remote-tracking branch 'sunxi/sunxi/for-next' into master
> > > > > > git bisect bad 37a292dcf77532547f335ed5063d9169031c9b08
> > > > > > # good: [e6d922c77db276a16f0b7933c2a9951dc9c0052c] Merge remote-tracking branch 'drm-misc-fixes/for-linux-next-fixes' into master
> > > > > > git bisect good e6d922c77db276a16f0b7933c2a9951dc9c0052c
> > > > > > # bad: [cbe49fbb8f6c8d29bc1d9a5a9a742ef2c2eb6320] Merge remote-tracking branch 'mvebu/for-next' into master
> > > > > > git bisect bad cbe49fbb8f6c8d29bc1d9a5a9a742ef2c2eb6320
> > > > > > # bad: [d0e12484e7e1ede73c538744cdbe9439f7335d01] Merge remote-tracking branch 'arm-soc/for-next' into master
> > > > > > git bisect bad d0e12484e7e1ede73c538744cdbe9439f7335d01
> > > > > > # good: [24a23387c15f34bad2485a9e1c3b7ac6f0fb35a6] Merge branch 'asm-generic-cleanup' into asm-generic
> > > > > > git bisect good 24a23387c15f34bad2485a9e1c3b7ac6f0fb35a6
> > > > > > # good: [3a8eb4d3421a2ca0f95ac3b1a8f012940d4f0d52] Merge remote-tracking branch 'kbuild/for-next' into master
> > > > > > git bisect good 3a8eb4d3421a2ca0f95ac3b1a8f012940d4f0d52
> > > > > > # bad: [20f96e606509ee5084690179afe1810b95617a92] Merge branches 'fixes' and 'misc' into for-next
> > > > > > git bisect bad 20f96e606509ee5084690179afe1810b95617a92
> > > > > > # good: [d6d51a96c7d63b7450860a3037f2d62388286a52] ARM: 9014/2: Replace string mem* functions for KASan
> > > > > > git bisect good d6d51a96c7d63b7450860a3037f2d62388286a52
> > > > > > # good: [5615f69bc2097452ecc954f5264d784e158d6801] ARM: 9016/2: Initialize the mapping of KASan shadow memory
> > > > > > git bisect good 5615f69bc2097452ecc954f5264d784e158d6801
> > > > > > # bad: [fc2933c133744305236793025b00c2f7d258b687] ARM: 9020/1: mm: use correct section size macro to describe the FDT virtual address
> > > > > > git bisect bad fc2933c133744305236793025b00c2f7d258b687
> > > > > > # bad: [421015713b306e47af95d4d61cdfbd96d462e4cb] ARM: 9017/2: Enable KASan for ARM
> > > > > > git bisect bad 421015713b306e47af95d4d61cdfbd96d462e4cb
> > > > > > # first bad commit: [421015713b306e47af95d4d61cdfbd96d462e4cb] ARM: 9017/2: Enable KASan for ARMog
> > > > > >
> > > > > > An allyesconfig kernel compiled with clang does not link properly with
> > > > > > ld.bfd without a workaround [1], which I do not have time to apply and
> > > > > > test now but can later if it is relevant. I have not done any triage on
> > > > > > this yet either but I wanted to get the report out in case there is
> > > > > > anything obvious.
> > > > > >
> > > > > > [1]: https://github.com/ClangBuiltLinux/linux/issues/325
> > > > >
> > > > > relro? smells like:
> > > > > https://lore.kernel.org/lkml/20201016175339.2429280-1-ndesaulniers@google.com/T/#u
> > > > >
> > > >
> > > > Huh, did not even realize that the error messages were the same, my bad!
> > > >
> > > > This issue is simple enough to produce by just adding CONFIG_KASAN=y to
> > > > multi_v7_defconfig. I tried adding '-z norelro' to LDFLAGS_vmlinux in
> > > > arch/arm/Makefile and it fixes the build error but the resulting kernel
> > > > does not boot in QEMU.
> > > >
> > > > $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 distclean defconfig
> > > >
> > > > $ scripts/config -e KASAN
> > > >
> > > > $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 olddefconfig zImage
> > > >
> > > > $ ~/cbl/github/boot-utils/boot-qemu.sh -a arm32_v7 -k .
> > > > /home/nathan/cbl/github/boot-utils/images/arm/rootfs.cpio.zst: 3176448 bytes
> > > > + timeout --foreground 3m unbuffer qemu-system-arm -machine virt -no-reboot -append 'console=ttyAMA0 ' -display none -initrd /home/nathan/cbl/github/boot-utils/images/arm/rootfs.cpio -kernel /home/nathan/src/linux-next/arch/arm/boot/zImage -m 512m -nodefaults -serial mon:stdio
> > > > + RET=124
> > > > + set +x
> > > >
> > > > '-z norelro' boots fine without KASAN so I assume there is something up
> > > > specifically with KASAN and LLVM for ARM.
> > > >
> > >
> > > How long did you wait for it to boot? Booting a KASAN kernel under
> > > QEMU emulation is going to be *very* slow.
> >
> > The timeout command above is 3m and there was no output from the kernel
> > in that amount of time. What kind of time should I be reasonably
> > expecting?
> >
> 
> 3 minutes is probably long enough.
> 
> Do you see any output with 'earlycon=pl011,0x9000000' added to the
> kernel command line?

Yes.

$ ~/cbl/github/boot-utils/boot-qemu.sh -a arm32_v7 -k .
/home/nathan/cbl/github/boot-utils/images/arm/rootfs.cpio.zst: 3176448 bytes 
+ timeout --foreground 3m unbuffer qemu-system-arm -machine virt -no-reboot -append 'console=ttyAMA0 earlycon=pl011,0x9000000 ' -display none -initrd /home/nathan/cbl/github/boot-utils/images/arm/rootfs.cpio -kernel /home/nathan/src/linux-next/arch/arm/boot/zImage -m 512m -nodefaults -serial mon:stdio
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.10.0-rc1-next-20201029-dirty (nathan@ubuntu-m3-large-x86) (ClangBuiltLinux clang version 12.0.0 (https://github.com/llvm/llvm-project 1df8d7b4f23da304061bf30b617132f8ba9ab80a), LLD 12.0.0 (https://github.com/llvm/llvm-project 1df8d7b4f23da304061bf30b617132f8ba9ab80a)) #1 SMP Thu Oct 29 18:26:00 MST 2020
[    0.000000] CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c5387d
[    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: linux,dummy-virt
[    0.000000] earlycon: pl11 at MMIO 0x09000000 (options '')
[    0.000000] printk: bootconsole [pl11] enabled
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] efi: UEFI not found.
[    0.000000] cma: Reserved 64 MiB at 0x5c000000
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000040000000-0x000000005fffffff]
[    0.000000]   Normal   empty
[    0.000000]   HighMem  empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000040000000-0x000000005fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x000000005fffffff]
[    0.000000] kasan: Mapping kernel virtual memory block: c0000000-e0000000 at shadow: b7000000-bb000000
[    0.000000] kasan: Mapping kernel virtual memory block: bf000000-c0000000 at shadow: b6e00000-b7000000
[    0.000000] kasan: Kernel address sanitizer initialized
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv0.2 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: Trusted OS migration not required
[    0.000000] percpu: Embedded 20 pages/cpu s49676 r8192 d24052 u81920
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 130048
[    0.000000] Kernel command line: console=ttyAMA0 earlycon=pl011,0x9000000 
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 329852K/524288K available (21504K kernel code, 8544K rwdata, 14676K rodata, 2048K init, 4843K bss, 128900K reserved, 65536K cma-reserved, 0K highmem)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu: 	RCU event tracing is enabled.
[    0.000000] rcu: 	RCU restricting CPUs from NR_CPUS=16 to nr_cpu_ids=1.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
[    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.000000] GICv2m: range[mem 0x08020000-0x08020fff], SPI[80:143]
[    0.000000] random: get_random_bytes called from start_kernel+0x208/0x3d0 with crng_init=0
[    0.000000] arch_timer: cp15 timer(s) running at 62.50MHz (virt).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
[    0.000156] sched_clock: 56 bits at 62MHz, resolution 16ns, wraps every 4398046511096ns
[    0.000565] Switching to timer-based delay loop, resolution 16ns
[    0.006124] Console: colour dummy device 80x30
[    0.007840] Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=625000)
[    0.011577] pid_max: default: 32768 minimum: 301
[    0.014889] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.015189] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.043926] CPU: Testing write buffer coherency: ok
[    0.045820] CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
[    0.057716] /cpus/cpu@0 missing clock-frequency property
[    0.058105] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.070417] Setting up static identity map for 0x40300000 - 0x403000ac
[    0.075105] rcu: Hierarchical SRCU implementation.
[    0.084843] EFI services will not be available.
[    0.087124] smp: Bringing up secondary CPUs ...
[    0.087384] smp: Brought up 1 node, 1 CPU
[    0.087617] SMP: Total of 1 processors activated (125.00 BogoMIPS).
[    0.087878] CPU: All CPU(s) started in SVC mode.
[    0.105778] devtmpfs: initialized
[    0.283349] VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0
[    0.310896] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.311679] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.312469] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.312803] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.313125] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.313445] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.313761] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.314082] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.314400] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.314718] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.315031] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.315338] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.315661] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.315979] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.316296] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.316608] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.316923] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.317234] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.317549] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.317860] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.318177] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.318493] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.318809] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.319133] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.319457] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.319774] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.320091] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.320593] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.320909] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.321220] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.321532] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.321844] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.322157] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.322475] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.322788] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.323098] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.323424] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.323738] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.324050] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.324358] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.324673] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.324988] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.325303] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.325624] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.325941] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.326255] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.326573] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.326883] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.327193] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.327510] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.327826] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.328138] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.328457] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.328767] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.329081] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.329400] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.329711] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.330021] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.330326] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.330780] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.331104] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.331417] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.331733] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.332054] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.332381] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.332696] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.333001] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.333320] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.333648] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.333964] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.334272] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.334580] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.334894] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.335212] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.335528] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.335846] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.336162] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.336482] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.336804] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.337124] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.337443] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.337761] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.338087] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.338414] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.338756] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.339074] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.339396] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.339737] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.340061] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.340379] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.340695] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.341161] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.341504] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.341843] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.342151] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.342492] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.342809] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.343129] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.343445] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.343761] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.344079] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.344410] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.344755] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.345066] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.345383] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.345719] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.346031] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.346350] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.346664] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.346976] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.347289] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.347642] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.347952] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.348275] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.348618] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.348930] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.349245] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.349563] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.349872] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.350191] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.350508] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.350832] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.351280] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.351632] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.351940] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.352257] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.352604] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.352918] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.353228] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.353543] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.353855] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.354170] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.354503] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.354833] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.355144] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.355477] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.355811] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.356133] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.356439] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.356757] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.357075] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.357381] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.357726] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.358037] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.358345] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.358663] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.358979] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.359287] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.359599] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.359911] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.360230] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.360549] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.360860] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.361313] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.361642] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.361953] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.362262] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.362578] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.362888] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.363205] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.363520] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.363821] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.364139] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.364445] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.364759] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.365070] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.365384] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.365695] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.366003] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.366306] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.366611] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.366924] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.367248] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.367569] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.367876] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.368197] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.368515] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.368829] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.369137] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.369454] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.369772] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.370079] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.370393] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.370709] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.371023] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.371490] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.371808] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.372122] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.372435] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.372767] futex hash table entries: 256 (order: 2, 16384 bytes, linear)

Then there is no output after that.

Cheers,
Nathan

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

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

[Ard Biesheuvel]

On Fri, 30 Oct 2020 at 09:04, Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> On Fri, Oct 30, 2020 at 08:58:20AM +0100, Ard Biesheuvel wrote:
> > On Fri, 30 Oct 2020 at 08:57, Nathan Chancellor
> > <natechancellor@gmail.com> wrote:
> > >
> > > On Fri, Oct 30, 2020 at 08:52:53AM +0100, Ard Biesheuvel wrote:
> > > > On Fri, 30 Oct 2020 at 02:32, Nathan Chancellor
> > > > <natechancellor@gmail.com> wrote:
> > > > >
> > > > > On Thu, Oct 29, 2020 at 05:38:22PM -0700, Nick Desaulniers wrote:
> > > > > > On Thu, Oct 29, 2020 at 5:29 PM Nathan Chancellor
> > > > > > <natechancellor@gmail.com> wrote:
> > > > > > >
> > > > > > > On Mon, Oct 19, 2020 at 10:41:35AM +0200, Linus Walleij wrote:
> > > > > > > > This is the 16th and final (knock on wood) version of
> > > > > > > > KASan for ARM32.
> > > > > > > >
> > > > > > > > Changes since v15:
> > > > > > > >
> > > > > > > > - Things now work on all boards we have tested on including
> > > > > > > >   Broadcom and i.MX6Q.
> > > > > > > >
> > > > > > > > - Folded in a fix from Ard to PAGE_ALIGN() the end of
> > > > > > > >   mappings making everything work on all Broadcom board.
> > > > > > > >
> > > > > > > > - Folded in a fix from Ahmad Fatoum making things work
> > > > > > > >   with fortify on i.MX6Q.
> > > > > > > >
> > > > > > > > - Testing and testing and testing on build servers.
> > > > > > > >
> > > > > > > > - We are good to go.
> > > > > > > >
> > > > > > > > I will now put this in Russell's patch tracker for v5.11.
> > > > > > > >
> > > > > > > > There is a git branch you can pull in:
> > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kasan
> > > > > > > >
> > > > > > > > This branch includes Ard's two patches already in Russell's
> > > > > > > > patch tracker.
> > > > > > > >
> > > > > > > >
> > > > > > > > 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                  |  33 ++
> > > > > > > >  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                 |  26 ++
> > > > > > > >  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                      | 292 ++++++++++++++++++
> > > > > > > >  arch/arm/mm/mmu.c                             |  18 ++
> > > > > > > >  arch/arm/mm/pgd.c                             |  16 +-
> > > > > > > >  arch/arm/vdso/Makefile                        |   2 +
> > > > > > > >  26 files changed, 561 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.26.2
> > > > > > > >
> > > > > > >
> > > > > > > After this series was applied and available in -next, ARCH=arm LLVM=1
> > > > > > > allyesconfig builds started failing:
> > > > > > >
> > > > > > > $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- KCONFIG_ALLCONFIG=<(echo CONFIG_CPU_BIG_ENDIAN=n) LLVM=1 distclean allyesconfig vmlinux
> > > > > > > ...
> > > > > > > ld.lld: error: section: .exit.data is not contiguous with other relro sections
> > > > > > > ...
> > > > > > >
> > > > > > > $ git bisect ld: [3f267ec60b922eff2a5c90d532357a39f155b730] Add linux-next specific files for 20201029
> > > > > > > # good: [23859ae44402f4d935b9ee548135dd1e65e2cbf4] Merge tag 'trace-v5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
> > > > > > > git bisect start '3f267ec60b922eff2a5c90d532357a39f155b730' '23859ae44402f4d935b9ee548135dd1e65e2cbf4'
> > > > > > > # bad: [bfa70a4ea4bfa6f87b58cf8b90b88297389c92b7] Merge remote-tracking branch 'mtd/mtd/next' into master
> > > > > > > git bisect bad bfa70a4ea4bfa6f87b58cf8b90b88297389c92b7
> > > > > > > # bad: [37a292dcf77532547f335ed5063d9169031c9b08] Merge remote-tracking branch 'sunxi/sunxi/for-next' into master
> > > > > > > git bisect bad 37a292dcf77532547f335ed5063d9169031c9b08
> > > > > > > # good: [e6d922c77db276a16f0b7933c2a9951dc9c0052c] Merge remote-tracking branch 'drm-misc-fixes/for-linux-next-fixes' into master
> > > > > > > git bisect good e6d922c77db276a16f0b7933c2a9951dc9c0052c
> > > > > > > # bad: [cbe49fbb8f6c8d29bc1d9a5a9a742ef2c2eb6320] Merge remote-tracking branch 'mvebu/for-next' into master
> > > > > > > git bisect bad cbe49fbb8f6c8d29bc1d9a5a9a742ef2c2eb6320
> > > > > > > # bad: [d0e12484e7e1ede73c538744cdbe9439f7335d01] Merge remote-tracking branch 'arm-soc/for-next' into master
> > > > > > > git bisect bad d0e12484e7e1ede73c538744cdbe9439f7335d01
> > > > > > > # good: [24a23387c15f34bad2485a9e1c3b7ac6f0fb35a6] Merge branch 'asm-generic-cleanup' into asm-generic
> > > > > > > git bisect good 24a23387c15f34bad2485a9e1c3b7ac6f0fb35a6
> > > > > > > # good: [3a8eb4d3421a2ca0f95ac3b1a8f012940d4f0d52] Merge remote-tracking branch 'kbuild/for-next' into master
> > > > > > > git bisect good 3a8eb4d3421a2ca0f95ac3b1a8f012940d4f0d52
> > > > > > > # bad: [20f96e606509ee5084690179afe1810b95617a92] Merge branches 'fixes' and 'misc' into for-next
> > > > > > > git bisect bad 20f96e606509ee5084690179afe1810b95617a92
> > > > > > > # good: [d6d51a96c7d63b7450860a3037f2d62388286a52] ARM: 9014/2: Replace string mem* functions for KASan
> > > > > > > git bisect good d6d51a96c7d63b7450860a3037f2d62388286a52
> > > > > > > # good: [5615f69bc2097452ecc954f5264d784e158d6801] ARM: 9016/2: Initialize the mapping of KASan shadow memory
> > > > > > > git bisect good 5615f69bc2097452ecc954f5264d784e158d6801
> > > > > > > # bad: [fc2933c133744305236793025b00c2f7d258b687] ARM: 9020/1: mm: use correct section size macro to describe the FDT virtual address
> > > > > > > git bisect bad fc2933c133744305236793025b00c2f7d258b687
> > > > > > > # bad: [421015713b306e47af95d4d61cdfbd96d462e4cb] ARM: 9017/2: Enable KASan for ARM
> > > > > > > git bisect bad 421015713b306e47af95d4d61cdfbd96d462e4cb
> > > > > > > # first bad commit: [421015713b306e47af95d4d61cdfbd96d462e4cb] ARM: 9017/2: Enable KASan for ARMog
> > > > > > >
> > > > > > > An allyesconfig kernel compiled with clang does not link properly with
> > > > > > > ld.bfd without a workaround [1], which I do not have time to apply and
> > > > > > > test now but can later if it is relevant. I have not done any triage on
> > > > > > > this yet either but I wanted to get the report out in case there is
> > > > > > > anything obvious.
> > > > > > >
> > > > > > > [1]: https://github.com/ClangBuiltLinux/linux/issues/325
> > > > > >
> > > > > > relro? smells like:
> > > > > > https://lore.kernel.org/lkml/20201016175339.2429280-1-ndesaulniers@google.com/T/#u
> > > > > >
> > > > >
> > > > > Huh, did not even realize that the error messages were the same, my bad!
> > > > >
> > > > > This issue is simple enough to produce by just adding CONFIG_KASAN=y to
> > > > > multi_v7_defconfig. I tried adding '-z norelro' to LDFLAGS_vmlinux in
> > > > > arch/arm/Makefile and it fixes the build error but the resulting kernel
> > > > > does not boot in QEMU.
> > > > >
> > > > > $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 distclean defconfig
> > > > >
> > > > > $ scripts/config -e KASAN
> > > > >
> > > > > $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 olddefconfig zImage
> > > > >
> > > > > $ ~/cbl/github/boot-utils/boot-qemu.sh -a arm32_v7 -k .
> > > > > /home/nathan/cbl/github/boot-utils/images/arm/rootfs.cpio.zst: 3176448 bytes
> > > > > + timeout --foreground 3m unbuffer qemu-system-arm -machine virt -no-reboot -append 'console=ttyAMA0 ' -display none -initrd /home/nathan/cbl/github/boot-utils/images/arm/rootfs.cpio -kernel /home/nathan/src/linux-next/arch/arm/boot/zImage -m 512m -nodefaults -serial mon:stdio
> > > > > + RET=124
> > > > > + set +x
> > > > >
> > > > > '-z norelro' boots fine without KASAN so I assume there is something up
> > > > > specifically with KASAN and LLVM for ARM.
> > > > >
> > > >
> > > > How long did you wait for it to boot? Booting a KASAN kernel under
> > > > QEMU emulation is going to be *very* slow.
> > >
> > > The timeout command above is 3m and there was no output from the kernel
> > > in that amount of time. What kind of time should I be reasonably
> > > expecting?
> > >
> >
> > 3 minutes is probably long enough.
> >
> > Do you see any output with 'earlycon=pl011,0x9000000' added to the
> > kernel command line?
>
> Yes.
>
> $ ~/cbl/github/boot-utils/boot-qemu.sh -a arm32_v7 -k .
> /home/nathan/cbl/github/boot-utils/images/arm/rootfs.cpio.zst: 3176448 bytes
> + timeout --foreground 3m unbuffer qemu-system-arm -machine virt -no-reboot -append 'console=ttyAMA0 earlycon=pl011,0x9000000 ' -display none -initrd /home/nathan/cbl/github/boot-utils/images/arm/rootfs.cpio -kernel /home/nathan/src/linux-next/arch/arm/boot/zImage -m 512m -nodefaults -serial mon:stdio
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 5.10.0-rc1-next-20201029-dirty (nathan@ubuntu-m3-large-x86) (ClangBuiltLinux clang version 12.0.0 (https://github.com/llvm/llvm-project 1df8d7b4f23da304061bf30b617132f8ba9ab80a), LLD 12.0.0 (https://github.com/llvm/llvm-project 1df8d7b4f23da304061bf30b617132f8ba9ab80a)) #1 SMP Thu Oct 29 18:26:00 MST 2020
> [    0.000000] CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c5387d
> [    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: linux,dummy-virt
> [    0.000000] earlycon: pl11 at MMIO 0x09000000 (options '')
> [    0.000000] printk: bootconsole [pl11] enabled
> [    0.000000] Memory policy: Data cache writealloc
> [    0.000000] efi: UEFI not found.
> [    0.000000] cma: Reserved 64 MiB at 0x5c000000
> [    0.000000] Zone ranges:
> [    0.000000]   DMA      [mem 0x0000000040000000-0x000000005fffffff]
> [    0.000000]   Normal   empty
> [    0.000000]   HighMem  empty
> [    0.000000] Movable zone start for each node
> [    0.000000] Early memory node ranges
> [    0.000000]   node   0: [mem 0x0000000040000000-0x000000005fffffff]
> [    0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x000000005fffffff]
> [    0.000000] kasan: Mapping kernel virtual memory block: c0000000-e0000000 at shadow: b7000000-bb000000
> [    0.000000] kasan: Mapping kernel virtual memory block: bf000000-c0000000 at shadow: b6e00000-b7000000
> [    0.000000] kasan: Kernel address sanitizer initialized
> [    0.000000] psci: probing for conduit method from DT.
> [    0.000000] psci: PSCIv0.2 detected in firmware.
> [    0.000000] psci: Using standard PSCI v0.2 function IDs
> [    0.000000] psci: Trusted OS migration not required
> [    0.000000] percpu: Embedded 20 pages/cpu s49676 r8192 d24052 u81920
> [    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 130048
> [    0.000000] Kernel command line: console=ttyAMA0 earlycon=pl011,0x9000000
> [    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
> [    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes, linear)
> [    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
> [    0.000000] Memory: 329852K/524288K available (21504K kernel code, 8544K rwdata, 14676K rodata, 2048K init, 4843K bss, 128900K reserved, 65536K cma-reserved, 0K highmem)
> [    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> [    0.000000] rcu: Hierarchical RCU implementation.
> [    0.000000] rcu:     RCU event tracing is enabled.
> [    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=16 to nr_cpu_ids=1.
> [    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
> [    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
> [    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
> [    0.000000] GICv2m: range[mem 0x08020000-0x08020fff], SPI[80:143]
> [    0.000000] random: get_random_bytes called from start_kernel+0x208/0x3d0 with crng_init=0
> [    0.000000] arch_timer: cp15 timer(s) running at 62.50MHz (virt).
> [    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
> [    0.000156] sched_clock: 56 bits at 62MHz, resolution 16ns, wraps every 4398046511096ns
> [    0.000565] Switching to timer-based delay loop, resolution 16ns
> [    0.006124] Console: colour dummy device 80x30
> [    0.007840] Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=625000)
> [    0.011577] pid_max: default: 32768 minimum: 301
> [    0.014889] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
> [    0.015189] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
> [    0.043926] CPU: Testing write buffer coherency: ok
> [    0.045820] CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
> [    0.057716] /cpus/cpu@0 missing clock-frequency property
> [    0.058105] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
> [    0.070417] Setting up static identity map for 0x40300000 - 0x403000ac
> [    0.075105] rcu: Hierarchical SRCU implementation.
> [    0.084843] EFI services will not be available.
> [    0.087124] smp: Bringing up secondary CPUs ...
> [    0.087384] smp: Brought up 1 node, 1 CPU
> [    0.087617] SMP: Total of 1 processors activated (125.00 BogoMIPS).
> [    0.087878] CPU: All CPU(s) started in SVC mode.
> [    0.105778] devtmpfs: initialized
> [    0.283349] VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0
> [    0.310896] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
> [    0.311679] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.312469] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.312803] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.313125] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.313445] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.313761] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.314082] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.314400] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.314718] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.315031] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.315338] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.315661] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.315979] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.316296] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.316608] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.316923] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.317234] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.317549] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.317860] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.318177] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.318493] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.318809] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.319133] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.319457] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.319774] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.320091] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.320593] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.320909] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.321220] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.321532] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.321844] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.322157] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.322475] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.322788] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.323098] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.323424] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.323738] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.324050] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.324358] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.324673] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.324988] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.325303] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.325624] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.325941] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.326255] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.326573] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.326883] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.327193] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.327510] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.327826] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.328138] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.328457] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.328767] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.329081] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.329400] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.329711] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.330021] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.330326] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.330780] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.331104] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.331417] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.331733] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.332054] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.332381] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.332696] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.333001] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.333320] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.333648] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.333964] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.334272] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.334580] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.334894] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.335212] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.335528] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.335846] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.336162] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.336482] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.336804] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.337124] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.337443] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.337761] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.338087] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.338414] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.338756] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.339074] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.339396] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.339737] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.340061] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.340379] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.340695] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.341161] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.341504] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.341843] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.342151] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.342492] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.342809] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.343129] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.343445] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.343761] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.344079] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.344410] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.344755] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.345066] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.345383] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.345719] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.346031] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.346350] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.346664] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.346976] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.347289] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.347642] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.347952] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.348275] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.348618] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.348930] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.349245] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.349563] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.349872] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.350191] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.350508] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.350832] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.351280] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.351632] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.351940] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.352257] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.352604] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.352918] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.353228] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.353543] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.353855] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.354170] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.354503] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.354833] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.355144] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.355477] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.355811] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.356133] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.356439] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.356757] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.357075] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.357381] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.357726] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.358037] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.358345] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.358663] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.358979] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.359287] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.359599] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.359911] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.360230] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.360549] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.360860] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.361313] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.361642] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.361953] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.362262] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.362578] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.362888] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.363205] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.363520] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.363821] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.364139] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.364445] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.364759] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.365070] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.365384] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.365695] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.366003] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.366306] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.366611] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.366924] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.367248] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.367569] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.367876] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.368197] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.368515] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.368829] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.369137] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.369454] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.369772] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.370079] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.370393] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.370709] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.371023] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.371490] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.371808] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.372122] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.372435] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> [    0.372767] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
>
> Then there is no output after that.
>

Ouch. This looks like futex_init() is being called over and over
again, which is a core_initcall.

This will need some dissecting of the binary, but we need to figure
out what is going on in the initcall dispatch code.

If you build with symbols, you should be able to run it in the
debugger. Just set a breakpoint on futex_init() and step through the
code until you can observe how/why it is being called a second time.

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

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

[Nathan Chancellor]

On Fri, Oct 30, 2020 at 09:10:56AM +0100, Ard Biesheuvel wrote:
> On Fri, 30 Oct 2020 at 09:04, Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > On Fri, Oct 30, 2020 at 08:58:20AM +0100, Ard Biesheuvel wrote:
> > > On Fri, 30 Oct 2020 at 08:57, Nathan Chancellor
> > > <natechancellor@gmail.com> wrote:
> > > >
> > > > On Fri, Oct 30, 2020 at 08:52:53AM +0100, Ard Biesheuvel wrote:
> > > > > On Fri, 30 Oct 2020 at 02:32, Nathan Chancellor
> > > > > <natechancellor@gmail.com> wrote:
> > > > > >
> > > > > > On Thu, Oct 29, 2020 at 05:38:22PM -0700, Nick Desaulniers wrote:
> > > > > > > On Thu, Oct 29, 2020 at 5:29 PM Nathan Chancellor
> > > > > > > <natechancellor@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On Mon, Oct 19, 2020 at 10:41:35AM +0200, Linus Walleij wrote:
> > > > > > > > > This is the 16th and final (knock on wood) version of
> > > > > > > > > KASan for ARM32.
> > > > > > > > >
> > > > > > > > > Changes since v15:
> > > > > > > > >
> > > > > > > > > - Things now work on all boards we have tested on including
> > > > > > > > >   Broadcom and i.MX6Q.
> > > > > > > > >
> > > > > > > > > - Folded in a fix from Ard to PAGE_ALIGN() the end of
> > > > > > > > >   mappings making everything work on all Broadcom board.
> > > > > > > > >
> > > > > > > > > - Folded in a fix from Ahmad Fatoum making things work
> > > > > > > > >   with fortify on i.MX6Q.
> > > > > > > > >
> > > > > > > > > - Testing and testing and testing on build servers.
> > > > > > > > >
> > > > > > > > > - We are good to go.
> > > > > > > > >
> > > > > > > > > I will now put this in Russell's patch tracker for v5.11.
> > > > > > > > >
> > > > > > > > > There is a git branch you can pull in:
> > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kasan
> > > > > > > > >
> > > > > > > > > This branch includes Ard's two patches already in Russell's
> > > > > > > > > patch tracker.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 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                  |  33 ++
> > > > > > > > >  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                 |  26 ++
> > > > > > > > >  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                      | 292 ++++++++++++++++++
> > > > > > > > >  arch/arm/mm/mmu.c                             |  18 ++
> > > > > > > > >  arch/arm/mm/pgd.c                             |  16 +-
> > > > > > > > >  arch/arm/vdso/Makefile                        |   2 +
> > > > > > > > >  26 files changed, 561 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.26.2
> > > > > > > > >
> > > > > > > >
> > > > > > > > After this series was applied and available in -next, ARCH=arm LLVM=1
> > > > > > > > allyesconfig builds started failing:
> > > > > > > >
> > > > > > > > $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- KCONFIG_ALLCONFIG=<(echo CONFIG_CPU_BIG_ENDIAN=n) LLVM=1 distclean allyesconfig vmlinux
> > > > > > > > ...
> > > > > > > > ld.lld: error: section: .exit.data is not contiguous with other relro sections
> > > > > > > > ...
> > > > > > > >
> > > > > > > > $ git bisect ld: [3f267ec60b922eff2a5c90d532357a39f155b730] Add linux-next specific files for 20201029
> > > > > > > > # good: [23859ae44402f4d935b9ee548135dd1e65e2cbf4] Merge tag 'trace-v5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
> > > > > > > > git bisect start '3f267ec60b922eff2a5c90d532357a39f155b730' '23859ae44402f4d935b9ee548135dd1e65e2cbf4'
> > > > > > > > # bad: [bfa70a4ea4bfa6f87b58cf8b90b88297389c92b7] Merge remote-tracking branch 'mtd/mtd/next' into master
> > > > > > > > git bisect bad bfa70a4ea4bfa6f87b58cf8b90b88297389c92b7
> > > > > > > > # bad: [37a292dcf77532547f335ed5063d9169031c9b08] Merge remote-tracking branch 'sunxi/sunxi/for-next' into master
> > > > > > > > git bisect bad 37a292dcf77532547f335ed5063d9169031c9b08
> > > > > > > > # good: [e6d922c77db276a16f0b7933c2a9951dc9c0052c] Merge remote-tracking branch 'drm-misc-fixes/for-linux-next-fixes' into master
> > > > > > > > git bisect good e6d922c77db276a16f0b7933c2a9951dc9c0052c
> > > > > > > > # bad: [cbe49fbb8f6c8d29bc1d9a5a9a742ef2c2eb6320] Merge remote-tracking branch 'mvebu/for-next' into master
> > > > > > > > git bisect bad cbe49fbb8f6c8d29bc1d9a5a9a742ef2c2eb6320
> > > > > > > > # bad: [d0e12484e7e1ede73c538744cdbe9439f7335d01] Merge remote-tracking branch 'arm-soc/for-next' into master
> > > > > > > > git bisect bad d0e12484e7e1ede73c538744cdbe9439f7335d01
> > > > > > > > # good: [24a23387c15f34bad2485a9e1c3b7ac6f0fb35a6] Merge branch 'asm-generic-cleanup' into asm-generic
> > > > > > > > git bisect good 24a23387c15f34bad2485a9e1c3b7ac6f0fb35a6
> > > > > > > > # good: [3a8eb4d3421a2ca0f95ac3b1a8f012940d4f0d52] Merge remote-tracking branch 'kbuild/for-next' into master
> > > > > > > > git bisect good 3a8eb4d3421a2ca0f95ac3b1a8f012940d4f0d52
> > > > > > > > # bad: [20f96e606509ee5084690179afe1810b95617a92] Merge branches 'fixes' and 'misc' into for-next
> > > > > > > > git bisect bad 20f96e606509ee5084690179afe1810b95617a92
> > > > > > > > # good: [d6d51a96c7d63b7450860a3037f2d62388286a52] ARM: 9014/2: Replace string mem* functions for KASan
> > > > > > > > git bisect good d6d51a96c7d63b7450860a3037f2d62388286a52
> > > > > > > > # good: [5615f69bc2097452ecc954f5264d784e158d6801] ARM: 9016/2: Initialize the mapping of KASan shadow memory
> > > > > > > > git bisect good 5615f69bc2097452ecc954f5264d784e158d6801
> > > > > > > > # bad: [fc2933c133744305236793025b00c2f7d258b687] ARM: 9020/1: mm: use correct section size macro to describe the FDT virtual address
> > > > > > > > git bisect bad fc2933c133744305236793025b00c2f7d258b687
> > > > > > > > # bad: [421015713b306e47af95d4d61cdfbd96d462e4cb] ARM: 9017/2: Enable KASan for ARM
> > > > > > > > git bisect bad 421015713b306e47af95d4d61cdfbd96d462e4cb
> > > > > > > > # first bad commit: [421015713b306e47af95d4d61cdfbd96d462e4cb] ARM: 9017/2: Enable KASan for ARMog
> > > > > > > >
> > > > > > > > An allyesconfig kernel compiled with clang does not link properly with
> > > > > > > > ld.bfd without a workaround [1], which I do not have time to apply and
> > > > > > > > test now but can later if it is relevant. I have not done any triage on
> > > > > > > > this yet either but I wanted to get the report out in case there is
> > > > > > > > anything obvious.
> > > > > > > >
> > > > > > > > [1]: https://github.com/ClangBuiltLinux/linux/issues/325
> > > > > > >
> > > > > > > relro? smells like:
> > > > > > > https://lore.kernel.org/lkml/20201016175339.2429280-1-ndesaulniers@google.com/T/#u
> > > > > > >
> > > > > >
> > > > > > Huh, did not even realize that the error messages were the same, my bad!
> > > > > >
> > > > > > This issue is simple enough to produce by just adding CONFIG_KASAN=y to
> > > > > > multi_v7_defconfig. I tried adding '-z norelro' to LDFLAGS_vmlinux in
> > > > > > arch/arm/Makefile and it fixes the build error but the resulting kernel
> > > > > > does not boot in QEMU.
> > > > > >
> > > > > > $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 distclean defconfig
> > > > > >
> > > > > > $ scripts/config -e KASAN
> > > > > >
> > > > > > $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 olddefconfig zImage
> > > > > >
> > > > > > $ ~/cbl/github/boot-utils/boot-qemu.sh -a arm32_v7 -k .
> > > > > > /home/nathan/cbl/github/boot-utils/images/arm/rootfs.cpio.zst: 3176448 bytes
> > > > > > + timeout --foreground 3m unbuffer qemu-system-arm -machine virt -no-reboot -append 'console=ttyAMA0 ' -display none -initrd /home/nathan/cbl/github/boot-utils/images/arm/rootfs.cpio -kernel /home/nathan/src/linux-next/arch/arm/boot/zImage -m 512m -nodefaults -serial mon:stdio
> > > > > > + RET=124
> > > > > > + set +x
> > > > > >
> > > > > > '-z norelro' boots fine without KASAN so I assume there is something up
> > > > > > specifically with KASAN and LLVM for ARM.
> > > > > >
> > > > >
> > > > > How long did you wait for it to boot? Booting a KASAN kernel under
> > > > > QEMU emulation is going to be *very* slow.
> > > >
> > > > The timeout command above is 3m and there was no output from the kernel
> > > > in that amount of time. What kind of time should I be reasonably
> > > > expecting?
> > > >
> > >
> > > 3 minutes is probably long enough.
> > >
> > > Do you see any output with 'earlycon=pl011,0x9000000' added to the
> > > kernel command line?
> >
> > Yes.
> >
> > $ ~/cbl/github/boot-utils/boot-qemu.sh -a arm32_v7 -k .
> > /home/nathan/cbl/github/boot-utils/images/arm/rootfs.cpio.zst: 3176448 bytes
> > + timeout --foreground 3m unbuffer qemu-system-arm -machine virt -no-reboot -append 'console=ttyAMA0 earlycon=pl011,0x9000000 ' -display none -initrd /home/nathan/cbl/github/boot-utils/images/arm/rootfs.cpio -kernel /home/nathan/src/linux-next/arch/arm/boot/zImage -m 512m -nodefaults -serial mon:stdio
> > [    0.000000] Booting Linux on physical CPU 0x0
> > [    0.000000] Linux version 5.10.0-rc1-next-20201029-dirty (nathan@ubuntu-m3-large-x86) (ClangBuiltLinux clang version 12.0.0 (https://github.com/llvm/llvm-project 1df8d7b4f23da304061bf30b617132f8ba9ab80a), LLD 12.0.0 (https://github.com/llvm/llvm-project 1df8d7b4f23da304061bf30b617132f8ba9ab80a)) #1 SMP Thu Oct 29 18:26:00 MST 2020
> > [    0.000000] CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c5387d
> > [    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: linux,dummy-virt
> > [    0.000000] earlycon: pl11 at MMIO 0x09000000 (options '')
> > [    0.000000] printk: bootconsole [pl11] enabled
> > [    0.000000] Memory policy: Data cache writealloc
> > [    0.000000] efi: UEFI not found.
> > [    0.000000] cma: Reserved 64 MiB at 0x5c000000
> > [    0.000000] Zone ranges:
> > [    0.000000]   DMA      [mem 0x0000000040000000-0x000000005fffffff]
> > [    0.000000]   Normal   empty
> > [    0.000000]   HighMem  empty
> > [    0.000000] Movable zone start for each node
> > [    0.000000] Early memory node ranges
> > [    0.000000]   node   0: [mem 0x0000000040000000-0x000000005fffffff]
> > [    0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x000000005fffffff]
> > [    0.000000] kasan: Mapping kernel virtual memory block: c0000000-e0000000 at shadow: b7000000-bb000000
> > [    0.000000] kasan: Mapping kernel virtual memory block: bf000000-c0000000 at shadow: b6e00000-b7000000
> > [    0.000000] kasan: Kernel address sanitizer initialized
> > [    0.000000] psci: probing for conduit method from DT.
> > [    0.000000] psci: PSCIv0.2 detected in firmware.
> > [    0.000000] psci: Using standard PSCI v0.2 function IDs
> > [    0.000000] psci: Trusted OS migration not required
> > [    0.000000] percpu: Embedded 20 pages/cpu s49676 r8192 d24052 u81920
> > [    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 130048
> > [    0.000000] Kernel command line: console=ttyAMA0 earlycon=pl011,0x9000000
> > [    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
> > [    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes, linear)
> > [    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
> > [    0.000000] Memory: 329852K/524288K available (21504K kernel code, 8544K rwdata, 14676K rodata, 2048K init, 4843K bss, 128900K reserved, 65536K cma-reserved, 0K highmem)
> > [    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> > [    0.000000] rcu: Hierarchical RCU implementation.
> > [    0.000000] rcu:     RCU event tracing is enabled.
> > [    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=16 to nr_cpu_ids=1.
> > [    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
> > [    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
> > [    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
> > [    0.000000] GICv2m: range[mem 0x08020000-0x08020fff], SPI[80:143]
> > [    0.000000] random: get_random_bytes called from start_kernel+0x208/0x3d0 with crng_init=0
> > [    0.000000] arch_timer: cp15 timer(s) running at 62.50MHz (virt).
> > [    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
> > [    0.000156] sched_clock: 56 bits at 62MHz, resolution 16ns, wraps every 4398046511096ns
> > [    0.000565] Switching to timer-based delay loop, resolution 16ns
> > [    0.006124] Console: colour dummy device 80x30
> > [    0.007840] Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=625000)
> > [    0.011577] pid_max: default: 32768 minimum: 301
> > [    0.014889] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
> > [    0.015189] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
> > [    0.043926] CPU: Testing write buffer coherency: ok
> > [    0.045820] CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable
> > [    0.057716] /cpus/cpu@0 missing clock-frequency property
> > [    0.058105] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
> > [    0.070417] Setting up static identity map for 0x40300000 - 0x403000ac
> > [    0.075105] rcu: Hierarchical SRCU implementation.
> > [    0.084843] EFI services will not be available.
> > [    0.087124] smp: Bringing up secondary CPUs ...
> > [    0.087384] smp: Brought up 1 node, 1 CPU
> > [    0.087617] SMP: Total of 1 processors activated (125.00 BogoMIPS).
> > [    0.087878] CPU: All CPU(s) started in SVC mode.
> > [    0.105778] devtmpfs: initialized
> > [    0.283349] VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0
> > [    0.310896] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
> > [    0.311679] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.312469] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.312803] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.313125] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.313445] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.313761] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.314082] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.314400] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.314718] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.315031] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.315338] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.315661] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.315979] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.316296] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.316608] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.316923] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.317234] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.317549] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.317860] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.318177] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.318493] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.318809] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.319133] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.319457] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.319774] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.320091] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.320593] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.320909] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.321220] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.321532] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.321844] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.322157] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.322475] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.322788] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.323098] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.323424] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.323738] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.324050] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.324358] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.324673] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.324988] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.325303] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.325624] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.325941] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.326255] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.326573] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.326883] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.327193] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.327510] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.327826] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.328138] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.328457] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.328767] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.329081] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.329400] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.329711] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.330021] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.330326] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.330780] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.331104] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.331417] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.331733] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.332054] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.332381] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.332696] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.333001] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.333320] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.333648] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.333964] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.334272] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.334580] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.334894] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.335212] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.335528] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.335846] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.336162] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.336482] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.336804] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.337124] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.337443] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.337761] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.338087] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.338414] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.338756] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.339074] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.339396] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.339737] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.340061] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.340379] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.340695] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.341161] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.341504] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.341843] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.342151] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.342492] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.342809] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.343129] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.343445] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.343761] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.344079] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.344410] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.344755] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.345066] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.345383] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.345719] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.346031] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.346350] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.346664] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.346976] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.347289] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.347642] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.347952] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.348275] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.348618] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.348930] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.349245] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.349563] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.349872] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.350191] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.350508] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.350832] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.351280] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.351632] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.351940] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.352257] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.352604] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.352918] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.353228] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.353543] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.353855] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.354170] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.354503] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.354833] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.355144] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.355477] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.355811] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.356133] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.356439] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.356757] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.357075] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.357381] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.357726] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.358037] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.358345] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.358663] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.358979] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.359287] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.359599] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.359911] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.360230] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.360549] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.360860] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.361313] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.361642] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.361953] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.362262] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.362578] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.362888] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.363205] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.363520] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.363821] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.364139] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.364445] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.364759] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.365070] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.365384] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.365695] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.366003] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.366306] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.366611] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.366924] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.367248] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.367569] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.367876] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.368197] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.368515] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.368829] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.369137] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.369454] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.369772] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.370079] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.370393] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.370709] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.371023] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.371490] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.371808] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.372122] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.372435] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > [    0.372767] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> >
> > Then there is no output after that.
> >
> 
> Ouch. This looks like futex_init() is being called over and over
> again, which is a core_initcall.
> 
> This will need some dissecting of the binary, but we need to figure
> out what is going on in the initcall dispatch code.
> 
> If you build with symbols, you should be able to run it in the
> debugger. Just set a breakpoint on futex_init() and step through the
> code until you can observe how/why it is being called a second time.

I have no idea how it is happening but futex_init keeps getting called
from within itself, if I am reading gdb right?

(gdb) hbreak futex_init
Hardware assisted breakpoint 1 at 0xc2727fac: file kernel/futex.c, line 4028.
(gdb) c
Continuing.

Breakpoint 1, futex_init () at kernel/futex.c:4028
4028    {
(gdb) n
4035            futex_hashsize = roundup_pow_of_two(256 * num_possible_cpus());
(gdb)
4038            futex_queues = alloc_large_system_hash("futex", sizeof(*futex_queues),
(gdb)
4035            futex_hashsize = roundup_pow_of_two(256 * num_possible_cpus());
(gdb)
4038            futex_queues = alloc_large_system_hash("futex", sizeof(*futex_queues),
(gdb)
4043            futex_hashsize = 1UL << futex_shift;
(gdb)
4045            futex_detect_cmpxchg();
(gdb)

Breakpoint 1, futex_init () at kernel/futex.c:4028
4028    {
(gdb)
4035            futex_hashsize = roundup_pow_of_two(256 * num_possible_cpus());
(gdb)
4038            futex_queues = alloc_large_system_hash("futex", sizeof(*futex_queues),
(gdb)
4035            futex_hashsize = roundup_pow_of_two(256 * num_possible_cpus());
(gdb)
4038            futex_queues = alloc_large_system_hash("futex", sizeof(*futex_queues),
(gdb)
4043            futex_hashsize = 1UL << futex_shift;
(gdb)
4045            futex_detect_cmpxchg();
(gdb)

If I step into futex_detect_cmpxchg(), I see us jump into vector_dabt
then back out futex_init.

(gdb) hbreak futex_init
Hardware assisted breakpoint 1 at 0xc2727fac: file kernel/futex.c, line 4028.
(gdb) hbreak futex_detect_cmpxchg
Hardware assisted breakpoint 2 at 0xc27280c8: file kernel/futex.c, line 4008.
(gdb) c
Continuing.

Breakpoint 1, futex_init () at kernel/futex.c:4028
4028    {
(gdb) c
Continuing.

Breakpoint 2, futex_detect_cmpxchg () at kernel/futex.c:4008
4008    {
(gdb) n
4022            if (cmpxchg_futex_value_locked(&curval, NULL, 0, 0) == -EFAULT)
(gdb)
vector_dabt () at arch/arm/kernel/entry-armv.S:1099
1099            vector_stub     dabt, ABT_MODE, 8
(gdb)
__dabt_svc () at arch/arm/kernel/entry-armv.S:194
194             svc_entry uaccess=0
(gdb)
__dabt_svc () at arch/arm/kernel/entry-armv.S:195
195             mov     r2, sp
(gdb)
196             dabt_helper
(gdb)
198             svc_exit r5                             @ return from exception
(gdb)
0xc0458040 in ?? ()
(gdb)
Cannot find bounds of current function
(gdb) finish
Run till exit from #0  0xc0458040 in ?? ()

Breakpoint 1, futex_init () at kernel/futex.c:4028
4028    {
(gdb)

I am going to be honest, I do not really understand what is going on
here but I am more than happy to provide whatever information is needed
to further explore this.

Cheers,
Nathan

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

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

[Arnd Bergmann]

On Fri, Oct 30, 2020 at 9:45 AM Nathan Chancellor
<natechancellor@gmail.com> wrote:
> On Fri, Oct 30, 2020 at 09:10:56AM +0100, Ard Biesheuvel wrote:
> 4043            futex_hashsize = 1UL << futex_shift;
> (gdb)
> 4045            futex_detect_cmpxchg();
> (gdb)

I can't explain it, but I'd point out that futex_detect_cmpxchg() has caused
problems in the past, with multiple patches for it proposed in the past
and none of them merged. One of the patches I had sent for it was:

commit 8232a8ffc332fa6a50296a51c4d85200a747256c
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Mar 4 17:33:00 2019 +0100

    [SUBMITTED 20190307] futex: mark futex_detect_cmpxchg() as 'noinline'

    On 32-bit ARM, I got a link failure in futex_init() when building
    with clang in some random configurations:

    kernel/futex.o:(.text.fixup+0x5c): relocation truncated to fit:
R_ARM_JUMP24 against `.init.text'

    As far as I can tell, the problem is that a branch is over 16MB
    apart in those configurations, but only if it branches back to
    the init text.

    Marking the futex_detect_cmpxchg() function as noinline and
    not __init avoids the problem for me.

    Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/kernel/futex.c b/kernel/futex.c
index e646661f6282..6fbbed45f51b 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -4061,7 +4061,7 @@ SYSCALL_DEFINE6(futex_time32, u32 __user *,
uaddr, int, op, u32, val,
 }
 #endif /* CONFIG_COMPAT_32BIT_TIME */

-static void __init futex_detect_cmpxchg(void)
+static noinline void futex_detect_cmpxchg(void)
 {
 #ifndef CONFIG_HAVE_FUTEX_CMPXCHG
        u32 curval;

I forgot what the problem was, but you might try that patch, or find
the previous discussions in the archive.

       Arnd

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

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

[Nathan Chancellor]

On Fri, Oct 30, 2020 at 09:51:27AM +0100, Arnd Bergmann wrote:
> On Fri, Oct 30, 2020 at 9:45 AM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> > On Fri, Oct 30, 2020 at 09:10:56AM +0100, Ard Biesheuvel wrote:
> > 4043            futex_hashsize = 1UL << futex_shift;
> > (gdb)
> > 4045            futex_detect_cmpxchg();
> > (gdb)
> 
> I can't explain it, but I'd point out that futex_detect_cmpxchg() has caused
> problems in the past, with multiple patches for it proposed in the past
> and none of them merged. One of the patches I had sent for it was:
> 
> commit 8232a8ffc332fa6a50296a51c4d85200a747256c
> Author: Arnd Bergmann <arnd@arndb.de>
> Date:   Mon Mar 4 17:33:00 2019 +0100
> 
>     [SUBMITTED 20190307] futex: mark futex_detect_cmpxchg() as 'noinline'
> 
>     On 32-bit ARM, I got a link failure in futex_init() when building
>     with clang in some random configurations:
> 
>     kernel/futex.o:(.text.fixup+0x5c): relocation truncated to fit:
> R_ARM_JUMP24 against `.init.text'
> 
>     As far as I can tell, the problem is that a branch is over 16MB
>     apart in those configurations, but only if it branches back to
>     the init text.
> 
>     Marking the futex_detect_cmpxchg() function as noinline and
>     not __init avoids the problem for me.
> 
>     Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> 
> diff --git a/kernel/futex.c b/kernel/futex.c
> index e646661f6282..6fbbed45f51b 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -4061,7 +4061,7 @@ SYSCALL_DEFINE6(futex_time32, u32 __user *,
> uaddr, int, op, u32, val,
>  }
>  #endif /* CONFIG_COMPAT_32BIT_TIME */
> 
> -static void __init futex_detect_cmpxchg(void)
> +static noinline void futex_detect_cmpxchg(void)
>  {
>  #ifndef CONFIG_HAVE_FUTEX_CMPXCHG
>         u32 curval;
> 
> I forgot what the problem was, but you might try that patch, or find
> the previous discussions in the archive.
> 
>        Arnd

As it turns out, that is the patch that fixes the ld.bfd issue that I
mentioned earlier in this thread and it fixes this issue as well.

To summarize, with the below diff, I can successfully boot
multi_v7_defconfig + CONFIG_KASAN=y when LLVM=1 is used (and I see KASAN
get initialized properly).

Cheers,
Nathan

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 4d76eab2b22d..3c0a64cefe52 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -10,7 +10,7 @@
 #
 # Copyright (C) 1995-2001 by Russell King
 
-LDFLAGS_vmlinux	:= --no-undefined -X --pic-veneer
+LDFLAGS_vmlinux	:= --no-undefined -X --pic-veneer -z norelro
 ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
 LDFLAGS_vmlinux	+= --be8
 KBUILD_LDFLAGS_MODULE	+= --be8
diff --git a/kernel/futex.c b/kernel/futex.c
index be68ac0d49ad..226bb20d175f 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -4004,7 +4004,7 @@ SYSCALL_DEFINE6(futex_time32, u32 __user *, uaddr, int, op, u32, val,
 }
 #endif /* CONFIG_COMPAT_32BIT_TIME */
 
-static void __init futex_detect_cmpxchg(void)
+static noinline void futex_detect_cmpxchg(void)
 {
 #ifndef CONFIG_HAVE_FUTEX_CMPXCHG
 	u32 curval;

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

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

[Fāng-ruì Sòng]

On Fri, Oct 30, 2020 at 2:09 AM Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> On Fri, Oct 30, 2020 at 09:51:27AM +0100, Arnd Bergmann wrote:
> > On Fri, Oct 30, 2020 at 9:45 AM Nathan Chancellor
> > <natechancellor@gmail.com> wrote:
> > > On Fri, Oct 30, 2020 at 09:10:56AM +0100, Ard Biesheuvel wrote:
> > > 4043            futex_hashsize = 1UL << futex_shift;
> > > (gdb)
> > > 4045            futex_detect_cmpxchg();
> > > (gdb)
> >
> > I can't explain it, but I'd point out that futex_detect_cmpxchg() has caused
> > problems in the past, with multiple patches for it proposed in the past
> > and none of them merged. One of the patches I had sent for it was:
> >
> > commit 8232a8ffc332fa6a50296a51c4d85200a747256c
> > Author: Arnd Bergmann <arnd@arndb.de>
> > Date:   Mon Mar 4 17:33:00 2019 +0100
> >
> >     [SUBMITTED 20190307] futex: mark futex_detect_cmpxchg() as 'noinline'
> >
> >     On 32-bit ARM, I got a link failure in futex_init() when building
> >     with clang in some random configurations:
> >
> >     kernel/futex.o:(.text.fixup+0x5c): relocation truncated to fit:
> > R_ARM_JUMP24 against `.init.text'
> >
> >     As far as I can tell, the problem is that a branch is over 16MB
> >     apart in those configurations, but only if it branches back to
> >     the init text.
> >
> >     Marking the futex_detect_cmpxchg() function as noinline and
> >     not __init avoids the problem for me.
> >
> >     Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >
> > diff --git a/kernel/futex.c b/kernel/futex.c
> > index e646661f6282..6fbbed45f51b 100644
> > --- a/kernel/futex.c
> > +++ b/kernel/futex.c
> > @@ -4061,7 +4061,7 @@ SYSCALL_DEFINE6(futex_time32, u32 __user *,
> > uaddr, int, op, u32, val,
> >  }
> >  #endif /* CONFIG_COMPAT_32BIT_TIME */
> >
> > -static void __init futex_detect_cmpxchg(void)
> > +static noinline void futex_detect_cmpxchg(void)
> >  {
> >  #ifndef CONFIG_HAVE_FUTEX_CMPXCHG
> >         u32 curval;
> >
> > I forgot what the problem was, but you might try that patch, or find
> > the previous discussions in the archive.
> >
> >        Arnd
>
> As it turns out, that is the patch that fixes the ld.bfd issue that I
> mentioned earlier in this thread and it fixes this issue as well.
>
> To summarize, with the below diff, I can successfully boot
> multi_v7_defconfig + CONFIG_KASAN=y when LLVM=1 is used (and I see KASAN
> get initialized properly).
>
> Cheers,
> Nathan
>
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 4d76eab2b22d..3c0a64cefe52 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -10,7 +10,7 @@
>  #
>  # Copyright (C) 1995-2001 by Russell King
>
> -LDFLAGS_vmlinux        := --no-undefined -X --pic-veneer
> +LDFLAGS_vmlinux        := --no-undefined -X --pic-veneer -z norelro
>  ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
>  LDFLAGS_vmlinux        += --be8
>  KBUILD_LDFLAGS_MODULE  += --be8
> diff --git a/kernel/futex.c b/kernel/futex.c
> index be68ac0d49ad..226bb20d175f 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -4004,7 +4004,7 @@ SYSCALL_DEFINE6(futex_time32, u32 __user *, uaddr, int, op, u32, val,
>  }
>  #endif /* CONFIG_COMPAT_32BIT_TIME */
>
> -static void __init futex_detect_cmpxchg(void)
> +static noinline void futex_detect_cmpxchg(void)
>  {
>  #ifndef CONFIG_HAVE_FUTEX_CMPXCHG
>         u32 curval;
>
> --
> You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-linux+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20201030090945.GA3635064%40ubuntu-m3-large-x86.

About "ARM: Replace string mem* functions for KASan", it added .weak
memcpy to arch/arm/lib/memcpy.S
However, the convention is to change .weak + ENTRY(...) to WEAK(...)

In particular, clang 12 will reject `.weak memcpy; .global memcpy`
(they had different semantics in GNU as and LLVM integrated assembler
for a long time AND binutils maintainer agreed that .weak and .global
are strange and should not be used - though binutils will not make the
change to cause disruption)

Please see https://github.com/ClangBuiltLinux/linux/issues/1190

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

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

[Nick Desaulniers]

On Wed, Nov 4, 2020 at 4:30 PM Fāng-ruì Sòng <maskray@google.com> wrote:
>
> About "ARM: Replace string mem* functions for KASan", it added .weak
> memcpy to arch/arm/lib/memcpy.S
> However, the convention is to change .weak + ENTRY(...) to WEAK(...)
>
> In particular, clang 12 will reject `.weak memcpy; .global memcpy`
> (they had different semantics in GNU as and LLVM integrated assembler
> for a long time AND binutils maintainer agreed that .weak and .global
> are strange and should not be used - though binutils will not make the
> change to cause disruption)
>
> Please see https://github.com/ClangBuiltLinux/linux/issues/1190

It's straightforward for us to fixup; Fangrui has sent patches for
x86, perf, and 64b arm already which have been accepted.  I forget
though what is the convention for "Fixes:" tags for patches in -next?
The SHAs change when pulled, right?
-- 
Thanks,
~Nick Desaulniers

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

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

[Ard Biesheuvel]

On Thu, 5 Nov 2020 at 01:38, Nick Desaulniers <ndesaulniers@google.com> wrote:
>
> On Wed, Nov 4, 2020 at 4:30 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> >
> > About "ARM: Replace string mem* functions for KASan", it added .weak
> > memcpy to arch/arm/lib/memcpy.S
> > However, the convention is to change .weak + ENTRY(...) to WEAK(...)
> >
> > In particular, clang 12 will reject `.weak memcpy; .global memcpy`
> > (they had different semantics in GNU as and LLVM integrated assembler
> > for a long time AND binutils maintainer agreed that .weak and .global
> > are strange and should not be used - though binutils will not make the
> > change to cause disruption)
> >
> > Please see https://github.com/ClangBuiltLinux/linux/issues/1190
>
> It's straightforward for us to fixup; Fangrui has sent patches for
> x86, perf, and 64b arm already which have been accepted.  I forget
> though what is the convention for "Fixes:" tags for patches in -next?
> The SHAs change when pulled, right?

No, only when rebasing. It depends on the maintainer how likely that
is to happen for changes that are in -next, but usually the commit IDs
are stable once pulled into -next.

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

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

[Mike Rapoport]

On Thu, Nov 05, 2020 at 08:52:46AM +0100, Ard Biesheuvel wrote:
> On Thu, 5 Nov 2020 at 01:38, Nick Desaulniers <ndesaulniers@google.com> wrote:
> >
> > On Wed, Nov 4, 2020 at 4:30 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> > >
> > > About "ARM: Replace string mem* functions for KASan", it added .weak
> > > memcpy to arch/arm/lib/memcpy.S
> > > However, the convention is to change .weak + ENTRY(...) to WEAK(...)
> > >
> > > In particular, clang 12 will reject `.weak memcpy; .global memcpy`
> > > (they had different semantics in GNU as and LLVM integrated assembler
> > > for a long time AND binutils maintainer agreed that .weak and .global
> > > are strange and should not be used - though binutils will not make the
> > > change to cause disruption)
> > >
> > > Please see https://github.com/ClangBuiltLinux/linux/issues/1190
> >
> > It's straightforward for us to fixup; Fangrui has sent patches for
> > x86, perf, and 64b arm already which have been accepted.  I forget
> > though what is the convention for "Fixes:" tags for patches in -next?
> > The SHAs change when pulled, right?
> 
> No, only when rebasing. It depends on the maintainer how likely that
> is to happen for changes that are in -next, but usually the commit IDs
> are stable once pulled into -next.

With a small exception of mm tree ;-)

-- 
Sincerely yours,
Mike.

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

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

[Nick Desaulniers]

On Thu, Oct 29, 2020 at 6:32 PM Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> On Thu, Oct 29, 2020 at 05:38:22PM -0700, Nick Desaulniers wrote:
> > On Thu, Oct 29, 2020 at 5:29 PM Nathan Chancellor
> > <natechancellor@gmail.com> wrote:
> > >
> > > After this series was applied and available in -next, ARCH=arm LLVM=1
> > > allyesconfig builds started failing:
> > >
> > > $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- KCONFIG_ALLCONFIG=<(echo CONFIG_CPU_BIG_ENDIAN=n) LLVM=1 distclean allyesconfig vmlinux
> > > ...
> > > ld.lld: error: section: .exit.data is not contiguous with other relro sections
> > > ...
> >
> > relro? smells like:
> > https://lore.kernel.org/lkml/20201016175339.2429280-1-ndesaulniers@google.com/T/#u
> >
>
> Huh, did not even realize that the error messages were the same, my bad!
>
> This issue is simple enough to produce by just adding CONFIG_KASAN=y to
> multi_v7_defconfig. I tried adding '-z norelro' to LDFLAGS_vmlinux in
> arch/arm/Makefile and it fixes the build error but the resulting kernel
> does not boot in QEMU.

> '-z norelro' boots fine without KASAN so I assume there is something up
> specifically with KASAN and LLVM for ARM.

Regardless, we still want `-z norelro`. Can you please send a patch if
you still have the diff locally?
-- 
Thanks,
~Nick Desaulniers

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

[PATCH] ARM: Link with '-z norelro'

[Nathan Chancellor]

When linking a multi_v7_defconfig + CONFIG_KASAN=y kernel with
LD=ld.lld, the following error occurs:

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 zImage
ld.lld: error: section: .exit.data is not contiguous with other relro sections

LLD defaults to '-z relro', which is unneeded for the kernel because
program headers are not used nor is there any position independent code
generation or linking for ARM. Add '-z norelro' to LDFLAGS_vmlinux to
avoid this error.

Link: https://github.com/ClangBuiltLinux/linux/issues/1189
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
 arch/arm/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 4d76eab2b22d..3c0a64cefe52 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -10,7 +10,7 @@
 #
 # Copyright (C) 1995-2001 by Russell King
 
-LDFLAGS_vmlinux	:= --no-undefined -X --pic-veneer
+LDFLAGS_vmlinux	:= --no-undefined -X --pic-veneer -z norelro
 ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
 LDFLAGS_vmlinux	+= --be8
 KBUILD_LDFLAGS_MODULE	+= --be8

base-commit: a0796429c6abecf8afaeb65b1db286af1fb579d1
-- 
2.29.2


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

Re: [PATCH] ARM: Link with '-z norelro'

[Nick Desaulniers]

On Mon, Nov 9, 2020 at 5:56 PM Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> When linking a multi_v7_defconfig + CONFIG_KASAN=y kernel with
> LD=ld.lld, the following error occurs:
>
> $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 zImage
> ld.lld: error: section: .exit.data is not contiguous with other relro sections
>
> LLD defaults to '-z relro', which is unneeded for the kernel because
> program headers are not used nor is there any position independent code
> generation or linking for ARM. Add '-z norelro' to LDFLAGS_vmlinux to
> avoid this error.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/1189
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>

Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>

Thanks for the patch!
See also: https://lore.kernel.org/linux-arm-kernel/20201016175339.2429280-1-ndesaulniers@google.com/
where we just did the same thing for aarch64.

> ---
>  arch/arm/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 4d76eab2b22d..3c0a64cefe52 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -10,7 +10,7 @@
>  #
>  # Copyright (C) 1995-2001 by Russell King
>
> -LDFLAGS_vmlinux        := --no-undefined -X --pic-veneer
> +LDFLAGS_vmlinux        := --no-undefined -X --pic-veneer -z norelro
>  ifeq ($(CONFIG_CPU_ENDIAN_BE8),y)
>  LDFLAGS_vmlinux        += --be8
>  KBUILD_LDFLAGS_MODULE  += --be8
>
> base-commit: a0796429c6abecf8afaeb65b1db286af1fb579d1
> --
> 2.29.2


-- 
Thanks,
~Nick Desaulniers

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

Re: [PATCH] ARM: Link with '-z norelro'

[Nick Desaulniers]

On Mon, Nov 9, 2020 at 6:05 PM Nick Desaulniers <ndesaulniers@google.com> wrote:
>
> On Mon, Nov 9, 2020 at 5:56 PM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > When linking a multi_v7_defconfig + CONFIG_KASAN=y kernel with
> > LD=ld.lld, the following error occurs:
> >
> > $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 zImage
> > ld.lld: error: section: .exit.data is not contiguous with other relro sections
> >
> > LLD defaults to '-z relro', which is unneeded for the kernel because
> > program headers are not used nor is there any position independent code
> > generation or linking for ARM. Add '-z norelro' to LDFLAGS_vmlinux to
> > avoid this error.
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1189
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
>
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> Tested-by: Nick Desaulniers <ndesaulniers@google.com>
>
> Thanks for the patch!
> See also: https://lore.kernel.org/linux-arm-kernel/20201016175339.2429280-1-ndesaulniers@google.com/
> where we just did the same thing for aarch64.

I was thinking more about this last night.  If we're going to be
playing whack-a-mole for each architecture with this, would it be
worthwhile for us to raise this up to the top level Makefile?
-- 
Thanks,
~Nick Desaulniers

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

Re: [PATCH] ARM: Link with '-z norelro'

[Nathan Chancellor]

On Tue, Nov 10, 2020 at 10:49:32AM -0800, Nick Desaulniers wrote:
> On Mon, Nov 9, 2020 at 6:05 PM Nick Desaulniers <ndesaulniers@google.com> wrote:
> >
> > On Mon, Nov 9, 2020 at 5:56 PM Nathan Chancellor
> > <natechancellor@gmail.com> wrote:
> > >
> > > When linking a multi_v7_defconfig + CONFIG_KASAN=y kernel with
> > > LD=ld.lld, the following error occurs:
> > >
> > > $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 zImage
> > > ld.lld: error: section: .exit.data is not contiguous with other relro sections
> > >
> > > LLD defaults to '-z relro', which is unneeded for the kernel because
> > > program headers are not used nor is there any position independent code
> > > generation or linking for ARM. Add '-z norelro' to LDFLAGS_vmlinux to
> > > avoid this error.
> > >
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/1189
> > > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> >
> > Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> > Tested-by: Nick Desaulniers <ndesaulniers@google.com>
> >
> > Thanks for the patch!
> > See also: https://lore.kernel.org/linux-arm-kernel/20201016175339.2429280-1-ndesaulniers@google.com/
> > where we just did the same thing for aarch64.
> 
> I was thinking more about this last night.  If we're going to be
> playing whack-a-mole for each architecture with this, would it be
> worthwhile for us to raise this up to the top level Makefile?

Sure, I can send a patch along tomorrow that adds '-z norelro' to
LDFLAGS_vmlinux in the top level Makefile.

Cheers,
Nathan

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

Re: [PATCH] ARM: Link with '-z norelro'

[Nick Desaulniers]

Does this need to get submitted to
https://www.armlinux.org.uk/developer/patches/section.php?section=0
since `-z norelro` will produce warnings in ld.bfd for architectures
that don't support that (the results of the thread on adding it
globally)?

On Wed, Nov 11, 2020 at 6:52 PM Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> On Tue, Nov 10, 2020 at 10:49:32AM -0800, Nick Desaulniers wrote:
> > On Mon, Nov 9, 2020 at 6:05 PM Nick Desaulniers <ndesaulniers@google.com> wrote:
> > >
> > > On Mon, Nov 9, 2020 at 5:56 PM Nathan Chancellor
> > > <natechancellor@gmail.com> wrote:
> > > >
> > > > When linking a multi_v7_defconfig + CONFIG_KASAN=y kernel with
> > > > LD=ld.lld, the following error occurs:
> > > >
> > > > $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 zImage
> > > > ld.lld: error: section: .exit.data is not contiguous with other relro sections
> > > >
> > > > LLD defaults to '-z relro', which is unneeded for the kernel because
> > > > program headers are not used nor is there any position independent code
> > > > generation or linking for ARM. Add '-z norelro' to LDFLAGS_vmlinux to
> > > > avoid this error.
> > > >
> > > > Link: https://github.com/ClangBuiltLinux/linux/issues/1189
> > > > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> > >
> > > Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> > > Tested-by: Nick Desaulniers <ndesaulniers@google.com>
> > >
> > > Thanks for the patch!
> > > See also: https://lore.kernel.org/linux-arm-kernel/20201016175339.2429280-1-ndesaulniers@google.com/
> > > where we just did the same thing for aarch64.
> >
> > I was thinking more about this last night.  If we're going to be
> > playing whack-a-mole for each architecture with this, would it be
> > worthwhile for us to raise this up to the top level Makefile?
>
> Sure, I can send a patch along tomorrow that adds '-z norelro' to
> LDFLAGS_vmlinux in the top level Makefile.
>
> Cheers,
> Nathan



-- 
Thanks,
~Nick Desaulniers

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

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

[Ahmad Fatoum]

Hello,

On 10/19/20 10:41 AM, Linus Walleij wrote:
> This is the 16th and final (knock on wood) version of
> KASan for ARM32

I was about to report an apparent incompatibility with ftrace (see below),
but I can't reproduce this when rebasing the patch stack onto v5.10-rc2.

I paste the log here anyway in case someone else runs into it. I don't
know which commit between v5.9.5 and v5.10-rc2 is to thank for fixing/masking
the splat.

[    0.000000] ftrace: allocating 31200 entries in 61 pages
[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: CPU: 0 PID: 0 at arch/arm/kernel/insn.c:47 __arm_gen_branch+0x78/0x80
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.9.5-20201105-1 #1
[    0.000000] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[    0.000000] Backtrace:
[    0.000000] [<c1eaed78>] (dump_backtrace) from [<c1eaf120>] (show_stack+0x20/0x24)
[    0.000000]  r7:600000d3 r6:c2730b80 r5:00000000 r4:c2730b80
[    0.000000] [<c1eaf100>] (show_stack) from [<c1eb8130>] (dump_stack+0x8c/0xa4)
[    0.000000] [<c1eb80a4>] (dump_stack) from [<c015a2dc>] (__warn+0x284/0x2bc)
[    0.000000]  r7:0000002f r6:00000009 r5:c01267a4 r4:c1f094a0
[    0.000000] [<c015a058>] (__warn) from [<c1eb01b4>] (warn_slowpath_fmt+0xc0/0x140)
[    0.000000]  r9:c01267a4 r8:0000002f r7:c1f094a0 r6:00000000 r5:c2603ec0 r4:b74c07cc
[    0.000000] [<c1eb00f8>] (warn_slowpath_fmt) from [<c01267a4>] (__arm_gen_branch+0x78/0x80)
[    0.000000]  r10:e605ab68 r9:c0125f48 r8:c2607070 r7:00000000 r6:0000756d r5:0000056e
[    0.000000]  r4:00000000
[    0.000000] [<c012672c>] (__arm_gen_branch) from [<c012654c>] (ftrace_make_nop+0x58/0x88)
[    0.000000]  r5:0000056e r4:c2500354
[    0.000000] [<c01264f4>] (ftrace_make_nop) from [<c03c3d04>] (ftrace_process_locs+0x8d8/0xc60)
[    0.000000]  r4:e6003a00
[    0.000000] [<c03c342c>] (ftrace_process_locs) from [<c251e628>] (ftrace_init+0x90/0x140)
[    0.000000]  r10:10c5387d r9:c1f43ba8 r8:c25c8250 r7:c25a9ad0 r6:00000001 r5:c2607070
[    0.000000]  r4:c2908b80
[    0.000000] [<c251e598>] (ftrace_init) from [<c2501698>] (start_kernel+0x160/0x34c)
[    0.000000]  r9:00000001 r8:c2606ec0 r7:00000000 r6:c2606ec0 r5:c28bc000 r4:ffffffff
[    0.000000] [<c2501538>] (start_kernel) from [<00000000>] (0x0)
[    0.000000]  r9:412fc09a r8:18000000 r7:00000000 r6:10c0387d r5:00000051 r4:c2500334
[    0.000000] ---[ end trace bec787061c40ac80 ]---
[    0.000000] ------------[ ftrace bug ]------------
[    0.000000] ftrace failed to modify
[    0.000000] [<c2500354>] set_reset_devices+0x10/0x28
[    0.000000]  actual:   a7:d9:01:eb
[    0.000000] Initializing ftrace call sites
[    0.000000] ftrace record flags: 0
[    0.000000]  (0)
[    0.000000]  expected tramp: c0125f54
[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:2065 ftrace_bug+0x328/0x39c
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Tainted: G        W         5.9.5-20201105-1 #1
[    0.000000] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[    0.000000] Backtrace:
[    0.000000] [<c1eaed78>] (dump_backtrace) from [<c1eaf120>] (show_stack+0x20/0x24)
[    0.000000]  r7:600000d3 r6:c2730b80 r5:00000000 r4:c2730b80
[    0.000000] [<c1eaf100>] (show_stack) from [<c1eb8130>] (dump_stack+0x8c/0xa4)
[    0.000000] [<c1eb80a4>] (dump_stack) from [<c015a2dc>] (__warn+0x284/0x2bc)
[    0.000000]  r7:00000811 r6:00000009 r5:c1eb4f3c r4:c1f42960
[    0.000000] [<c015a058>] (__warn) from [<c1eb01b4>] (warn_slowpath_fmt+0xc0/0x140)
[    0.000000]  r9:c1eb4f3c r8:00000811 r7:c1f42960 r6:00000000 r5:c2603ec0 r4:b74c07cc
[    0.000000] [<c1eb00f8>] (warn_slowpath_fmt) from [<c1eb4f3c>] (ftrace_bug+0x328/0x39c)
[    0.000000]  r10:e605ab68 r9:00000000 r8:c2607070 r7:bbc0b56d r6:e605ab6c r5:00000000
[    0.000000]  r4:e605ab68
[    0.000000] [<c1eb4c14>] (ftrace_bug) from [<c03c3a8c>] (ftrace_process_locs+0x660/0xc60)
[    0.000000]  r7:c0125f48 r6:0000756d r5:0000056e r4:e6003a00
[    0.000000] [<c03c342c>] (ftrace_process_locs) from [<c251e628>] (ftrace_init+0x90/0x140)
[    0.000000]  r10:10c5387d r9:c1f43ba8 r8:c25c8250 r7:c25a9ad0 r6:00000001 r5:c2607070
[    0.000000]  r4:c2908b80
[    0.000000] [<c251e598>] (ftrace_init) from [<c2501698>] (start_kernel+0x160/0x34c)
[    0.000000]  r9:00000001 r8:c2606ec0 r7:00000000 r6:c2606ec0 r5:c28bc000 r4:ffffffff
[    0.000000] [<c2501538>] (start_kernel) from [<00000000>] (0x0)
[    0.000000]  r9:412fc09a r8:18000000 r7:00000000 r6:10c0387d r5:00000051 r4:c2500334
[    0.000000] ---[ end trace bec787061c40ac81 ]---
[    0.000000] ftrace: allocated 61 pages with 5 groups



-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

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