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

[Marco Elver <elver@google.com>]

On Tue, 21 Apr 2026 at 19:22, 'Kees Cook' via kasan-dev
<kasan-dev@googlegroups.com> wrote:
>
> On Wed, Apr 15, 2026 at 04:37:05PM +0200, Marco Elver wrote:
> > The builtin __builtin_infer_alloc_token(<malloc-args>, ...) instructs
> > the compiler to infer an allocation type from arguments commonly passed
> > to memory-allocating functions and returns a type-derived token ID. The
> > implementation passes kmalloc-args to the builtin: the compiler performs
> > best-effort type inference, and then recognizes common patterns such as
> > `kmalloc(sizeof(T), ...)`, `kmalloc(sizeof(T) * n, ...)`, but also
> > `(T *)kmalloc(...)`. Where the compiler fails to infer a type the
> > fallback token (default: 0) is chosen.
> >
> > Note: kmalloc_obj(..) APIs fix the pattern how size and result type are
> > expressed, and therefore ensures there's not much drift in which
> > patterns the compiler needs to recognize. Specifically, kmalloc_obj()
> > and friends expand to `(TYPE *)KMALLOC(__obj_size, GFP)`, which the
> > compiler recognizes via the cast to TYPE*.
>
> Great! I'm glad this gets deterministically handled for the kmalloc_obj*
> cases.
>
> > Additionally, when I compile my kernel with -Rpass=alloc-token, which
> > provides diagnostics where (after dead-code elimination) type inference
> > failed, I see 186 allocation sites where the compiler failed to identify
> > a type (down from 966 when I sent the RFC [4]). Some initial review
> > confirms these are mostly variable sized buffers, but also include
> > structs with trailing flexible length arrays.
>
> For the call-site-partitioning series[1] I sent before, I had
> per-site caches for fixed-sized allocations and size bucket caches for
> variably-sized allocations. I'd like to see something similar for this
> series. Specifically, I replaced "kmalloc_slab" with "choose_slab" that
> did O(1) to find the dedicated cache/bucket for the allocation[2].
>
> In this case, we now have a build-time-constant value that it should be
> possible to use to look up a _single_ dedicated cache/bucket for the
> given unique type: there is no need to do hashing.

That should be a separate series; I know what you're getting at, but
it's a significant rework and a different design with different
properties. This simpler patch is likely ready for the next merge
window (once I send v3), and in light of recent developments, I'd like
this to land sooner than later.

> > [...]
> > -config RANDOM_KMALLOC_CACHES
> > -     default n
> > +config PARTITION_KMALLOC_CACHES
> >       depends on !SLUB_TINY
> > -     bool "Randomize slab caches for normal kmalloc"
> > +     bool "Partitioned slab caches for normal kmalloc"
> >       help
> > -       A hardening feature that creates multiple copies of slab caches for
> > -       normal kmalloc allocation and makes kmalloc randomly pick one based
> > -       on code address, which makes the attackers more difficult to spray
> > -       vulnerable memory objects on the heap for the purpose of exploiting
> > -       memory vulnerabilities.
> > +       A hardening feature that creates multiple isolated copies of slab
> > +       caches for normal kmalloc allocations. This makes it more difficult
> > +       to exploit memory-safety vulnerabilities by attacking vulnerable
> > +       co-located memory objects. Several modes are provided.
> >
> >         Currently the number of copies is set to 16, a reasonably large value
>
> The "16" buckets seems to hold for TYPED_KMALLOC_CACHES too? My goal
> with the earlier type-partitioning was to get _total_ isolation, not
> simply bucketed: 1 cache (or sizes-bucket) for each type. The "16"
> limitation from RANDOM_KMALLOC_CACHES was kind of arbitrary due to the
> hashing.

The token ID is also a hash, although it can be configured to be
unbounded to effectively give unique hash per type. As-is, limiting to
16 keeps it comparable to the RANDOM mode, albeit IMHO with better
isolation properties with the same overheads. As-is, performance
properties of RANDOM and TYPED are comparable, and the friction to
switch between them is minimal.

Unlike a completely new design, which will have comletely different
performance and memory usage properties - and wouldn't be comparable.

> >         that effectively diverges the memory objects allocated for different
> >         subsystems or modules into different caches, at the expense of a
> > -       limited degree of memory and CPU overhead that relates to hardware and
> > -       system workload.
> > +       limited degree of memory and CPU overhead that relates to hardware
> > +       and system workload.
> > +
> > +choice
> > +     prompt "Partitioned slab cache mode"
> > +     depends on PARTITION_KMALLOC_CACHES
> > +     default RANDOM_KMALLOC_CACHES
>
> I think this should be adjusted a bit:
>
> config CC_HAS_ALLOC_TOKEN
>         def_bool $(cc-option,-falloc-token-max=123)
>
> ...
> choice
>         prompt "Partitioned slab cache mode"
>         depends on PARTITION_KMALLOC_CACHES
>         default TYPED_KMALLOC_CACHES if CC_HAS_ALLOC_TOKEN
>         default RANDOM_KMALLOC_CACHES

Sure.

> And actually, perhaps a global rename of the options so the selection
> naming is at the end of the CONFIG phrase, and bundle the on/off into
> the choice:
>
>
> choice
>         prompt "Partitioned slab cache mode"
>         depends on PARTITION_KMALLOC_CACHES
>         default KMALLOC_PARTITION_TYPED if !SLUB_TINY && CC_HAS_ALLOC_TOKEN
>         default KMALLOC_PARTITION_RANDOM if !SLUB_TINY
>         default KMALLOC_PARTITION_NONE
>
> config KMALLOC_PARTITION_NONE
> ...
> config KMALLOC_PARTITION_RANDOM
>         depends on !SLUB_TINY
> ...
> config KMALLOC_PARTITION_TYPED
>         depends on !SLUB_TINY && CC_HAS_ALLOC_TOKEN

There was a comment somewhere else that even introducing
PARTITION_KMALLOC_CACHES might confuse users of RANDOM_KMALLOC_CACHES.
I think completely getting rid of and renaming RANDOM_KMALLOC_CACHES
has marginal benefit, and will cause friction for existing users (even
moreso than already). I see little benefit here, and would prefer not
to break user configs more than needed: configs that already set
RANDOM_KMALLOC_CACHES, upon rebuild will be prompted to enable
PARTITION_KMALLOC_CACHES; if user says Y, then their previous
selection (RANDOM) would already be picked and they don't have to
rediscover that it exists under a new name.

I can make this change, but only if you're sure the benefit outweighs
the downsides here.

Thanks,
-- Marco