| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Sun, 2 Jul 2023 17:09:11 -0700 (PDT)
From: David Rientjes <rientjes@...gle.com>
To: Julian Pidancet <julian.pidancet@...cle.com>
cc: Christoph Lameter <cl@...ux.com>,
"Lameter, Christopher" <cl@...amperecomputing.com>,
Pekka Enberg <penberg@...nel.org>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Vlastimil Babka <vbabka@...e.cz>,
Roman Gushchin <roman.gushchin@...ux.dev>,
Hyeonggon Yoo <42.hyeyoo@...il.com>, linux-mm@...ck.org,
Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, Matthew Wilcox <willy@...radead.org>,
Kees Cook <keescook@...omium.org>,
Rafael Aquini <aquini@...hat.com>
Subject: Re: [PATCH v2] mm/slub: disable slab merging in the default
configuration
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@...cle.com>
> Reviewed-by: Kees Cook <keescook@...omium.org>
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@oracle.com/
>
> .../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
> ===============
Powered by blists - more mailing lists