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

-Kees

-- 
Kees Cook