From: Marco Elver <elver@google.com>
To: Feng Tang <feng.tang@intel.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
Oliver Glitta <glittao@gmail.com>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] mm/slub, kunit: Add a test case for kmalloc redzone check
Date: Tue, 29 Nov 2022 10:31:55 +0100 [thread overview]
Message-ID: <CANpmjNNkLWvNYUf-bPPDBcqFWegp3_NpYdhygvYU1dtT52m29g@mail.gmail.com> (raw)
In-Reply-To: <20221129063358.3012362-2-feng.tang@intel.com>
On Tue, 29 Nov 2022 at 07:37, Feng Tang <feng.tang@intel.com> wrote:
>
> kmalloc redzone check for slub has been merged, and it's better to add
> a kunit case for it, which is inspired by a real-world case as described
> in commit 120ee599b5bf ("staging: octeon-usb: prevent memory corruption"):
>
> "
> octeon-hcd will crash the kernel when SLOB is used. This usually happens
> after the 18-byte control transfer when a device descriptor is read.
> The DMA engine is always transferring full 32-bit words and if the
> transfer is shorter, some random garbage appears after the buffer.
> The problem is not visible with SLUB since it rounds up the allocations
> to word boundary, and the extra bytes will go undetected.
> "
>
> To avoid interrupting the normal functioning of kmalloc caches, a
> kmem_cache mimicing kmalloc cache is created with similar and all
> necessary flags to have kmalloc-redzone enabled, and kmalloc_trace()
> is used to really test the orig_size and redzone setup.
>
> Suggested-by: Vlastimil Babka <vbabka@suse.cz>
> Signed-off-by: Feng Tang <feng.tang@intel.com>
> ---
> Changelog:
>
> since v1:
> * create a new cache mimicing kmalloc cache, reduce dependency
> over global slub_debug setting (Vlastimil Babka)
>
> lib/slub_kunit.c | 23 +++++++++++++++++++++++
> mm/slab.h | 3 ++-
> 2 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/lib/slub_kunit.c b/lib/slub_kunit.c
> index a303adf8f11c..dbdd656624d0 100644
> --- a/lib/slub_kunit.c
> +++ b/lib/slub_kunit.c
> @@ -122,6 +122,28 @@ static void test_clobber_redzone_free(struct kunit *test)
> kmem_cache_destroy(s);
> }
>
> +static void test_kmalloc_redzone_access(struct kunit *test)
> +{
> + struct kmem_cache *s = kmem_cache_create("TestSlub_RZ_kmalloc", 32, 0,
> + SLAB_KMALLOC|SLAB_STORE_USER|SLAB_RED_ZONE|DEFAULT_FLAGS,
> + NULL);
> + u8 *p = kmalloc_trace(s, GFP_KERNEL, 18);
> +
> + kasan_disable_current();
> +
> + /* Suppress the -Warray-bounds warning */
> + OPTIMIZER_HIDE_VAR(p);
> + p[18] = 0xab;
> + p[19] = 0xab;
> +
> + kmem_cache_free(s, p);
> + validate_slab_cache(s);
> + KUNIT_EXPECT_EQ(test, 2, slab_errors);
> +
> + kasan_enable_current();
> + kmem_cache_destroy(s);
> +}
> +
> static int test_init(struct kunit *test)
> {
> slab_errors = 0;
> @@ -141,6 +163,7 @@ static struct kunit_case test_cases[] = {
> #endif
>
> KUNIT_CASE(test_clobber_redzone_free),
> + KUNIT_CASE(test_kmalloc_redzone_access),
> {}
> };
>
> diff --git a/mm/slab.h b/mm/slab.h
> index c71590f3a22b..b6cd98b16ba7 100644
> --- a/mm/slab.h
> +++ b/mm/slab.h
> @@ -327,7 +327,8 @@ static inline slab_flags_t kmem_cache_flags(unsigned int object_size,
> /* Legal flag mask for kmem_cache_create(), for various configurations */
> #define SLAB_CORE_FLAGS (SLAB_HWCACHE_ALIGN | SLAB_CACHE_DMA | \
> SLAB_CACHE_DMA32 | SLAB_PANIC | \
> - SLAB_TYPESAFE_BY_RCU | SLAB_DEBUG_OBJECTS )
> + SLAB_KMALLOC | SLAB_SKIP_KFENCE | \
> + SLAB_TYPESAFE_BY_RCU | SLAB_DEBUG_OBJECTS)
Shouldn't this hunk be in the previous patch, otherwise that patch
alone will fail?
This will also make SLAB_SKIP_KFENCE generally available to be used
for cache creation. This is a significant change, and before it wasn't
possible. Perhaps add a brief note to the commit message (or have a
separate patch). We were trying to avoid making this possible, as it
might be abused - however, given it's required for tests like these, I
suppose there's no way around it.
Thanks,
-- Marco
next prev parent reply other threads:[~2022-11-29 14:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-29 6:33 [PATCH v2 1/2] mm/slub, kunit: add SLAB_SKIP_KFENCE flag for cache creation Feng Tang
2022-11-29 6:33 ` [PATCH v2 2/2] mm/slub, kunit: Add a test case for kmalloc redzone check Feng Tang
2022-11-29 9:31 ` Marco Elver [this message]
2022-11-29 11:01 ` Vlastimil Babka
2022-11-29 11:48 ` Marco Elver
2022-11-29 12:02 ` Vlastimil Babka
2022-11-29 12:50 ` Feng Tang
2022-11-29 12:56 ` Marco Elver
2022-11-29 17:48 ` Vlastimil Babka
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=CANpmjNNkLWvNYUf-bPPDBcqFWegp3_NpYdhygvYU1dtT52m29g@mail.gmail.com \
--to=elver@google.com \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=feng.tang@intel.com \
--cc=glittao@gmail.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=vbabka@suse.cz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox