Re: [PATCH v1] slab: support for compiler-assisted type-based slab cache partitioning

[Marco Elver]

On Mon, 6 Apr 2026 at 06:28, 'Harry Yoo (Oracle)' via kasan-dev
<kasan-dev@xxxxxxxxxxxxxxxx> wrote:
> On Fri, Apr 03, 2026 at 08:29:22PM +0200, Vlastimil Babka (SUSE) wrote:
> > On 4/3/26 08:27, Harry Yoo (Oracle) wrote:
> > >> diff --git a/include/linux/slab.h b/include/linux/slab.h
> > >> index 15a60b501b95..c0bf00ee6025 100644
> > >> --- a/include/linux/slab.h
> > >> +++ b/include/linux/slab.h
> > >> @@ -864,10 +877,10 @@ unsigned int kmem_cache_sheaf_size(struct slab_sheaf *sheaf);
> > >>   * with the exception of kunit tests
> > >>   */
> > >>
> > >> -void *__kmalloc_noprof(size_t size, gfp_t flags)
> > >> +void *__kmalloc_noprof(size_t size, gfp_t flags, kmalloc_token_t token)
> > >>                            __assume_kmalloc_alignment __alloc_size(1);
> > >>
> > >> -void *__kmalloc_node_noprof(DECL_BUCKET_PARAMS(size, b), gfp_t flags, int node)
> > >> +void *__kmalloc_node_noprof(DECL_BUCKET_PARAMS(size, b), gfp_t flags, int node, kmalloc_token_t token)
> > >>                            __assume_kmalloc_alignment __alloc_size(1);
> > >
> > > So the @token parameter is unused when CONFIG_PARTITION_KMALLOC_CACHES is
> > > disabled but still increases the kernel size by a few kilobytes...
> > > but yeah I'm not sure if we can get avoid it without hurting readability.
> > >
> > > Just saying. (does anybody care?)
> >
> > Well we did care enough with CONFIG_SLAB_BUCKETS to hide the unused param
> > using DECL_BUCKET_PARAMS(),
>
> Hmm yeah.
>
> I wasn't sure if we could do this without hurting readability,
> but perhaps we could...
>
> > so maybe extend that idea?
> > I think it's not just kernel size, but increased register pressure etc.

I'll take a closer look at generated code. In some cases the compiler
ought to omit zero-sized arguments, so I want to be sure we're not
prematurely optimizing and the size increase is not some other effect.

> Something like this should work? (diff on top of this patch)

Thanks, I'll consider it.

Re your other comments:

> Assuming not all people building the kernel are security experts...
> (including myself) could you please add some insights/guidance on how to
> decide between RANDOM_KMALLOC_CACHES and TYPED_KMALLOC_CACHES?

You can find different arguments for either, and in the original RFC
that was part of the discussion. However, my biased view is that
type-based partitioning in general is the stronger security boundary.
Because it creates a deterministic separation; specifically isolating
pointer-containing objects from pointerless ones: it effectively kills
certain classes of exploit techniques that probabilistic defenses
(like randomization) only delay, especially in environments where
attackers can retry or use side-channels.

The current pointer/non-pointer scheme is relatively intuitive with
well-understood properties, and a good start. However, an open
research question is if better alloc-token ID schemes exist: one that
is tailored to kernel data structures that would meaningfully increase
exploitation difficulty further without increasing the number of
partitions. Since an improved scheme could simply be activated with a
compiler flag, having the baseline infrastructure available and
maintained is the first step.

> Now somewhat out-of-scope (or at least pre-existing) review comments
> from Sashiko that I think are still worth mentioning...

Indeed, these are pre-existing issues with RANDOM_KMALLOC_CACHES.
Worth follow-up patches, but this patch here wants to just get the
TYPED_KMALLOC_CACHES infrastructure in place so we can build on top of
it.

Thanks,
-- Marco