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 0E098C54E58 for ; Mon, 25 Mar 2024 19:32:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 65CC46B0089; Mon, 25 Mar 2024 15:32:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 60CEF6B0093; Mon, 25 Mar 2024 15:32:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D4586B0095; Mon, 25 Mar 2024 15:32:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 3BA406B0089 for ; Mon, 25 Mar 2024 15:32:26 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 08CF9A060F for ; Mon, 25 Mar 2024 19:32:25 +0000 (UTC) X-FDA: 81936557892.17.07AFBD2 Received: from out-172.mta0.migadu.com (out-172.mta0.migadu.com [91.218.175.172]) by imf29.hostedemail.com (Postfix) with ESMTP id 95C4112000C for ; Mon, 25 Mar 2024 19:32:22 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=Tt9y8gqe; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf29.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.172 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711395144; 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=1gryeiILn0m+T/+WOsFBV2kucx78V+7dn4UI+UGeudY=; b=d1fFH6N9dEyYMks3ovQKJXHzDEV9C0xqUdeoNSsZj6IgmfEujAtDNxe8rEWUYejKIDF1yQ 1DGkaZeEUnHBOvYYnv5WiV0qlsSpYjQNp7I7udunPQR84/UzxwE210sEAdj//xBCgu54S2 RjcoyoOAOBannxGveJDAaU5ksffb718= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=Tt9y8gqe; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf29.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.172 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711395144; a=rsa-sha256; cv=none; b=LBH4FG66+KcqSJetY6yPy8ajcIliyUOPGFD+SJkX8idFUZjmZoibHw+vqOdvpcWhGuLR1P xPOTDkzo2r7U8pTtFRSGOg3R1lVV/xe5m2/60vASa5QoDRLvQ49oeB7OOGflu6Fb7CdySp rMK77LQl0MdJYsOVFC33h1fksvymSrA= Date: Mon, 25 Mar 2024 15:32:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1711395138; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1gryeiILn0m+T/+WOsFBV2kucx78V+7dn4UI+UGeudY=; b=Tt9y8gqecpCFTIL+y/osjlhWrpo1KQtb/1UXfmFeze654xW6zkDcEyie11UoFjNjp4BXp9 oZP1t2r17ya36MzSoPE3/EfxxXiNsLPXf7EoIbhni7lnDr7tntgBdh7Yphl73XODtkfzFy eoEKO/4ji3L41u98P86ayEAcTjMOSPo= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Vlastimil Babka Cc: Kees Cook , Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, "GONG, Ruiqi" , Xiu Jianfeng , Suren Baghdasaryan , Jann Horn , Matteo Rizzo , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-hardening@vger.kernel.org, jvoisin Subject: Re: [PATCH v2 0/9] slab: Introduce dedicated bucket allocator Message-ID: <24vn56fs7oohqgw3rhssiwglmviruqnt44y6oeajzvskostcrr@7jzhmxjbhcha> References: <20240305100933.it.923-kees@kernel.org> <5e1571de-2c5a-4be4-93f4-01582094ee96@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5e1571de-2c5a-4be4-93f4-01582094ee96@suse.cz> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Stat-Signature: qukottrzrnt1ysm71se3czk4qk38u5kt X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 95C4112000C X-HE-Tag: 1711395142-9343 X-HE-Meta: U2FsdGVkX1/eQEgNtzrFSPhhZ/bQFbBaKp7TUxnX1r05TgqLLE8IXYD1MGy8o3HYXzNTmSZRV6ET9OPs4IIcM88/AjDMBcHLF23IqLIRSRz1IHcAkgMgI8oCYeoFo5k9lgUbelsLIywsc3g2P0yfXS7KgXnJ8CQBjhhcTiK4e8B38HF/8ndaT879FIH8axn9b0iW9f+9Euy0A3QsZDxnV2On4rkRm5mnFctLPuSEcw/YLj25V8urj5bdix5EJssVcY4UxyIk219Wv1te7MEf9e/3kuVOhZsUASkimeAzPA3j/QiOwzzH3k1zKKBIYvpz9tetlTji4Gx9GxJLV97PanybWPs24gTLJqj1zxqo0GAs8QunsLDYho4cV5OP47jUzO4sZ+xpwcAyHFIIY4CvK5UkwnMzRez5jWSIf1SGKE1aQbQdfRub2RwnTiRfHL1rQHTv7V5Uzot+I+OtLFcLD7CuwDJU6v5ng2+jjvOVqM3t4SlAcjqOb83BYXFcbFIvEv6fwb05EiOTpVjlybATuPoQuIQztWKFspH7wMMd2tBXEgwx49Dxe5E9Wi2dKbw6QhUM8Y4eLroZkkzEoF0OFgmtMs7W5J3FHxaoVq9eg4MynzEMDBJIgivY0rw4FfSpyAVVdevxT8duyG9QKE7ZQIftinRVw5BmcVpEm2rocBHrepnxuuBAWrm1xwxf9JKbDkR2lJEakSTvIfl9CcLlUF+yJmW0zIMTX4u5ZycNEkhyWw33F3wmaZRQ9sQV5/pZRDaxdO7hveHzUBMB2tunfs76BD6ox2gsgBigKocYu1HwjjkiR2ddwc+ULa5hQolABNVKEtsewRa4LtYK4loBqygQgBJnU4Ds3lnkKGI1jWlIjq0CVm6rHCjI/HPfdvG3sVOi77jvOND28QS+5syMq5DZSwB6gZ0NTwTflQLTevpVSOHC0ebi6RgciXdeYTLogPIjPb+YT1oZxjOefsV 7fcbS5vK HHNJX0oH7ZQ1ZXQCgU7/q6e3U0u2kkm6A6w6M8+Gu9AQJsWDl7ThNII0p9NK/H30C9MGAnZzpQKQZL+7aMrlmmuiu0Kb8R9fQlu5aXW1wlcJ07W9DoBKjUPyu0MjzTZvD1bBAibM42X5H5x9FWJNeEq4vykaCrb9IJ6LCXyrsFBOs4SY98dWsLmexem99R7IyY/KmeVqO+76D9nRQDFwmFk6cbHqPC6SLw4b8FtaaFABhz4zLnliOocFTsjY+k+vK6gdu5d5Zjz5TLABuACUfmQI/5bTjc9ANwp8MVU6q0F7yjfvr+q1GdyiMaU4MqYwkjKB25PY66V9yBPL7jy8SsLcUIzNju3W3gp3a0qsnjvWlT2rioCPgnyUtmnt8uW1Dlq8yI/7lyPhEthxLM7i+QZUs3eduR5oK3dm4W45XgXJV617ncS4NJ7qnfZ3+foLITSlTFGsG3KengqsMW8QQ5YdO9k52aXhMmH+wqUWw14ZqTWTirJUUm6FhcSk0pODuE4Khb934Y6APX91pzmFfyVkpPECdbpubyf3PLhzlUp1MOC00dJbZn2PrfDfcZ6vI2kjzpFJYMVpG5CKS04D0XiR6F9aKGs6vPpwkLryg26gyuRM3wjkIPBG8EiXHymg+5BU1kg4p8RFYeo2rMDHaNxiVicZGSpUaJSqbd/cs3EvHPo7L8bGpgYoAUm68eKmTTSr5UXOVWX+8WZcA6kHR8Himp6CfhogBGQmE3GjOzmXbuhE= 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 Mon, Mar 25, 2024 at 10:03:23AM +0100, Vlastimil Babka wrote: > On 3/5/24 11:10 AM, Kees Cook wrote: > > Hi, > > > > Repeating the commit logs for patch 4 here: > > > > Dedicated caches are available For fixed size allocations via > > kmem_cache_alloc(), but for dynamically sized allocations there is only > > the global kmalloc API's set of buckets available. This means it isn't > > possible to separate specific sets of dynamically sized allocations into > > a separate collection of caches. > > > > This leads to a use-after-free exploitation weakness in the Linux > > kernel since many heap memory spraying/grooming attacks depend on using > > userspace-controllable dynamically sized allocations to collide with > > fixed size allocations that end up in same cache. > > > > While CONFIG_RANDOM_KMALLOC_CACHES provides a probabilistic defense > > against these kinds of "type confusion" attacks, including for fixed > > same-size heap objects, we can create a complementary deterministic > > defense for dynamically sized allocations. > > > > In order to isolate user-controllable sized allocations from system > > allocations, introduce kmem_buckets_create(), which behaves like > > kmem_cache_create(). (The next patch will introduce kmem_buckets_alloc(), > > which behaves like kmem_cache_alloc().) > > > > Allows for confining allocations to a dedicated set of sized caches > > (which have the same layout as the kmalloc caches). > > > > This can also be used in the future once codetag allocation annotations > > exist to implement per-caller allocation cache isolation[0] even for > > dynamic allocations. > > > > Link: https://lore.kernel.org/lkml/202402211449.401382D2AF@keescook [0] > > > > After the implemetation are 2 example patches of how this could be used > > for some repeat "offenders" that get used in exploits. There are more to > > be isolated beyond just these. Repeating the commit log for patch 8 here: > > > > The msg subsystem is a common target for exploiting[1][2][3][4][5][6] > > use-after-free type confusion flaws in the kernel for both read and > > write primitives. Avoid having a user-controlled size cache share the > > global kmalloc allocator by using a separate set of kmalloc buckets. > > > > Link: https://blog.hacktivesecurity.com/index.php/2022/06/13/linux-kernel-exploit-development-1day-case-study/ [1] > > Link: https://hardenedvault.net/blog/2022-11-13-msg_msg-recon-mitigation-ved/ [2] > > Link: https://www.willsroot.io/2021/08/corctf-2021-fire-of-salvation-writeup.html [3] > > Link: https://a13xp0p0v.github.io/2021/02/09/CVE-2021-26708.html [4] > > Link: https://google.github.io/security-research/pocs/linux/cve-2021-22555/writeup.html [5] > > Link: https://zplin.me/papers/ELOISE.pdf [6] > > Hi Kees, > > after reading [1] I think the points should be addressed, mainly about the > feasibility of converting users manually. On a related technical note I > worry what will become of /proc/slabinfo when we convert non-trivial amounts > of users. There shouldn't be any need to convert users to this interface - just leverage the alloc_hooks() macro.