From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4F1D0EB64D9 for ; Tue, 27 Jun 2023 19:32:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D7F8B8D0002; Tue, 27 Jun 2023 15:32:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D2FB98D0001; Tue, 27 Jun 2023 15:32:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BF7188D0002; Tue, 27 Jun 2023 15:32:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id AE8048D0001 for ; Tue, 27 Jun 2023 15:32:20 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 7543A409BD for ; Tue, 27 Jun 2023 19:32:20 +0000 (UTC) X-FDA: 80949524040.24.6599155 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by imf03.hostedemail.com (Postfix) with ESMTP id 8B2BD20021 for ; Tue, 27 Jun 2023 19:32:18 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=SLlivscb; spf=pass (imf03.hostedemail.com: domain of rientjes@google.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=rientjes@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687894338; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ck21h6YvUFdrodIGjj6YsU+OWYBVIflql5oiEYBppsM=; b=w44QIeYRZMdo7NILS7CUDBX2t+Xj8d8fd+J0ugZamBR920OpUsoi/6/M51JCEar1tM3dhx 30dBoIkB6FWhJXMRuFTFJ3x9ihb/b7N8pmmNtmn1YA87E+Ik1So+BVh47Sgu+aqngPgEUG NQtBDO99p9+to5G8w+Ri8e+8TiCrMH0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687894338; a=rsa-sha256; cv=none; b=07NwKPaRTpWN40Ls7VW80NRrsxEsbZpGP/1LLuZ+JOmjB5AWxv2dzrY/FHVoNJioGjzFhn TQf3EvINe0RPMqNPWCxpm+KPe3zyCGjiKIlT047Z9mcTsyZiJIRg7lG0DOhgEhJahJJApJ mnLkLxwL7ei2RJCCC45oDQ0iJdnGsvU= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=SLlivscb; spf=pass (imf03.hostedemail.com: domain of rientjes@google.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=rientjes@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-1b82afd519fso31275ad.1 for ; Tue, 27 Jun 2023 12:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1687894337; x=1690486337; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=ck21h6YvUFdrodIGjj6YsU+OWYBVIflql5oiEYBppsM=; b=SLlivscbvsR1PVQf5GVSNkbJ2yyQ76xW2h8F30oXjhTUb4nMDmTr7nvn0j9cDaRm0r DhW92Y68Ihi9JRL8OJ1OG0HY/EwZjhPPUicsv4v7vsW4/BV38ukoNsM5XcclyqoYQZD7 Va67Z7ErZMtA2svIeftPoqkaPmQ6Vn7Y+kAXnricFTcFNAM119XeFqEETW9uJ/czqSai iuupc+e+x8ZLEbNLbxrxsX6vGXvwLiKoEoG9l4v5qWc2+pwYppsPVvsxACNDuPe8jhGu l9bSrQh2JzUdXPV71x3+YHM7N4DTRL8RJ/VTaGMeFQYsHP6y48oj3fyyEWKUfFxBfJtW viNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687894337; x=1690486337; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ck21h6YvUFdrodIGjj6YsU+OWYBVIflql5oiEYBppsM=; b=UVftgxHKrCHPmEKGdQvur7fe7qgB4C0YJb3kZ5n1WQqTFK4v31Ezr6uayS1ihLv0N5 HlwF24Uc/66OADdx+7RUV72qU65JR9ggq3md8WSO3VLOhOCkfZFKy2LPSUSYUzjhgw+a mI8xhmAodq5jFJNeg0NwPsI55oEOHIyFdou9KXdiTPwHgMx1bP2UThV0EFxwOw6m/END sihj8gshNf86sEEYzbvcdQTnGEP72EBYrnlyIDecNXCLmRZ5XfumAO8lUNfh3p1gag4w qPEbDrIettZlXdI8qmrozNc2Mb7AfuMQuMKkjKMGibpJ2sYWSvG41JHmToOIiZtfyihH RpvQ== X-Gm-Message-State: AC+VfDy8IqDXbjD++bAPZOkvSDuJSDzUfFX/cU/sJMYD80PDaveK1t4S OccYUTcE4e3EA+LACBGC5GfrQg== X-Google-Smtp-Source: ACHHUZ6arFC51dXDUj/BzIkIsYYKV1kMOuQaZX0aowuibpY/Cz1H30KX128wSJWTPXqV6huFvB/TDw== X-Received: by 2002:a17:902:ec91:b0:1b0:ceb:d67f with SMTP id x17-20020a170902ec9100b001b00cebd67fmr33959plg.8.1687894337073; Tue, 27 Jun 2023 12:32:17 -0700 (PDT) Received: from [2620:0:1008:15:ab4c:7287:2273:1bd0] ([2620:0:1008:15:ab4c:7287:2273:1bd0]) by smtp.gmail.com with ESMTPSA id iw4-20020a170903044400b001b80104446fsm4192320plb.20.2023.06.27.12.32.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Jun 2023 12:32:16 -0700 (PDT) Date: Tue, 27 Jun 2023 12:32:15 -0700 (PDT) From: David Rientjes To: Julian Pidancet cc: Christoph Lameter , Pekka Enberg , Joonsoo Kim , Andrew Morton , Vlastimil Babka , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm@kvack.org, Jonathan Corbet , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Matthew Wilcox , Kees Cook , Rafael Aquini Subject: Re: [PATCH] mm/slub: disable slab merging in the default configuration In-Reply-To: <20230627132131.214475-1-julian.pidancet@oracle.com> Message-ID: <48bd9819-3571-6b53-f1ad-ec013be742c0@google.com> References: <20230627132131.214475-1-julian.pidancet@oracle.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="2003067076-1055337799-1687894336=:2486373" X-Rspamd-Queue-Id: 8B2BD20021 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: whb5grdfhjujwirqz6ohm4znrx83r8kq X-HE-Tag: 1687894338-653414 X-HE-Meta: U2FsdGVkX1+c3sUm8bpTRZtLufmKTRQgW9cDfFiZpG45Z/7HHjjvdluP22vau8XftrK8nzWqJZMvAgAXTyPPvbHUA8F2fnVI7y8pMdpYMPQPPSso13/rc+pUEkD78/SZIfsRFz2fEbYlLkgJ4sQ60LbaE6CE65zH+Omz+hyU5QxWthfowvoiOOrsGVSp596S1LyqXzi0XCUM/r20yfL14fP/VRzGMoZofqNS65mBs2Ht8Wj7A7BEtcQ4im3Tg/7iSQleorydezNBChRXeOwaSrsZsUzEM/xx6BuZprjscntb0xx4yJ2JzZdDT9nPra8bhpJVsUjzT6nPy7U+vxptcvFjVIfm9dQBa9tQUB9atcKDieKDB7b+wvF0fpzArMU/M4jWeic1cSegY9Bn++WxXZY/4t/tCtPUfHXgPjfwFwfZHIw/MnRv0GWyaRG2G7MzEBzkpwAf+VG/xFk51mCKhW0DpVZFrLswwIbJxlsvsZCssasBu9+bRjC1L4iiVDu2UsBjv+rfw7azVmw/VNEyqpAqzivPggRZsSvM6eLpcZSQYE7k33ysuCFeXVzDByNydnu9sQw2EmIzkK+nEQNPSo3JMEyHV0B8wR+7ITwnUuE26gOjZmyRejGMfSPfmFIo1/TocMVv6epqVbnxepf8kT/u5Al2abRF4+M5ULoIQKa2gOeNOEIa2KDm8lR/B3a8HLlaXC6fhZYo0nYfpISp6EGJ16HKGrxi0CvPop6kpU7VLa0xZZWd9ZQSfAGZUcrWjb8671VxHiPfrxCcbppAWOCgEXIW3/C1X7008dTrIJam3ELdCEPVs89hk1e4uAiEWj0fv91xeXdOfnC1Hud6E6yZ0xsYm5ahSQpCGsv1IxfXCgJ1GDNhKEu3+mkN9NPlvfpTyP85ShjM24c1ExLbm9tjQZezcGrwW2AkVAiU/CzzSuBT+38vuxhSScWAQqwAmQe+/7Qb9VcOsABTZzC j6cLxdEX xC0+7C8BGFrs38kDDlDuT4O0PbELoV56zCGwliSxmmaShFzqu253o5WAbKMSOK/Sev1Eohy5oDUCPEaYe4LoFopHj2KMBuAflfQ1Sb1RWM9p3mQFqk4hQSSJ4wU47extThJDGX1gomRcEZAPVQ/+Vqje59wky2SBLGIoISD5/+BP+V57YQo8izPYyUl+As/xBEopjS0dp0QYEWne2uY2515suwGd8BN6AvX9CeBlEKF9Beu2JmfAsKKl3psDmlsFGhe6sFXdoDPY3Xv12U49fNp8xkdETAUh85ivH8HDRjghloaRrJnEg2nk7k32ElHa74BI+5N3cTGH6fGASgknUO/KtI6VFYAFaejGo7QgyyP1Vop4SHmEsae7vT6CWrBT3c0HjaIVxaCzvIF97mGplxVmbGL9L5XX/BVwMbXc5MJJu1zz+jYSMP+y9ZukMt+EwTLEb3r3bZCOmEafarXGTUM9yjkdipblk2xEb8AiiMxeJKJij4NDCo9JJD/Zs1vstD2KXEf9qfUZBsPoUzrjpWglpmFsGGAyRMolu X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2003067076-1055337799-1687894336=:2486373 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT 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 > --- > 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 > > --2003067076-1055337799-1687894336=:2486373--