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 43BF4C27C79 for ; Thu, 20 Jun 2024 18:41:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 77DFF6B0396; Thu, 20 Jun 2024 14:41:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 72B8B6B0397; Thu, 20 Jun 2024 14:41:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F3076B0398; Thu, 20 Jun 2024 14:41:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 416F36B0396 for ; Thu, 20 Jun 2024 14:41:52 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B26EFC04F8 for ; Thu, 20 Jun 2024 18:41:51 +0000 (UTC) X-FDA: 82252136022.06.411B096 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf11.hostedemail.com (Postfix) with ESMTP id 7113B4000F for ; Thu, 20 Jun 2024 18:41:49 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="t1Ksv8W/"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf11.hostedemail.com: domain of kees@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=kees@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718908899; 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=OUYKKPemzbWjY+NB1WRvAbjyMmc4gtqlwbLRwZjzLYk=; b=GOFOy5lcrE6Gp0OartMuEAAPaiYhpokk0D3mKtikfZa0PU4RajKmw29sn9d9TcvSVLrAaQ h0qzt4YxcceXGTC9slJW2PV2fruxgkSznCmR8hPfbuOEagJCsaReVu+dhTJ8uF6aYKo5s+ Y5QY/8yB0PU60ZGpCyDU19J7jQUo6iU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718908899; a=rsa-sha256; cv=none; b=EmcsjY3FcDDuiVqguS645CqgfFKK2AiGkTPOgGqNoY3OtOyx0QkrJBgchPRhqudMWUWTwN x83QmgQaQ6Q3a+gPFl+2AZuWpaEJYusPtT4ulZezcUTpP46mAaWD7GcTG7n++Biow8abad 11wKQAdohgJMpj9+MH4nb/uQ6S7qGzU= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="t1Ksv8W/"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf11.hostedemail.com: domain of kees@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=kees@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 4F843CE28A4; Thu, 20 Jun 2024 18:41:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 815A3C2BD10; Thu, 20 Jun 2024 18:41:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718908905; bh=a0OvAmDcT+HUsVh7NHWlsxuonu7EIGyjpP5cNmXaiJM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=t1Ksv8W/rEtx6NZTGvA4yhN3GLcpoOPuO4kh/j/guKM4DuzWnsmxz0sETH+GZprW9 e95FrUmpaiWUZmYvTJYQSqr+cf6phCzKLhux981lvX1eOfjqE9/ON1wlrOs7DGh9px e4Lz67fjNMKx3gi7VppJ1f4cHqkROxLzOHRB6QOR3sHw959Tkv9agzhyYxKeaBM05o cYejZYgHWSRwXAYeajNNJFIe+VB/GAsvJ2LTUb1rW4YiQvlsVUKNKnhpmCcEEAblyB TQf3z0puGRC85s7ZxlkPZv2pnSoQOdzsSAUJ6/6NUpocNDLK8PzUsRACgxqG+NAumZ Pc4/grSmZr17Q== Date: Thu, 20 Jun 2024 11:41:45 -0700 From: Kees Cook To: Vlastimil Babka Cc: "GONG, Ruiqi" , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , jvoisin , Andrew Morton , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Xiu Jianfeng , Suren Baghdasaryan , Kent Overstreet , Jann Horn , Matteo Rizzo , Thomas Graf , Herbert Xu , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-hardening@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH v5 2/6] mm/slab: Plumb kmem_buckets into __do_kmalloc_node() Message-ID: <202406201138.97812F8D48@keescook> References: <20240619192131.do.115-kees@kernel.org> <20240619193357.1333772-2-kees@kernel.org> <7f122473-3d36-401d-8df4-02d981949f00@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7f122473-3d36-401d-8df4-02d981949f00@suse.cz> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 7113B4000F X-Stat-Signature: hrbcnh5c3xtan41g5euyxddg8qpq1tty X-Rspam-User: X-HE-Tag: 1718908909-801645 X-HE-Meta: U2FsdGVkX186wD1+vyhA+YReTQ3qM9xeVV7U0nBljSyXpYcJMlkI71sdi1p9QVW11h5WPiFlyoWWpLhmsQ+JQy5+glN9o2MLbrI8d3s97t5yziHvupZwuccLV07fP7fU+HVtRCst0t25zNyF3O/C76se0PxXkojpCq6ncG3PmdZW+aTDY8coWt3qhEUDE4GULT3sAfUVM0UDRrukflYwP/61pGWa4guCULdux91aipZJX7rMm8TmuqQ3tfhUTbLegIOEn4bSPWjVYP4+HUEyvoAlX7hQgTiGniq3MJRqoHHt/x4ue+qJ0cEp/h386SNb9SdBhSB2OWPIbZCkrr9Jym+ptf7I65qQYNYK/xXlQ50z5q6BBtHss2k+a1xOs57FZpGaL2CgMXWqQkPewNrSD/IiWNYnCTldlZeAu3AN0g9aDdNgp0GOa4nJmPGRO1MjbUQu+RgtaM2ARYMUfH99QS9J9hyA1Zk3VjOTAxfK9yJwbFkzbMSfk98SxcKqdE6S28VT03riA6Qw7oiHc11F0xnHEWWU1+Bt4AhdTuRm0tpo3cNeJ4mmmvFN1hj2nqL9hfhTUds57VKUyKGp/fRBSW+O6Lk8IVeIEjrY0CfYe9sPQdl4aXQIAsIrSLfOtPMqcmfAkhFkTgBcnyq+IxSKCK8TIJxC8c8cPm0AwYNMkdLnhOeF/gVazTdqjLi/TSRH4wgfN8jl7Xnd+9Ou/tZZODd+uQIjxv2F0ZC3eKZqcyrCd1CcAs8i/2Kz8YWISZcD4vuZYAvYRezUqoxIMvr2Y3Uf01bDP0X+bUAVfFsRWjuY6+6RtF0dg4C0jew1cJdXEzIW6wUhnlzg5gpQ+jWodQtDJUlXyyCegMeOEGhMSxvpp/Wwj2WgCDKEbXDbuNIcjT5unGFKd1/lRzR46/Y7bPjyfPHSKKVZuksVmm56UjvfDxj4fEMJ6UjDx4TXcsHNrRVWypmISIOflpwa1If A7l5kx+i SA57ieCf9AGisRzfw7fc2PCWSIBheTrGz2Qza13j1plvlg1Tzz662EvQtGsmKuYGstGt2WND6+8tAQtzy+l6JZ8HazGe8b36GRl7if7H0lgZWDBuymzw/ZOhlWG3mtssCJXG4/iZ+AwPydL61PBNt3fj8c6PdFX7niNSgAhhVD/AdsslgySjrNDCU0SSINEdm7QP7urzZlGs12w8T/YFh9JjvWrvMgYTKCYDQEMmqTnm9dZztOgio9KUWK3HOuJZ/SCeziNB1+4U38g/E+scz9v4CsFGqlz2V/7ywa3CVroXJFDASw1mtZIL4CpU7rrKBmqKqpcMPjaoEiF1Z5YGn2qx9Gg== 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: List-Subscribe: List-Unsubscribe: On Thu, Jun 20, 2024 at 03:08:32PM +0200, Vlastimil Babka wrote: > On 6/19/24 9:33 PM, Kees Cook wrote: > > Introduce CONFIG_SLAB_BUCKETS which provides the infrastructure to > > support separated kmalloc buckets (in the following kmem_buckets_create() > > patches and future codetag-based separation). Since this will provide > > a mitigation for a very common case of exploits, enable it by default. > > No longer "enable it by default". Whoops! Yes, thank you. > > > > > To be able to choose which buckets to allocate from, make the buckets > > available to the internal kmalloc interfaces by adding them as the > > first argument, rather than depending on the buckets being chosen from > > second argument now Fixed. > > > the fixed set of global buckets. Where the bucket is not available, > > pass NULL, which means "use the default system kmalloc bucket set" > > (the prior existing behavior), as implemented in kmalloc_slab(). > > > > To avoid adding the extra argument when !CONFIG_SLAB_BUCKETS, only the > > top-level macros and static inlines use the buckets argument (where > > they are stripped out and compiled out respectively). The actual extern > > functions can then been built without the argument, and the internals > > fall back to the global kmalloc buckets unconditionally. > > Also describes the previous implementation and not the new one? I think this still describes the implementation: the macros are doing this work now. I wanted to explain in the commit log why the "static inline"s still have explicit arguments (they will vanish during inlining), as they are needed to detect the need for the using the global buckets. > > --- a/mm/Kconfig > > +++ b/mm/Kconfig > > @@ -273,6 +273,22 @@ config SLAB_FREELIST_HARDENED > > sacrifices to harden the kernel slab allocator against common > > freelist exploit methods. > > > > +config SLAB_BUCKETS > > + bool "Support allocation from separate kmalloc buckets" > > + depends on !SLUB_TINY > > + help > > + Kernel heap attacks frequently depend on being able to create > > + specifically-sized allocations with user-controlled contents > > + that will be allocated into the same kmalloc bucket as a > > + target object. To avoid sharing these allocation buckets, > > + provide an explicitly separated set of buckets to be used for > > + user-controlled allocations. This may very slightly increase > > + memory fragmentation, though in practice it's only a handful > > + of extra pages since the bulk of user-controlled allocations > > + are relatively long-lived. > > + > > + If unsure, say Y. > > I was wondering why I don't see the buckets in slabinfo and turns out it was > SLAB_MERGE_DEFAULT. It would probably make sense for SLAB_MERGE_DEFAULT to > depends on !SLAB_BUCKETS now as the merging defeats the purpose, wdyt? You mention this was a misunderstanding in the next email, but just to reply here: I explicitly use SLAB_NO_MERGE, so if it ever DOES become invisible, then yes, that would be unexpected! Thanks for the review! -- Kees Cook