Re: [PATCH v3 0/6] mm/slab: Support selecting slab hardening features at boot

[Harry Yoo <harry@kernel.org>]

On Fri, Nov 13, 2026 at 11:56:20AM +0100, Marco Elver wrote:
> On Fri, 13 Nov 2026 at 09:51, Chris Down <chris@chrisdown.name> wrote:
> >
> > Slab hardening settings are currently all build time choices. This means
> > that, unfortunately, hosts with different requirements end up needing
> > separate kernel images. At Meta, for example, some hosts are built with
> > these options and the rest of the fleet isn't, and that's one of the
> > things that keeps those kernels apart.
> >
> > This series does two things:
> >
> > - SLAB_FREELIST_HARDENED and SLAB_FREELIST_RANDOM are cheap enough with
> >   sheaves that it makes more sense to just enable them by default than
> >   to make them switchable. With both on, system level benchmarks didn't
> >   change measurably, only slowpath heavy microbenchmarks did [1].
> >
> > - SLAB_BUCKETS and KMALLOC_PARTITION_CACHES cost memory (Harry measured
> >   about 1 MiB and 18 MiB respectively after boot on a 64 CPU VM [2]), so
> >   they get slab_buckets= and kmalloc_partition= boot parameters, which
> >   default to on when the option is built in.
> >
> > Whether those two should be folded into a single slab_hardening= is
> > still open [3].
> 
> A coarse slab_hardening= option can easily be replaced by
> documentation. While less knobs is better, an intransparent coarse
> variant of slab_hardening= just makes the admin wonder "what does that
> actually to, and do I want it?". They still have to go and look up
> what it actually does, and at that point it doesn't add much value
> (alternative suggestion below).
> 
> > > > light: "I'm willying to sacrifice _some_ memory and CPU for security"
> > > > full: "I'm willying to sacrifice more overhead for security
> 
> Who will decide what is light and full? I think there just won't be
> any consensus reached.

You're probably right.

> One thing that users may want is an "all off" option, similar to
> mitigations=off, should they wish to get max performance back with a
> single option. So you could consider slab_hardening=off.

slab_hardening=off sounds good to me.

However this assumes "all on" is the right thing to do by default,
but not enabling slab hardening is not as nearly critical as not
enabling mitigations to CPU vulnerabilities, no?

I'd rather mirror hardened_usercopy= instead of mitigations=off.

slab_hardening=on (turn on all slab hardening features)
slab_hardening=off (turn off all slab hardening features)
(Otherwise it is determined by CONFIG_*.)

> But at that point it may be more consistent to drop slab_buckets= and
> kmalloc_partition= in favor of arguments to slab_hardening=, such as
> slab_hardening=nobuckets,partition. This would mirror mitigations=,
> and should cater to the usecase of slab_hardening=off to get max
> performance with a single option.

I hope we don't reach this point, but more fine-grained control should
be achivable if it is indeed required.

> But I would not add options such as 'light', 'full'.

Fair enough.

> Thanks,
> -- Marco

-- 
Cheers,
Harry / Hyeonggon