linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/2] kasan, mm: reset tag when access metadata
@ 2021-07-27  4:00 Kuan-Ying Lee
  2021-07-27  4:00 ` [PATCH 1/2] " Kuan-Ying Lee
  2021-07-27  4:00 ` [PATCH 2/2] kasan, mm: reset tag for hex dump address Kuan-Ying Lee
  0 siblings, 2 replies; 14+ messages in thread
From: Kuan-Ying Lee @ 2021-07-27  4:00 UTC (permalink / raw)
  To: Nicholas Tang, Andrew Yang, Andrey Konovalov, Andrey Ryabinin,
	Alexander Potapenko, Marco Elver, Chinwen Chang, Andrew Morton
  Cc: kasan-dev, linux-mm, linux-kernel, linux-arm-kernel,
	linux-mediatek, Kuan-Ying Lee

With hardware tag-based kasan enabled, we reset the tag
when we access metadata to avoid from false alarm.

Kuan-Ying Lee (2):
  kasan, mm: reset tag when access metadata
  kasan, mm: reset tag for hex dump address

 mm/kmemleak.c | 6 +++---
 mm/slub.c     | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

-- 
2.18.0

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [PATCH 1/2] kasan, mm: reset tag when access metadata
  2021-07-27  4:00 [PATCH 0/2] kasan, mm: reset tag when access metadata Kuan-Ying Lee
@ 2021-07-27  4:00 ` Kuan-Ying Lee
  2021-07-27  7:10   ` Marco Elver
  2021-07-27  4:00 ` [PATCH 2/2] kasan, mm: reset tag for hex dump address Kuan-Ying Lee
  1 sibling, 1 reply; 14+ messages in thread
From: Kuan-Ying Lee @ 2021-07-27  4:00 UTC (permalink / raw)
  To: Nicholas Tang, Andrew Yang, Andrey Konovalov, Andrey Ryabinin,
	Alexander Potapenko, Marco Elver, Chinwen Chang, Andrew Morton
  Cc: kasan-dev, linux-mm, linux-kernel, linux-arm-kernel,
	linux-mediatek, Kuan-Ying Lee

Hardware tag-based KASAN doesn't use compiler instrumentation, we
can not use kasan_disable_current() to ignore tag check.

Thus, we need to reset tags when accessing metadata.

Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
---
 mm/kmemleak.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 228a2fbe0657..73d46d16d575 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -290,7 +290,7 @@ static void hex_dump_object(struct seq_file *seq,
 	warn_or_seq_printf(seq, "  hex dump (first %zu bytes):\n", len);
 	kasan_disable_current();
 	warn_or_seq_hex_dump(seq, DUMP_PREFIX_NONE, HEX_ROW_SIZE,
-			     HEX_GROUP_SIZE, ptr, len, HEX_ASCII);
+			     HEX_GROUP_SIZE, kasan_reset_tag((void *)ptr), len, HEX_ASCII);
 	kasan_enable_current();
 }
 
@@ -1171,7 +1171,7 @@ static bool update_checksum(struct kmemleak_object *object)
 
 	kasan_disable_current();
 	kcsan_disable_current();
-	object->checksum = crc32(0, (void *)object->pointer, object->size);
+	object->checksum = crc32(0, kasan_reset_tag((void *)object->pointer), object->size);
 	kasan_enable_current();
 	kcsan_enable_current();
 
@@ -1246,7 +1246,7 @@ static void scan_block(void *_start, void *_end,
 			break;
 
 		kasan_disable_current();
-		pointer = *ptr;
+		pointer = *(unsigned long *)kasan_reset_tag((void *)ptr);
 		kasan_enable_current();
 
 		untagged_ptr = (unsigned long)kasan_reset_tag((void *)pointer);
-- 
2.18.0

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [PATCH 2/2] kasan, mm: reset tag for hex dump address
  2021-07-27  4:00 [PATCH 0/2] kasan, mm: reset tag when access metadata Kuan-Ying Lee
  2021-07-27  4:00 ` [PATCH 1/2] " Kuan-Ying Lee
@ 2021-07-27  4:00 ` Kuan-Ying Lee
  2021-07-27  7:20   ` Marco Elver
  1 sibling, 1 reply; 14+ messages in thread
From: Kuan-Ying Lee @ 2021-07-27  4:00 UTC (permalink / raw)
  To: Nicholas Tang, Andrew Yang, Andrey Konovalov, Andrey Ryabinin,
	Alexander Potapenko, Marco Elver, Chinwen Chang, Andrew Morton
  Cc: kasan-dev, linux-mm, linux-kernel, linux-arm-kernel,
	linux-mediatek, Kuan-Ying Lee

Text is a string. We need to move this kasan_reset_tag()
to address but text.

Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
---
 mm/slub.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
index 6dad2b6fda6f..d20674f839ba 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -576,8 +576,8 @@ static void print_section(char *level, char *text, u8 *addr,
 			  unsigned int length)
 {
 	metadata_access_enable();
-	print_hex_dump(level, kasan_reset_tag(text), DUMP_PREFIX_ADDRESS,
-			16, 1, addr, length, 1);
+	print_hex_dump(level, text, DUMP_PREFIX_ADDRESS,
+			16, 1, kasan_reset_tag((void *)addr), length, 1);
 	metadata_access_disable();
 }
 
-- 
2.18.0

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/2] kasan, mm: reset tag when access metadata
  2021-07-27  4:00 ` [PATCH 1/2] " Kuan-Ying Lee
@ 2021-07-27  7:10   ` Marco Elver
  2021-07-27  8:32     ` Kuan-Ying Lee
  0 siblings, 1 reply; 14+ messages in thread
From: Marco Elver @ 2021-07-27  7:10 UTC (permalink / raw)
  To: Kuan-Ying Lee
  Cc: Nicholas Tang, Andrew Yang, Andrey Konovalov, Andrey Ryabinin,
	Alexander Potapenko, Chinwen Chang, Andrew Morton, kasan-dev,
	linux-mm, linux-kernel, linux-arm-kernel, linux-mediatek,
	Catalin Marinas

+Cc Catalin

On Tue, 27 Jul 2021 at 06:00, Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com> wrote:
>
> Hardware tag-based KASAN doesn't use compiler instrumentation, we
> can not use kasan_disable_current() to ignore tag check.
>
> Thus, we need to reset tags when accessing metadata.
>
> Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>

This looks reasonable, but the patch title is not saying this is
kmemleak, nor does the description say what the problem is. What
problem did you encounter? Was it a false positive?

Perhaps this should have been "kmemleak, kasan: reset pointer tags to
avoid false positives" ?

> ---
>  mm/kmemleak.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/mm/kmemleak.c b/mm/kmemleak.c
> index 228a2fbe0657..73d46d16d575 100644
> --- a/mm/kmemleak.c
> +++ b/mm/kmemleak.c
> @@ -290,7 +290,7 @@ static void hex_dump_object(struct seq_file *seq,
>         warn_or_seq_printf(seq, "  hex dump (first %zu bytes):\n", len);
>         kasan_disable_current();
>         warn_or_seq_hex_dump(seq, DUMP_PREFIX_NONE, HEX_ROW_SIZE,
> -                            HEX_GROUP_SIZE, ptr, len, HEX_ASCII);
> +                            HEX_GROUP_SIZE, kasan_reset_tag((void *)ptr), len, HEX_ASCII);
>         kasan_enable_current();
>  }
>
> @@ -1171,7 +1171,7 @@ static bool update_checksum(struct kmemleak_object *object)
>
>         kasan_disable_current();
>         kcsan_disable_current();
> -       object->checksum = crc32(0, (void *)object->pointer, object->size);
> +       object->checksum = crc32(0, kasan_reset_tag((void *)object->pointer), object->size);
>         kasan_enable_current();
>         kcsan_enable_current();
>
> @@ -1246,7 +1246,7 @@ static void scan_block(void *_start, void *_end,
>                         break;
>
>                 kasan_disable_current();
> -               pointer = *ptr;
> +               pointer = *(unsigned long *)kasan_reset_tag((void *)ptr);
>                 kasan_enable_current();
>
>                 untagged_ptr = (unsigned long)kasan_reset_tag((void *)pointer);
> --
> 2.18.0
>
> --
> You received this message because you are subscribed to the Google Groups "kasan-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20210727040021.21371-2-Kuan-Ying.Lee%40mediatek.com.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 2/2] kasan, mm: reset tag for hex dump address
  2021-07-27  4:00 ` [PATCH 2/2] kasan, mm: reset tag for hex dump address Kuan-Ying Lee
@ 2021-07-27  7:20   ` Marco Elver
  2021-07-27  8:54     ` Kuan-Ying Lee
  0 siblings, 1 reply; 14+ messages in thread
From: Marco Elver @ 2021-07-27  7:20 UTC (permalink / raw)
  To: Kuan-Ying Lee
  Cc: Nicholas Tang, Andrew Yang, Andrey Konovalov, Andrey Ryabinin,
	Alexander Potapenko, Chinwen Chang, Andrew Morton, kasan-dev,
	linux-mm, linux-kernel, linux-arm-kernel, linux-mediatek

On Tue, 27 Jul 2021 at 06:00, Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com> wrote:
>
> Text is a string. We need to move this kasan_reset_tag()
> to address but text.
>
> Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>

This patch also makes sense (I think), thanks for sending. But it's
unclear what the problem is. The fact that when the address is printed
it still includes the tag? Or a false positive?
It'd be good to clarify in the commit message.

Here I'd also use a more descriptive patch title, something like
"kasan, slub: reset tag when printing address".

Also, I think this patch requires a:

  Fixes: aa1ef4d7b3f6 ("kasan, mm: reset tags when accessing metadata")

So that stable kernels can pick this up if appropriate.

> ---
>  mm/slub.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index 6dad2b6fda6f..d20674f839ba 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -576,8 +576,8 @@ static void print_section(char *level, char *text, u8 *addr,
>                           unsigned int length)
>  {
>         metadata_access_enable();
> -       print_hex_dump(level, kasan_reset_tag(text), DUMP_PREFIX_ADDRESS,
> -                       16, 1, addr, length, 1);
> +       print_hex_dump(level, text, DUMP_PREFIX_ADDRESS,
> +                       16, 1, kasan_reset_tag((void *)addr), length, 1);
>         metadata_access_disable();
>  }
>
> --
> 2.18.0
>
> --
> You received this message because you are subscribed to the Google Groups "kasan-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20210727040021.21371-3-Kuan-Ying.Lee%40mediatek.com.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/2] kasan, mm: reset tag when access metadata
  2021-07-27  7:10   ` Marco Elver
@ 2021-07-27  8:32     ` Kuan-Ying Lee
  2021-07-27  9:34       ` Marco Elver
  2021-07-27 19:22       ` Catalin Marinas
  0 siblings, 2 replies; 14+ messages in thread
From: Kuan-Ying Lee @ 2021-07-27  8:32 UTC (permalink / raw)
  To: Marco Elver
  Cc: Nicholas Tang, Andrew Yang, Andrey Konovalov, Andrey Ryabinin,
	Alexander Potapenko, Chinwen Chang, Andrew Morton, kasan-dev,
	linux-mm, linux-kernel, linux-arm-kernel, linux-mediatek,
	Catalin Marinas, Kuan-Ying.Lee

On Tue, 2021-07-27 at 09:10 +0200, Marco Elver wrote:
> +Cc Catalin
> 
> On Tue, 27 Jul 2021 at 06:00, Kuan-Ying Lee <
> Kuan-Ying.Lee@mediatek.com> wrote:
> > 
> > Hardware tag-based KASAN doesn't use compiler instrumentation, we
> > can not use kasan_disable_current() to ignore tag check.
> > 
> > Thus, we need to reset tags when accessing metadata.
> > 
> > Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
> 
> This looks reasonable, but the patch title is not saying this is
> kmemleak, nor does the description say what the problem is. What
> problem did you encounter? Was it a false positive?

kmemleak would scan kernel memory to check memory leak.
When it scans on the invalid slab and dereference, the issue
will occur like below.

So I think we should reset the tag before scanning.

# echo scan > /sys/kernel/debug/kmemleak
[  151.905804]
==================================================================
[  151.907120] BUG: KASAN: out-of-bounds in scan_block+0x58/0x170
[  151.908773] Read at addr f7ff0000c0074eb0 by task kmemleak/138
[  151.909656] Pointer tag: [f7], memory tag: [fe]
[  151.910195]
[  151.910876] CPU: 7 PID: 138 Comm: kmemleak Not tainted 5.14.0-rc2-
00001-g8cae8cd89f05-dirty #134
[  151.912085] Hardware name: linux,dummy-virt (DT)
[  151.912868] Call trace:
[  151.913211]  dump_backtrace+0x0/0x1b0
[  151.913796]  show_stack+0x1c/0x30
[  151.914248]  dump_stack_lvl+0x68/0x84
[  151.914778]  print_address_description+0x7c/0x2b4
[  151.915340]  kasan_report+0x138/0x38c
[  151.915804]  __do_kernel_fault+0x190/0x1c4
[  151.916386]  do_tag_check_fault+0x78/0x90
[  151.916856]  do_mem_abort+0x44/0xb4
[  151.917308]  el1_abort+0x40/0x60
[  151.917754]  el1h_64_sync_handler+0xb4/0xd0
[  151.918270]  el1h_64_sync+0x78/0x7c
[  151.918714]  scan_block+0x58/0x170
[  151.919157]  scan_gray_list+0xdc/0x1a0
[  151.919626]  kmemleak_scan+0x2ac/0x560
[  151.920129]  kmemleak_scan_thread+0xb0/0xe0
[  151.920635]  kthread+0x154/0x160
[  151.921115]  ret_from_fork+0x10/0x18
[  151.921717]
[  151.922077] Allocated by task 0:
[  151.922523]  kasan_save_stack+0x2c/0x60
[  151.923099]  __kasan_kmalloc+0xec/0x104
[  151.923502]  __kmalloc+0x224/0x3c4
[  151.924172]  __register_sysctl_paths+0x200/0x290
[  151.924709]  register_sysctl_table+0x2c/0x40
[  151.925175]  sysctl_init+0x20/0x34
[  151.925665]  proc_sys_init+0x3c/0x48
[  151.926136]  proc_root_init+0x80/0x9c
[  151.926547]  start_kernel+0x648/0x6a4
[  151.926987]  __primary_switched+0xc0/0xc8
[  151.927557]
[  151.927994] Freed by task 0:
[  151.928340]  kasan_save_stack+0x2c/0x60
[  151.928766]  kasan_set_track+0x2c/0x40
[  151.929173]  kasan_set_free_info+0x44/0x54
[  151.929568]  ____kasan_slab_free.constprop.0+0x150/0x1b0
[  151.930063]  __kasan_slab_free+0x14/0x20
[  151.930449]  slab_free_freelist_hook+0xa4/0x1fc
[  151.930924]  kfree+0x1e8/0x30c
[  151.931285]  put_fs_context+0x124/0x220
[  151.931731]  vfs_kern_mount.part.0+0x60/0xd4
[  151.932280]  kern_mount+0x24/0x4c
[  151.932686]  bdev_cache_init+0x70/0x9c
[  151.933122]  vfs_caches_init+0xdc/0xf4
[  151.933578]  start_kernel+0x638/0x6a4
[  151.934014]  __primary_switched+0xc0/0xc8
[  151.934478]
[  151.934757] The buggy address belongs to the object at
ffff0000c0074e00
[  151.934757]  which belongs to the cache kmalloc-256 of size 256
[  151.935744] The buggy address is located 176 bytes inside of
[  151.935744]  256-byte region [ffff0000c0074e00, ffff0000c0074f00)
[  151.936702] The buggy address belongs to the page:
[  151.937378] page:(____ptrval____) refcount:1 mapcount:0
mapping:0000000000000000 index:0x0 pfn:0x100074
[  151.938682] head:(____ptrval____) order:2 compound_mapcount:0
compound_pincount:0
[  151.939440] flags:
0xbfffc0000010200(slab|head|node=0|zone=2|lastcpupid=0xffff|kasantag=0x
0)
[  151.940886] raw: 0bfffc0000010200 0000000000000000 dead000000000122
f5ff0000c0002300
[  151.941634] raw: 0000000000000000 0000000000200020 00000001ffffffff
0000000000000000
[  151.942353] page dumped because: kasan: bad access detected
[  151.942923]
[  151.943214] Memory state around the buggy address:
[  151.943896]  ffff0000c0074c00: f0 f0 f0 f0 f0 f0 f0 f0 f0 fe fe fe
fe fe fe fe
[  151.944857]  ffff0000c0074d00: fe fe fe fe fe fe fe fe fe fe fe fe
fe fe fe fe
[  151.945892] >ffff0000c0074e00: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 fe
fe fe fe fe
[  151.946407]                                                     ^
[  151.946939]  ffff0000c0074f00: fe fe fe fe fe fe fe fe fe fe fe fe
fe fe fe fe
[  151.947445]  ffff0000c0075000: fb fb fb fb fb fb fb fb fb fb fb fb
fb fb fb fb
[  151.947999]
==================================================================
[  151.948524] Disabling lock debugging due to kernel taint
[  156.434569] kmemleak: 181 new suspected memory leaks (see
/sys/kernel/debug/kmemleak)

> 
> Perhaps this should have been "kmemleak, kasan: reset pointer tags to
> avoid false positives" ?

Thanks for the suggestions.
But I think it doesn't belong to false
positive becuase scan block
touched invalid metadata certainly.

Maybe "kmemleak, kasan: reset tags when scanning block"?

> 
> > ---
> >  mm/kmemleak.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/mm/kmemleak.c b/mm/kmemleak.c
> > index 228a2fbe0657..73d46d16d575 100644
> > --- a/mm/kmemleak.c
> > +++ b/mm/kmemleak.c
> > @@ -290,7 +290,7 @@ static void hex_dump_object(struct seq_file
> > *seq,
> >         warn_or_seq_printf(seq, "  hex dump (first %zu bytes):\n",
> > len);
> >         kasan_disable_current();
> >         warn_or_seq_hex_dump(seq, DUMP_PREFIX_NONE, HEX_ROW_SIZE,
> > -                            HEX_GROUP_SIZE, ptr, len, HEX_ASCII);
> > +                            HEX_GROUP_SIZE, kasan_reset_tag((void
> > *)ptr), len, HEX_ASCII);
> >         kasan_enable_current();
> >  }
> > 
> > @@ -1171,7 +1171,7 @@ static bool update_checksum(struct
> > kmemleak_object *object)
> > 
> >         kasan_disable_current();
> >         kcsan_disable_current();
> > -       object->checksum = crc32(0, (void *)object->pointer,
> > object->size);
> > +       object->checksum = crc32(0, kasan_reset_tag((void *)object-
> > >pointer), object->size);
> >         kasan_enable_current();
> >         kcsan_enable_current();
> > 
> > @@ -1246,7 +1246,7 @@ static void scan_block(void *_start, void
> > *_end,
> >                         break;
> > 
> >                 kasan_disable_current();
> > -               pointer = *ptr;
> > +               pointer = *(unsigned long *)kasan_reset_tag((void
> > *)ptr);
> >                 kasan_enable_current();
> > 
> >                 untagged_ptr = (unsigned long)kasan_reset_tag((void
> > *)pointer);
> > --
> > 2.18.0
> > 
> > --
> > You received this message because you are subscribed to the Google
> > Groups "kasan-dev" group.
> > To unsubscribe from this group and stop receiving emails from it,
> > send an email to kasan-dev+unsubscribe@googlegroups.com.
> > To view this discussion on the web visit 
> > https://urldefense.com/v3/__https://groups.google.com/d/msgid/kasan-dev/20210727040021.21371-2-Kuan-Ying.Lee*40mediatek.com__;JQ!!CTRNKA9wMg0ARbw!wNP4ZkYDM7Xvs9xfzKwYuG1X2h9zFqST8_Vm2jSvZUl9BiS8SPFMTvMp3VAPKCnuWELL7Q$
> >  .

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 2/2] kasan, mm: reset tag for hex dump address
  2021-07-27  7:20   ` Marco Elver
@ 2021-07-27  8:54     ` Kuan-Ying Lee
  0 siblings, 0 replies; 14+ messages in thread
From: Kuan-Ying Lee @ 2021-07-27  8:54 UTC (permalink / raw)
  To: Marco Elver
  Cc: Nicholas Tang, Andrew Yang, Andrey Konovalov, Andrey Ryabinin,
	Alexander Potapenko, Chinwen Chang, Andrew Morton, kasan-dev,
	linux-mm, linux-kernel, linux-arm-kernel, linux-mediatek,
	Kuan-Ying.Lee

On Tue, 2021-07-27 at 09:20 +0200, Marco Elver wrote:
> On Tue, 27 Jul 2021 at 06:00, Kuan-Ying Lee <
> Kuan-Ying.Lee@mediatek.com> wrote:
> > 
> > Text is a string. We need to move this kasan_reset_tag()
> > to address but text.
> > 
> > Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
> 
> This patch also makes sense (I think), thanks for sending. But it's
> unclear what the problem is. The fact that when the address is
> printed
> it still includes the tag? Or a false positive?
> It'd be good to clarify in the commit message.

Yes, printed address includes the tag, so when we access the
metadata, we will encounter tag mismatch with HW tag-based kasan
enabled.

> 
> Here I'd also use a more descriptive patch title, something like
> "kasan, slub: reset tag when printing address".
> 
> Also, I think this patch requires a:
> 
>   Fixes: aa1ef4d7b3f6 ("kasan, mm: reset tags when accessing
> metadata")
> 
> So that stable kernels can pick this up if appropriate.

Thank you, Marco.
I will refine commit message in the v2.

> 
> > ---
> >  mm/slub.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/mm/slub.c b/mm/slub.c
> > index 6dad2b6fda6f..d20674f839ba 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -576,8 +576,8 @@ static void print_section(char *level, char
> > *text, u8 *addr,
> >                           unsigned int length)
> >  {
> >         metadata_access_enable();
> > -       print_hex_dump(level, kasan_reset_tag(text),
> > DUMP_PREFIX_ADDRESS,
> > -                       16, 1, addr, length, 1);
> > +       print_hex_dump(level, text, DUMP_PREFIX_ADDRESS,
> > +                       16, 1, kasan_reset_tag((void *)addr),
> > length, 1);
> >         metadata_access_disable();
> >  }
> > 
> > --
> > 2.18.0
> > 
> > --
> > You received this message because you are subscribed to the Google
> > Groups "kasan-dev" group.
> > To unsubscribe from this group and stop receiving emails from it,
> > send an email to kasan-dev+unsubscribe@googlegroups.com.
> > To view this discussion on the web visit 
> > https://urldefense.com/v3/__https://groups.google.com/d/msgid/kasan-dev/20210727040021.21371-3-Kuan-Ying.Lee*40mediatek.com__;JQ!!CTRNKA9wMg0ARbw!13XOuYbzPQrBvIDMNbrT7vm8RGc56Oqr402PDfQRDmHrrBsujrZUr7O9q24JeDJ_3NlWSQ$
> >  .

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/2] kasan, mm: reset tag when access metadata
  2021-07-27  8:32     ` Kuan-Ying Lee
@ 2021-07-27  9:34       ` Marco Elver
  2021-07-27 19:22       ` Catalin Marinas
  1 sibling, 0 replies; 14+ messages in thread
From: Marco Elver @ 2021-07-27  9:34 UTC (permalink / raw)
  To: Kuan-Ying Lee
  Cc: Nicholas Tang, Andrew Yang, Andrey Konovalov, Andrey Ryabinin,
	Alexander Potapenko, Chinwen Chang, Andrew Morton, kasan-dev,
	linux-mm, linux-kernel, linux-arm-kernel, linux-mediatek,
	Catalin Marinas

On Tue, 27 Jul 2021 at 10:32, Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com> wrote:
>
> On Tue, 2021-07-27 at 09:10 +0200, Marco Elver wrote:
> > +Cc Catalin
> >
> > On Tue, 27 Jul 2021 at 06:00, Kuan-Ying Lee <
> > Kuan-Ying.Lee@mediatek.com> wrote:
> > >
> > > Hardware tag-based KASAN doesn't use compiler instrumentation, we
> > > can not use kasan_disable_current() to ignore tag check.
> > >
> > > Thus, we need to reset tags when accessing metadata.
> > >
> > > Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
> >
> > This looks reasonable, but the patch title is not saying this is
> > kmemleak, nor does the description say what the problem is. What
> > problem did you encounter? Was it a false positive?
>
> kmemleak would scan kernel memory to check memory leak.
> When it scans on the invalid slab and dereference, the issue
> will occur like below.

Please also add this info to commit message.

> So I think we should reset the tag before scanning.
>
> # echo scan > /sys/kernel/debug/kmemleak
> [  151.905804]
> ==================================================================
> [  151.907120] BUG: KASAN: out-of-bounds in scan_block+0x58/0x170
> [  151.908773] Read at addr f7ff0000c0074eb0 by task kmemleak/138
> [  151.909656] Pointer tag: [f7], memory tag: [fe]
> [  151.910195]
> [  151.910876] CPU: 7 PID: 138 Comm: kmemleak Not tainted 5.14.0-rc2-
> 00001-g8cae8cd89f05-dirty #134
> [  151.912085] Hardware name: linux,dummy-virt (DT)
> [  151.912868] Call trace:
> [  151.913211]  dump_backtrace+0x0/0x1b0
> [  151.913796]  show_stack+0x1c/0x30
> [  151.914248]  dump_stack_lvl+0x68/0x84
> [  151.914778]  print_address_description+0x7c/0x2b4
> [  151.915340]  kasan_report+0x138/0x38c
> [  151.915804]  __do_kernel_fault+0x190/0x1c4
> [  151.916386]  do_tag_check_fault+0x78/0x90
> [  151.916856]  do_mem_abort+0x44/0xb4
> [  151.917308]  el1_abort+0x40/0x60
> [  151.917754]  el1h_64_sync_handler+0xb4/0xd0
> [  151.918270]  el1h_64_sync+0x78/0x7c
> [  151.918714]  scan_block+0x58/0x170
> [  151.919157]  scan_gray_list+0xdc/0x1a0
> [  151.919626]  kmemleak_scan+0x2ac/0x560
> [  151.920129]  kmemleak_scan_thread+0xb0/0xe0
> [  151.920635]  kthread+0x154/0x160
> [  151.921115]  ret_from_fork+0x10/0x18
> [  151.921717]
> [  151.922077] Allocated by task 0:
> [  151.922523]  kasan_save_stack+0x2c/0x60
> [  151.923099]  __kasan_kmalloc+0xec/0x104
> [  151.923502]  __kmalloc+0x224/0x3c4
> [  151.924172]  __register_sysctl_paths+0x200/0x290
> [  151.924709]  register_sysctl_table+0x2c/0x40
> [  151.925175]  sysctl_init+0x20/0x34
> [  151.925665]  proc_sys_init+0x3c/0x48
> [  151.926136]  proc_root_init+0x80/0x9c
> [  151.926547]  start_kernel+0x648/0x6a4
> [  151.926987]  __primary_switched+0xc0/0xc8
> [  151.927557]
> [  151.927994] Freed by task 0:
> [  151.928340]  kasan_save_stack+0x2c/0x60
> [  151.928766]  kasan_set_track+0x2c/0x40
> [  151.929173]  kasan_set_free_info+0x44/0x54
> [  151.929568]  ____kasan_slab_free.constprop.0+0x150/0x1b0
> [  151.930063]  __kasan_slab_free+0x14/0x20
> [  151.930449]  slab_free_freelist_hook+0xa4/0x1fc
> [  151.930924]  kfree+0x1e8/0x30c
> [  151.931285]  put_fs_context+0x124/0x220
> [  151.931731]  vfs_kern_mount.part.0+0x60/0xd4
> [  151.932280]  kern_mount+0x24/0x4c
> [  151.932686]  bdev_cache_init+0x70/0x9c
> [  151.933122]  vfs_caches_init+0xdc/0xf4
> [  151.933578]  start_kernel+0x638/0x6a4
> [  151.934014]  __primary_switched+0xc0/0xc8
> [  151.934478]
> [  151.934757] The buggy address belongs to the object at
> ffff0000c0074e00
> [  151.934757]  which belongs to the cache kmalloc-256 of size 256
> [  151.935744] The buggy address is located 176 bytes inside of
> [  151.935744]  256-byte region [ffff0000c0074e00, ffff0000c0074f00)
> [  151.936702] The buggy address belongs to the page:
> [  151.937378] page:(____ptrval____) refcount:1 mapcount:0
> mapping:0000000000000000 index:0x0 pfn:0x100074
> [  151.938682] head:(____ptrval____) order:2 compound_mapcount:0
> compound_pincount:0
> [  151.939440] flags:
> 0xbfffc0000010200(slab|head|node=0|zone=2|lastcpupid=0xffff|kasantag=0x
> 0)
> [  151.940886] raw: 0bfffc0000010200 0000000000000000 dead000000000122
> f5ff0000c0002300
> [  151.941634] raw: 0000000000000000 0000000000200020 00000001ffffffff
> 0000000000000000
> [  151.942353] page dumped because: kasan: bad access detected
> [  151.942923]
> [  151.943214] Memory state around the buggy address:
> [  151.943896]  ffff0000c0074c00: f0 f0 f0 f0 f0 f0 f0 f0 f0 fe fe fe
> fe fe fe fe
> [  151.944857]  ffff0000c0074d00: fe fe fe fe fe fe fe fe fe fe fe fe
> fe fe fe fe
> [  151.945892] >ffff0000c0074e00: f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 f7 fe
> fe fe fe fe
> [  151.946407]                                                     ^
> [  151.946939]  ffff0000c0074f00: fe fe fe fe fe fe fe fe fe fe fe fe
> fe fe fe fe
> [  151.947445]  ffff0000c0075000: fb fb fb fb fb fb fb fb fb fb fb fb
> fb fb fb fb
> [  151.947999]
> ==================================================================
> [  151.948524] Disabling lock debugging due to kernel taint
> [  156.434569] kmemleak: 181 new suspected memory leaks (see
> /sys/kernel/debug/kmemleak)
>
> >
> > Perhaps this should have been "kmemleak, kasan: reset pointer tags to
> > avoid false positives" ?
>
> Thanks for the suggestions.
> But I think it doesn't belong to false
> positive becuase scan block
> touched invalid metadata certainly.

It's how kmemleak works, so we knowingly access invalid memory, and
for all intents and purposes it's a false positive.

> Maybe "kmemleak, kasan: reset tags when scanning block"?

That's fine.

Thanks,
-- Marco


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/2] kasan, mm: reset tag when access metadata
  2021-07-27  8:32     ` Kuan-Ying Lee
  2021-07-27  9:34       ` Marco Elver
@ 2021-07-27 19:22       ` Catalin Marinas
  2021-07-28 11:05         ` Kuan-Ying Lee
  2021-07-30 14:57         ` Andrey Konovalov
  1 sibling, 2 replies; 14+ messages in thread
From: Catalin Marinas @ 2021-07-27 19:22 UTC (permalink / raw)
  To: Kuan-Ying Lee
  Cc: Marco Elver, Nicholas Tang, Andrew Yang, Andrey Konovalov,
	Andrey Ryabinin, Alexander Potapenko, Chinwen Chang,
	Andrew Morton, kasan-dev, linux-mm, linux-kernel,
	linux-arm-kernel, linux-mediatek

On Tue, Jul 27, 2021 at 04:32:02PM +0800, Kuan-Ying Lee wrote:
> On Tue, 2021-07-27 at 09:10 +0200, Marco Elver wrote:
> > +Cc Catalin
> > 
> > On Tue, 27 Jul 2021 at 06:00, Kuan-Ying Lee <
> > Kuan-Ying.Lee@mediatek.com> wrote:
> > > 
> > > Hardware tag-based KASAN doesn't use compiler instrumentation, we
> > > can not use kasan_disable_current() to ignore tag check.
> > > 
> > > Thus, we need to reset tags when accessing metadata.
> > > 
> > > Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
> > 
> > This looks reasonable, but the patch title is not saying this is
> > kmemleak, nor does the description say what the problem is. What
> > problem did you encounter? Was it a false positive?
> 
> kmemleak would scan kernel memory to check memory leak.
> When it scans on the invalid slab and dereference, the issue
> will occur like below.
> 
> So I think we should reset the tag before scanning.
> 
> # echo scan > /sys/kernel/debug/kmemleak
> [  151.905804]
> ==================================================================
> [  151.907120] BUG: KASAN: out-of-bounds in scan_block+0x58/0x170
> [  151.908773] Read at addr f7ff0000c0074eb0 by task kmemleak/138
> [  151.909656] Pointer tag: [f7], memory tag: [fe]

It would be interesting to find out why the tag doesn't match. Kmemleak
should in principle only scan valid objects that have been allocated and
the pointer can be safely dereferenced. 0xfe is KASAN_TAG_INVALID, so it
either goes past the size of the object (into the red zone) or it still
accesses the object after it was marked as freed but before being
released from kmemleak.

With slab, looking at __cache_free(), it calls kasan_slab_free() before
___cache_free() -> kmemleak_free_recursive(), so the second scenario is
possible. With slub, however, slab_free_hook() first releases the object
from kmemleak before poisoning it. Based on the stack dump, you are
using slub, so it may be that kmemleak goes into the object red zones.

I'd like this clarified before blindly resetting the tag.

-- 
Catalin


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/2] kasan, mm: reset tag when access metadata
  2021-07-27 19:22       ` Catalin Marinas
@ 2021-07-28 11:05         ` Kuan-Ying Lee
  2021-07-28 12:43           ` Marco Elver
  2021-07-30 14:57         ` Andrey Konovalov
  1 sibling, 1 reply; 14+ messages in thread
From: Kuan-Ying Lee @ 2021-07-28 11:05 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Marco Elver, Nicholas Tang, Andrew Yang, Andrey Konovalov,
	Andrey Ryabinin, Alexander Potapenko, Chinwen Chang,
	Andrew Morton, kasan-dev, linux-mm, linux-kernel,
	linux-arm-kernel, linux-mediatek, Kuan-Ying.Lee

On Tue, 2021-07-27 at 20:22 +0100, Catalin Marinas wrote:
> On Tue, Jul 27, 2021 at 04:32:02PM +0800, Kuan-Ying Lee wrote:
> > On Tue, 2021-07-27 at 09:10 +0200, Marco Elver wrote:
> > > +Cc Catalin
> > > 
> > > On Tue, 27 Jul 2021 at 06:00, Kuan-Ying Lee <
> > > Kuan-Ying.Lee@mediatek.com> wrote:
> > > > 
> > > > Hardware tag-based KASAN doesn't use compiler instrumentation,
> > > > we
> > > > can not use kasan_disable_current() to ignore tag check.
> > > > 
> > > > Thus, we need to reset tags when accessing metadata.
> > > > 
> > > > Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
> > > 
> > > This looks reasonable, but the patch title is not saying this is
> > > kmemleak, nor does the description say what the problem is. What
> > > problem did you encounter? Was it a false positive?
> > 
> > kmemleak would scan kernel memory to check memory leak.
> > When it scans on the invalid slab and dereference, the issue
> > will occur like below.
> > 
> > So I think we should reset the tag before scanning.
> > 
> > # echo scan > /sys/kernel/debug/kmemleak
> > [  151.905804]
> > ==================================================================
> > [  151.907120] BUG: KASAN: out-of-bounds in scan_block+0x58/0x170
> > [  151.908773] Read at addr f7ff0000c0074eb0 by task kmemleak/138
> > [  151.909656] Pointer tag: [f7], memory tag: [fe]
> 
> It would be interesting to find out why the tag doesn't match.
> Kmemleak
> should in principle only scan valid objects that have been allocated
> and
> the pointer can be safely dereferenced. 0xfe is KASAN_TAG_INVALID, so
> it
> either goes past the size of the object (into the red zone) or it
> still
> accesses the object after it was marked as freed but before being
> released from kmemleak.
> 
> With slab, looking at __cache_free(), it calls kasan_slab_free()
> before
> ___cache_free() -> kmemleak_free_recursive(), so the second scenario
> is
> possible. With slub, however, slab_free_hook() first releases the
> object
> from kmemleak before poisoning it. Based on the stack dump, you are
> using slub, so it may be that kmemleak goes into the object red
> zones.
> 
> I'd like this clarified before blindly resetting the tag.

This kasan issue only happened on hardware tag-based kasan mode.
Because kasan_disable_current() works for generic and sw tag-based
kasan.

HW tag-based kasan depends on slub so slab will not hit this
issue.
I think we can just check if HW tag-based kasan is enabled or not
and decide to reset the tag as below.

if (kasan_has_integrated_init()) // slub case, hw-tag kasan
	pointer = *(unsigned long *)kasan_reset_tag((void *)ptr);
else
	pointer = *ptr; // slab

Is this better or any other suggestions?
Any suggestion is appreciated.

Thanks,
Kuan-Ying Lee

> 

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/2] kasan, mm: reset tag when access metadata
  2021-07-28 11:05         ` Kuan-Ying Lee
@ 2021-07-28 12:43           ` Marco Elver
  0 siblings, 0 replies; 14+ messages in thread
From: Marco Elver @ 2021-07-28 12:43 UTC (permalink / raw)
  To: Kuan-Ying Lee
  Cc: Catalin Marinas, Nicholas Tang, Andrew Yang, Andrey Konovalov,
	Andrey Ryabinin, Alexander Potapenko, Chinwen Chang,
	Andrew Morton, kasan-dev, linux-mm, linux-kernel,
	linux-arm-kernel, linux-mediatek

On Wed, 28 Jul 2021 at 13:05, Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com> wrote:
>
> On Tue, 2021-07-27 at 20:22 +0100, Catalin Marinas wrote:
> > On Tue, Jul 27, 2021 at 04:32:02PM +0800, Kuan-Ying Lee wrote:
> > > On Tue, 2021-07-27 at 09:10 +0200, Marco Elver wrote:
> > > > +Cc Catalin
> > > >
> > > > On Tue, 27 Jul 2021 at 06:00, Kuan-Ying Lee <
> > > > Kuan-Ying.Lee@mediatek.com> wrote:
> > > > >
> > > > > Hardware tag-based KASAN doesn't use compiler instrumentation,
> > > > > we
> > > > > can not use kasan_disable_current() to ignore tag check.
> > > > >
> > > > > Thus, we need to reset tags when accessing metadata.
> > > > >
> > > > > Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
> > > >
> > > > This looks reasonable, but the patch title is not saying this is
> > > > kmemleak, nor does the description say what the problem is. What
> > > > problem did you encounter? Was it a false positive?
> > >
> > > kmemleak would scan kernel memory to check memory leak.
> > > When it scans on the invalid slab and dereference, the issue
> > > will occur like below.
> > >
> > > So I think we should reset the tag before scanning.
> > >
> > > # echo scan > /sys/kernel/debug/kmemleak
> > > [  151.905804]
> > > ==================================================================
> > > [  151.907120] BUG: KASAN: out-of-bounds in scan_block+0x58/0x170
> > > [  151.908773] Read at addr f7ff0000c0074eb0 by task kmemleak/138
> > > [  151.909656] Pointer tag: [f7], memory tag: [fe]
> >
> > It would be interesting to find out why the tag doesn't match.
> > Kmemleak
> > should in principle only scan valid objects that have been allocated
> > and
> > the pointer can be safely dereferenced. 0xfe is KASAN_TAG_INVALID, so
> > it
> > either goes past the size of the object (into the red zone) or it
> > still
> > accesses the object after it was marked as freed but before being
> > released from kmemleak.
> >
> > With slab, looking at __cache_free(), it calls kasan_slab_free()
> > before
> > ___cache_free() -> kmemleak_free_recursive(), so the second scenario
> > is
> > possible. With slub, however, slab_free_hook() first releases the
> > object
> > from kmemleak before poisoning it. Based on the stack dump, you are
> > using slub, so it may be that kmemleak goes into the object red
> > zones.
> >
> > I'd like this clarified before blindly resetting the tag.
>
> This kasan issue only happened on hardware tag-based kasan mode.
> Because kasan_disable_current() works for generic and sw tag-based
> kasan.
>
> HW tag-based kasan depends on slub so slab will not hit this
> issue.
> I think we can just check if HW tag-based kasan is enabled or not
> and decide to reset the tag as below.
>
> if (kasan_has_integrated_init()) // slub case, hw-tag kasan
>         pointer = *(unsigned long *)kasan_reset_tag((void *)ptr);
> else
>         pointer = *ptr; // slab

This is redundant. kasan_reset_tag() is a noop if
!IS_ENABLED(CONFIG_KASAN_HW_TAGS).

> Is this better or any other suggestions?
> Any suggestion is appreciated.

The current version is fine. But I think Catalin's point about why
kmemleak accesses the data in the first place still deserves some
investigation. Could it be a race between free and kmemleak scan?


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/2] kasan, mm: reset tag when access metadata
  2021-07-27 19:22       ` Catalin Marinas
  2021-07-28 11:05         ` Kuan-Ying Lee
@ 2021-07-30 14:57         ` Andrey Konovalov
  2021-07-30 15:24           ` Catalin Marinas
  2021-08-04  5:31           ` kuan.ying lee
  1 sibling, 2 replies; 14+ messages in thread
From: Andrey Konovalov @ 2021-07-30 14:57 UTC (permalink / raw)
  To: Catalin Marinas, Kuan-Ying Lee
  Cc: Marco Elver, Nicholas Tang, Andrew Yang, Andrey Ryabinin,
	Alexander Potapenko, Chinwen Chang, Andrew Morton, kasan-dev,
	Linux Memory Management List, LKML, Linux ARM,
	moderated list:ARM/Mediatek SoC support

On Tue, Jul 27, 2021 at 9:22 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> On Tue, Jul 27, 2021 at 04:32:02PM +0800, Kuan-Ying Lee wrote:
> > On Tue, 2021-07-27 at 09:10 +0200, Marco Elver wrote:
> > > +Cc Catalin
> > >
> > > On Tue, 27 Jul 2021 at 06:00, Kuan-Ying Lee <
> > > Kuan-Ying.Lee@mediatek.com> wrote:
> > > >
> > > > Hardware tag-based KASAN doesn't use compiler instrumentation, we
> > > > can not use kasan_disable_current() to ignore tag check.
> > > >
> > > > Thus, we need to reset tags when accessing metadata.
> > > >
> > > > Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
> > >
> > > This looks reasonable, but the patch title is not saying this is
> > > kmemleak, nor does the description say what the problem is. What
> > > problem did you encounter? Was it a false positive?
> >
> > kmemleak would scan kernel memory to check memory leak.
> > When it scans on the invalid slab and dereference, the issue
> > will occur like below.
> >
> > So I think we should reset the tag before scanning.
> >
> > # echo scan > /sys/kernel/debug/kmemleak
> > [  151.905804]
> > ==================================================================
> > [  151.907120] BUG: KASAN: out-of-bounds in scan_block+0x58/0x170
> > [  151.908773] Read at addr f7ff0000c0074eb0 by task kmemleak/138
> > [  151.909656] Pointer tag: [f7], memory tag: [fe]
>
> It would be interesting to find out why the tag doesn't match. Kmemleak
> should in principle only scan valid objects that have been allocated and
> the pointer can be safely dereferenced. 0xfe is KASAN_TAG_INVALID, so it
> either goes past the size of the object (into the red zone) or it still
> accesses the object after it was marked as freed but before being
> released from kmemleak.
>
> With slab, looking at __cache_free(), it calls kasan_slab_free() before
> ___cache_free() -> kmemleak_free_recursive(), so the second scenario is
> possible. With slub, however, slab_free_hook() first releases the object
> from kmemleak before poisoning it. Based on the stack dump, you are
> using slub, so it may be that kmemleak goes into the object red zones.
>
> I'd like this clarified before blindly resetting the tag.

AFAIK, kmemleak scans the whole object including the leftover redzone
for kmalloc-allocated objects.

Looking at the report, there are 11 0xf7 granules, which amounts to
176 bytes, and the object is allocated from the kmalloc-256 cache. So
when kmemleak accesses the last 256-176 bytes, it causes faults, as
those are marked with KASAN_KMALLOC_REDZONE == KASAN_TAG_INVALID ==
0xfe.

Generally, resetting tags in kasan_disable/enable_current() section
should be fine to suppress MTE faults, provided those sections had
been added correctly in the first place.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/2] kasan, mm: reset tag when access metadata
  2021-07-30 14:57         ` Andrey Konovalov
@ 2021-07-30 15:24           ` Catalin Marinas
  2021-08-04  5:31           ` kuan.ying lee
  1 sibling, 0 replies; 14+ messages in thread
From: Catalin Marinas @ 2021-07-30 15:24 UTC (permalink / raw)
  To: Andrey Konovalov
  Cc: Kuan-Ying Lee, Marco Elver, Nicholas Tang, Andrew Yang,
	Andrey Ryabinin, Alexander Potapenko, Chinwen Chang,
	Andrew Morton, kasan-dev, Linux Memory Management List, LKML,
	Linux ARM, moderated list:ARM/Mediatek SoC support

On Fri, Jul 30, 2021 at 04:57:20PM +0200, Andrey Konovalov wrote:
> On Tue, Jul 27, 2021 at 9:22 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
> >
> > On Tue, Jul 27, 2021 at 04:32:02PM +0800, Kuan-Ying Lee wrote:
> > > On Tue, 2021-07-27 at 09:10 +0200, Marco Elver wrote:
> > > > +Cc Catalin
> > > >
> > > > On Tue, 27 Jul 2021 at 06:00, Kuan-Ying Lee <
> > > > Kuan-Ying.Lee@mediatek.com> wrote:
> > > > >
> > > > > Hardware tag-based KASAN doesn't use compiler instrumentation, we
> > > > > can not use kasan_disable_current() to ignore tag check.
> > > > >
> > > > > Thus, we need to reset tags when accessing metadata.
> > > > >
> > > > > Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
> > > >
> > > > This looks reasonable, but the patch title is not saying this is
> > > > kmemleak, nor does the description say what the problem is. What
> > > > problem did you encounter? Was it a false positive?
> > >
> > > kmemleak would scan kernel memory to check memory leak.
> > > When it scans on the invalid slab and dereference, the issue
> > > will occur like below.
> > >
> > > So I think we should reset the tag before scanning.
> > >
> > > # echo scan > /sys/kernel/debug/kmemleak
> > > [  151.905804]
> > > ==================================================================
> > > [  151.907120] BUG: KASAN: out-of-bounds in scan_block+0x58/0x170
> > > [  151.908773] Read at addr f7ff0000c0074eb0 by task kmemleak/138
> > > [  151.909656] Pointer tag: [f7], memory tag: [fe]
> >
> > It would be interesting to find out why the tag doesn't match. Kmemleak
> > should in principle only scan valid objects that have been allocated and
> > the pointer can be safely dereferenced. 0xfe is KASAN_TAG_INVALID, so it
> > either goes past the size of the object (into the red zone) or it still
> > accesses the object after it was marked as freed but before being
> > released from kmemleak.
> >
> > With slab, looking at __cache_free(), it calls kasan_slab_free() before
> > ___cache_free() -> kmemleak_free_recursive(), so the second scenario is
> > possible. With slub, however, slab_free_hook() first releases the object
> > from kmemleak before poisoning it. Based on the stack dump, you are
> > using slub, so it may be that kmemleak goes into the object red zones.
> >
> > I'd like this clarified before blindly resetting the tag.
> 
> AFAIK, kmemleak scans the whole object including the leftover redzone
> for kmalloc-allocated objects.
> 
> Looking at the report, there are 11 0xf7 granules, which amounts to
> 176 bytes, and the object is allocated from the kmalloc-256 cache. So
> when kmemleak accesses the last 256-176 bytes, it causes faults, as
> those are marked with KASAN_KMALLOC_REDZONE == KASAN_TAG_INVALID ==
> 0xfe.
> 
> Generally, resetting tags in kasan_disable/enable_current() section
> should be fine to suppress MTE faults, provided those sections had
> been added correctly in the first place.

Thanks for the explanation, the patch makes sense. FWIW:

Acked-by: Catalin Marinas <catalin.marinas@arm.com>


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/2] kasan, mm: reset tag when access metadata
  2021-07-30 14:57         ` Andrey Konovalov
  2021-07-30 15:24           ` Catalin Marinas
@ 2021-08-04  5:31           ` kuan.ying lee
  1 sibling, 0 replies; 14+ messages in thread
From: kuan.ying lee @ 2021-08-04  5:31 UTC (permalink / raw)
  To: Andrey Konovalov, Catalin Marinas
  Cc: Marco Elver, Nicholas Tang, Andrew Yang, Andrey Ryabinin,
	Alexander Potapenko, Chinwen Chang, Andrew Morton, kasan-dev,
	Linux Memory Management List, LKML, Linux ARM,
	moderated list:ARM/Mediatek SoC support, kuan-ying.lee

On Fri, 2021-07-30 at 16:57 +0200, Andrey Konovalov wrote:
> On Tue, Jul 27, 2021 at 9:22 PM Catalin Marinas <
> catalin.marinas@arm.com> wrote:
> > 
> > On Tue, Jul 27, 2021 at 04:32:02PM +0800, Kuan-Ying Lee wrote:
> > > On Tue, 2021-07-27 at 09:10 +0200, Marco Elver wrote:
> > > > +Cc Catalin
> > > > 
> > > > On Tue, 27 Jul 2021 at 06:00, Kuan-Ying Lee <
> > > > Kuan-Ying.Lee@mediatek.com> wrote:
> > > > > 
> > > > > Hardware tag-based KASAN doesn't use compiler
> > > > > instrumentation, we
> > > > > can not use kasan_disable_current() to ignore tag check.
> > > > > 
> > > > > Thus, we need to reset tags when accessing metadata.
> > > > > 
> > > > > Signed-off-by: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
> > > > 
> > > > This looks reasonable, but the patch title is not saying this
> > > > is
> > > > kmemleak, nor does the description say what the problem is.
> > > > What
> > > > problem did you encounter? Was it a false positive?
> > > 
> > > kmemleak would scan kernel memory to check memory leak.
> > > When it scans on the invalid slab and dereference, the issue
> > > will occur like below.
> > > 
> > > So I think we should reset the tag before scanning.
> > > 
> > > # echo scan > /sys/kernel/debug/kmemleak
> > > [  151.905804]
> > > =================================================================
> > > =
> > > [  151.907120] BUG: KASAN: out-of-bounds in scan_block+0x58/0x170
> > > [  151.908773] Read at addr f7ff0000c0074eb0 by task kmemleak/138
> > > [  151.909656] Pointer tag: [f7], memory tag: [fe]
> > 
> > It would be interesting to find out why the tag doesn't match.
> > Kmemleak
> > should in principle only scan valid objects that have been
> > allocated and
> > the pointer can be safely dereferenced. 0xfe is KASAN_TAG_INVALID,
> > so it
> > either goes past the size of the object (into the red zone) or it
> > still
> > accesses the object after it was marked as freed but before being
> > released from kmemleak.
> > 
> > With slab, looking at __cache_free(), it calls kasan_slab_free()
> > before
> > ___cache_free() -> kmemleak_free_recursive(), so the second
> > scenario is
> > possible. With slub, however, slab_free_hook() first releases the
> > object
> > from kmemleak before poisoning it. Based on the stack dump, you are
> > using slub, so it may be that kmemleak goes into the object red
> > zones.
> > 
> > I'd like this clarified before blindly resetting the tag.
> 
> AFAIK, kmemleak scans the whole object including the leftover redzone
> for kmalloc-allocated objects.
> 
> Looking at the report, there are 11 0xf7 granules, which amounts to
> 176 bytes, and the object is allocated from the kmalloc-256 cache. So
> when kmemleak accesses the last 256-176 bytes, it causes faults, as
> those are marked with KASAN_KMALLOC_REDZONE == KASAN_TAG_INVALID ==
> 0xfe.
> 
> Generally, resetting tags in kasan_disable/enable_current() section
> should be fine to suppress MTE faults, provided those sections had
> been added correctly in the first place.

Thanks Andrey for explanation.
I will refine commit and upload v2.

Thanks.

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2021-08-04  5:31 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-27  4:00 [PATCH 0/2] kasan, mm: reset tag when access metadata Kuan-Ying Lee
2021-07-27  4:00 ` [PATCH 1/2] " Kuan-Ying Lee
2021-07-27  7:10   ` Marco Elver
2021-07-27  8:32     ` Kuan-Ying Lee
2021-07-27  9:34       ` Marco Elver
2021-07-27 19:22       ` Catalin Marinas
2021-07-28 11:05         ` Kuan-Ying Lee
2021-07-28 12:43           ` Marco Elver
2021-07-30 14:57         ` Andrey Konovalov
2021-07-30 15:24           ` Catalin Marinas
2021-08-04  5:31           ` kuan.ying lee
2021-07-27  4:00 ` [PATCH 2/2] kasan, mm: reset tag for hex dump address Kuan-Ying Lee
2021-07-27  7:20   ` Marco Elver
2021-07-27  8:54     ` Kuan-Ying Lee

This is a public inbox, see mirroring instructions
on how to clone and mirror all data and code used for this inbox