linux-kernel - Re: [PATCH] kasan: unpoison use memset to init unaligned object size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 21 Jun 2021 19:42:50 +0200
From:   Marco Elver <elver@...gle.com>
To:     yee.lee@...iatek.com
Cc:     andreyknvl@...il.com, wsd_upstream@...iatek.com,
        Andrey Ryabinin <ryabinin.a.a@...il.com>,
        Alexander Potapenko <glider@...gle.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        "open list:KASAN" <kasan-dev@...glegroups.com>,
        "open list:MEMORY MANAGEMENT" <linux-mm@...ck.org>,
        open list <linux-kernel@...r.kernel.org>,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-arm-kernel@...ts.infradead.org>,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-mediatek@...ts.infradead.org>
Subject: Re: [PATCH] kasan: unpoison use memset to init unaligned object size

On Mon, 21 Jun 2021 at 17:45, <yee.lee@...iatek.com> wrote:
>
> From: Yee Lee <yee.lee@...iatek.com>
>
> This patch adds a memset to initialize object of unaligned size.

s/This patch adds/Add/

> Duing to the MTE granulrity, the integrated initialization using

s/Duing/Doing/
s/granulrity/granularity/

> hwtag instruction will force clearing out bytes in granular size,
> which may cause undesired effect, such as overwriting to the redzone
> of SLUB debug. In this patch, for the unaligned object size, function

Did you encounter a crash due to this? Was it only SLUB debug that
caused the problem?

Do you have data on what the percentage of allocations are that would
now be treated differently? E.g. what's the percentage of such
odd-sized allocations during a normal boot with SLUB debug off?

We need to know if this change would pessimize a non-debug kernel, and
if so, we'd have to make the below behave differently.

> uses memset to initailize context instead of the hwtag instruction.

s/initailize/initialize/

> Signed-off-by: Yee Lee <yee.lee@...iatek.com>
> ---
>  mm/kasan/kasan.h | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> index 8f450bc28045..d8faa64614b7 100644
> --- a/mm/kasan/kasan.h
> +++ b/mm/kasan/kasan.h
> @@ -387,8 +387,11 @@ static inline void kasan_unpoison(const void *addr, size_t size, bool init)
>
>         if (WARN_ON((unsigned long)addr & KASAN_GRANULE_MASK))
>                 return;
> +       if (init && ((unsigned long)size & KASAN_GRANULE_MASK)) {
> +               init = false;
> +               memset((void *)addr, 0, size);

Should use memzero_explicit().

> +       }
>         size = round_up(size, KASAN_GRANULE_SIZE);
> -

Remove whitespace change.

>         hw_set_mem_tag_range((void *)addr, size, tag, init);
>  }

Thanks,
-- Marco