[PATCH v3 0/2] arm: kasan: support CONFIG_KASAN_VMALLOC

Since the framework of KASAN_VMALLOC is well-developed,
It's easy to support for ARM that simply not to map shadow of VMALLOC
area on kasan_init.

Since the virtual address of vmalloc for Arm is also between
MODULE_VADDR and 0x100000000 (ZONE_HIGHMEM), which means the shadow
address has already included between KASAN_SHADOW_START and
KASAN_SHADOW_END.
Thus we need to change nothing for memory map of Arm.

This can fix ARM_MODULE_PLTS with KASan, support KASan for higmem
and provide the first step to support CONFIG_VMAP_STACK with Arm.
    

Test on
1. Qemu with memory 2G and vmalloc=500M for 3G/1G mapping.
2. Qemu with memory 2G and vmalloc=500M for 3G/1G mapping + LPAE.
3. Qemu with memory 2G and vmalloc=500M for 2G/2G mapping.

v3:
    rebase on 5.17-rc5.
    Add simple doc for "arm: kasan: support CONFIG_KASAN_VMALLOC"
    Tweak commit message.

v2:
    rebase on 5.17-rc3


Lecopzer Chen (2):
  arm: kasan: support CONFIG_KASAN_VMALLOC
  arm: kconfig: fix MODULE_PLTS for KASAN with KASAN_VMALLOC

 arch/arm/Kconfig                 |  2 ++
 arch/arm/include/asm/kasan_def.h | 11 ++++++++++-
 arch/arm/mm/kasan_init.c         |  6 +++++-
 3 files changed, 17 insertions(+), 2 deletions(-)

-- 
2.25.1

5 more lines

Simply make shadow of vmalloc area mapped on demand.

Since the virtual address of vmalloc for Arm is also between
MODULE_VADDR and 0x100000000 (ZONE_HIGHMEM), which means the shadow
address has already included between KASAN_SHADOW_START and
KASAN_SHADOW_END.
Thus we need to change nothing for memory map of Arm.

This can fix ARM_MODULE_PLTS with KASan, support KASan for higmem
and provide the first step to support CONFIG_VMAP_STACK with Arm.

Signed-off-by: Lecopzer Chen <redacted>
---
 arch/arm/Kconfig                 |  1 +
 arch/arm/include/asm/kasan_def.h | 11 ++++++++++-
 arch/arm/mm/kasan_init.c         |  6 +++++-
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4c97cb40eebb..78250e246cc6 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig

@@ -72,6 +72,7 @@ config ARM
 	select HAVE_ARCH_KFENCE if MMU && !XIP_KERNEL
 	select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
 	select HAVE_ARCH_KASAN if MMU && !XIP_KERNEL
+	select HAVE_ARCH_KASAN_VMALLOC if HAVE_ARCH_KASAN
 	select HAVE_ARCH_MMAP_RND_BITS if MMU
 	select HAVE_ARCH_PFN_VALID
 	select HAVE_ARCH_SECCOMP

diff --git a/arch/arm/include/asm/kasan_def.h b/arch/arm/include/asm/kasan_def.h
index 5739605aa7cf..96fd1d3b5a0c 100644
--- a/arch/arm/include/asm/kasan_def.h
+++ b/arch/arm/include/asm/kasan_def.h

@@ -19,7 +19,16 @@
  * space to use as shadow memory for KASan as follows:
  *
  * +----+ 0xffffffff
- * |    |							\
+ * |    |\
+ * |    | |-> ZONE_HIGHMEM for vmalloc virtual address space.
+ * |    | |   Such as vmalloc(), GFP_HIGHUSER (__GFP__HIGHMEM),
+ * |    | |   module address using ARM_MODULE_PLTS, etc.
+ * |    | |
+ * |    | |   If CONFIG_KASAN_VMALLOC=y, this area would populate
+ * |    | |   shadow address on demand.
+ * |    |/
+ * +----+ VMALLOC_START
+ * |    |\
  * |    | |-> Static kernel image (vmlinux) BSS and page table
  * |    |/
  * +----+ PAGE_OFFSET

diff --git a/arch/arm/mm/kasan_init.c b/arch/arm/mm/kasan_init.c
index 5ad0d6c56d56..29caee9c79ce 100644
--- a/arch/arm/mm/kasan_init.c
+++ b/arch/arm/mm/kasan_init.c

@@ -236,7 +236,11 @@ void __init kasan_init(void)
 
 	clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);
 
-	kasan_populate_early_shadow(kasan_mem_to_shadow((void *)VMALLOC_START),
+	if (!IS_ENABLED(CONFIG_KASAN_VMALLOC))
+		kasan_populate_early_shadow(kasan_mem_to_shadow((void *)VMALLOC_START),
+					    kasan_mem_to_shadow((void *)VMALLOC_END));
+
+	kasan_populate_early_shadow(kasan_mem_to_shadow((void *)VMALLOC_END),
 				    kasan_mem_to_shadow((void *)-1UL) + 1);
 
 	for_each_mem_range(i, &pa_start, &pa_end) {

-- 
2.25.1


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

When we run out of module space address with ko insertion,
and with MODULE_PLTS, module would turn to try to find memory
from VMALLOC address space.

Unfortunately, with KASAN enabled, VMALLOC doesn't work without
KASAN_VMALLOC, thus select KASAN_VMALLOC by default.

8<--- cut here ---
 Unable to handle kernel paging request at virtual address bd300860
 [bd300860] *pgd=41cf1811, *pte=41cf26df, *ppte=41cf265f
 Internal error: Oops: 80f [#1] PREEMPT SMP ARM
 Modules linked in: hello(O+)
 CPU: 0 PID: 89 Comm: insmod Tainted: G           O      5.16.0-rc6+ #19
 Hardware name: Generic DT based system
 PC is at mmioset+0x30/0xa8
 LR is at 0x0
 pc : [<c077ed30>]    lr : [<00000000>]    psr: 20000013
 sp : c451fc18  ip : bd300860  fp : c451fc2c
 r10: f18042cc  r9 : f18042d0  r8 : 00000000
 r7 : 00000001  r6 : 00000003  r5 : 01312d00  r4 : f1804300
 r3 : 00000000  r2 : 00262560  r1 : 00000000  r0 : bd300860
 Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
 Control: 10c5387d  Table: 43e9406a  DAC: 00000051
 Register r0 information: non-paged memory
 Register r1 information: NULL pointer
 Register r2 information: non-paged memory
 Register r3 information: NULL pointer
 Register r4 information: 4887-page vmalloc region starting at 0xf1802000 allocated at load_module+0x14f4/0x32a8
 Register r5 information: non-paged memory
 Register r6 information: non-paged memory
 Register r7 information: non-paged memory
 Register r8 information: NULL pointer
 Register r9 information: 4887-page vmalloc region starting at 0xf1802000 allocated at load_module+0x14f4/0x32a8
 Register r10 information: 4887-page vmalloc region starting at 0xf1802000 allocated at load_module+0x14f4/0x32a8
 Register r11 information: non-slab/vmalloc memory
 Register r12 information: non-paged memory
 Process insmod (pid: 89, stack limit = 0xc451c000)
 Stack: (0xc451fc18 to 0xc4520000)
 fc00:                                                       f18041f0 c04803a4
 fc20: c451fc44 c451fc30 c048053c c0480358 f1804030 01312cff c451fc64 c451fc48

58 more lines

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 78250e246cc6..d797a3699959 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig

@@ -1515,6 +1515,7 @@ config ARCH_WANT_GENERAL_HUGETLB
 config ARM_MODULE_PLTS
 	bool "Use PLTs to allow module memory to spill over into vmalloc area"
 	depends on MODULES
+	select KASAN_VMALLOC if KASAN
 	default y
 	help
 	  Allocate PLTs when loading modules so that jumps and calls whose

-- 
2.25.1


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

On Sun, Feb 27, 2022 at 2:48 PM Lecopzer Chen
[off-list ref] wrote:

Since the framework of KASAN_VMALLOC is well-developed,
It's easy to support for ARM that simply not to map shadow of VMALLOC
area on kasan_init.

Since the virtual address of vmalloc for Arm is also between
MODULE_VADDR and 0x100000000 (ZONE_HIGHMEM), which means the shadow
address has already included between KASAN_SHADOW_START and
KASAN_SHADOW_END.
Thus we need to change nothing for memory map of Arm.

This can fix ARM_MODULE_PLTS with KASan, support KASan for higmem
and provide the first step to support CONFIG_VMAP_STACK with Arm.


Test on
1. Qemu with memory 2G and vmalloc=500M for 3G/1G mapping.
2. Qemu with memory 2G and vmalloc=500M for 3G/1G mapping + LPAE.
3. Qemu with memory 2G and vmalloc=500M for 2G/2G mapping.

v3:
    rebase on 5.17-rc5.
    Add simple doc for "arm: kasan: support CONFIG_KASAN_VMALLOC"
    Tweak commit message.

Ater testing this with my kernel-in-vmalloc patches and some hacks, I got
the kernel booting in the VMALLOC area with KASan enabled!
See:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kernel-in-vmalloc-v5.17-rc1

That's a pretty serious stress test. So:
Tested-by: Linus Walleij <redacted>
Reviewed-by: Linus Walleij <redacted>
for the series.

I suppose you could put this into Russell's patch tracker, it's gonna be
for kernel v5.19 by now but why stress. It seems I can fix up
kernel-in-vmalloc on top and submit that for v5.19 as well.

Yours,
Linus Walleij

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

On Sun, Feb 27, 2022 at 09:47:25PM +0800, Lecopzer Chen wrote:

7 more quoted lines

This diagram is incorrect. We already have the memory layout in
Documentation/arm/memory.rst, so we don't need another set of
documentation that is misleading.

-- 
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

On Fri, Mar 11, 2022 at 12:08:52AM +0100, Linus Walleij wrote:

On Sun, Feb 27, 2022 at 2:48 PM Lecopzer Chen
[off-list ref] wrote:

quoted

Since the framework of KASAN_VMALLOC is well-developed,
It's easy to support for ARM that simply not to map shadow of VMALLOC
area on kasan_init.

Since the virtual address of vmalloc for Arm is also between
MODULE_VADDR and 0x100000000 (ZONE_HIGHMEM), which means the shadow
address has already included between KASAN_SHADOW_START and
KASAN_SHADOW_END.
Thus we need to change nothing for memory map of Arm.

This can fix ARM_MODULE_PLTS with KASan, support KASan for higmem
and provide the first step to support CONFIG_VMAP_STACK with Arm.


Test on
1. Qemu with memory 2G and vmalloc=500M for 3G/1G mapping.
2. Qemu with memory 2G and vmalloc=500M for 3G/1G mapping + LPAE.
3. Qemu with memory 2G and vmalloc=500M for 2G/2G mapping.

v3:
    rebase on 5.17-rc5.
    Add simple doc for "arm: kasan: support CONFIG_KASAN_VMALLOC"
    Tweak commit message.

Ater testing this with my kernel-in-vmalloc patches and some hacks, I got
the kernel booting in the VMALLOC area with KASan enabled!
See:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kernel-in-vmalloc-v5.17-rc1

That's a pretty serious stress test. So:
Tested-by: Linus Walleij <redacted>
Reviewed-by: Linus Walleij <redacted>
for the series.

I suppose you could put this into Russell's patch tracker, it's gonna be
for kernel v5.19 by now but why stress. It seems I can fix up
kernel-in-vmalloc on top and submit that for v5.19 as well.

Ard's series already adds vmap stack support (which we've been doing
some last minute panic-debugging on to get it ready for this merge
window), but the above description makes it sound like this series is
a pre-requisit for that.

Is it? Will Ard's work cause further regressions because this series
isn't merged.

Please clarify - and urgently, there is not much time left before the
merge window opens.

-- 
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

On Sun, Feb 27, 2022 at 09:47:25PM +0800, Lecopzer Chen wrote:

quoted

Simply make shadow of vmalloc area mapped on demand.

Since the virtual address of vmalloc for Arm is also between
MODULE_VADDR and 0x100000000 (ZONE_HIGHMEM), which means the shadow
address has already included between KASAN_SHADOW_START and
KASAN_SHADOW_END.
Thus we need to change nothing for memory map of Arm.

This can fix ARM_MODULE_PLTS with KASan, support KASan for higmem
and provide the first step to support CONFIG_VMAP_STACK with Arm.

Signed-off-by: Lecopzer Chen <redacted>
---
 arch/arm/Kconfig                 |  1 +
 arch/arm/include/asm/kasan_def.h | 11 ++++++++++-
 arch/arm/mm/kasan_init.c         |  6 +++++-
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4c97cb40eebb..78250e246cc6 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig

@@ -72,6 +72,7 @@ config ARM
 	select HAVE_ARCH_KFENCE if MMU && !XIP_KERNEL
 	select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
 	select HAVE_ARCH_KASAN if MMU && !XIP_KERNEL
+	select HAVE_ARCH_KASAN_VMALLOC if HAVE_ARCH_KASAN
 	select HAVE_ARCH_MMAP_RND_BITS if MMU
 	select HAVE_ARCH_PFN_VALID
 	select HAVE_ARCH_SECCOMP

diff --git a/arch/arm/include/asm/kasan_def.h b/arch/arm/include/asm/kasan_def.h
index 5739605aa7cf..96fd1d3b5a0c 100644
--- a/arch/arm/include/asm/kasan_def.h
+++ b/arch/arm/include/asm/kasan_def.h

@@ -19,7 +19,16 @@
  * space to use as shadow memory for KASan as follows:
  *
  * +----+ 0xffffffff
- * |    |							\

12 more quoted lines

 Ok, should I send a v4 to remove this?



BRs,
Lecopzer

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

On Fri, Mar 11, 2022 at 12:08:52AM +0100, Linus Walleij wrote:

quoted

On Sun, Feb 27, 2022 at 2:48 PM Lecopzer Chen
[off-list ref] wrote:

quoted

Since the framework of KASAN_VMALLOC is well-developed,
It's easy to support for ARM that simply not to map shadow of VMALLOC
area on kasan_init.

Since the virtual address of vmalloc for Arm is also between
MODULE_VADDR and 0x100000000 (ZONE_HIGHMEM), which means the shadow
address has already included between KASAN_SHADOW_START and
KASAN_SHADOW_END.
Thus we need to change nothing for memory map of Arm.

This can fix ARM_MODULE_PLTS with KASan, support KASan for higmem
and provide the first step to support CONFIG_VMAP_STACK with Arm.


Test on
1. Qemu with memory 2G and vmalloc=500M for 3G/1G mapping.
2. Qemu with memory 2G and vmalloc=500M for 3G/1G mapping + LPAE.
3. Qemu with memory 2G and vmalloc=500M for 2G/2G mapping.

v3:
    rebase on 5.17-rc5.
    Add simple doc for "arm: kasan: support CONFIG_KASAN_VMALLOC"
    Tweak commit message.

Ater testing this with my kernel-in-vmalloc patches and some hacks, I got
the kernel booting in the VMALLOC area with KASan enabled!
See:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=kernel-in-vmalloc-v5.17-rc1

That's a pretty serious stress test. So:
Tested-by: Linus Walleij <redacted>
Reviewed-by: Linus Walleij <redacted>
for the series.

I suppose you could put this into Russell's patch tracker, it's gonna be
for kernel v5.19 by now but why stress. It seems I can fix up

13 more quoted lines

Sorry I didn't describe it clearly,

config VMAP_STACK
  default y
  bool "Use a virtually-mapped stack"
  depends on HAVE_ARCH_VMAP_STACK
  depends on !KASAN || KASAN_HW_TAGS || KASAN_VMALLOC

This means KASAN can support with VMAP_STACK=y



BRs,
Lecopzer

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