2023-07-05 12:57:08

by andrey.konovalov

[permalink] [raw]
Subject: [PATCH] kasan, slub: fix HW_TAGS zeroing with slub_debug

From: Andrey Konovalov <[email protected]>

Commit 946fa0dbf2d8 ("mm/slub: extend redzone check to extra allocated
kmalloc space than requested") added precise kmalloc redzone poisoning
to the slub_debug functionality.

However, this commit didn't account for HW_TAGS KASAN fully initializing
the object via its built-in memory initialization feature. Even though
HW_TAGS KASAN memory initialization contains special memory initialization
handling for when slub_debug is enabled, it does not account for in-object
slub_debug redzones. As a result, HW_TAGS KASAN can overwrite these
redzones and cause false-positive slub_debug reports.

To fix the issue, avoid HW_TAGS KASAN memory initialization when slub_debug
is enabled altogether. Implement this by moving the __slub_debug_enabled
check to slab_post_alloc_hook. Common slab code seems like a more
appropriate place for a slub_debug check anyway.

Fixes: 946fa0dbf2d8 ("mm/slub: extend redzone check to extra allocated kmalloc space than requested")
Cc: <[email protected]>
Reported-by: Mark Rutland <[email protected]>
Signed-off-by: Andrey Konovalov <[email protected]>
---
mm/kasan/kasan.h | 12 ------------
mm/slab.h | 16 ++++++++++++++--
2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
index b799f11e45dc..2e973b36fe07 100644
--- a/mm/kasan/kasan.h
+++ b/mm/kasan/kasan.h
@@ -466,18 +466,6 @@ static inline void kasan_unpoison(const void *addr, size_t size, bool init)

if (WARN_ON((unsigned long)addr & KASAN_GRANULE_MASK))
return;
- /*
- * Explicitly initialize the memory with the precise object size to
- * avoid overwriting the slab redzone. This disables initialization in
- * the arch code and may thus lead to performance penalty. This penalty
- * does not affect production builds, as slab redzones are not enabled
- * there.
- */
- if (__slub_debug_enabled() &&
- init && ((unsigned long)size & KASAN_GRANULE_MASK)) {
- init = false;
- memzero_explicit((void *)addr, size);
- }
size = round_up(size, KASAN_GRANULE_SIZE);

hw_set_mem_tag_range((void *)addr, size, tag, init);
diff --git a/mm/slab.h b/mm/slab.h
index 6a5633b25eb5..9c0e09d0f81f 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -723,6 +723,7 @@ static inline void slab_post_alloc_hook(struct kmem_cache *s,
unsigned int orig_size)
{
unsigned int zero_size = s->object_size;
+ bool kasan_init = init;
size_t i;

flags &= gfp_allowed_mask;
@@ -739,6 +740,17 @@ static inline void slab_post_alloc_hook(struct kmem_cache *s,
(s->flags & SLAB_KMALLOC))
zero_size = orig_size;

+ /*
+ * When slub_debug is enabled, avoid memory initialization integrated
+ * into KASAN and instead zero out the memory via the memset below with
+ * the proper size. Otherwise, KASAN might overwrite SLUB redzones and
+ * cause false-positive reports. This does not lead to a performance
+ * penalty on production builds, as slub_debug is not intended to be
+ * enabled there.
+ */
+ if (__slub_debug_enabled())
+ kasan_init = false;
+
/*
* As memory initialization might be integrated into KASAN,
* kasan_slab_alloc and initialization memset must be
@@ -747,8 +759,8 @@ static inline void slab_post_alloc_hook(struct kmem_cache *s,
* As p[i] might get tagged, memset and kmemleak hook come after KASAN.
*/
for (i = 0; i < size; i++) {
- p[i] = kasan_slab_alloc(s, p[i], flags, init);
- if (p[i] && init && !kasan_has_integrated_init())
+ p[i] = kasan_slab_alloc(s, p[i], flags, kasan_init);
+ if (p[i] && init && (!kasan_init || !kasan_has_integrated_init()))
memset(p[i], 0, zero_size);
kmemleak_alloc_recursive(p[i], s->object_size, 1,
s->flags, flags);
--
2.25.1



2023-07-05 13:05:42

by Marco Elver

[permalink] [raw]
Subject: Re: [PATCH] kasan, slub: fix HW_TAGS zeroing with slub_debug

On Wed, 5 Jul 2023 at 14:44, <[email protected]> wrote:
>
> From: Andrey Konovalov <[email protected]>
>
> Commit 946fa0dbf2d8 ("mm/slub: extend redzone check to extra allocated
> kmalloc space than requested") added precise kmalloc redzone poisoning
> to the slub_debug functionality.
>
> However, this commit didn't account for HW_TAGS KASAN fully initializing
> the object via its built-in memory initialization feature. Even though
> HW_TAGS KASAN memory initialization contains special memory initialization
> handling for when slub_debug is enabled, it does not account for in-object
> slub_debug redzones. As a result, HW_TAGS KASAN can overwrite these
> redzones and cause false-positive slub_debug reports.
>
> To fix the issue, avoid HW_TAGS KASAN memory initialization when slub_debug
> is enabled altogether. Implement this by moving the __slub_debug_enabled
> check to slab_post_alloc_hook. Common slab code seems like a more
> appropriate place for a slub_debug check anyway.
>
> Fixes: 946fa0dbf2d8 ("mm/slub: extend redzone check to extra allocated kmalloc space than requested")
> Cc: <[email protected]>
> Reported-by: Mark Rutland <[email protected]>

Is it fixing this issue:

https://lore.kernel.org/all/20230628154714.GB22090@willie-the-truck/

Or some other issue?

> Signed-off-by: Andrey Konovalov <[email protected]>

Other than the question above, it looks sane:

Acked-by: Marco Elver <[email protected]>

> ---
> mm/kasan/kasan.h | 12 ------------
> mm/slab.h | 16 ++++++++++++++--
> 2 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> index b799f11e45dc..2e973b36fe07 100644
> --- a/mm/kasan/kasan.h
> +++ b/mm/kasan/kasan.h
> @@ -466,18 +466,6 @@ static inline void kasan_unpoison(const void *addr, size_t size, bool init)
>
> if (WARN_ON((unsigned long)addr & KASAN_GRANULE_MASK))
> return;
> - /*
> - * Explicitly initialize the memory with the precise object size to
> - * avoid overwriting the slab redzone. This disables initialization in
> - * the arch code and may thus lead to performance penalty. This penalty
> - * does not affect production builds, as slab redzones are not enabled
> - * there.
> - */
> - if (__slub_debug_enabled() &&
> - init && ((unsigned long)size & KASAN_GRANULE_MASK)) {
> - init = false;
> - memzero_explicit((void *)addr, size);
> - }
> size = round_up(size, KASAN_GRANULE_SIZE);
>
> hw_set_mem_tag_range((void *)addr, size, tag, init);
> diff --git a/mm/slab.h b/mm/slab.h
> index 6a5633b25eb5..9c0e09d0f81f 100644
> --- a/mm/slab.h
> +++ b/mm/slab.h
> @@ -723,6 +723,7 @@ static inline void slab_post_alloc_hook(struct kmem_cache *s,
> unsigned int orig_size)
> {
> unsigned int zero_size = s->object_size;
> + bool kasan_init = init;
> size_t i;
>
> flags &= gfp_allowed_mask;
> @@ -739,6 +740,17 @@ static inline void slab_post_alloc_hook(struct kmem_cache *s,
> (s->flags & SLAB_KMALLOC))
> zero_size = orig_size;
>
> + /*
> + * When slub_debug is enabled, avoid memory initialization integrated
> + * into KASAN and instead zero out the memory via the memset below with
> + * the proper size. Otherwise, KASAN might overwrite SLUB redzones and
> + * cause false-positive reports. This does not lead to a performance
> + * penalty on production builds, as slub_debug is not intended to be
> + * enabled there.
> + */
> + if (__slub_debug_enabled())
> + kasan_init = false;
> +
> /*
> * As memory initialization might be integrated into KASAN,
> * kasan_slab_alloc and initialization memset must be
> @@ -747,8 +759,8 @@ static inline void slab_post_alloc_hook(struct kmem_cache *s,
> * As p[i] might get tagged, memset and kmemleak hook come after KASAN.
> */
> for (i = 0; i < size; i++) {
> - p[i] = kasan_slab_alloc(s, p[i], flags, init);
> - if (p[i] && init && !kasan_has_integrated_init())
> + p[i] = kasan_slab_alloc(s, p[i], flags, kasan_init);
> + if (p[i] && init && (!kasan_init || !kasan_has_integrated_init()))
> memset(p[i], 0, zero_size);
> kmemleak_alloc_recursive(p[i], s->object_size, 1,
> s->flags, flags);
> --
> 2.25.1
>

2023-07-05 13:41:41

by Andrey Konovalov

[permalink] [raw]
Subject: Re: [PATCH] kasan, slub: fix HW_TAGS zeroing with slub_debug

On Wed, Jul 5, 2023 at 2:51 PM Marco Elver <[email protected]> wrote:
>
> On Wed, 5 Jul 2023 at 14:44, <[email protected]> wrote:
> >
> > From: Andrey Konovalov <[email protected]>
> >
> > Commit 946fa0dbf2d8 ("mm/slub: extend redzone check to extra allocated
> > kmalloc space than requested") added precise kmalloc redzone poisoning
> > to the slub_debug functionality.
> >
> > However, this commit didn't account for HW_TAGS KASAN fully initializing
> > the object via its built-in memory initialization feature. Even though
> > HW_TAGS KASAN memory initialization contains special memory initialization
> > handling for when slub_debug is enabled, it does not account for in-object
> > slub_debug redzones. As a result, HW_TAGS KASAN can overwrite these
> > redzones and cause false-positive slub_debug reports.
> >
> > To fix the issue, avoid HW_TAGS KASAN memory initialization when slub_debug
> > is enabled altogether. Implement this by moving the __slub_debug_enabled
> > check to slab_post_alloc_hook. Common slab code seems like a more
> > appropriate place for a slub_debug check anyway.
> >
> > Fixes: 946fa0dbf2d8 ("mm/slub: extend redzone check to extra allocated kmalloc space than requested")
> > Cc: <[email protected]>
> > Reported-by: Mark Rutland <[email protected]>
>
> Is it fixing this issue:
>
> https://lore.kernel.org/all/20230628154714.GB22090@willie-the-truck/

Yes, my bad, messed up the Reported-by tag. The correct one should be:

Reported-by: Will Deacon <[email protected]>

> Other than the question above, it looks sane:
>
> Acked-by: Marco Elver <[email protected]>

Thank you, Marco!

2023-07-06 09:54:50

by Will Deacon

[permalink] [raw]
Subject: Re: [PATCH] kasan, slub: fix HW_TAGS zeroing with slub_debug

On Wed, Jul 05, 2023 at 03:19:06PM +0200, Andrey Konovalov wrote:
> On Wed, Jul 5, 2023 at 2:51 PM Marco Elver <[email protected]> wrote:
> >
> > On Wed, 5 Jul 2023 at 14:44, <[email protected]> wrote:
> > >
> > > From: Andrey Konovalov <[email protected]>
> > >
> > > Commit 946fa0dbf2d8 ("mm/slub: extend redzone check to extra allocated
> > > kmalloc space than requested") added precise kmalloc redzone poisoning
> > > to the slub_debug functionality.
> > >
> > > However, this commit didn't account for HW_TAGS KASAN fully initializing
> > > the object via its built-in memory initialization feature. Even though
> > > HW_TAGS KASAN memory initialization contains special memory initialization
> > > handling for when slub_debug is enabled, it does not account for in-object
> > > slub_debug redzones. As a result, HW_TAGS KASAN can overwrite these
> > > redzones and cause false-positive slub_debug reports.
> > >
> > > To fix the issue, avoid HW_TAGS KASAN memory initialization when slub_debug
> > > is enabled altogether. Implement this by moving the __slub_debug_enabled
> > > check to slab_post_alloc_hook. Common slab code seems like a more
> > > appropriate place for a slub_debug check anyway.
> > >
> > > Fixes: 946fa0dbf2d8 ("mm/slub: extend redzone check to extra allocated kmalloc space than requested")
> > > Cc: <[email protected]>
> > > Reported-by: Mark Rutland <[email protected]>
> >
> > Is it fixing this issue:
> >
> > https://lore.kernel.org/all/20230628154714.GB22090@willie-the-truck/
>
> Yes, my bad, messed up the Reported-by tag. The correct one should be:
>
> Reported-by: Will Deacon <[email protected]>
>
> > Other than the question above, it looks sane:
> >
> > Acked-by: Marco Elver <[email protected]>
>
> Thank you, Marco!

Cheers, this seems to fix the splats for me:

Tested-by: Will Deacon <[email protected]>

Will

2023-07-10 10:19:24

by Vlastimil Babka

[permalink] [raw]
Subject: Re: [PATCH] kasan, slub: fix HW_TAGS zeroing with slub_debug

On 7/5/23 14:44, [email protected] wrote:
> From: Andrey Konovalov <[email protected]>
>
> Commit 946fa0dbf2d8 ("mm/slub: extend redzone check to extra allocated
> kmalloc space than requested") added precise kmalloc redzone poisoning
> to the slub_debug functionality.
>
> However, this commit didn't account for HW_TAGS KASAN fully initializing
> the object via its built-in memory initialization feature. Even though
> HW_TAGS KASAN memory initialization contains special memory initialization
> handling for when slub_debug is enabled, it does not account for in-object
> slub_debug redzones. As a result, HW_TAGS KASAN can overwrite these
> redzones and cause false-positive slub_debug reports.
>
> To fix the issue, avoid HW_TAGS KASAN memory initialization when slub_debug
> is enabled altogether. Implement this by moving the __slub_debug_enabled
> check to slab_post_alloc_hook. Common slab code seems like a more
> appropriate place for a slub_debug check anyway.
>
> Fixes: 946fa0dbf2d8 ("mm/slub: extend redzone check to extra allocated kmalloc space than requested")
> Cc: <[email protected]>
> Reported-by: Mark Rutland <[email protected]>
> Signed-off-by: Andrey Konovalov <[email protected]>

Acked-by: Vlastimil Babka <[email protected]>

Thanks!