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 CF7D2C433FE for ; Mon, 21 Nov 2022 21:35:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 507B66B0071; Mon, 21 Nov 2022 16:35:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 49B566B0073; Mon, 21 Nov 2022 16:35:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 333536B0074; Mon, 21 Nov 2022 16:35:40 -0500 (EST) 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 20E0B6B0071 for ; Mon, 21 Nov 2022 16:35:40 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E18D51C6226 for ; Mon, 21 Nov 2022 21:35:39 +0000 (UTC) X-FDA: 80158756398.27.CA615BE Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf02.hostedemail.com (Postfix) with ESMTP id 81B888000B for ; Mon, 21 Nov 2022 21:35:38 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id A29856148C; Mon, 21 Nov 2022 21:35:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3FB4DC433D6; Mon, 21 Nov 2022 21:35:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669066537; bh=ME3JoFynEewzrOSy9c/B1ctbwfUDRGobuFBsXDrfdw8=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=qoxS8FrV44z8YCfl3O/WSwGWeEfMrhZaleDfeKlLyy/FburDP3i2I/LH7Wf7Gzyv5 f94asK7C6zzNQVssQefVHv274RkO1LR0qMFPlxvep6gbuBy5YUlQLOdHWermXvcmsa oLRDGu7JRKVZ3rglw6KkylEpLbjHNCuLEn1Jnvju95PohaVMggaw/qTcfH3RDk83aF oZppzQSx8/NUdzmWh/2CyQLePYR8D2eM6IeUrTlwaknOgX+n6v229zr8X+6K42MDjV JCVPOpIKDtS42aqMl+9o0ncZ3tV9zE++7CJEyYgB2zGvmYJn0pdeJcPWnvEgpYVlPw gborMbJ9tZYnw== Date: Mon, 21 Nov 2022 13:35:30 -0800 From: Kees Cook To: Vlastimil Babka , Christoph Lameter , David Rientjes , Joonsoo Kim , Pekka Enberg CC: Hyeonggon Yoo <42.hyeyoo@gmail.com>, Roman Gushchin , Andrew Morton , Linus Torvalds , Matthew Wilcox , patches@lists.linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Kees Cook Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_01/12=5D_mm=2C_slab=3A_ignore_har?= =?US-ASCII?Q?dened_usercopy_parameters_when_disabled?= User-Agent: K-9 Mail for Android In-Reply-To: <20221121171202.22080-2-vbabka@suse.cz> References: <20221121171202.22080-1-vbabka@suse.cz> <20221121171202.22080-2-vbabka@suse.cz> Message-ID: <206E0154-63A6-45CF-8E19-BD01B35AEF0B@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669066538; a=rsa-sha256; cv=none; b=Kht4/vuvdwzMuN6GMxpO4pJAsk250yJNIBBITimsoBk6AI5mRzXGQzI/msb4dcr72hxqSO 28CyjDk2/jB3iEE9dW9UaD5g0R/ax8A/xhYTnskHzdGaVc9g3cj0CwbX07vq0zdOqDAa2s y0HCg5AOJcXjuSVSUYU+lW/qkbFvdQY= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=qoxS8FrV; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf02.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 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=1669066538; 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=BCh3SblZJegFw1Q6nM7ONkeIQrQ7qXoov5X4CDhg5eQ=; b=EvU+B3b1OVWVgWWYJ2Gr1V+pInYG3Iq59GMevWxQBCT8SiM9pMXOGEdnDg+/pixYEGZQXf 3IpPcDAuEJbR/DSbEvkJVKTWoimezXzwCdRGOIIL8cjEHZR9AphtXg8wD6mPWOhkkGRhxR lO8uWmhqwQZ9Q4cP9FQSQyyJz/FsLgM= Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=qoxS8FrV; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf02.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org X-Stat-Signature: jyifubaysb9jdh5yxr5tsmrxc6u87jgx X-Rspamd-Queue-Id: 81B888000B X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1669066538-566400 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: On November 21, 2022 9:11:51 AM PST, Vlastimil Babka wro= te: >With CONFIG_HARDENED_USERCOPY not enabled, there are no >__check_heap_object() checks happening that would use the kmem_cache >useroffset and usersize fields=2E Yet the fields are still initialized, >preventing merging of otherwise compatible caches=2E Thus ignore the >values passed to cache creation and leave them zero when >CONFIG_HARDENED_USERCOPY is disabled=2E > >In a quick virtme boot test, this has reduced the number of caches in >/proc/slabinfo from 131 to 111=2E > >Cc: Kees Cook >Signed-off-by: Vlastimil Babka >--- > mm/slab_common=2Ec | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > >diff --git a/mm/slab_common=2Ec b/mm/slab_common=2Ec >index 0042fb2730d1=2E=2Ea8cb5de255fc 100644 >--- a/mm/slab_common=2Ec >+++ b/mm/slab_common=2Ec >@@ -317,7 +317,8 @@ kmem_cache_create_usercopy(const char *name, > flags &=3D CACHE_CREATE_MASK; >=20 > /* Fail closed on bad usersize of useroffset values=2E */ >- if (WARN_ON(!usersize && useroffset) || >+ if (!IS_ENABLED(CONFIG_HARDENED_USERCOPY) || >+ WARN_ON(!usersize && useroffset) || > WARN_ON(size < usersize || size - usersize < useroffset)) > usersize =3D useroffset =3D 0; >=20 >@@ -640,6 +641,9 @@ void __init create_boot_cache(struct kmem_cache *s, c= onst char *name, > align =3D max(align, size); > s->align =3D calculate_alignment(flags, align, size); >=20 >+ if (!IS_ENABLED(CONFIG_HARDENED_USERCOPY)) >+ useroffset =3D usersize =3D 0; >+ > s->useroffset =3D useroffset; > s->usersize =3D usersize; >=20 "Always non-mergeable" is intentional here, but I do see the argument for = not doing it under hardened-usercopy=2E That said, if you keep this part, maybe go the full step and ifdef away us= eroffset/usersize's struct member definition and other logic, especially fo= r SLUB_TINY benefits, so 2 ulongs are dropped from the cache struct? -Kees --=20 Kees Cook