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

[David Rientjes]

On Fri, 30 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 memory overhead is low 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.
> 
> A timed kernel compilation test, on x86 with 4K pages, conducted 10
> times with slab_merge, and the same test then conducted with
> slab_nomerge on the same hardware in a similar state do not show any
> sign of performance hit one way or another:
> 
>       | slab_merge       | slab_nomerge     |
> ------+------------------+------------------|
> Time  |  588.080 ± 0.799 |  587.308 ± 1.411 |
> Min   |          586.267 |          584.640 |
> Max   |          589.248 |          590.091 |
> 
> Peaks in slab usage during the test workload reveal a memory overhead
> of 2.2 MiB when using slab_nomerge. Slab usage overhead after a fresh boot
> amounts to 2.3 MiB:
> 
> Slab Usage         | slab_merge | slab_nomerge |
> -------------------+------------+--------------|
> After fresh boot   |   79908 kB |     82284 kB |
> During test (peak) |  127940 kB |    130204 kB |
> 
> Signed-off-by: Julian Pidancet <julian.pidancet@xxxxxxxxxx>
> Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx>

Thanks for continuing to work on this.

I think we need more data beyond just kernbench.  Christoph's point about 
different page sizes is interesting.  In the above results, I don't know 
the page orders for the various slab caches that this workload will 
stress.  I think the memory overhead data may be different depending on 
how slab_max_order is being used, if at all.

We should be able to run this through a variety of different benchmarks 
and measure peak slab usage at the same time for due diligence.  I support 
the change in the default, I would just prefer to know what the 
implications of it is.

Is it possible to collect data for other microbenchmarks and real-world 
workloads?  And perhaps also with different page sizes where this will 
impact memory overhead more?  I can help running more workloads once we 
have the next set of data.

> ---
> 
> v2:
>   - Re-run benchmark to minimize variance in results due to CPU
>     frequency scaling.
>   - Record slab usage after boot and peaks during tests workload.
>   - Include benchmark results in commit message.
>   - Fix typo: s/MEGE/MERGE/.
>   - Specify that "overhead" refers to memory overhead in SLUB doc.
> 
> v1:
>   - Link: https://lore.kernel.org/linux-mm/20230627132131.214475-1-julian.pidancet@xxxxxxxxxx/
> 
>  .../admin-guide/kernel-parameters.txt         | 29 ++++++++++---------
>  Documentation/mm/slub.rst                     |  7 +++--
>  mm/Kconfig                                    |  6 ++--
>  3 files changed, 22 insertions(+), 20 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index c5e7bb4babf0..7e78471a96b7 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..0e2ce82177c0 100644
> --- a/Documentation/mm/slub.rst
> +++ b/Documentation/mm/slub.rst
> @@ -122,9 +122,10 @@ 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.
> -``slabinfo -a`` displays which slabs were merged together.
> +If the kernel is built with ``CONFIG_SLAB_MERGE_DEFAULT`` or if ``slab_merge``
> +is specified on the kernel command line, then SLUB may merge similar slabs
> +together in order to reduce memory overhead and increase cache hotness of
> +objects.  ``slabinfo -a`` displays which slabs were merged together.
>  

Suggest mentioning that one of the primary goals of slab cache merging is 
to reduce cache footprint.

>  Slab validation
>  ===============