linux-kernel - Re: [PATCH 13/32] kmsan: Support SLAB

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:   Thu, 16 Nov 2023 16:08:15 +0100
From:   Ilya Leoshkevich <iii@...ux.ibm.com>
To:     Alexander Potapenko <glider@...gle.com>
Cc:     Alexander Gordeev <agordeev@...ux.ibm.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Christoph Lameter <cl@...ux.com>,
        David Rientjes <rientjes@...gle.com>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        Marco Elver <elver@...gle.com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Pekka Enberg <penberg@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Hyeonggon Yoo <42.hyeyoo@...il.com>,
        kasan-dev@...glegroups.com, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, linux-s390@...r.kernel.org,
        linux-trace-kernel@...r.kernel.org,
        Mark Rutland <mark.rutland@....com>,
        Roman Gushchin <roman.gushchin@...ux.dev>,
        Sven Schnelle <svens@...ux.ibm.com>
Subject: Re: [PATCH 13/32] kmsan: Support SLAB_POISON

On Thu, 2023-11-16 at 15:55 +0100, Alexander Potapenko wrote:
> On Wed, Nov 15, 2023 at 9:34 PM Ilya Leoshkevich <iii@...ux.ibm.com>
> wrote:
> > 
> > Avoid false KMSAN negatives with SLUB_DEBUG by allowing
> > kmsan_slab_free() to poison the freed memory, and by preventing
> > init_object() from unpoisoning new allocations.
> > 
> > Signed-off-by: Ilya Leoshkevich <iii@...ux.ibm.com>
> > ---
> >  mm/kmsan/hooks.c | 2 +-
> >  mm/slub.c        | 3 ++-
> >  2 files changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/mm/kmsan/hooks.c b/mm/kmsan/hooks.c
> > index 7b5814412e9f..7a30274b893c 100644
> > --- a/mm/kmsan/hooks.c
> > +++ b/mm/kmsan/hooks.c
> > @@ -76,7 +76,7 @@ void kmsan_slab_free(struct kmem_cache *s, void
> > *object)
> >                 return;
> > 
> >         /* RCU slabs could be legally used after free within the
> > RCU period */
> > -       if (unlikely(s->flags & (SLAB_TYPESAFE_BY_RCU |
> > SLAB_POISON)))
> > +       if (unlikely(s->flags & SLAB_TYPESAFE_BY_RCU))
> >                 return;
> >         /*
> >          * If there's a constructor, freed memory must remain in
> > the same state
> > diff --git a/mm/slub.c b/mm/slub.c
> > index 63d281dfacdb..8d9aa4d7cb7e 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -1024,7 +1024,8 @@ static __printf(3, 4) void slab_err(struct
> > kmem_cache *s, struct slab *slab,
> >         add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE);
> >  }
> > 
> > -static void init_object(struct kmem_cache *s, void *object, u8
> > val)
> > +__no_sanitize_memory static void
> 
> __no_sanitize_memory should be used with great care, because it drops
> all instrumentation from the function, and any shadow writes will be
> lost.
> Won't it be better to add kmsan_poison() to init_object() if you want
> it to stay uninitialized?

I wanted to avoid a ping-pong here, in which we already have properly
poisoned memory, then memset() incorrectly unpoisons it, and then we
undo the damage. My first attempt involved using __memset() instead,
but this resulted in worse assembly code. I wish there were something
like memset_noinstr().

Right now init_object() doesn't seem to be doing anything besides these
memset()s, but this can of course change in the future. So I don't mind
using kmsan_poison() instead of __no_sanitize_memory here too much,
since it results in better maintainability.