| Message ID | 20231121220155.1217090-15-iii@linux.ibm.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | kmsan: Enable on s390 | expand |
On Tue, Nov 21, 2023 at 11:02 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. The usage of > memset_no_sanitize_memory() does not degrade the generated code > quality. > > There are two alternatives to this approach. First, init_object() > can be marked with __no_sanitize_memory. This annotation should be used > with great care, because it drops all instrumentation from the > function, and any shadow writes will be lost. Even though this is not a > concern with the current init_object() implementation, this may change > in the future. > > Second, kmsan_poison_memory() calls may be added after memset() calls. > The downside is that init_object() is called from > free_debug_processing(), in which case poisoning will erase the > distinction between simply uninitialized memory and UAF. > > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> > --- > mm/kmsan/hooks.c | 2 +- > mm/slub.c | 10 ++++++---- > 2 files changed, 7 insertions(+), 5 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..169e5f645ea8 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -1030,7 +1030,8 @@ static void init_object(struct kmem_cache *s, void *object, u8 val) > unsigned int poison_size = s->object_size; > > if (s->flags & SLAB_RED_ZONE) { > - memset(p - s->red_left_pad, val, s->red_left_pad); > + memset_no_sanitize_memory(p - s->red_left_pad, val, As I wrote in patch 13/33, let's try to use __memset() here (with a comment that we want to preserve the previously poisoned memory)
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..169e5f645ea8 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -1030,7 +1030,8 @@ static void init_object(struct kmem_cache *s, void *object, u8 val) unsigned int poison_size = s->object_size; if (s->flags & SLAB_RED_ZONE) { - memset(p - s->red_left_pad, val, s->red_left_pad); + memset_no_sanitize_memory(p - s->red_left_pad, val, + s->red_left_pad); if (slub_debug_orig_size(s) && val == SLUB_RED_ACTIVE) { /* @@ -1043,12 +1044,13 @@ static void init_object(struct kmem_cache *s, void *object, u8 val) } if (s->flags & __OBJECT_POISON) { - memset(p, POISON_FREE, poison_size - 1); - p[poison_size - 1] = POISON_END; + memset_no_sanitize_memory(p, POISON_FREE, poison_size - 1); + memset_no_sanitize_memory(p + poison_size - 1, POISON_END, 1); } if (s->flags & SLAB_RED_ZONE) - memset(p + poison_size, val, s->inuse - poison_size); + memset_no_sanitize_memory(p + poison_size, val, + s->inuse - poison_size); } static void restore_bytes(struct kmem_cache *s, char *message, u8 data,
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. The usage of memset_no_sanitize_memory() does not degrade the generated code quality. There are two alternatives to this approach. First, init_object() can be marked with __no_sanitize_memory. This annotation should be used with great care, because it drops all instrumentation from the function, and any shadow writes will be lost. Even though this is not a concern with the current init_object() implementation, this may change in the future. Second, kmsan_poison_memory() calls may be added after memset() calls. The downside is that init_object() is called from free_debug_processing(), in which case poisoning will erase the distinction between simply uninitialized memory and UAF. Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> --- mm/kmsan/hooks.c | 2 +- mm/slub.c | 10 ++++++---- 2 files changed, 7 insertions(+), 5 deletions(-)