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]
Message-ID: <46b1468146206e6cef0c33ecbfd86e02ea819db4.camel@mediatek.com>
Date:   Tue, 22 Jun 2021 18:48:13 +0800
From:   Yee Lee <yee.lee@...iatek.com>
To:     Marco Elver <elver@...gle.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: [v2]unpoison use memzero to init unaligned object

On Tue, 2021-06-22 at 11:01 +0200, Marco Elver wrote:
> On Tue, 22 Jun 2021 at 10:48, <yee.lee@...iatek.com> wrote:
> > 
> > From: Yee Lee <yee.lee@...iatek.com>
> > 
> > Follows the discussion: 
> > https://patchwork.kernel.org/project/linux-mediatek/list/?series=504439
> 
> The info about the percentage of how frequent this is could have been
> provided as a simple reply to the discussion.
> 
> > This patch Add memzero_explict to initialize unaligned object.
> 
> This patch does not apply to anything (I see it depends on the
> previous patch).
> 
> What you need to do is modify the original patch, and then send a
> [PATCH v2] (git helps with that by passing --reroll-count or -v) that
> applies cleanly to your base kernel tree.
> 
> The commit message will usually end with '---' and then briefly
> denote
> what changed since the last version.
> 
Got it.

> 
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#the-canonical-patch-format
> 
> > Based on the integrateion of initialization in kasan_unpoison().
> > The hwtag instructions, constrained with its granularity, has to
> > overwrite the data btyes in unaligned objects. This would cause
> > issue when it works with SLUB debug redzoning.
> > 
> > In this patch, an additional initalizaing path is added for the
> > unaligned objects. It contains memzero_explict() to clear out the
> > data and disables its init flag for the following hwtag actions.
> > 
> > In lab test, this path is executed about 1.1%(941/80854) within the
> > overall kasan_unpoison during a non-debug booting process.
> 
> Nice, thanks for the data. If it is somehow doable, however, I'd
> still
> recommend to additionally guard the new code path by a check if
> debug-support was requested. Ideally with an IS_ENABLED() config
> check
> so that if it's a production kernel the branch is simply optimized
> out
> by the compiler.

Does it mean the memzero code path would be applied only at
CONFIG_DEBUG_SLUB enabled? It expects no other potential overwriting
in non-debug kernel.
 
By the way, based on de-coupling principle, adding a specific
conditional statement(is_enable slub_debug) in a primitive
funciton(kasan_unpoison) is not neat. It may be more proper that the
conditional statement be added in other procedures of slub alloc.
 
Thanks,

BR,
Yee

> 
> > Lab test: QEMU5.2 (+mte) / linux kernel 5.13-rc7
> > 
> > Signed-off-by: Yee Lee <yee.lee@...iatek.com>
> > ---
> >  mm/kasan/kasan.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> > index d8faa64614b7..edc11bcc3ff3 100644
> > --- a/mm/kasan/kasan.h
> > +++ b/mm/kasan/kasan.h
> > @@ -389,7 +389,7 @@ static inline void kasan_unpoison(const void
> > *addr, size_t size, bool init)
> >                 return;
> >         if (init && ((unsigned long)size & KASAN_GRANULE_MASK)) {
> >                 init = false;
> > -               memset((void *)addr, 0, size);
> > +               memzero_explicit((void *)addr, size);
> >         }
> >         size = round_up(size, KASAN_GRANULE_SIZE);
> >         hw_set_mem_tag_range((void *)addr, size, tag, init);
> > 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@...glegroups.com.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/kasan-dev/20210622084723.27637-1-yee.lee%40mediatek.com
> > .

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ