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 8554FC25B7C for ; Fri, 24 May 2024 13:43:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EEB296B0085; Fri, 24 May 2024 09:43:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E9A4B6B0088; Fri, 24 May 2024 09:43:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D3AAA6B0089; Fri, 24 May 2024 09:43:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B4B476B0085 for ; Fri, 24 May 2024 09:43:38 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 76C4D1409DB for ; Fri, 24 May 2024 13:43:38 +0000 (UTC) X-FDA: 82153406916.14.3E84B4D Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf14.hostedemail.com (Postfix) with ESMTP id 15315100014 for ; Fri, 24 May 2024 13:43:35 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=mRmEcha3; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=GXZoXpNM; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=mRmEcha3; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=GXZoXpNM; dmarc=none; spf=pass (imf14.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716558216; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=YJ9ov1ih/Htcxrz4xMcatNZjxTV+V0xnQjiLS2C3JSU=; b=pTOMkyGBpWexC14O3TyLakrXLHAO+Eii2Z9xDPk1sXhBz4mPvaWKGUEBtZbJosIjUUKpns 9Pl2qNp6wSYtnxUWoejdl9oEXFglKijOgWe6JnVX7vjW4SCo9xKnFdsb8sOcH0Edtj4Hsb EA08xyMBNewJEsC6Areg0lw+xFhxyFI= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=mRmEcha3; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=GXZoXpNM; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=mRmEcha3; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=GXZoXpNM; dmarc=none; spf=pass (imf14.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716558216; a=rsa-sha256; cv=none; b=tm0QDzbIqX/2lxYsiphqoDKgS5Oo8YYKql/fvnk53Cibvnln072Fd1zaewBKYrq1tWFeG4 Zg8Gu1foWwPS8/DScW2woSYuVJKI/tqql7C51egXSaahNIjZBD/H9uRQvH42GGeqlou6sb 93iQdnaT4OPa8bIp1+5W2LPZPL9kFuE= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 3EBAA20A5D; Fri, 24 May 2024 13:43:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1716558214; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=YJ9ov1ih/Htcxrz4xMcatNZjxTV+V0xnQjiLS2C3JSU=; b=mRmEcha3Ltz9RvWXvBHgnAjREnJML1EWvgVKjXYnAc/TC/uUALwWWAkKx4jUxqeCATbhQY 0TyEqSH8ALvf/SudneTHyGosAunG/R0gsrG0MzN3VNZNf/4LKmIRbnKp5PcgUK+PdKsl+M kciguIGkB/zGr5zMHCWyRyoqh9JykL0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1716558214; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=YJ9ov1ih/Htcxrz4xMcatNZjxTV+V0xnQjiLS2C3JSU=; b=GXZoXpNMzdZhUODaVJ840CfdlwgPp8zoRlDmRoJyoVSMJAL7zMi2Nr5zUk5Dgsz1Wzq4E0 yFz73dNdAZuPRcDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1716558214; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=YJ9ov1ih/Htcxrz4xMcatNZjxTV+V0xnQjiLS2C3JSU=; b=mRmEcha3Ltz9RvWXvBHgnAjREnJML1EWvgVKjXYnAc/TC/uUALwWWAkKx4jUxqeCATbhQY 0TyEqSH8ALvf/SudneTHyGosAunG/R0gsrG0MzN3VNZNf/4LKmIRbnKp5PcgUK+PdKsl+M kciguIGkB/zGr5zMHCWyRyoqh9JykL0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1716558214; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=YJ9ov1ih/Htcxrz4xMcatNZjxTV+V0xnQjiLS2C3JSU=; b=GXZoXpNMzdZhUODaVJ840CfdlwgPp8zoRlDmRoJyoVSMJAL7zMi2Nr5zUk5Dgsz1Wzq4E0 yFz73dNdAZuPRcDg== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 163B213A3D; Fri, 24 May 2024 13:43:34 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id y2EfBYaZUGa8IQAAD6G6ig (envelope-from ); Fri, 24 May 2024 13:43:34 +0000 Message-ID: Date: Fri, 24 May 2024 15:43:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 4/6] mm/slab: Introduce kmem_buckets_create() and family Content-Language: en-US To: Kees Cook Cc: Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm@kvack.org, "GONG, Ruiqi" , Xiu Jianfeng , Suren Baghdasaryan , Kent Overstreet , Jann Horn , Matteo Rizzo , Thomas Graf , Herbert Xu , julien.voisin@dustri.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org References: <20240424213019.make.366-kees@kernel.org> <20240424214104.3248214-4-keescook@chromium.org> From: Vlastimil Babka Autocrypt: addr=vbabka@suse.cz; keydata= xsFNBFZdmxYBEADsw/SiUSjB0dM+vSh95UkgcHjzEVBlby/Fg+g42O7LAEkCYXi/vvq31JTB KxRWDHX0R2tgpFDXHnzZcQywawu8eSq0LxzxFNYMvtB7sV1pxYwej2qx9B75qW2plBs+7+YB 87tMFA+u+L4Z5xAzIimfLD5EKC56kJ1CsXlM8S/LHcmdD9Ctkn3trYDNnat0eoAcfPIP2OZ+ 9oe9IF/R28zmh0ifLXyJQQz5ofdj4bPf8ecEW0rhcqHfTD8k4yK0xxt3xW+6Exqp9n9bydiy tcSAw/TahjW6yrA+6JhSBv1v2tIm+itQc073zjSX8OFL51qQVzRFr7H2UQG33lw2QrvHRXqD Ot7ViKam7v0Ho9wEWiQOOZlHItOOXFphWb2yq3nzrKe45oWoSgkxKb97MVsQ+q2SYjJRBBH4 8qKhphADYxkIP6yut/eaj9ImvRUZZRi0DTc8xfnvHGTjKbJzC2xpFcY0DQbZzuwsIZ8OPJCc LM4S7mT25NE5kUTG/TKQCk922vRdGVMoLA7dIQrgXnRXtyT61sg8PG4wcfOnuWf8577aXP1x 6mzw3/jh3F+oSBHb/GcLC7mvWreJifUL2gEdssGfXhGWBo6zLS3qhgtwjay0Jl+kza1lo+Cv BB2T79D4WGdDuVa4eOrQ02TxqGN7G0Biz5ZLRSFzQSQwLn8fbwARAQABzSBWbGFzdGltaWwg QmFia2EgPHZiYWJrYUBzdXNlLmN6PsLBlAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIe AQIXgBYhBKlA1DSZLC6OmRA9UCJPp+fMgqZkBQJkBREIBQkRadznAAoJECJPp+fMgqZkNxIQ ALZRqwdUGzqL2aeSavbum/VF/+td+nZfuH0xeWiO2w8mG0+nPd5j9ujYeHcUP1edE7uQrjOC Gs9sm8+W1xYnbClMJTsXiAV88D2btFUdU1mCXURAL9wWZ8Jsmz5ZH2V6AUszvNezsS/VIT87 AmTtj31TLDGwdxaZTSYLwAOOOtyqafOEq+gJB30RxTRE3h3G1zpO7OM9K6ysLdAlwAGYWgJJ V4JqGsQ/lyEtxxFpUCjb5Pztp7cQxhlkil0oBYHkudiG8j1U3DG8iC6rnB4yJaLphKx57NuQ PIY0Bccg+r9gIQ4XeSK2PQhdXdy3UWBr913ZQ9AI2usid3s5vabo4iBvpJNFLgUmxFnr73SJ KsRh/2OBsg1XXF/wRQGBO9vRuJUAbnaIVcmGOUogdBVS9Sun/Sy4GNA++KtFZK95U7J417/J Hub2xV6Ehc7UGW6fIvIQmzJ3zaTEfuriU1P8ayfddrAgZb25JnOW7L1zdYL8rXiezOyYZ8Fm ZyXjzWdO0RpxcUEp6GsJr11Bc4F3aae9OZtwtLL/jxc7y6pUugB00PodgnQ6CMcfR/HjXlae h2VS3zl9+tQWHu6s1R58t5BuMS2FNA58wU/IazImc/ZQA+slDBfhRDGYlExjg19UXWe/gMcl De3P1kxYPgZdGE2eZpRLIbt+rYnqQKy8UxlszsBNBFsZNTUBCACfQfpSsWJZyi+SHoRdVyX5 J6rI7okc4+b571a7RXD5UhS9dlVRVVAtrU9ANSLqPTQKGVxHrqD39XSw8hxK61pw8p90pg4G /N3iuWEvyt+t0SxDDkClnGsDyRhlUyEWYFEoBrrCizbmahOUwqkJbNMfzj5Y7n7OIJOxNRkB IBOjPdF26dMP69BwePQao1M8Acrrex9sAHYjQGyVmReRjVEtv9iG4DoTsnIR3amKVk6si4Ea X/mrapJqSCcBUVYUFH8M7bsm4CSxier5ofy8jTEa/CfvkqpKThTMCQPNZKY7hke5qEq1CBk2 wxhX48ZrJEFf1v3NuV3OimgsF2odzieNABEBAAHCwXwEGAEKACYCGwwWIQSpQNQ0mSwujpkQ PVAiT6fnzIKmZAUCZAUSmwUJDK5EZgAKCRAiT6fnzIKmZOJGEACOKABgo9wJXsbWhGWYO7mD 8R8mUyJHqbvaz+yTLnvRwfe/VwafFfDMx5GYVYzMY9TWpA8psFTKTUIIQmx2scYsRBUwm5VI EurRWKqENcDRjyo+ol59j0FViYysjQQeobXBDDE31t5SBg++veI6tXfpco/UiKEsDswL1WAr tEAZaruo7254TyH+gydURl2wJuzo/aZ7Y7PpqaODbYv727Dvm5eX64HCyyAH0s6sOCyGF5/p eIhrOn24oBf67KtdAN3H9JoFNUVTYJc1VJU3R1JtVdgwEdr+NEciEfYl0O19VpLE/PZxP4wX PWnhf5WjdoNI1Xec+RcJ5p/pSel0jnvBX8L2cmniYnmI883NhtGZsEWj++wyKiS4NranDFlA HdDM3b4lUth1pTtABKQ1YuTvehj7EfoWD3bv9kuGZGPrAeFNiHPdOT7DaXKeHpW9homgtBxj 8aX/UkSvEGJKUEbFL9cVa5tzyialGkSiZJNkWgeHe+jEcfRT6pJZOJidSCdzvJpbdJmm+eED w9XOLH1IIWh7RURU7G1iOfEfmImFeC3cbbS73LQEFGe1urxvIH5K/7vX+FkNcr9ujwWuPE9b 1C2o4i/yZPLXIVy387EjA6GZMqvQUFuSTs/GeBcv0NjIQi8867H3uLjz+mQy63fAitsDwLmR EP+ylKVEKb0Q2A== In-Reply-To: <20240424214104.3248214-4-keescook@chromium.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Action: no action X-Rspamd-Queue-Id: 15315100014 X-Stat-Signature: wo4g4opwk6aexa3a7cx5cikt9ntueg4a X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1716558215-846773 X-HE-Meta: U2FsdGVkX1+IXNT9xjXayJ769uX0LMtg3tnxKpsx6O/487LtVRpk44ZyHk4V0+ZNaE7h6SRUifGOAr5ssUP9BNG3r14ycpA2WYbMx/65edOztNAL5vXuC79/ypj2+o96GSweHUsYACDliRTKEx8iPtHv5Qqw2se+melLIUPbIw1d4BnM0JFMxUlJYhhvZhk5OOaNU/4KO1phxeid5+q0q7vmyLKj18nqkLJBmwzi9mmsxlyhVq5mv5YqsNwvEZdioa5khFjYrcKiKrvWBhr4hGbGHfOUlviQyJ17BjNPrLhQ3ZiJItor3zlPpZ4bZvbOdrvZijSJd3qMcvaEhbhMaeHz5hvojwUpEAx3wOIa72xnMqgZlGpWxs7zxO7tJSWxpd5Es2n35tbYIdp8Vsi1Doy9ErA/Z9CqZI7sKTCOtAlisciAXBmoeC4g9C0kfeq3bL6Saf8X+ggOp/Oxq0WIZ+56nz9UkIrlCm7sQpRITTHcYOlB9goHo1TlWeyVwOoyXaPkX9piM3MPB404M/FXtmIxuRgBCG+l2FlUvY/ObhH5Pf2MzD/oMGpRdjMd5lDc6z18VsTcdjUDHmscQILlQNiwCXXilV0jt1dk2YnXCslGEYLdGBLhtrPVc4IHd7iQh4+F7vHTcs1tYvqK+t/aog4HKxtm5qSH2bWTcgAXkwjVbE7/jLe7ouIXiRQLg0BZ+3x3v1Ifduc5Su3lgKJtEJpHNpGzoCjImzGiweWZIrCOnnPhfoXK4djP4Ua1LyOht2IHPd6sLvJ7EswNmeZr0F0OTrUXzc4hRHD4uHKjpFZoiXxV+/m0UUdk/4ZeWyQoVpE1Puy/wGUYo33N5cTKbizO0JXsGK6++4/ITKwObry6uojqU/t2i9EbPHdPTnlJp/oBOWaPWTIj6HlFJo/ytdYxcoAljQ1EIn/OQoEctZiy7xzZHsOxoHUtOIoR31CcdwDSj9iLPYSDkzyni4/ KZ7SDc3o Pf3ghUiHjaWiO0u8MG/n0HyrHjcgziWwmhKYroGyqGEb40bSy5hlyzhMi7+0DlvSBc/dqHceeG+LCI+/9pGOx8VuDIme/LhFByV2O5GkP4FgcR7Bzk1uvqblynAgzObpDHCfWOubXTpS8aibAf8yjxaHriqFgSDEn8Z91kfllgSYPd9jxn1Al62TdMpc1unQe3XyPizaxNSKkval7tmQAusF7cGt/Zx6qx7io/I1SagcXv6J4/2OWuOJU1ViNyqXzfuFFxyv9EeZUTnl1KtqXGzGesPibtt+KKtvORQkirgsBGLaqWpDzQhbQ+MP1MSevvX6NG9SNi2ijchM4qUnqLorzXDirxnRqdXlcKLbRRaQPYXzw8VgDdAkQC/FAxEEHhBMLWK5Men45gkOtlLtETehjXETjK52nrHqV8LGCeZINnt6xXKOcaqGyyR+jCEQuqhEPJcccs/FE98Q5Fhg7BEDTI19UjEn2AUdPLqcXYCGMTDs3au2JTYOXzkICJTlP1iDMsfAZdw6yUAGdXtT6fvu9fF+u2eXnAT2GlhvZhs8tAuUyxrXcczyArWhQRNG2EGQZO1nVCvAo3U0cNZwbCq9SICGEGZR/srku 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 4/24/24 11:41 PM, Kees Cook wrote: > 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 isolation these > kinds of interfaces will not become an unbounded game of whack-a-mole. For > example, pass through memdup_user(), making isolation there very > effective. > > In order to isolate user-controllable sized allocations from system > allocations, introduce kmem_buckets_create(), which behaves like > kmem_cache_create(). Introduce kmem_buckets_alloc(), which behaves like > kmem_cache_alloc(). Introduce kmem_buckets_alloc_track_caller() for > where caller tracking is needed. Introduce kmem_buckets_valloc() for > cases where vmalloc callback is needed. > > 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 to extend codetag allocation > annotations to implement per-caller allocation cache isolation[1] even > for dynamic allocations. > > Memory allocation pinning[2] is still needed to plug the Use-After-Free > cross-allocator weakness, but that is an existing and separate issue > which is complementary to this improvement. Development continues for > that feature via the SLAB_VIRTUAL[3] series (which could also provide > guard pages -- another complementary improvement). > > Link: https://lore.kernel.org/lkml/202402211449.401382D2AF@keescook [1] > Link: https://googleprojectzero.blogspot.com/2021/10/how-simple-linux-kernel-memory.html [2] > Link: https://lore.kernel.org/lkml/20230915105933.495735-1-matteorizzo@google.com/ [3] > Signed-off-by: Kees Cook So this seems like it's all unconditional and not depending on a config option? I'd rather see one, as has been done for all similar functionality before, as not everyone will want this trade-off. Also AFAIU every new user (patches 5, 6) will add new bunch of lines to /proc/slabinfo? And when you integrate alloc tagging, do you expect every callsite will do that as well? Any idea how many there would be and what kind of memory overhead it will have in the end?