On Tue, Jun 27, 2023 at 03:21:31PM +0200, Julian Pidancet wrote: > Make CONFIG_SLAB_MERGE_DEFAULT default to n unless CONFIG_SLUB_TINY is > enabled. Benefits of slab merging is limited on systems that are not > memory constrained: the overhead is negligible and evidence of its > effect on cache hotness is hard to come by. > > On the other hand, distinguishing allocations into different slabs will > make attacks that rely on "heap spraying" more difficult to carry out > with success. > > Take sides with security in the default kernel configuration over > questionnable performance benefits/memory efficiency. > > Signed-off-by: Julian Pidancet <julian.pidancet@xxxxxxxxxx> > --- > In an attempt to assess the performance impact of disabling slab > merging, a timed linux kernel compilation test has been conducted first > using slab_merge, then using slab_nomerge. Both tests started in an > identical state. Commodity hardware was used: a laptop with an AMD Ryzen > 5 3500U CPU, and 16GiB of RAM. The kernel source files were placed on > an XFS partition because of the extensive use of slab caches in XFS. > > The results are as follows: > > | slab_merge | slab_nomerge | > ------+------------------+------------------| > Time | 489.074 ± 10.334 | 489.975 ± 10.350 | > Min | 459.688 | 460.554 | > Max | 493.126 | 494.282 | > > The benchmark favors the configuration where merging is disabled, but the > difference is only ~0.18%, well under statistical significance. As mentioned, please include these kinds of perf notes in the commit log; it's useful to see later. :) Regardless, yes, please. I have been running slab_nomerge on all my systems for years and years now. With the typo fixed and commit log updated, please consider this: Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx> -Kees -- Kees Cook
