Message-ID: <CANpmjNO+spktteYZezk7PGLFOyoeuFyziKiU-1GXbpeyKLZLPg@mail.gmail.com>
Date:   Wed, 5 Jul 2023 14:50:30 +0200
From:   Marco Elver <elver@...gle.com>
To:     andrey.konovalov@...ux.dev
Cc:     Mark Rutland <mark.rutland@....com>,
        Andrey Konovalov <andreyknvl@...il.com>,
        Alexander Potapenko <glider@...gle.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Andrey Ryabinin <ryabinin.a.a@...il.com>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        kasan-dev@...glegroups.com,
        Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        Catalin Marinas <catalin.marinas@....com>,
        Peter Collingbourne <pcc@...gle.com>,
        Feng Tang <feng.tang@...el.com>, stable@...r.kernel.org,
        Christoph Lameter <cl@...ux.com>,
        Pekka Enberg <penberg@...nel.org>,
        David Rientjes <rientjes@...gle.com>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Roman Gushchin <roman.gushchin@...ux.dev>,
        Hyeonggon Yoo <42.hyeyoo@...il.com>,
        linux-kernel@...r.kernel.org,
        Andrey Konovalov <andreyknvl@...gle.com>
Subject: Re: [PATCH] kasan, slub: fix HW_TAGS zeroing with slub_debug

On Wed, 5 Jul 2023 at 14:44, <andrey.konovalov@...ux.dev> wrote:
>
> From: Andrey Konovalov <andreyknvl@...gle.com>
>
> 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: <stable@...r.kernel.org>
> Reported-by: Mark Rutland <mark.rutland@....com>

Is it fixing this issue:

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

Or some other issue?

> Signed-off-by: Andrey Konovalov <andreyknvl@...gle.com>

Other than the question above, it looks sane:

Acked-by: Marco Elver <elver@...gle.com>

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

Powered by blists - more mailing lists