Re: [PATCH 13/32] kmsan: Support SLAB_POISON

[Ilya Leoshkevich <iii@linux.ibm.com>]

On Thu, 2023-11-16 at 15:55 +0100, Alexander Potapenko wrote:
> On Wed, Nov 15, 2023 at 9:34 PM Ilya Leoshkevich <iii@linux.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@linux.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.