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 6667EC27C79 for ; Thu, 20 Jun 2024 22:48:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D3D3F6B00AA; Thu, 20 Jun 2024 18:48:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C51168D00DB; Thu, 20 Jun 2024 18:48:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A7E468D00F0; Thu, 20 Jun 2024 18:48:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 7C4F38D00DB for ; Thu, 20 Jun 2024 18:48:29 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 35FF916061B for ; Thu, 20 Jun 2024 22:48:29 +0000 (UTC) X-FDA: 82252757538.23.6987272 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) by imf01.hostedemail.com (Postfix) with ESMTP id 8071440004 for ; Thu, 20 Jun 2024 22:48:26 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=BUcwBTAi; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf01.hostedemail.com: domain of ak@linux.intel.com has no SPF policy when checking 198.175.65.19) smtp.mailfrom=ak@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718923699; a=rsa-sha256; cv=none; b=0+avAQXe1IXCDHvVZtFTIw+hOhE8z9u4SjItPY+8uA0TtIPAdc2CnjJ264LzDEVZL1P6WS Ia8/qPLZrooXt9LFaSulZqQv7IB0wXnve0hzN5ooqZOAHYU7iKX/dl662o0eG4cp0Xgv2s DQIbdJyQQPZ2Lnl+zHRM2eevAVtweAA= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=BUcwBTAi; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf01.hostedemail.com: domain of ak@linux.intel.com has no SPF policy when checking 198.175.65.19) smtp.mailfrom=ak@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718923699; 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=zoovoJhNRfgDjC9B72bTorp2/szLX092n+btLcuuqSU=; b=FD8AMuefj6ldGmEl5FU8kQUcnpj9FF34pGEFkXU1namZrguHu+AHC5qdbLvMxgb0jMnJ1h oXdlaj0GYaAhdt40zuJHO/LMZBUzkwg/Lt3GCYsbSZBkLGfMqBQto32qUUap2knlAVC1Fj 6dFyTUA15cv7TaYWoyPWz6FF0IivJJo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1718923707; x=1750459707; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=zoovoJhNRfgDjC9B72bTorp2/szLX092n+btLcuuqSU=; b=BUcwBTAin4Z+8qTxMd8bdPF+jNsNpwuqVY5UyXUeGqgaKmfqO3lNa9P7 Ond0X3PkDYf5gWnTjvINk6OOIhwEel9nOhSTUTC16enQz+Tee28fDm0BL AoUVeZgTz6SKLr1JJLYPFLUOGX4TaaNYtuawGPy/YAnNlUDwL4vQDSoyQ en6wmwqGgW2AmsKS3aBoQiR9cTnFzjFCzQ7v+ZuujioYEpRYHjtMLLMDM EIk1EQDmvXyv3d6AiYnm+5sF8f8bKcWEVWXG+CPhWFqKW6MdboFx8x+Pi kvNRhhMOOc6KohGDSV6r3M+8UAG3ZitUJEnWiq8OQ0F5jACqlOW8DpkHF Q==; X-CSE-ConnectionGUID: UJUbeuWJS4e5JS+wcafTog== X-CSE-MsgGUID: FeANIDlvS5u4Jow3COjuaw== X-IronPort-AV: E=McAfee;i="6700,10204,11109"; a="15767065" X-IronPort-AV: E=Sophos;i="6.08,252,1712646000"; d="scan'208";a="15767065" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jun 2024 15:48:25 -0700 X-CSE-ConnectionGUID: XpaLxycjSxeqMiVY+nQ8Bw== X-CSE-MsgGUID: nKLgFteISSeH3bWw+T/wLQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,252,1712646000"; d="scan'208";a="42506433" Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.54.38.190]) by fmviesa010.fm.intel.com with ESMTP; 20 Jun 2024 15:48:24 -0700 Received: by tassilo.localdomain (Postfix, from userid 1000) id 537703003B6; Thu, 20 Jun 2024 15:48:24 -0700 (PDT) From: Andi Kleen To: Kees Cook Cc: Vlastimil Babka , "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 4/6] mm/slab: Introduce kmem_buckets_create() and family In-Reply-To: <20240619193357.1333772-4-kees@kernel.org> (Kees Cook's message of "Wed, 19 Jun 2024 12:33:52 -0700") References: <20240619192131.do.115-kees@kernel.org> <20240619193357.1333772-4-kees@kernel.org> Date: Thu, 20 Jun 2024 15:48:24 -0700 Message-ID: <87r0crut6v.fsf@linux.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 8071440004 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: h68dnrt6geougwq8yex8oto8ecjkd1ge X-HE-Tag: 1718923706-8991 X-HE-Meta: U2FsdGVkX1/tQh5vnaHSIM4RWxJEyPUREB4WBilG3VL4wxhh7T5awTQ73JZT1zhL7eFYU5zKKW/HXWM1k+Njjg1Hw1iABMACTo2LfSI7Tq9UqnhK6i7g8wTxJPNhqN8oN8fGNhYZMOsc94dBxgI54r1mk0+b2+kdXXk0mQ8DT9O+x9aZpR6HmmL9xEHgxuPWKRxW7H6oLI5r69mmM6GAV/BQpJHPadzLD0sO+M2RxTXqn6UXJmsR0OSKObWFZQcnBnSrTSGvH6Wz9sqWbMyFWmhJmGMLbCA53QpmbMhPS50MKExnhbiEr7JFsfVX7pjjHtrLezXk1O4n1CdwBaKwBGHJsKnTVr9eDcr4Tdbgp15FFFuVdwq9KAni36sb2YVntLOXdWpJiqWk4ZmpuYBuf5X5Vgr921J4ju7y7ejaYrEUomKkocBfPbxSkLe6AeEtPcvQDLS9MmDtzk+9AeMTZ/iXqgzTQg4A+zluXX8K8/iRaXtynTc3Fr3vSAKL1TtR9t7s6MPb/tIcXg06p/dhTrzpOQx/dj/AX5yQcgo5Ig3U9aYMX+uxj8TXZJwhypUJ22OnlqKvx8YABik6giz5HEX03wtxUS0S5W+uY1uyqnJsvPLB8xRP5o2G1GQPZZ5+hdAF/SBC5/M+clSKYlt4yg4X8fWbiyzmiIMRGvkiOMYQWxB+cE/d2dGad+wUStvRvxp6S7p+5tR32Df+y/53fdSVk5eHEaLi28pqkXgoXi8ihctrUMgUAS8bHNf8Pb538AWs2QT3VIkEHfjVSHHadKUhMmtzWa5sqBT64PulrvUrJ5lHDgpRHK2fzBMlTx+j8S8+COicAygD4XrKa0exggp740eE9ecZBvBx8d3vRKvFIfoSFjo87wC9+JtB7ehf9kznyKSP5r4ymbna+cUu6IMjGbWISmEXE6QXF4vi/lqspmi+0fcbc/7Zi32gH27h7cr7TFzJTjZS7aYKYwP BWSwihc8 MLWWMkqQ5DoHuSbCcS6iPGs8jGJq1jldxLgfCJ7dgEE2EzZ1aahna1gYQnDHLc+RDBI6ciIcEDz/uS2k0RHkvkO9sgaX2f6SfdGhBdf0VfKw3EdxbJG0N1mYT9hQpMr+56fFbK7AZJU7+GYVmxAaeprAtEuAlaUCOHTCdyoAY9Rz+J1WmameX4Rw0PD9ih6n1cFtIoBlQjIJoCPw7vdpM9vcgx0MPnXYqc68EjZ5qCU8JcxD3oWJ87YvdnR0uyKO/eL5k 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: Kees Cook writes: > 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 that are directly user > controlled. Addressing these cases is limited in scope, so isolating these > kinds of interfaces will not become an unbounded game of whack-a-mole. For > example, many pass through memdup_user(), making isolation there very > effective. Isn't the attack still possible if the attacker can free the slab page during the use-after-free period with enough memory pressure? Someone else might grab the page that was in the bucket for another slab and the type confusion could hurt again. Or is there some other defense against that, other than CONFIG_DEBUG_PAGEALLOC or full slab poisoning? And how expensive does it get when any of those are enabled? I remember reading some paper about a apple allocator trying similar techniques and it tried very hard to never reuse memory (probably not a good idea for Linux though) I assume you thought about this, but it would be good to discuss such limitations and interactions in the commit log. -Andi