arm64: kasan: support CONFIG_KASAN_VMALLOC

Linux support KAsan for VMALLOC since commit 3c5c3cfb9ef4da9 ("kasan: support backing vmalloc space with real shadow memory")

Like how the MODULES_VADDR does now, just not to early populate the VMALLOC_START between VMALLOC_END.
similarly, the kernel code mapping is now in the VMALLOC area and should keep these area populated.

Signed-off-by Lecopzer Chen <[email protected]>

---
 arch/arm64/mm/kasan_init.c | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

arch/arm64/mm/kasan_init.c +1 -0

index d8e66c78440e..39b218a64279 100644
@@ -214,6 +214,7 @@ static void __init kasan_init_shadow(void)
 {
        u64 kimg_shadow_start, kimg_shadow_end;
        u64 mod_shadow_start, mod_shadow_end;
+       u64 vmalloc_shadow_start, vmalloc_shadow_end;
        phys_addr_t pa_start, pa_end;
        u64 i;
 

arch/arm64/mm/kasan_init.c +14 -6

        /*
         * We are going to perform proper setup of shadow memory.
         * At first we should unmap early shadow (clear_pgds() call below).

@@ -241,12 +245,21 @@ static void __init kasan_init_shadow(void)
 
        kasan_populate_early_shadow(kasan_mem_to_shadow((void *)PAGE_END),
                                   (void *)mod_shadow_start);
-       kasan_populate_early_shadow((void *)kimg_shadow_end,
-                                  (void *)KASAN_SHADOW_END);
+       if (IS_ENABLED(CONFIG_KASAN_VMALLOC)) {
+               kasan_populate_early_shadow((void *)vmalloc_shadow_end,
+                                           (void *)KASAN_SHADOW_END);
+               if (vmalloc_shadow_start > mod_shadow_end)
+                       kasan_populate_early_shadow((void *)mod_shadow_end,
+                                                   (void *)vmalloc_shadow_start);
+
+       } else {
+               kasan_populate_early_shadow((void *)kimg_shadow_end,
+                                           (void *)KASAN_SHADOW_END);
+               if (kimg_shadow_start > mod_shadow_end)
+                       kasan_populate_early_shadow((void *)mod_shadow_end,
+                                                   (void *)kimg_shadow_start);
+       }
 
-       if (kimg_shadow_start > mod_shadow_end)
-               kasan_populate_early_shadow((void *)mod_shadow_end,
-                                           (void *)kimg_shadow_start);
 
        for_each_mem_range(i, &pa_start, &pa_end) {
                void *start = (void *)__phys_to_virt(pa_start);
--

2.25.1

Quoted 9 lines

Linux support KAsan for VMALLOC since commit 3c5c3cfb9ef4da9 ("kasan: support backing vmalloc space with real shadow memory")

Like how the MODULES_VADDR does now, just not to early populate the VMALLOC_START between VMALLOC_END.
similarly, the kernel code mapping is now in the VMALLOC area and should keep these area populated.

Quoted 1 line

Signed-off-by Lecopzer Chen <[email protected]>

This commit log text is a bit hard to follow. You are saying that the vmalloc region is *not* backed with zero shadow or any default mapping at all, right, and everything gets allocated on demand, just like is the case for modules?

Linux support KAsan for VMALLOC since commit 3c5c3cfb9ef4da9 ("kasan: support backing vmalloc space with real shadow memory")

Like how the MODULES_VADDR does now, just not to early populate the VMALLOC_START between VMALLOC_END.
similarly, the kernel code mapping is now in the VMALLOC area and should keep these area populated.

Signed-off-by Lecopzer Chen <[email protected]>

---
 arch/arm64/mm/kasan_init.c | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

arch/arm64/mm/kasan_init.c +4 -0

index d8e66c78440e..39b218a64279 100644
@@ -214,6 +214,7 @@ static void __init kasan_init_shadow(void)
 {
 	u64 kimg_shadow_start, kimg_shadow_end;
 	u64 mod_shadow_start, mod_shadow_end;
+	u64 vmalloc_shadow_start, vmalloc_shadow_end;
 	phys_addr_t pa_start, pa_end;
 	u64 i;
 

@@ -223,6 +224,9 @@ static void __init kasan_init_shadow(void)
 	mod_shadow_start = (u64)kasan_mem_to_shadow((void *)MODULES_VADDR);
 	mod_shadow_end = (u64)kasan_mem_to_shadow((void *)MODULES_END);
 
+	vmalloc_shadow_start = (u64)kasan_mem_to_shadow((void *)VMALLOC_START);
+	vmalloc_shadow_end = (u64)kasan_mem_to_shadow((void *)VMALLOC_END);
+
 	/*
 	 * We are going to perform proper setup of shadow memory.
 	 * At first we should unmap early shadow (clear_pgds() call below).

Quoted 37 lines

Linux support KAsan for VMALLOC since commit 3c5c3cfb9ef4da9 ("kasan: support backing vmalloc space with real shadow memory")

Like how the MODULES_VADDR does now, just not to early populate the VMALLOC_START between VMALLOC_END.
similarly, the kernel code mapping is now in the VMALLOC area and should keep these area populated.

Signed-off-by Lecopzer Chen <[email protected]>

---
 arch/arm64/mm/kasan_init.c | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

arch/arm64/mm/kasan_init.c +4 -0

index d8e66c78440e..39b218a64279 100644
@@ -214,6 +214,7 @@ static void __init kasan_init_shadow(void)
 {
 	u64 kimg_shadow_start, kimg_shadow_end;
 	u64 mod_shadow_start, mod_shadow_end;
+	u64 vmalloc_shadow_start, vmalloc_shadow_end;
 	phys_addr_t pa_start, pa_end;
 	u64 i;
 

@@ -223,6 +224,9 @@ static void __init kasan_init_shadow(void)
 	mod_shadow_start = (u64)kasan_mem_to_shadow((void *)MODULES_VADDR);
 	mod_shadow_end = (u64)kasan_mem_to_shadow((void *)MODULES_END);
 
+	vmalloc_shadow_start = (u64)kasan_mem_to_shadow((void *)VMALLOC_START);
+	vmalloc_shadow_end = (u64)kasan_mem_to_shadow((void *)VMALLOC_END);
+
 	/*
 	 * We are going to perform proper setup of shadow memory.
 	 * At first we should unmap early shadow (clear_pgds() call below).

@@ -241,12 +245,21 @@ static void __init kasan_init_shadow(void)
 

arch/arm64/mm/kasan_init.c static void __init kasan_init_shadow(void) · line 248

Quoted 5 lines

arch/arm64/mm/kasan_init.c +1 -2

 	kasan_populate_early_shadow(kasan_mem_to_shadow((void *)PAGE_END),
 				   (void *)mod_shadow_start);
-	kasan_populate_early_shadow((void *)kimg_shadow_end,
-				   (void *)KASAN_SHADOW_END);
+	if (IS_ENABLED(CONFIG_KASAN_VMALLOC)) {

Do we really need yet another CONFIG option for KASAN? What's the use-case for *not* enabling this if you're already enabling one of the KASAN backends?

arch/arm64/mm/kasan_init.c static void __init kasan_init_shadow(void) · line 251

Quoted 3 lines

arch/arm64/mm/kasan_init.c +3 -0

+		kasan_populate_early_shadow((void *)vmalloc_shadow_end,
+					    (void *)KASAN_SHADOW_END);
+		if (vmalloc_shadow_start > mod_shadow_end)

To echo Ard's concern: when is the above 'if' condition true?

Quoted 38 lines · Lecopzer Chen

Quoted 37 lines

Linux support KAsan for VMALLOC since commit 3c5c3cfb9ef4da9 ("kasan: support backing vmalloc space with real shadow memory")

Like how the MODULES_VADDR does now, just not to early populate the VMALLOC_START between VMALLOC_END.
similarly, the kernel code mapping is now in the VMALLOC area and should keep these area populated.

Signed-off-by Lecopzer Chen <[email protected]>

---
 arch/arm64/mm/kasan_init.c | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

arch/arm64/mm/kasan_init.c +4 -0

index d8e66c78440e..39b218a64279 100644
@@ -214,6 +214,7 @@ static void __init kasan_init_shadow(void)
 {
 	u64 kimg_shadow_start, kimg_shadow_end;
 	u64 mod_shadow_start, mod_shadow_end;
+	u64 vmalloc_shadow_start, vmalloc_shadow_end;
 	phys_addr_t pa_start, pa_end;
 	u64 i;
 

@@ -223,6 +224,9 @@ static void __init kasan_init_shadow(void)
 	mod_shadow_start = (u64)kasan_mem_to_shadow((void *)MODULES_VADDR);
 	mod_shadow_end = (u64)kasan_mem_to_shadow((void *)MODULES_END);
 
+	vmalloc_shadow_start = (u64)kasan_mem_to_shadow((void *)VMALLOC_START);
+	vmalloc_shadow_end = (u64)kasan_mem_to_shadow((void *)VMALLOC_END);
+
 	/*
 	 * We are going to perform proper setup of shadow memory.
 	 * At first we should unmap early shadow (clear_pgds() call below).

@@ -241,12 +245,21 @@ static void __init kasan_init_shadow(void)
 

Quoted 9 lines

arch/arm64/mm/kasan_init.c static void __init kasan_init_shadow(void) · line 248

Quoted 5 lines

arch/arm64/mm/kasan_init.c +1 -2

 	kasan_populate_early_shadow(kasan_mem_to_shadow((void *)PAGE_END),
 				   (void *)mod_shadow_start);
-	kasan_populate_early_shadow((void *)kimg_shadow_end,
-				   (void *)KASAN_SHADOW_END);
+	if (IS_ENABLED(CONFIG_KASAN_VMALLOC)) {

Do we really need yet another CONFIG option for KASAN? What's the use-case for *not* enabling this if you're already enabling one of the KASAN backends?

As I know, KASAN_VMALLOC now only supports KASAN_GENERIC and also KASAN_VMALLOC uses more memory to map real shadow memory (1/8 of vmalloc va).

There should be someone can enable KASAN_GENERIC but can't use VMALLOC due to memory issue.

Quoted 48 lines

Quoted 47 lines · Lecopzer Chen

Quoted 36 lines

Linux support KAsan for VMALLOC since commit 3c5c3cfb9ef4da9 ("kasan: support backing vmalloc space with real shadow memory")

Like how the MODULES_VADDR does now, just not to early populate the VMALLOC_START between VMALLOC_END.
similarly, the kernel code mapping is now in the VMALLOC area and should keep these area populated.

Signed-off-by Lecopzer Chen <[email protected]>

---
 arch/arm64/mm/kasan_init.c | 23 ++++++++++++++++++-----

 1 file changed, 18 insertions(+), 5 deletions(-)

arch/arm64/mm/kasan_init.c +4 -0

index d8e66c78440e..39b218a64279 100644
@@ -214,6 +214,7 @@ static void __init kasan_init_shadow(void)
  {
   u64 kimg_shadow_start, kimg_shadow_end;
   u64 mod_shadow_start, mod_shadow_end;
+ u64 vmalloc_shadow_start, vmalloc_shadow_end;
   phys_addr_t pa_start, pa_end;
   u64 i;
 

@@ -223,6 +224,9 @@ static void __init kasan_init_shadow(void)
   mod_shadow_start = (u64)kasan_mem_to_shadow((void *)MODULES_VADDR);
   mod_shadow_end = (u64)kasan_mem_to_shadow((void *)MODULES_END);
 
+ vmalloc_shadow_start = (u64)kasan_mem_to_shadow((void *)VMALLOC_START);
+ vmalloc_shadow_end = (u64)kasan_mem_to_shadow((void *)VMALLOC_END);
+
   /*
    * We are going to perform proper setup of shadow memory.
    * At first we should unmap early shadow (clear_pgds() call below).

arch/arm64/mm/kasan_init.c static void __init kasan_init_shadow(void) · line 248

Quoted 6 lines

arch/arm64/mm/kasan_init.c +1 -2

@@ -241,12 +245,21 @@ static void __init kasan_init_shadow(void)
 
   kasan_populate_early_shadow(kasan_mem_to_shadow((void *)PAGE_END),
                              (void *)mod_shadow_start);
- kasan_populate_early_shadow((void *)kimg_shadow_end,
-                            (void *)KASAN_SHADOW_END);
+ if (IS_ENABLED(CONFIG_KASAN_VMALLOC)) {

Do we really need yet another CONFIG option for KASAN? What's the use-case for *not* enabling this if you're already enabling one of the KASAN backends?

Quoted 2 lines

As I know, KASAN_VMALLOC now only supports KASAN_GENERIC and also KASAN_VMALLOC uses more memory to map real shadow memory (1/8 of vmalloc va).

The shadow is allocated dynamically though, isn't it?

Quoted 2 lines

There should be someone can enable KASAN_GENERIC but can't use VMALLOC due to memory issue.

That doesn't sound particularly realistic to me. The reason I'm pushing here is because I would _really_ like to move to VMAP stack unconditionally, and that would effectively force KASAN_VMALLOC to be set if KASAN is in use.

So unless there's a really good reason not to do that, please can we make this unconditional for arm64? Pretty please?

Quoted 50 lines · Lecopzer Chen

Quoted 48 lines

Quoted 47 lines · Lecopzer Chen

Quoted 36 lines

Linux support KAsan for VMALLOC since commit 3c5c3cfb9ef4da9 ("kasan: support backing vmalloc space with real shadow memory")

Like how the MODULES_VADDR does now, just not to early populate the VMALLOC_START between VMALLOC_END.
similarly, the kernel code mapping is now in the VMALLOC area and should keep these area populated.

Signed-off-by Lecopzer Chen <[email protected]>

---
 arch/arm64/mm/kasan_init.c | 23 ++++++++++++++++++-----

 1 file changed, 18 insertions(+), 5 deletions(-)

arch/arm64/mm/kasan_init.c +4 -0

index d8e66c78440e..39b218a64279 100644
@@ -214,6 +214,7 @@ static void __init kasan_init_shadow(void)
  {
   u64 kimg_shadow_start, kimg_shadow_end;
   u64 mod_shadow_start, mod_shadow_end;
+ u64 vmalloc_shadow_start, vmalloc_shadow_end;
   phys_addr_t pa_start, pa_end;
   u64 i;
 

@@ -223,6 +224,9 @@ static void __init kasan_init_shadow(void)
   mod_shadow_start = (u64)kasan_mem_to_shadow((void *)MODULES_VADDR);
   mod_shadow_end = (u64)kasan_mem_to_shadow((void *)MODULES_END);
 
+ vmalloc_shadow_start = (u64)kasan_mem_to_shadow((void *)VMALLOC_START);
+ vmalloc_shadow_end = (u64)kasan_mem_to_shadow((void *)VMALLOC_END);
+
   /*
    * We are going to perform proper setup of shadow memory.
    * At first we should unmap early shadow (clear_pgds() call below).

arch/arm64/mm/kasan_init.c static void __init kasan_init_shadow(void) · line 248

Quoted 6 lines

arch/arm64/mm/kasan_init.c +1 -2

@@ -241,12 +245,21 @@ static void __init kasan_init_shadow(void)
 
   kasan_populate_early_shadow(kasan_mem_to_shadow((void *)PAGE_END),
                              (void *)mod_shadow_start);
- kasan_populate_early_shadow((void *)kimg_shadow_end,
-                            (void *)KASAN_SHADOW_END);
+ if (IS_ENABLED(CONFIG_KASAN_VMALLOC)) {

Do we really need yet another CONFIG option for KASAN? What's the use-case for *not* enabling this if you're already enabling one of the KASAN backends?

Quoted 4 lines

Quoted 2 lines

As I know, KASAN_VMALLOC now only supports KASAN_GENERIC and also KASAN_VMALLOC uses more memory to map real shadow memory (1/8 of vmalloc va).

The shadow is allocated dynamically though, isn't it?

Yes, but It's still a cost.

Quoted 9 lines

Quoted 2 lines

There should be someone can enable KASAN_GENERIC but can't use VMALLOC due to memory issue.

That doesn't sound particularly realistic to me. The reason I'm pushing here is because I would _really_ like to move to VMAP stack unconditionally, and that would effectively force KASAN_VMALLOC to be set if KASAN is in use.

So unless there's a really good reason not to do that, please can we make this unconditional for arm64? Pretty please?

I think it's fine since we have a good reason. Also if someone have memory issue in KASAN_VMALLOC, they can use SW_TAG, right?

However the SW_TAG/HW_TAG is not supported VMALLOC yet. So the code would be like

if (IS_ENABLED(CONFIG_KASAN_GENERIC))

		/* explain the relationship between 
		 * KASAN_GENERIC and KASAN_VMALLOC in arm64
		 * XXX: because we want VMAP stack....
		 */

Quoted 67 lines · Lecopzer Chen

Quoted 50 lines · Lecopzer Chen

Quoted 48 lines

Quoted 47 lines · Lecopzer Chen

Quoted 36 lines

Linux support KAsan for VMALLOC since commit 3c5c3cfb9ef4da9 ("kasan: support backing vmalloc space with real shadow memory")

Like how the MODULES_VADDR does now, just not to early populate the VMALLOC_START between VMALLOC_END.
similarly, the kernel code mapping is now in the VMALLOC area and should keep these area populated.

Signed-off-by Lecopzer Chen <[email protected]>

---
 arch/arm64/mm/kasan_init.c | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

arch/arm64/mm/kasan_init.c +4 -0

index d8e66c78440e..39b218a64279 100644
@@ -214,6 +214,7 @@ static void __init kasan_init_shadow(void)
 {
  u64 kimg_shadow_start, kimg_shadow_end;
  u64 mod_shadow_start, mod_shadow_end;
+ u64 vmalloc_shadow_start, vmalloc_shadow_end;
  phys_addr_t pa_start, pa_end;
  u64 i;
 

@@ -223,6 +224,9 @@ static void __init kasan_init_shadow(void)
  mod_shadow_start = (u64)kasan_mem_to_shadow((void *)MODULES_VADDR);
  mod_shadow_end = (u64)kasan_mem_to_shadow((void *)MODULES_END);
 
+ vmalloc_shadow_start = (u64)kasan_mem_to_shadow((void *)VMALLOC_START);
+ vmalloc_shadow_end = (u64)kasan_mem_to_shadow((void *)VMALLOC_END);
+
  /*
   * We are going to perform proper setup of shadow memory.
   * At first we should unmap early shadow (clear_pgds() call below).

arch/arm64/mm/kasan_init.c static void __init kasan_init_shadow(void) · line 248

Quoted 6 lines

arch/arm64/mm/kasan_init.c +1 -2

@@ -241,12 +245,21 @@ static void __init kasan_init_shadow(void)
 
  kasan_populate_early_shadow(kasan_mem_to_shadow((void *)PAGE_END),
                             (void *)mod_shadow_start);
- kasan_populate_early_shadow((void *)kimg_shadow_end,
-                            (void *)KASAN_SHADOW_END);
+ if (IS_ENABLED(CONFIG_KASAN_VMALLOC)) {

Do we really need yet another CONFIG option for KASAN? What's the use-case for *not* enabling this if you're already enabling one of the KASAN backends?

Quoted 4 lines

Quoted 2 lines

As I know, KASAN_VMALLOC now only supports KASAN_GENERIC and also KASAN_VMALLOC uses more memory to map real shadow memory (1/8 of vmalloc va).

The shadow is allocated dynamically though, isn't it?

Yes, but It's still a cost.

Quoted 9 lines

Quoted 2 lines

There should be someone can enable KASAN_GENERIC but can't use VMALLOC due to memory issue.

That doesn't sound particularly realistic to me. The reason I'm pushing here is because I would _really_ like to move to VMAP stack unconditionally, and that would effectively force KASAN_VMALLOC to be set if KASAN is in use.

So unless there's a really good reason not to do that, please can we make this unconditional for arm64? Pretty please?

Quoted 8 lines

I think it's fine since we have a good reason. Also if someone have memory issue in KASAN_VMALLOC, they can use SW_TAG, right?

However the SW_TAG/HW_TAG is not supported VMALLOC yet. So the code would be like

if (IS_ENABLED(CONFIG_KASAN_GENERIC))

Just make this CONFIG_KASAN_VMALLOC, since that depends on KASAN_GENERIC.

Quoted 4 lines

/* explain the relationship between
* KASAN_GENERIC and KASAN_VMALLOC in arm64
* XXX: because we want VMAP stack.... */

I don't understand the relation with SW_TAGS. The VMAP_STACK dependency is:

        depends on !KASAN || KASAN_HW_TAGS || KASAN_VMALLOC

which doesn't mention SW_TAGS at all. So that seems to imply that SW_TAGS and VMAP_STACK are mutually exclusive :(

Quoted 80 lines · Will Deacon

Quoted 67 lines · Lecopzer Chen

Quoted 50 lines · Lecopzer Chen

Quoted 48 lines

Quoted 47 lines · Lecopzer Chen

Quoted 36 lines

Linux support KAsan for VMALLOC since commit 3c5c3cfb9ef4da9 ("kasan: support backing vmalloc space with real shadow memory")

Like how the MODULES_VADDR does now, just not to early populate the VMALLOC_START between VMALLOC_END.
similarly, the kernel code mapping is now in the VMALLOC area and should keep these area populated.

Signed-off-by Lecopzer Chen <[email protected]>

---
 arch/arm64/mm/kasan_init.c | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

arch/arm64/mm/kasan_init.c +4 -0

index d8e66c78440e..39b218a64279 100644
@@ -214,6 +214,7 @@ static void __init kasan_init_shadow(void)
 {
  u64 kimg_shadow_start, kimg_shadow_end;
  u64 mod_shadow_start, mod_shadow_end;
+ u64 vmalloc_shadow_start, vmalloc_shadow_end;
  phys_addr_t pa_start, pa_end;
  u64 i;
 

@@ -223,6 +224,9 @@ static void __init kasan_init_shadow(void)
  mod_shadow_start = (u64)kasan_mem_to_shadow((void *)MODULES_VADDR);
  mod_shadow_end = (u64)kasan_mem_to_shadow((void *)MODULES_END);
 
+ vmalloc_shadow_start = (u64)kasan_mem_to_shadow((void *)VMALLOC_START);
+ vmalloc_shadow_end = (u64)kasan_mem_to_shadow((void *)VMALLOC_END);
+
  /*
   * We are going to perform proper setup of shadow memory.
   * At first we should unmap early shadow (clear_pgds() call below).

arch/arm64/mm/kasan_init.c static void __init kasan_init_shadow(void) · line 248

Quoted 6 lines

arch/arm64/mm/kasan_init.c +1 -2

@@ -241,12 +245,21 @@ static void __init kasan_init_shadow(void)
 
  kasan_populate_early_shadow(kasan_mem_to_shadow((void *)PAGE_END),
                             (void *)mod_shadow_start);
- kasan_populate_early_shadow((void *)kimg_shadow_end,
-                            (void *)KASAN_SHADOW_END);
+ if (IS_ENABLED(CONFIG_KASAN_VMALLOC)) {

Do we really need yet another CONFIG option for KASAN? What's the use-case for *not* enabling this if you're already enabling one of the KASAN backends?

Quoted 4 lines

Quoted 2 lines

As I know, KASAN_VMALLOC now only supports KASAN_GENERIC and also KASAN_VMALLOC uses more memory to map real shadow memory (1/8 of vmalloc va).

The shadow is allocated dynamically though, isn't it?

Yes, but It's still a cost.

Quoted 9 lines

Quoted 2 lines

There should be someone can enable KASAN_GENERIC but can't use VMALLOC due to memory issue.

That doesn't sound particularly realistic to me. The reason I'm pushing here is because I would _really_ like to move to VMAP stack unconditionally, and that would effectively force KASAN_VMALLOC to be set if KASAN is in use.

So unless there's a really good reason not to do that, please can we make this unconditional for arm64? Pretty please?

Quoted 8 lines

I think it's fine since we have a good reason. Also if someone have memory issue in KASAN_VMALLOC, they can use SW_TAG, right?

However the SW_TAG/HW_TAG is not supported VMALLOC yet. So the code would be like

if (IS_ENABLED(CONFIG_KASAN_GENERIC))

Just make this CONFIG_KASAN_VMALLOC, since that depends on KASAN_GENERIC.

Quoted 8 lines

Quoted 4 lines

/* explain the relationship between
* KASAN_GENERIC and KASAN_VMALLOC in arm64
* XXX: because we want VMAP stack.... */

I don't understand the relation with SW_TAGS. The VMAP_STACK dependency is:

        depends on !KASAN || KASAN_HW_TAGS || KASAN_VMALLOC

This means that VMAP_STACK can be only enabled if KASAN_HW_TAGS=y or if KASAN_VMALLOC=y for other modes.

Quoted 1 line

Quoted 2 lines

which doesn't mention SW_TAGS at all. So that seems to imply that SW_TAGS and VMAP_STACK are mutually exclusive :(

SW_TAGS doesn't yet have vmalloc support, so it's not compatible with VMAP_STACK. Once vmalloc support is added to SW_TAGS, KASAN_VMALLOC should be allowed to be enabled with SW_TAGS. This series is a step towards having that support, but doesn't implement it. That will be a separate effort.

Quoted 94 lines · Andrey Konovalov

Quoted 80 lines · Will Deacon

Quoted 67 lines · Lecopzer Chen

Quoted 50 lines · Lecopzer Chen

Quoted 48 lines

Quoted 47 lines · Lecopzer Chen

Quoted 36 lines

Linux support KAsan for VMALLOC since commit 3c5c3cfb9ef4da9 ("kasan: support backing vmalloc space with real shadow memory")

Like how the MODULES_VADDR does now, just not to early populate the VMALLOC_START between VMALLOC_END.
similarly, the kernel code mapping is now in the VMALLOC area and should keep these area populated.

Signed-off-by Lecopzer Chen <[email protected]>

---
 arch/arm64/mm/kasan_init.c | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

arch/arm64/mm/kasan_init.c +4 -0

index d8e66c78440e..39b218a64279 100644
@@ -214,6 +214,7 @@ static void __init kasan_init_shadow(void)
 {
  u64 kimg_shadow_start, kimg_shadow_end;
  u64 mod_shadow_start, mod_shadow_end;
+ u64 vmalloc_shadow_start, vmalloc_shadow_end;
  phys_addr_t pa_start, pa_end;
  u64 i;
 

@@ -223,6 +224,9 @@ static void __init kasan_init_shadow(void)
  mod_shadow_start = (u64)kasan_mem_to_shadow((void *)MODULES_VADDR);
  mod_shadow_end = (u64)kasan_mem_to_shadow((void *)MODULES_END);
 
+ vmalloc_shadow_start = (u64)kasan_mem_to_shadow((void *)VMALLOC_START);
+ vmalloc_shadow_end = (u64)kasan_mem_to_shadow((void *)VMALLOC_END);
+
  /*
   * We are going to perform proper setup of shadow memory.
   * At first we should unmap early shadow (clear_pgds() call below).

arch/arm64/mm/kasan_init.c static void __init kasan_init_shadow(void) · line 248

Quoted 6 lines

arch/arm64/mm/kasan_init.c +1 -2

@@ -241,12 +245,21 @@ static void __init kasan_init_shadow(void)
 
  kasan_populate_early_shadow(kasan_mem_to_shadow((void *)PAGE_END),
                             (void *)mod_shadow_start);
- kasan_populate_early_shadow((void *)kimg_shadow_end,
-                            (void *)KASAN_SHADOW_END);
+ if (IS_ENABLED(CONFIG_KASAN_VMALLOC)) {

Do we really need yet another CONFIG option for KASAN? What's the use-case for *not* enabling this if you're already enabling one of the KASAN backends?

Quoted 4 lines

Quoted 2 lines

As I know, KASAN_VMALLOC now only supports KASAN_GENERIC and also KASAN_VMALLOC uses more memory to map real shadow memory (1/8 of vmalloc va).

The shadow is allocated dynamically though, isn't it?

Yes, but It's still a cost.

Quoted 9 lines

Quoted 2 lines

There should be someone can enable KASAN_GENERIC but can't use VMALLOC due to memory issue.

That doesn't sound particularly realistic to me. The reason I'm pushing here is because I would _really_ like to move to VMAP stack unconditionally, and that would effectively force KASAN_VMALLOC to be set if KASAN is in use.

So unless there's a really good reason not to do that, please can we make this unconditional for arm64? Pretty please?

Quoted 8 lines

I think it's fine since we have a good reason. Also if someone have memory issue in KASAN_VMALLOC, they can use SW_TAG, right?

However the SW_TAG/HW_TAG is not supported VMALLOC yet. So the code would be like

if (IS_ENABLED(CONFIG_KASAN_GENERIC))

Just make this CONFIG_KASAN_VMALLOC, since that depends on KASAN_GENERIC.

Quoted 8 lines

Quoted 4 lines

/* explain the relationship between
* KASAN_GENERIC and KASAN_VMALLOC in arm64
* XXX: because we want VMAP stack.... */

I don't understand the relation with SW_TAGS. The VMAP_STACK dependency is:

        depends on !KASAN || KASAN_HW_TAGS || KASAN_VMALLOC

This means that VMAP_STACK can be only enabled if KASAN_HW_TAGS=y or if KASAN_VMALLOC=y for other modes.

Quoted 1 line

Quoted 8 lines

Quoted 2 lines

which doesn't mention SW_TAGS at all. So that seems to imply that SW_TAGS and VMAP_STACK are mutually exclusive :(

SW_TAGS doesn't yet have vmalloc support, so it's not compatible with VMAP_STACK. Once vmalloc support is added to SW_TAGS, KASAN_VMALLOC should be allowed to be enabled with SW_TAGS. This series is a step towards having that support, but doesn't implement it. That will be a separate effort.

Ok, thanks. Then I think we should try to invert the dependency here, if possible, so that the KASAN backends depend on !VMAP_STACK if they don't support it, rather than silently disabling VMAP_STACK when they are selected.

Quoted 71 lines

Quoted 49 lines · Lecopzer Chen

Quoted 47 lines

Quoted 47 lines · Lecopzer Chen

Quoted 36 lines

Linux support KAsan for VMALLOC since commit 3c5c3cfb9ef4da9 ("kasan: support backing vmalloc space with real shadow memory")

Like how the MODULES_VADDR does now, just not to early populate the VMALLOC_START between VMALLOC_END.
similarly, the kernel code mapping is now in the VMALLOC area and should keep these area populated.

Signed-off-by Lecopzer Chen <[email protected]>

---
 arch/arm64/mm/kasan_init.c | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

arch/arm64/mm/kasan_init.c +4 -0

index d8e66c78440e..39b218a64279 100644
@@ -214,6 +214,7 @@ static void __init kasan_init_shadow(void)
 {
  u64 kimg_shadow_start, kimg_shadow_end;
  u64 mod_shadow_start, mod_shadow_end;
+ u64 vmalloc_shadow_start, vmalloc_shadow_end;
  phys_addr_t pa_start, pa_end;
  u64 i;
 

@@ -223,6 +224,9 @@ static void __init kasan_init_shadow(void)
  mod_shadow_start = (u64)kasan_mem_to_shadow((void *)MODULES_VADDR);
  mod_shadow_end = (u64)kasan_mem_to_shadow((void *)MODULES_END);
 
+ vmalloc_shadow_start = (u64)kasan_mem_to_shadow((void *)VMALLOC_START);
+ vmalloc_shadow_end = (u64)kasan_mem_to_shadow((void *)VMALLOC_END);
+
  /*
   * We are going to perform proper setup of shadow memory.
   * At first we should unmap early shadow (clear_pgds() call below).

arch/arm64/mm/kasan_init.c static void __init kasan_init_shadow(void) · line 248

Quoted 6 lines

arch/arm64/mm/kasan_init.c +1 -2

@@ -241,12 +245,21 @@ static void __init kasan_init_shadow(void)
 
  kasan_populate_early_shadow(kasan_mem_to_shadow((void *)PAGE_END),
                             (void *)mod_shadow_start);
- kasan_populate_early_shadow((void *)kimg_shadow_end,
-                            (void *)KASAN_SHADOW_END);
+ if (IS_ENABLED(CONFIG_KASAN_VMALLOC)) {

Do we really need yet another CONFIG option for KASAN? What's the use-case for *not* enabling this if you're already enabling one of the KASAN backends?

Quoted 5 lines

Quoted 3 lines

commit message
As I know, KASAN_VMALLOC now only supports KASAN_GENERIC and also KASAN_VMALLOC uses more memory to map real shadow memory (1/8 of vmalloc va).

The shadow is allocated dynamically though, isn't it?

Yes, but It's still a cost.

Quoted 9 lines

Quoted 2 lines

There should be someone can enable KASAN_GENERIC but can't use VMALLOC due to memory issue.

That doesn't sound particularly realistic to me. The reason I'm pushing here is because I would _really_ like to move to VMAP stack unconditionally, and that would effectively force KASAN_VMALLOC to be set if KASAN is in use.

So unless there's a really good reason not to do that, please can we make this unconditional for arm64? Pretty please?

I think it's fine since we have a good reason. Also if someone have memory issue in KASAN_VMALLOC, they can use SW_TAG, right?

Quoted 4 lines

However the SW_TAG/HW_TAG is not supported VMALLOC yet. So the code would be like

if (IS_ENABLED(CONFIG_KASAN_GENERIC))

Just make this CONFIG_KASAN_VMALLOC, since that depends on KASAN_GENERIC.

Arm64 provide defined macro for KERNEL_START and KERNEL_END, thus replace them by the abstration instead of using _text and _end.

Signed-off-by Lecopzer Chen <[email protected]>

---
 arch/arm64/mm/kasan_init.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

arch/arm64/mm/kasan_init.c +2 -2

index 39b218a64279..fa8d7ece895d 100644
@@ -218,8 +218,8 @@ static void __init kasan_init_shadow(void)
 	phys_addr_t pa_start, pa_end;
 	u64 i;
 
-	kimg_shadow_start = (u64)kasan_mem_to_shadow(_text) & PAGE_MASK;
-	kimg_shadow_end = PAGE_ALIGN((u64)kasan_mem_to_shadow(_end));
+	kimg_shadow_start = (u64)kasan_mem_to_shadow(KERNEL_START) & PAGE_MASK;
+	kimg_shadow_end = PAGE_ALIGN((u64)kasan_mem_to_shadow(KERNEL_END));
 
 	mod_shadow_start = (u64)kasan_mem_to_shadow((void *)MODULES_VADDR);
 	mod_shadow_end = (u64)kasan_mem_to_shadow((void *)MODULES_END);

Quoted 26 lines

Arm64 provide defined macro for KERNEL_START and KERNEL_END, thus replace them by the abstration instead of using _text and _end.

Signed-off-by Lecopzer Chen <[email protected]>

---
 arch/arm64/mm/kasan_init.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

arch/arm64/mm/kasan_init.c +2 -2

index 39b218a64279..fa8d7ece895d 100644
@@ -218,8 +218,8 @@ static void __init kasan_init_shadow(void)
 	phys_addr_t pa_start, pa_end;
 	u64 i;
 
-	kimg_shadow_start = (u64)kasan_mem_to_shadow(_text) & PAGE_MASK;
-	kimg_shadow_end = PAGE_ALIGN((u64)kasan_mem_to_shadow(_end));
+	kimg_shadow_start = (u64)kasan_mem_to_shadow(KERNEL_START) & PAGE_MASK;
+	kimg_shadow_end = PAGE_ALIGN((u64)kasan_mem_to_shadow(KERNEL_END));
 
 	mod_shadow_start = (u64)kasan_mem_to_shadow((void *)MODULES_VADDR);
 	mod_shadow_end = (u64)kasan_mem_to_shadow((void *)MODULES_END);

@@ -241,7 +241,7 @@ static void __init kasan_init_shadow(void)
 	clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);
 

arch/arm64/mm/kasan_init.c static void __init kasan_init_shadow(void) · line 244

Quoted 3 lines

arch/arm64/mm/kasan_init.c +1 -1

 	kasan_map_populate(kimg_shadow_start, kimg_shadow_end,
-			   early_pfn_to_nid(virt_to_pfn(lm_alias(_text))));
+			   early_pfn_to_nid(virt_to_pfn(lm_alias(KERNEL_START))));

To be honest, I think this whole line is pointless. We should be able to pass NUMA_NO_NODE now that we're not abusing the vmemmap() allocator to populate the shadow.

Quoted 27 lines · Lecopzer Chen

Quoted 26 lines

Arm64 provide defined macro for KERNEL_START and KERNEL_END, thus replace them by the abstration instead of using _text and _end.

Signed-off-by Lecopzer Chen <[email protected]>

---
 arch/arm64/mm/kasan_init.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

arch/arm64/mm/kasan_init.c +2 -2

index 39b218a64279..fa8d7ece895d 100644
@@ -218,8 +218,8 @@ static void __init kasan_init_shadow(void)
 	phys_addr_t pa_start, pa_end;
 	u64 i;
 
-	kimg_shadow_start = (u64)kasan_mem_to_shadow(_text) & PAGE_MASK;
-	kimg_shadow_end = PAGE_ALIGN((u64)kasan_mem_to_shadow(_end));
+	kimg_shadow_start = (u64)kasan_mem_to_shadow(KERNEL_START) & PAGE_MASK;
+	kimg_shadow_end = PAGE_ALIGN((u64)kasan_mem_to_shadow(KERNEL_END));
 
 	mod_shadow_start = (u64)kasan_mem_to_shadow((void *)MODULES_VADDR);
 	mod_shadow_end = (u64)kasan_mem_to_shadow((void *)MODULES_END);

@@ -241,7 +241,7 @@ static void __init kasan_init_shadow(void)
 	clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);
 

Quoted 7 lines

arch/arm64/mm/kasan_init.c static void __init kasan_init_shadow(void) · line 244

Quoted 3 lines

arch/arm64/mm/kasan_init.c +1 -1

 	kasan_map_populate(kimg_shadow_start, kimg_shadow_end,
-			   early_pfn_to_nid(virt_to_pfn(lm_alias(_text))));
+			   early_pfn_to_nid(virt_to_pfn(lm_alias(KERNEL_START))));

To be honest, I think this whole line is pointless. We should be able to pass NUMA_NO_NODE now that we're not abusing the vmemmap() allocator to populate the shadow.

Do we need to fix this in this series? it seems another topic. If not, should this patch be removed in this series?

Quoted 35 lines

Quoted 27 lines · Lecopzer Chen

Quoted 26 lines

Arm64 provide defined macro for KERNEL_START and KERNEL_END, thus replace them by the abstration instead of using _text and _end.

Signed-off-by Lecopzer Chen <[email protected]>

---
 arch/arm64/mm/kasan_init.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

arch/arm64/mm/kasan_init.c +2 -2

index 39b218a64279..fa8d7ece895d 100644
@@ -218,8 +218,8 @@ static void __init kasan_init_shadow(void)
  phys_addr_t pa_start, pa_end;
  u64 i;
 
- kimg_shadow_start = (u64)kasan_mem_to_shadow(_text) & PAGE_MASK;
- kimg_shadow_end = PAGE_ALIGN((u64)kasan_mem_to_shadow(_end));
+ kimg_shadow_start = (u64)kasan_mem_to_shadow(KERNEL_START) & PAGE_MASK;
+ kimg_shadow_end = PAGE_ALIGN((u64)kasan_mem_to_shadow(KERNEL_END));
 
  mod_shadow_start = (u64)kasan_mem_to_shadow((void *)MODULES_VADDR);
  mod_shadow_end = (u64)kasan_mem_to_shadow((void *)MODULES_END);

@@ -241,7 +241,7 @@ static void __init kasan_init_shadow(void)
  clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);
 

Quoted 7 lines

arch/arm64/mm/kasan_init.c static void __init kasan_init_shadow(void) · line 244

Quoted 3 lines

arch/arm64/mm/kasan_init.c +1 -1

  kasan_map_populate(kimg_shadow_start, kimg_shadow_end,
-                    early_pfn_to_nid(virt_to_pfn(lm_alias(_text))));
+                    early_pfn_to_nid(virt_to_pfn(lm_alias(KERNEL_START))));

To be honest, I think this whole line is pointless. We should be able to pass NUMA_NO_NODE now that we're not abusing the vmemmap() allocator to populate the shadow.

Quoted 2 lines

Do we need to fix this in this series? it seems another topic. If not, should this patch be removed in this series?

Since you're reposting anyway, you may as well include a patch doing that. If you don't, then I will.

Will

I think it would be better to leave this for you since I'm not familiar with the relationship
between vmemmap() and NUMA_NO_NODE.

So I would just keep this patch in next version, is this fine with you?

After KASAN_VMALLOC works in arm64, we can randomize module region into vmalloc area now.

Test:

	VMALLOC area ffffffc010000000 fffffffdf0000000

	before the patch:
		module_alloc_base/end ffffffc008b80000 ffffffc010000000
	after the patch:
		module_alloc_base/end ffffffdcf4bed000 ffffffc010000000

	And the function that insmod some modules is fine.

Suggested-by Ard Biesheuvel <[email protected]>

Signed-off-by Lecopzer Chen <[email protected]>

---
 arch/arm64/kernel/kaslr.c  | 18 ++++++++++--------
 arch/arm64/kernel/module.c | 16 +++++++++-------
 2 files changed, 19 insertions(+), 15 deletions(-)

arch/arm64/kernel/kaslr.c +0 -0

index 1c74c45b9494..a2858058e724 100644

Quoted 25 lines

After KASAN_VMALLOC works in arm64, we can randomize module region into vmalloc area now.

Test:

	VMALLOC area ffffffc010000000 fffffffdf0000000

	before the patch:
		module_alloc_base/end ffffffc008b80000 ffffffc010000000
	after the patch:
		module_alloc_base/end ffffffdcf4bed000 ffffffc010000000

	And the function that insmod some modules is fine.

Suggested-by Ard Biesheuvel <[email protected]>

Signed-off-by Lecopzer Chen <[email protected]>

---
 arch/arm64/kernel/kaslr.c  | 18 ++++++++++--------
 arch/arm64/kernel/module.c | 16 +++++++++-------
 2 files changed, 19 insertions(+), 15 deletions(-)

arch/arm64/kernel/kaslr.c +0 -0

index 1c74c45b9494..a2858058e724 100644

arch/arm64/kernel/kaslr.c u64 __init kaslr_early_init(u64 dt_phys) · line 165

Quoted 7 lines

arch/arm64/kernel/kaslr.c +2 -2

@@ -161,15 +161,17 @@ u64 __init kaslr_early_init(u64 dt_phys)
 	/* use the top 16 bits to randomize the linear region */
 	memstart_offset_seed = seed >> 48;
 
-	if (IS_ENABLED(CONFIG_KASAN_GENERIC) ||
-	    IS_ENABLED(CONFIG_KASAN_SW_TAGS))
+	if (!IS_ENABLED(CONFIG_KASAN_VMALLOC) &&
+	    (IS_ENABLED(CONFIG_KASAN_GENERIC) ||

CONFIG_KASAN_VMALLOC depends on CONFIG_KASAN_GENERIC so why is this necessary?

Will

Quoted 38 lines · Lecopzer Chen

Quoted 25 lines

After KASAN_VMALLOC works in arm64, we can randomize module region into vmalloc area now.

Test:

	VMALLOC area ffffffc010000000 fffffffdf0000000

	before the patch:
		module_alloc_base/end ffffffc008b80000 ffffffc010000000
	after the patch:
		module_alloc_base/end ffffffdcf4bed000 ffffffc010000000

	And the function that insmod some modules is fine.

Suggested-by Ard Biesheuvel <[email protected]>

Signed-off-by Lecopzer Chen <[email protected]>

---
 arch/arm64/kernel/kaslr.c  | 18 ++++++++++--------
 arch/arm64/kernel/module.c | 16 +++++++++-------
 2 files changed, 19 insertions(+), 15 deletions(-)

arch/arm64/kernel/kaslr.c +0 -0

index 1c74c45b9494..a2858058e724 100644

arch/arm64/kernel/kaslr.c u64 __init kaslr_early_init(u64 dt_phys) · line 165

Quoted 7 lines

arch/arm64/kernel/kaslr.c +2 -2

@@ -161,15 +161,17 @@ u64 __init kaslr_early_init(u64 dt_phys)
 	/* use the top 16 bits to randomize the linear region */
 	memstart_offset_seed = seed >> 48;
 
-	if (IS_ENABLED(CONFIG_KASAN_GENERIC) ||
-	    IS_ENABLED(CONFIG_KASAN_SW_TAGS))
+	if (!IS_ENABLED(CONFIG_KASAN_VMALLOC) &&
+	    (IS_ENABLED(CONFIG_KASAN_GENERIC) ||

CONFIG_KASAN_VMALLOC depends on CONFIG_KASAN_GENERIC so why is this necessary?

Quoted 1 line

Will

CONFIG_KASAN_VMALLOC=y means CONFIG_KASAN_GENERIC=y but CONFIG_KASAN_GENERIC=y doesn't means CONFIG_KASAN_VMALLOC=y

So this if-condition allows only KASAN rather than KASAN + KASAN_VMALLOC enabled.

Please correct me if I'm wrong.

Linux supports KAsan for VMALLOC since commit 3c5c3cfb9ef4da9 ("kasan: support backing vmalloc space with real shadow memory")

Acroding to how x86 ported it [1], they early allocated p4d and pgd, but in arm64 I just simulate how KAsan supports MODULES_VADDR in arm64 by not to populate the vmalloc area except for kimg address.

Test environment:
4G and 8G Qemu virt,
39-bit VA + 4k PAGE_SIZE with 3-level page table, test by lib/test_kasan.ko and lib/test_kasan_module.ko

It also works in Kaslr with CONFIG_RANDOMIZE_MODULE_REGION_FULL and randomize module region inside vmalloc area.

[1]: commit 0609ae011deb41c ("x86/kasan: support KASAN_VMALLOC")

Signed-off-by Lecopzer Chen <[email protected]>

Acked-by Andrey Konovalov <[email protected]>

Tested-by Andrey Konovalov <[email protected]>

v2 -> v1
1. kasan_init.c tweak indent
2. change Kconfig depends only on HAVE_ARCH_KASAN
3. support randomized module region.

v1:
https://lore.kernel.org/lkml/[email protected]/

Lecopzer Chen (4):
arm64: kasan: don't populate vmalloc area for CONFIG_KASAN_VMALLOC
arm64: kasan: abstract _text and _end to KERNEL_START/END
arm64: Kconfig: support CONFIG_KASAN_VMALLOC
arm64: kaslr: support randomized module area with KASAN_VMALLOC

 arch/arm64/Kconfig         |  1 +
 arch/arm64/kernel/kaslr.c  | 18 ++++++++++--------
 arch/arm64/kernel/module.c | 16 +++++++++-------
 arch/arm64/mm/kasan_init.c | 29 +++++++++++++++++++++--------
 4 files changed, 41 insertions(+), 23 deletions(-)

--
2.25.1

Quoted 44 lines · Lecopzer Chen

Linux supports KAsan for VMALLOC since commit 3c5c3cfb9ef4da9 ("kasan: support backing vmalloc space with real shadow memory")

Acroding to how x86 ported it [1], they early allocated p4d and pgd, but in arm64 I just simulate how KAsan supports MODULES_VADDR in arm64 by not to populate the vmalloc area except for kimg address.

Test environment:
4G and 8G Qemu virt,
39-bit VA + 4k PAGE_SIZE with 3-level page table, test by lib/test_kasan.ko and lib/test_kasan_module.ko

It also works in Kaslr with CONFIG_RANDOMIZE_MODULE_REGION_FULL and randomize module region inside vmalloc area.

[1]: commit 0609ae011deb41c ("x86/kasan: support KASAN_VMALLOC")

Signed-off-by Lecopzer Chen <[email protected]>

Acked-by Andrey Konovalov <[email protected]>

Tested-by Andrey Konovalov <[email protected]>

v2 -> v1
1. kasan_init.c tweak indent
2. change Kconfig depends only on HAVE_ARCH_KASAN
3. support randomized module region.

v1:
https://lore.kernel.org/lkml/[email protected]/

Lecopzer Chen (4):
arm64: kasan: don't populate vmalloc area for CONFIG_KASAN_VMALLOC
arm64: kasan: abstract _text and _end to KERNEL_START/END
arm64: Kconfig: support CONFIG_KASAN_VMALLOC
arm64: kaslr: support randomized module area with KASAN_VMALLOC

 arch/arm64/Kconfig         |  1 +
 arch/arm64/kernel/kaslr.c  | 18 ++++++++++--------
 arch/arm64/kernel/module.c | 16 +++++++++-------
 arch/arm64/mm/kasan_init.c | 29 +++++++++++++++++++++--------
 4 files changed, 41 insertions(+), 23 deletions(-)

Quoted 3 lines

--
2.25.1

Hi Will,

Could you PTAL at the arm64 changes?

Linux supports KAsan for VMALLOC since commit 3c5c3cfb9ef4da9 ("kasan: support backing vmalloc space with real shadow memory")

Acroding to how x86 ported it [1], they early allocated p4d and pgd, but in arm64 I just simulate how KAsan supports MODULES_VADDR in arm64 by not to populate the vmalloc area except for kimg address.

Test environment:
4G and 8G Qemu virt,
39-bit VA + 4k PAGE_SIZE with 3-level page table, test by lib/test_kasan.ko and lib/test_kasan_module.ko

It also works in Kaslr with CONFIG_RANDOMIZE_MODULE_REGION_FULL and randomize module region inside vmalloc area.

[1]: commit 0609ae011deb41c ("x86/kasan: support KASAN_VMALLOC")

Signed-off-by Lecopzer Chen <[email protected]>

Acked-by Andrey Konovalov <[email protected]>

Tested-by Andrey Konovalov <[email protected]>

v2 -> v1
1. kasan_init.c tweak indent
2. change Kconfig depends only on HAVE_ARCH_KASAN
3. support randomized module region.

v1:
https://lore.kernel.org/lkml/[email protected]/

Lecopzer Chen (4):
arm64: kasan: don't populate vmalloc area for CONFIG_KASAN_VMALLOC
arm64: kasan: abstract _text and _end to KERNEL_START/END
arm64: Kconfig: support CONFIG_KASAN_VMALLOC
arm64: kaslr: support randomized module area with KASAN_VMALLOC

Linux supports KAsan for VMALLOC since commit 3c5c3cfb9ef4da9 ("kasan: support backing vmalloc space with real shadow memory")

Acroding to how x86 ported it [1], they early allocated p4d and pgd, but in arm64 I just simulate how KAsan supports MODULES_VADDR in arm64 by not to populate the vmalloc area except for kimg address.

Quoted 6 lines

Linux supports KAsan for VMALLOC since commit 3c5c3cfb9ef4da9 ("kasan: support backing vmalloc space with real shadow memory")

Acroding to how x86 ported it [1], they early allocated p4d and pgd, but in arm64 I just simulate how KAsan supports MODULES_VADDR in arm64 by not to populate the vmalloc area except for kimg address.

The one thing I've failed to grok from your series is how you deal with vmalloc allocations where the shadow overlaps with the shadow which has already been allocated for the kernel image. Please can you explain?

Quoted 11 lines · Lecopzer Chen

Quoted 6 lines

Linux supports KAsan for VMALLOC since commit 3c5c3cfb9ef4da9 ("kasan: support backing vmalloc space with real shadow memory")

Acroding to how x86 ported it [1], they early allocated p4d and pgd, but in arm64 I just simulate how KAsan supports MODULES_VADDR in arm64 by not to populate the vmalloc area except for kimg address.

The one thing I've failed to grok from your series is how you deal with vmalloc allocations where the shadow overlaps with the shadow which has already been allocated for the kernel image. Please can you explain?

The most key point is we don't map anything in the vmalloc shadow address. So we don't care where the kernel image locate inside vmalloc area.

kasan_map_populate(kimg_shadow_start, kimg_shadow_end,...)

Kernel image was populated with real mapping in its shadow address. I `bypass' the whole shadow of vmalloc area, the only place you can find about vmalloc_shadow is

	kasan_populate_early_shadow((void *)vmalloc_shadow_end,
			(void *)KASAN_SHADOW_END);

	-----------  vmalloc_shadow_start
 |           |
 |           | 
 |           | <= non-mapping
 |           |
 |           |
 |-----------|
 |///////////|<- kimage shadow with page table mapping.
 |-----------|
 |           |
 |           | <= non-mapping
 |           |
 ------------- vmalloc_shadow_end
 |00000000000|
 |00000000000| <= Zero shadow
 |00000000000|

------------- KASAN_SHADOW_END

vmalloc shadow will be mapped 'ondemend', see kasan_populate_vmalloc() in mm/vmalloc.c in detail.
So the shadow of vmalloc will be allocated later if anyone use its va.

Quoted 6 lines

Quoted 6 lines · Lecopzer Chen

Quoted 5 lines

Linux supports KAsan for VMALLOC since commit 3c5c3cfb9ef4da9 ("kasan: support backing vmalloc space with real shadow memory")

Acroding to how x86 ported it [1], they early allocated p4d and pgd, but in arm64 I just simulate how KAsan supports MODULES_VADDR in

arm64

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

by not to populate the vmalloc area except for kimg address.

The one thing I've failed to grok from your series is how you deal with vmalloc allocations where the shadow overlaps with the shadow which has already been allocated for the kernel image. Please can you explain?

The most key point is we don't map anything in the vmalloc shadow

address.

Quoted 26 lines

So we don't care where the kernel image locate inside vmalloc area.

kasan_map_populate(kimg_shadow_start, kimg_shadow_end,...)

Kernel image was populated with real mapping in its shadow address. I `bypass' the whole shadow of vmalloc area, the only place you can find about vmalloc_shadow is

      kasan_populate_early_shadow((void *)vmalloc_shadow_end,
                      (void *)KASAN_SHADOW_END);

      -----------  vmalloc_shadow_start
 |           |
 |           |
 |           | <= non-mapping
 |           |
 |           |
 |-----------|
 |///////////|<- kimage shadow with page table mapping.
 |-----------|
 |           |
 |           | <= non-mapping
 |           |
 ------------- vmalloc_shadow_end
 |00000000000|
 |00000000000| <= Zero shadow
 |00000000000|

Quoted 5 lines

------------- KASAN_SHADOW_END

vmalloc shadow will be mapped 'ondemend', see kasan_populate_vmalloc() in mm/vmalloc.c in detail.
So the shadow of vmalloc will be allocated later if anyone use its va.

Indeed, but the question I'm asking is what happens when an on-demand shadow
allocation from vmalloc overlaps with the shadow that we allocated early for
the kernel image?

Sounds like I have to go and read the code...

, and this early allocated vma will include kernel image.

Quoted 40 lines

Quoted 11 lines · Lecopzer Chen

Quoted 6 lines

Linux supports KAsan for VMALLOC since commit 3c5c3cfb9ef4da9 ("kasan: support backing vmalloc space with real shadow memory")

Acroding to how x86 ported it [1], they early allocated p4d and pgd, but in arm64 I just simulate how KAsan supports MODULES_VADDR in arm64 by not to populate the vmalloc area except for kimg address.

The one thing I've failed to grok from your series is how you deal with vmalloc allocations where the shadow overlaps with the shadow which has already been allocated for the kernel image. Please can you explain?

The most key point is we don't map anything in the vmalloc shadow address. So we don't care where the kernel image locate inside vmalloc area.

kasan_map_populate(kimg_shadow_start, kimg_shadow_end,...)

Kernel image was populated with real mapping in its shadow address. I `bypass' the whole shadow of vmalloc area, the only place you can find about vmalloc_shadow is

      kasan_populate_early_shadow((void *)vmalloc_shadow_end,
                      (void *)KASAN_SHADOW_END);

      -----------  vmalloc_shadow_start
 |           |
 |           |
 |           | <= non-mapping
 |           |
 |           |
 |-----------|
 |///////////|<- kimage shadow with page table mapping.
 |-----------|
 |           |
 |           | <= non-mapping
 |           |
 ------------- vmalloc_shadow_end
 |00000000000|
 |00000000000| <= Zero shadow
 |00000000000|

Quoted 5 lines

------------- KASAN_SHADOW_END

vmalloc shadow will be mapped 'ondemend', see kasan_populate_vmalloc() in mm/vmalloc.c in detail.
So the shadow of vmalloc will be allocated later if anyone use its va.

Indeed, but the question I'm asking is what happens when an on-demand shadow allocation from vmalloc overlaps with the shadow that we allocated early for the kernel image?

Sounds like I have to go and read the code...