From: Walter Wu <walter-zh.wu@mediatek.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: David Gow <davidgow@google.com>,
Brendan Higgins <brendanhiggins@google.com>,
Patricia Alfonso <trishalfonso@google.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Alexander Potapenko <glider@google.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
"Andrey Konovalov" <andreyknvl@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
kasan-dev <kasan-dev@googlegroups.com>,
Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
wsd_upstream <wsd_upstream@mediatek.com>,
<linux-mediatek@lists.infradead.org>
Subject: Re: [PATCH] kasan: fix KASAN unit tests for tag-based KASAN
Date: Tue, 21 Apr 2020 21:37:52 +0800 [thread overview]
Message-ID: <1587476272.5870.15.camel@mtksdccf07> (raw)
In-Reply-To: <CACT4Y+avYV1xoqB6V5XrQSs-p2s3mKKu+LZQc4EzPaW-jV+KaA@mail.gmail.com>
On Tue, 2020-04-21 at 15:01 +0200, 'Dmitry Vyukov' via kasan-dev wrote:
> On Tue, Apr 21, 2020 at 2:26 PM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> >
> > Hi Dmitry,
> >
> > On Tue, 2020-04-21 at 13:56 +0200, Dmitry Vyukov wrote:
> > > On Tue, Apr 21, 2020 at 3:40 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> > > >
> > > > When we use tag-based KASAN, then KASAN unit tests don't detect
> > > > out-of-bounds memory access. Because with tag-based KASAN the state
> > > > of each 16 aligned bytes of memory is encoded in one shadow byte
> > > > and the shadow value is tag of pointer, so we need to read next
> > > > shadow byte, the shadow value is not equal to tag of pointer,
> > > > then tag-based KASAN will detect out-of-bounds memory access.
> > > >
> > > > Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> > > > Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> > > > Cc: Dmitry Vyukov <dvyukov@google.com>
> > > > Cc: Alexander Potapenko <glider@google.com>
> > > > Cc: Matthias Brugger <matthias.bgg@gmail.com>
> > > > Cc: Andrey Konovalov <andreyknvl@google.com>
> > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > ---
> > > > lib/test_kasan.c | 62 ++++++++++++++++++++++++++++++++++++++++++------
> > > > 1 file changed, 55 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/lib/test_kasan.c b/lib/test_kasan.c
> > > > index e3087d90e00d..a164f6b47fe5 100644
> > > > --- a/lib/test_kasan.c
> > > > +++ b/lib/test_kasan.c
> > > > @@ -40,7 +40,12 @@ static noinline void __init kmalloc_oob_right(void)
> > > > return;
> > > > }
> > >
> > > Hi Walter,
> > >
> > > This would be great to have!
> > > But I am concerned about these series that port KASAN tests to KUNIT:
> > > https://lkml.org/lkml/2020/4/17/1144
> > > I suspect it will be one large merge conflict. Not sure what is the
> > > proper way to resovle this. I've added authors to CC.
> > >
> > Yes, it should have conflicts. Thanks for your reminder.
> > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > ptr[size] = 'x';
> > > > +#else
> > > > + ptr[size + 5] = 'x';
> > > > +#endif
> > > > +
> > >
> > > For this particular snippet I think we can reduce amount of idef'ery
> > > and amount of non-compiled code in each configuration with something
> > > like:
> > >
> > > ptr[size + 5] = 'x';
> > > if (ENABLED(CONFIG_KASAN_GENERIC))
> > > ptr[size] = 'x';
> > >
> > > One check runs always (it should pass in both configs, right?). The
> >
> > There is a problem, With generic KASAN it may trigger two KASAN reports.
>
> Why is this a problem? If there are 2, fine. KUNIT can check that if
> we expect 2, there are indeed 2.
>
Sorry, I originally assume my patch doesn't include in KUNIT. so I think
there is a problem. but I know your meaning. Can my patch upstream
first?
> > if we change it like:
> >
> > if (ENABLED(CONFIG_KASAN_GENERIC))
> > ptr[size] = 'x';
> > else
> > ptr[size + 5] = 'x';
> >
> > > only only in GENERIC, but it's C-level if rather than preprocessor.
> > > KUNIT should make 2 bugs per test easily expressable (and testable).
> > >
> >
> > >
> > >
> > >
> > > > kfree(ptr);
> > > > }
> > > >
> > > > @@ -92,7 +97,12 @@ static noinline void __init kmalloc_pagealloc_oob_right(void)
> > > > return;
> > > > }
> > > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > ptr[size] = 0;
> > > > +#else
> > > > + ptr[size + 6] = 0;
> > > > +#endif
> > > > +
> > > > kfree(ptr);
> > > > }
> > > >
> > > > @@ -162,7 +172,11 @@ static noinline void __init kmalloc_oob_krealloc_more(void)
> > > > return;
> > > > }
> > > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > ptr2[size2] = 'x';
> > > > +#else
> > > > + ptr2[size2 + 13] = 'x';
> > > > +#endif
> > > > kfree(ptr2);
> > > > }
> > > >
> > > > @@ -180,7 +194,12 @@ static noinline void __init kmalloc_oob_krealloc_less(void)
> > > > kfree(ptr1);
> > > > return;
> > > > }
> > > > +
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > ptr2[size2] = 'x';
> > > > +#else
> > > > + ptr2[size2 + 2] = 'x';
> > > > +#endif
> > > > kfree(ptr2);
> > > > }
> > > >
> > > > @@ -216,7 +235,11 @@ static noinline void __init kmalloc_oob_memset_2(void)
> > > > return;
> > > > }
> > > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > memset(ptr+7, 0, 2);
> > > > +#else
> > > > + memset(ptr+15, 0, 2);
> > > > +#endif
> > > > kfree(ptr);
> > > > }
> > > >
> > > > @@ -232,7 +255,11 @@ static noinline void __init kmalloc_oob_memset_4(void)
> > > > return;
> > > > }
> > > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > memset(ptr+5, 0, 4);
> > > > +#else
> > > > + memset(ptr+15, 0, 4);
> > > > +#endif
> > > > kfree(ptr);
> > > > }
> > > >
> > > > @@ -249,7 +276,11 @@ static noinline void __init kmalloc_oob_memset_8(void)
> > > > return;
> > > > }
> > > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > memset(ptr+1, 0, 8);
> > > > +#else
> > > > + memset(ptr+15, 0, 8);
> > > > +#endif
> > > > kfree(ptr);
> > > > }
> > > >
> > > > @@ -265,7 +296,11 @@ static noinline void __init kmalloc_oob_memset_16(void)
> > > > return;
> > > > }
> > > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > memset(ptr+1, 0, 16);
> > > > +#else
> > > > + memset(ptr+15, 0, 16);
> > > > +#endif
> > > > kfree(ptr);
> > > > }
> > > >
> > > > @@ -281,7 +316,11 @@ static noinline void __init kmalloc_oob_in_memset(void)
> > > > return;
> > > > }
> > > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > memset(ptr, 0, size+5);
> > > > +#else
> > > > + memset(ptr, 0, size+7);
> > > > +#endif
> > > > kfree(ptr);
> > > > }
> > > >
> > > > @@ -415,7 +454,11 @@ static noinline void __init kmem_cache_oob(void)
> > > > return;
> > > > }
> > > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > *p = p[size];
> > > > +#else
> > > > + *p = p[size + 8];
> > > > +#endif
> > > > kmem_cache_free(cache, p);
> > > > kmem_cache_destroy(cache);
> > > > }
> > > > @@ -497,6 +540,11 @@ static noinline void __init copy_user_test(void)
> > > > char __user *usermem;
> > > > size_t size = 10;
> > > > int unused;
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > + size_t oob_size = 1;
> > > > +#else
> > > > + size_t oob_size = 7;
> > > > +#endif
> > > >
> > > > kmem = kmalloc(size, GFP_KERNEL);
> > > > if (!kmem)
> > > > @@ -512,25 +560,25 @@ static noinline void __init copy_user_test(void)
> > > > }
> > > >
> > > > pr_info("out-of-bounds in copy_from_user()\n");
> > > > - unused = copy_from_user(kmem, usermem, size + 1);
> > > > + unused = copy_from_user(kmem, usermem, size + oob_size);
> > > >
> > > > pr_info("out-of-bounds in copy_to_user()\n");
> > > > - unused = copy_to_user(usermem, kmem, size + 1);
> > > > + unused = copy_to_user(usermem, kmem, size + oob_size);
> > > >
> > > > pr_info("out-of-bounds in __copy_from_user()\n");
> > > > - unused = __copy_from_user(kmem, usermem, size + 1);
> > > > + unused = __copy_from_user(kmem, usermem, size + oob_size);
> > > >
> > > > pr_info("out-of-bounds in __copy_to_user()\n");
> > > > - unused = __copy_to_user(usermem, kmem, size + 1);
> > > > + unused = __copy_to_user(usermem, kmem, size + oob_size);
> > > >
> > > > pr_info("out-of-bounds in __copy_from_user_inatomic()\n");
> > > > - unused = __copy_from_user_inatomic(kmem, usermem, size + 1);
> > > > + unused = __copy_from_user_inatomic(kmem, usermem, size + oob_size);
> > > >
> > > > pr_info("out-of-bounds in __copy_to_user_inatomic()\n");
> > > > - unused = __copy_to_user_inatomic(usermem, kmem, size + 1);
> > > > + unused = __copy_to_user_inatomic(usermem, kmem, size + oob_size);
> > > >
> > > > pr_info("out-of-bounds in strncpy_from_user()\n");
> > > > - unused = strncpy_from_user(kmem, usermem, size + 1);
> > > > + unused = strncpy_from_user(kmem, usermem, size + oob_size);
> > > >
> > > > vm_munmap((unsigned long)usermem, PAGE_SIZE);
> > > > kfree(kmem);
> > > > --
> > > > 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@googlegroups.com.
> > > > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20200421014007.6012-1-walter-zh.wu%40mediatek.com.
> >
> > --
> > 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@googlegroups.com.
> > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/1587472005.5870.7.camel%40mtksdccf07.
>
WARNING: multiple messages have this Message-ID (diff)
From: Walter Wu <walter-zh.wu@mediatek.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: wsd_upstream <wsd_upstream@mediatek.com>,
Patricia Alfonso <trishalfonso@google.com>,
Andrey Konovalov <andreyknvl@google.com>,
Brendan Higgins <brendanhiggins@google.com>,
LKML <linux-kernel@vger.kernel.org>,
kasan-dev <kasan-dev@googlegroups.com>,
Linux-MM <linux-mm@kvack.org>,
linux-mediatek@lists.infradead.org,
Alexander Potapenko <glider@google.com>,
David Gow <davidgow@google.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] kasan: fix KASAN unit tests for tag-based KASAN
Date: Tue, 21 Apr 2020 21:37:52 +0800 [thread overview]
Message-ID: <1587476272.5870.15.camel@mtksdccf07> (raw)
In-Reply-To: <CACT4Y+avYV1xoqB6V5XrQSs-p2s3mKKu+LZQc4EzPaW-jV+KaA@mail.gmail.com>
On Tue, 2020-04-21 at 15:01 +0200, 'Dmitry Vyukov' via kasan-dev wrote:
> On Tue, Apr 21, 2020 at 2:26 PM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> >
> > Hi Dmitry,
> >
> > On Tue, 2020-04-21 at 13:56 +0200, Dmitry Vyukov wrote:
> > > On Tue, Apr 21, 2020 at 3:40 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> > > >
> > > > When we use tag-based KASAN, then KASAN unit tests don't detect
> > > > out-of-bounds memory access. Because with tag-based KASAN the state
> > > > of each 16 aligned bytes of memory is encoded in one shadow byte
> > > > and the shadow value is tag of pointer, so we need to read next
> > > > shadow byte, the shadow value is not equal to tag of pointer,
> > > > then tag-based KASAN will detect out-of-bounds memory access.
> > > >
> > > > Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> > > > Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> > > > Cc: Dmitry Vyukov <dvyukov@google.com>
> > > > Cc: Alexander Potapenko <glider@google.com>
> > > > Cc: Matthias Brugger <matthias.bgg@gmail.com>
> > > > Cc: Andrey Konovalov <andreyknvl@google.com>
> > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > ---
> > > > lib/test_kasan.c | 62 ++++++++++++++++++++++++++++++++++++++++++------
> > > > 1 file changed, 55 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/lib/test_kasan.c b/lib/test_kasan.c
> > > > index e3087d90e00d..a164f6b47fe5 100644
> > > > --- a/lib/test_kasan.c
> > > > +++ b/lib/test_kasan.c
> > > > @@ -40,7 +40,12 @@ static noinline void __init kmalloc_oob_right(void)
> > > > return;
> > > > }
> > >
> > > Hi Walter,
> > >
> > > This would be great to have!
> > > But I am concerned about these series that port KASAN tests to KUNIT:
> > > https://lkml.org/lkml/2020/4/17/1144
> > > I suspect it will be one large merge conflict. Not sure what is the
> > > proper way to resovle this. I've added authors to CC.
> > >
> > Yes, it should have conflicts. Thanks for your reminder.
> > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > ptr[size] = 'x';
> > > > +#else
> > > > + ptr[size + 5] = 'x';
> > > > +#endif
> > > > +
> > >
> > > For this particular snippet I think we can reduce amount of idef'ery
> > > and amount of non-compiled code in each configuration with something
> > > like:
> > >
> > > ptr[size + 5] = 'x';
> > > if (ENABLED(CONFIG_KASAN_GENERIC))
> > > ptr[size] = 'x';
> > >
> > > One check runs always (it should pass in both configs, right?). The
> >
> > There is a problem, With generic KASAN it may trigger two KASAN reports.
>
> Why is this a problem? If there are 2, fine. KUNIT can check that if
> we expect 2, there are indeed 2.
>
Sorry, I originally assume my patch doesn't include in KUNIT. so I think
there is a problem. but I know your meaning. Can my patch upstream
first?
> > if we change it like:
> >
> > if (ENABLED(CONFIG_KASAN_GENERIC))
> > ptr[size] = 'x';
> > else
> > ptr[size + 5] = 'x';
> >
> > > only only in GENERIC, but it's C-level if rather than preprocessor.
> > > KUNIT should make 2 bugs per test easily expressable (and testable).
> > >
> >
> > >
> > >
> > >
> > > > kfree(ptr);
> > > > }
> > > >
> > > > @@ -92,7 +97,12 @@ static noinline void __init kmalloc_pagealloc_oob_right(void)
> > > > return;
> > > > }
> > > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > ptr[size] = 0;
> > > > +#else
> > > > + ptr[size + 6] = 0;
> > > > +#endif
> > > > +
> > > > kfree(ptr);
> > > > }
> > > >
> > > > @@ -162,7 +172,11 @@ static noinline void __init kmalloc_oob_krealloc_more(void)
> > > > return;
> > > > }
> > > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > ptr2[size2] = 'x';
> > > > +#else
> > > > + ptr2[size2 + 13] = 'x';
> > > > +#endif
> > > > kfree(ptr2);
> > > > }
> > > >
> > > > @@ -180,7 +194,12 @@ static noinline void __init kmalloc_oob_krealloc_less(void)
> > > > kfree(ptr1);
> > > > return;
> > > > }
> > > > +
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > ptr2[size2] = 'x';
> > > > +#else
> > > > + ptr2[size2 + 2] = 'x';
> > > > +#endif
> > > > kfree(ptr2);
> > > > }
> > > >
> > > > @@ -216,7 +235,11 @@ static noinline void __init kmalloc_oob_memset_2(void)
> > > > return;
> > > > }
> > > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > memset(ptr+7, 0, 2);
> > > > +#else
> > > > + memset(ptr+15, 0, 2);
> > > > +#endif
> > > > kfree(ptr);
> > > > }
> > > >
> > > > @@ -232,7 +255,11 @@ static noinline void __init kmalloc_oob_memset_4(void)
> > > > return;
> > > > }
> > > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > memset(ptr+5, 0, 4);
> > > > +#else
> > > > + memset(ptr+15, 0, 4);
> > > > +#endif
> > > > kfree(ptr);
> > > > }
> > > >
> > > > @@ -249,7 +276,11 @@ static noinline void __init kmalloc_oob_memset_8(void)
> > > > return;
> > > > }
> > > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > memset(ptr+1, 0, 8);
> > > > +#else
> > > > + memset(ptr+15, 0, 8);
> > > > +#endif
> > > > kfree(ptr);
> > > > }
> > > >
> > > > @@ -265,7 +296,11 @@ static noinline void __init kmalloc_oob_memset_16(void)
> > > > return;
> > > > }
> > > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > memset(ptr+1, 0, 16);
> > > > +#else
> > > > + memset(ptr+15, 0, 16);
> > > > +#endif
> > > > kfree(ptr);
> > > > }
> > > >
> > > > @@ -281,7 +316,11 @@ static noinline void __init kmalloc_oob_in_memset(void)
> > > > return;
> > > > }
> > > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > memset(ptr, 0, size+5);
> > > > +#else
> > > > + memset(ptr, 0, size+7);
> > > > +#endif
> > > > kfree(ptr);
> > > > }
> > > >
> > > > @@ -415,7 +454,11 @@ static noinline void __init kmem_cache_oob(void)
> > > > return;
> > > > }
> > > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > *p = p[size];
> > > > +#else
> > > > + *p = p[size + 8];
> > > > +#endif
> > > > kmem_cache_free(cache, p);
> > > > kmem_cache_destroy(cache);
> > > > }
> > > > @@ -497,6 +540,11 @@ static noinline void __init copy_user_test(void)
> > > > char __user *usermem;
> > > > size_t size = 10;
> > > > int unused;
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > + size_t oob_size = 1;
> > > > +#else
> > > > + size_t oob_size = 7;
> > > > +#endif
> > > >
> > > > kmem = kmalloc(size, GFP_KERNEL);
> > > > if (!kmem)
> > > > @@ -512,25 +560,25 @@ static noinline void __init copy_user_test(void)
> > > > }
> > > >
> > > > pr_info("out-of-bounds in copy_from_user()\n");
> > > > - unused = copy_from_user(kmem, usermem, size + 1);
> > > > + unused = copy_from_user(kmem, usermem, size + oob_size);
> > > >
> > > > pr_info("out-of-bounds in copy_to_user()\n");
> > > > - unused = copy_to_user(usermem, kmem, size + 1);
> > > > + unused = copy_to_user(usermem, kmem, size + oob_size);
> > > >
> > > > pr_info("out-of-bounds in __copy_from_user()\n");
> > > > - unused = __copy_from_user(kmem, usermem, size + 1);
> > > > + unused = __copy_from_user(kmem, usermem, size + oob_size);
> > > >
> > > > pr_info("out-of-bounds in __copy_to_user()\n");
> > > > - unused = __copy_to_user(usermem, kmem, size + 1);
> > > > + unused = __copy_to_user(usermem, kmem, size + oob_size);
> > > >
> > > > pr_info("out-of-bounds in __copy_from_user_inatomic()\n");
> > > > - unused = __copy_from_user_inatomic(kmem, usermem, size + 1);
> > > > + unused = __copy_from_user_inatomic(kmem, usermem, size + oob_size);
> > > >
> > > > pr_info("out-of-bounds in __copy_to_user_inatomic()\n");
> > > > - unused = __copy_to_user_inatomic(usermem, kmem, size + 1);
> > > > + unused = __copy_to_user_inatomic(usermem, kmem, size + oob_size);
> > > >
> > > > pr_info("out-of-bounds in strncpy_from_user()\n");
> > > > - unused = strncpy_from_user(kmem, usermem, size + 1);
> > > > + unused = strncpy_from_user(kmem, usermem, size + oob_size);
> > > >
> > > > vm_munmap((unsigned long)usermem, PAGE_SIZE);
> > > > kfree(kmem);
> > > > --
> > > > 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@googlegroups.com.
> > > > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20200421014007.6012-1-walter-zh.wu%40mediatek.com.
> >
> > --
> > 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@googlegroups.com.
> > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/1587472005.5870.7.camel%40mtksdccf07.
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
WARNING: multiple messages have this Message-ID (diff)
From: Walter Wu <walter-zh.wu@mediatek.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: wsd_upstream <wsd_upstream@mediatek.com>,
Patricia Alfonso <trishalfonso@google.com>,
Andrey Konovalov <andreyknvl@google.com>,
Brendan Higgins <brendanhiggins@google.com>,
LKML <linux-kernel@vger.kernel.org>,
kasan-dev <kasan-dev@googlegroups.com>,
Linux-MM <linux-mm@kvack.org>,
linux-mediatek@lists.infradead.org,
Alexander Potapenko <glider@google.com>,
David Gow <davidgow@google.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] kasan: fix KASAN unit tests for tag-based KASAN
Date: Tue, 21 Apr 2020 21:37:52 +0800 [thread overview]
Message-ID: <1587476272.5870.15.camel@mtksdccf07> (raw)
In-Reply-To: <CACT4Y+avYV1xoqB6V5XrQSs-p2s3mKKu+LZQc4EzPaW-jV+KaA@mail.gmail.com>
On Tue, 2020-04-21 at 15:01 +0200, 'Dmitry Vyukov' via kasan-dev wrote:
> On Tue, Apr 21, 2020 at 2:26 PM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> >
> > Hi Dmitry,
> >
> > On Tue, 2020-04-21 at 13:56 +0200, Dmitry Vyukov wrote:
> > > On Tue, Apr 21, 2020 at 3:40 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> > > >
> > > > When we use tag-based KASAN, then KASAN unit tests don't detect
> > > > out-of-bounds memory access. Because with tag-based KASAN the state
> > > > of each 16 aligned bytes of memory is encoded in one shadow byte
> > > > and the shadow value is tag of pointer, so we need to read next
> > > > shadow byte, the shadow value is not equal to tag of pointer,
> > > > then tag-based KASAN will detect out-of-bounds memory access.
> > > >
> > > > Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> > > > Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> > > > Cc: Dmitry Vyukov <dvyukov@google.com>
> > > > Cc: Alexander Potapenko <glider@google.com>
> > > > Cc: Matthias Brugger <matthias.bgg@gmail.com>
> > > > Cc: Andrey Konovalov <andreyknvl@google.com>
> > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > ---
> > > > lib/test_kasan.c | 62 ++++++++++++++++++++++++++++++++++++++++++------
> > > > 1 file changed, 55 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/lib/test_kasan.c b/lib/test_kasan.c
> > > > index e3087d90e00d..a164f6b47fe5 100644
> > > > --- a/lib/test_kasan.c
> > > > +++ b/lib/test_kasan.c
> > > > @@ -40,7 +40,12 @@ static noinline void __init kmalloc_oob_right(void)
> > > > return;
> > > > }
> > >
> > > Hi Walter,
> > >
> > > This would be great to have!
> > > But I am concerned about these series that port KASAN tests to KUNIT:
> > > https://lkml.org/lkml/2020/4/17/1144
> > > I suspect it will be one large merge conflict. Not sure what is the
> > > proper way to resovle this. I've added authors to CC.
> > >
> > Yes, it should have conflicts. Thanks for your reminder.
> > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > ptr[size] = 'x';
> > > > +#else
> > > > + ptr[size + 5] = 'x';
> > > > +#endif
> > > > +
> > >
> > > For this particular snippet I think we can reduce amount of idef'ery
> > > and amount of non-compiled code in each configuration with something
> > > like:
> > >
> > > ptr[size + 5] = 'x';
> > > if (ENABLED(CONFIG_KASAN_GENERIC))
> > > ptr[size] = 'x';
> > >
> > > One check runs always (it should pass in both configs, right?). The
> >
> > There is a problem, With generic KASAN it may trigger two KASAN reports.
>
> Why is this a problem? If there are 2, fine. KUNIT can check that if
> we expect 2, there are indeed 2.
>
Sorry, I originally assume my patch doesn't include in KUNIT. so I think
there is a problem. but I know your meaning. Can my patch upstream
first?
> > if we change it like:
> >
> > if (ENABLED(CONFIG_KASAN_GENERIC))
> > ptr[size] = 'x';
> > else
> > ptr[size + 5] = 'x';
> >
> > > only only in GENERIC, but it's C-level if rather than preprocessor.
> > > KUNIT should make 2 bugs per test easily expressable (and testable).
> > >
> >
> > >
> > >
> > >
> > > > kfree(ptr);
> > > > }
> > > >
> > > > @@ -92,7 +97,12 @@ static noinline void __init kmalloc_pagealloc_oob_right(void)
> > > > return;
> > > > }
> > > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > ptr[size] = 0;
> > > > +#else
> > > > + ptr[size + 6] = 0;
> > > > +#endif
> > > > +
> > > > kfree(ptr);
> > > > }
> > > >
> > > > @@ -162,7 +172,11 @@ static noinline void __init kmalloc_oob_krealloc_more(void)
> > > > return;
> > > > }
> > > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > ptr2[size2] = 'x';
> > > > +#else
> > > > + ptr2[size2 + 13] = 'x';
> > > > +#endif
> > > > kfree(ptr2);
> > > > }
> > > >
> > > > @@ -180,7 +194,12 @@ static noinline void __init kmalloc_oob_krealloc_less(void)
> > > > kfree(ptr1);
> > > > return;
> > > > }
> > > > +
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > ptr2[size2] = 'x';
> > > > +#else
> > > > + ptr2[size2 + 2] = 'x';
> > > > +#endif
> > > > kfree(ptr2);
> > > > }
> > > >
> > > > @@ -216,7 +235,11 @@ static noinline void __init kmalloc_oob_memset_2(void)
> > > > return;
> > > > }
> > > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > memset(ptr+7, 0, 2);
> > > > +#else
> > > > + memset(ptr+15, 0, 2);
> > > > +#endif
> > > > kfree(ptr);
> > > > }
> > > >
> > > > @@ -232,7 +255,11 @@ static noinline void __init kmalloc_oob_memset_4(void)
> > > > return;
> > > > }
> > > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > memset(ptr+5, 0, 4);
> > > > +#else
> > > > + memset(ptr+15, 0, 4);
> > > > +#endif
> > > > kfree(ptr);
> > > > }
> > > >
> > > > @@ -249,7 +276,11 @@ static noinline void __init kmalloc_oob_memset_8(void)
> > > > return;
> > > > }
> > > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > memset(ptr+1, 0, 8);
> > > > +#else
> > > > + memset(ptr+15, 0, 8);
> > > > +#endif
> > > > kfree(ptr);
> > > > }
> > > >
> > > > @@ -265,7 +296,11 @@ static noinline void __init kmalloc_oob_memset_16(void)
> > > > return;
> > > > }
> > > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > memset(ptr+1, 0, 16);
> > > > +#else
> > > > + memset(ptr+15, 0, 16);
> > > > +#endif
> > > > kfree(ptr);
> > > > }
> > > >
> > > > @@ -281,7 +316,11 @@ static noinline void __init kmalloc_oob_in_memset(void)
> > > > return;
> > > > }
> > > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > memset(ptr, 0, size+5);
> > > > +#else
> > > > + memset(ptr, 0, size+7);
> > > > +#endif
> > > > kfree(ptr);
> > > > }
> > > >
> > > > @@ -415,7 +454,11 @@ static noinline void __init kmem_cache_oob(void)
> > > > return;
> > > > }
> > > >
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > *p = p[size];
> > > > +#else
> > > > + *p = p[size + 8];
> > > > +#endif
> > > > kmem_cache_free(cache, p);
> > > > kmem_cache_destroy(cache);
> > > > }
> > > > @@ -497,6 +540,11 @@ static noinline void __init copy_user_test(void)
> > > > char __user *usermem;
> > > > size_t size = 10;
> > > > int unused;
> > > > +#ifdef CONFIG_KASAN_GENERIC
> > > > + size_t oob_size = 1;
> > > > +#else
> > > > + size_t oob_size = 7;
> > > > +#endif
> > > >
> > > > kmem = kmalloc(size, GFP_KERNEL);
> > > > if (!kmem)
> > > > @@ -512,25 +560,25 @@ static noinline void __init copy_user_test(void)
> > > > }
> > > >
> > > > pr_info("out-of-bounds in copy_from_user()\n");
> > > > - unused = copy_from_user(kmem, usermem, size + 1);
> > > > + unused = copy_from_user(kmem, usermem, size + oob_size);
> > > >
> > > > pr_info("out-of-bounds in copy_to_user()\n");
> > > > - unused = copy_to_user(usermem, kmem, size + 1);
> > > > + unused = copy_to_user(usermem, kmem, size + oob_size);
> > > >
> > > > pr_info("out-of-bounds in __copy_from_user()\n");
> > > > - unused = __copy_from_user(kmem, usermem, size + 1);
> > > > + unused = __copy_from_user(kmem, usermem, size + oob_size);
> > > >
> > > > pr_info("out-of-bounds in __copy_to_user()\n");
> > > > - unused = __copy_to_user(usermem, kmem, size + 1);
> > > > + unused = __copy_to_user(usermem, kmem, size + oob_size);
> > > >
> > > > pr_info("out-of-bounds in __copy_from_user_inatomic()\n");
> > > > - unused = __copy_from_user_inatomic(kmem, usermem, size + 1);
> > > > + unused = __copy_from_user_inatomic(kmem, usermem, size + oob_size);
> > > >
> > > > pr_info("out-of-bounds in __copy_to_user_inatomic()\n");
> > > > - unused = __copy_to_user_inatomic(usermem, kmem, size + 1);
> > > > + unused = __copy_to_user_inatomic(usermem, kmem, size + oob_size);
> > > >
> > > > pr_info("out-of-bounds in strncpy_from_user()\n");
> > > > - unused = strncpy_from_user(kmem, usermem, size + 1);
> > > > + unused = strncpy_from_user(kmem, usermem, size + oob_size);
> > > >
> > > > vm_munmap((unsigned long)usermem, PAGE_SIZE);
> > > > kfree(kmem);
> > > > --
> > > > 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@googlegroups.com.
> > > > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20200421014007.6012-1-walter-zh.wu%40mediatek.com.
> >
> > --
> > 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@googlegroups.com.
> > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/1587472005.5870.7.camel%40mtksdccf07.
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-04-21 13:38 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-21 1:40 [PATCH] kasan: fix KASAN unit tests for tag-based KASAN Walter Wu
2020-04-21 1:40 ` Walter Wu
2020-04-21 1:40 ` Walter Wu
2020-04-21 11:56 ` Dmitry Vyukov
2020-04-21 11:56 ` Dmitry Vyukov
2020-04-21 11:56 ` Dmitry Vyukov
2020-04-21 11:56 ` Dmitry Vyukov
2020-04-21 12:26 ` Walter Wu
2020-04-21 12:26 ` Walter Wu
2020-04-21 12:26 ` Walter Wu
2020-04-21 13:01 ` Dmitry Vyukov
2020-04-21 13:01 ` Dmitry Vyukov
2020-04-21 13:01 ` Dmitry Vyukov
2020-04-21 13:01 ` Dmitry Vyukov
2020-04-21 13:37 ` Walter Wu [this message]
2020-04-21 13:37 ` Walter Wu
2020-04-21 13:37 ` Walter Wu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1587476272.5870.15.camel@mtksdccf07 \
--to=walter-zh.wu@mediatek.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@google.com \
--cc=aryabinin@virtuozzo.com \
--cc=brendanhiggins@google.com \
--cc=davidgow@google.com \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=matthias.bgg@gmail.com \
--cc=trishalfonso@google.com \
--cc=wsd_upstream@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.