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 06:36:49PM +0000, Harry Yoo wrote:
> 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_*.)

Should have been CONFIG_*_DEFAULT_ON.

> > 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

-- 
Cheers,
Harry / Hyeonggon