Re: [PATCH] mm/slub: disable slab merging in the default configuration

From: David Rientjes
Date: Tue Jun 27 2023 - 15:32:26 EST


On Tue, 27 Jun 2023, 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.
>

I don't have an objection to this, I think it makes sense.

When you say overhead here, I assume you're referring to memory footprint?
Did you happen to have some system-wide numbers for what that looks like
when running some benchmarks, or even what the slab usage looks like after
a fresh boot?

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

I think this data should be in the changelog itself, as well as any
numbers to share on the memory footprint differences.

> .../admin-guide/kernel-parameters.txt | 29 ++++++++++---------
> Documentation/mm/slub.rst | 5 ++--
> mm/Kconfig | 6 ++--
> 3 files changed, 21 insertions(+), 19 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 9e5bab29685f..5fbf6ed3c62e 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -5652,21 +5652,22 @@
>
> slram= [HW,MTD]
>
> - slab_merge [MM]
> - Enable merging of slabs with similar size when the
> - kernel is built without CONFIG_SLAB_MERGE_DEFAULT.
> -
> slab_nomerge [MM]
> - Disable merging of slabs with similar size. May be
> - necessary if there is some reason to distinguish
> - allocs to different slabs, especially in hardened
> - environments where the risk of heap overflows and
> - layout control by attackers can usually be
> - frustrated by disabling merging. This will reduce
> - most of the exposure of a heap attack to a single
> - cache (risks via metadata attacks are mostly
> - unchanged). Debug options disable merging on their
> - own.
> + Disable merging of slabs with similar size when
> + the kernel is built with CONFIG_SLAB_MERGE_DEFAULT.
> + Allocations of the same size made in distinct
> + caches will be placed in separate slabs. In
> + hardened environment, the risk of heap overflows
> + and layout control by attackers can usually be
> + frustrated by disabling merging.
> +
> + slab_merge [MM]
> + Enable merging of slabs with similar size. May be
> + necessary to reduce overhead or increase cache
> + hotness of objects, at the cost of increased
> + exposure in case of a heap attack to a single
> + cache. (risks via metadata attacks are mostly
> + unchanged).
> For more information see Documentation/mm/slub.rst.
>
> slab_max_order= [MM, SLAB]
> diff --git a/Documentation/mm/slub.rst b/Documentation/mm/slub.rst
> index be75971532f5..e2549f4a98dd 100644
> --- a/Documentation/mm/slub.rst
> +++ b/Documentation/mm/slub.rst
> @@ -122,8 +122,9 @@ used on the wrong slab.
> Slab merging
> ============
>
> -If no debug options are specified then SLUB may merge similar slabs together
> -in order to reduce overhead and increase cache hotness of objects.
> +If the kernel is built with ``CONFIG_SLAB_MEGE_DEFAULT`` or if ``slab_merge``

s/MEGE/MERGE/

> +is specified on the kernel command line, then SLUB may merge similar slabs
> +together in order to reduce overhead and increase cache hotness of objects.

Specify that this is memory overhead?

> ``slabinfo -a`` displays which slabs were merged together.
>
> Slab validation
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 7672a22647b4..05b0304302d4 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -255,7 +255,7 @@ config SLUB_TINY
>
> config SLAB_MERGE_DEFAULT
> bool "Allow slab caches to be merged"
> - default y
> + default n
> depends on SLAB || SLUB
> help
> For reduced kernel memory fragmentation, slab caches can be
> @@ -264,8 +264,8 @@ config SLAB_MERGE_DEFAULT
> overwrite objects from merged caches (and more easily control
> cache layout), which makes such heap attacks easier to exploit
> by attackers. By keeping caches unmerged, these kinds of exploits
> - can usually only damage objects in the same cache. To disable
> - merging at runtime, "slab_nomerge" can be passed on the kernel
> + can usually only damage objects in the same cache. To enable
> + merging at runtime, "slab_merge" can be passed on the kernel
> command line.
>
> config SLAB_FREELIST_RANDOM
> --
> 2.40.1
>
>