Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp4613539rwb; Mon, 21 Nov 2022 09:36:58 -0800 (PST) X-Google-Smtp-Source: AA0mqf4QIcaSvcuvX2MJSUfQjzvN4FwWVlXlTbPrFt+lFLGh/Etmob3LQMQW2/oOP9JK8GBWSixj X-Received: by 2002:a50:fe8d:0:b0:461:9183:834b with SMTP id d13-20020a50fe8d000000b004619183834bmr2985963edt.196.1669052218224; Mon, 21 Nov 2022 09:36:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669052218; cv=none; d=google.com; s=arc-20160816; b=bRqtXut2hTjhyfvu5ZJBJc2c1kP0AjqmRqpe7HAG4UwcISN+34v8mGsj3zLdNHTez2 QqjGXaE1cNfPgNsZvlTxcxYYIOLfYsOXicfpRDzk9F90qhosIgViDxMNt6BkEhaxz6RU VbC2jAfJRq2xSg+7p4AYGKe31iNR0bAwpKuyyTo1whmOsqBhjMzuHfgQGw+xbgxplMwQ vnQpLhzahxb9DTWYIRXfIC6uAb0DrhusRj4WmVwa2elpyKx1BT3t5I4l6La1ciDON/uR PoOPjKht3qOpdqzll6O3lwWu0X3d8ptWo4zaCEIaRT3URpbRUrQwF5CMR53oujwGdrky hjlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature:dkim-signature; bh=iIAiT/GWezpGGl+wQsu7Tv56r8ovXdCIcTxm0/tgheY=; b=OH4gn9/yOQemXBxOCkzrxth+6xS29Ha57a7nfXKQmYtKul4+6quctLRGIWCFoji89D ZafSkFD9DBB3/RbIPAFNlMkXfI8bjw+/y/ble7HUmRtwClP+FcV4v7PC5JLDNDgvTO34 v5pYJTRCG0JTLj63ig1WxvMUaB9+LkcdZnA2lRWH5e4w7baOBjheQ85T70phCQy0IQQU Fm/jj87zRTzqayJ9lrggA5Ys2i7rK691pOYL/pUXRTvOSIgu9P8z8kljlEMV+MpVkImL aerMpHGHbeqU58ov4aFY8qLFQx+7alaG8nIM/StG8cDQBcSYz7tMJA9grQJXtdYCn7Lo ibdA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b="GvgIJH/o"; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=EtJakSav; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o19-20020aa7d3d3000000b0046909065335si7108384edr.525.2022.11.21.09.36.33; Mon, 21 Nov 2022 09:36:58 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b="GvgIJH/o"; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=EtJakSav; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230468AbiKURMT (ORCPT + 92 others); Mon, 21 Nov 2022 12:12:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33140 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230378AbiKURMP (ORCPT ); Mon, 21 Nov 2022 12:12:15 -0500 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AA862CB9C4 for ; Mon, 21 Nov 2022 09:12:12 -0800 (PST) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id ACEF41F8AC; Mon, 21 Nov 2022 17:12:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1669050730; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iIAiT/GWezpGGl+wQsu7Tv56r8ovXdCIcTxm0/tgheY=; b=GvgIJH/oeJ3busNpCVt+0e739h8ng7Y5p0H1Yvj8Oyyz4VNlMSoMJeSSkcRWIVIi+rwbOm 9iY7YqAVIJ3Q1bniJXZImm1Ex1ohYTS9h9AbyfhgjeSYdiWb6qiMTz0AxzDiwJ4mOMYjiq Wm6Ff/tkvltO0fhwoQ58ct2GtyMQF6o= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1669050730; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iIAiT/GWezpGGl+wQsu7Tv56r8ovXdCIcTxm0/tgheY=; b=EtJakSavfVgdRtpd6s1MaFBxytPX8OtTNWjLrPrxQfI+w+LmcN1V+PnY15Kz29QVD5t6PY jcDi72IIpNYPBRDQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 7F54113B03; Mon, 21 Nov 2022 17:12:10 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id INVuHmqxe2MQeQAAMHmgww (envelope-from ); Mon, 21 Nov 2022 17:12:10 +0000 From: Vlastimil Babka To: 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, Vlastimil Babka , Kees Cook Subject: [PATCH 01/12] mm, slab: ignore hardened usercopy parameters when disabled Date: Mon, 21 Nov 2022 18:11:51 +0100 Message-Id: <20221121171202.22080-2-vbabka@suse.cz> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221121171202.22080-1-vbabka@suse.cz> References: <20221121171202.22080-1-vbabka@suse.cz> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org With CONFIG_HARDENED_USERCOPY not enabled, there are no __check_heap_object() checks happening that would use the kmem_cache useroffset and usersize fields. Yet the fields are still initialized, preventing merging of otherwise compatible caches. Thus ignore the values passed to cache creation and leave them zero when CONFIG_HARDENED_USERCOPY is disabled. In a quick virtme boot test, this has reduced the number of caches in /proc/slabinfo from 131 to 111. Cc: Kees Cook Signed-off-by: Vlastimil Babka --- mm/slab_common.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/mm/slab_common.c b/mm/slab_common.c index 0042fb2730d1..a8cb5de255fc 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -317,7 +317,8 @@ kmem_cache_create_usercopy(const char *name, flags &= CACHE_CREATE_MASK; /* Fail closed on bad usersize of useroffset values. */ - if (WARN_ON(!usersize && useroffset) || + if (!IS_ENABLED(CONFIG_HARDENED_USERCOPY) || + WARN_ON(!usersize && useroffset) || WARN_ON(size < usersize || size - usersize < useroffset)) usersize = useroffset = 0; @@ -640,6 +641,9 @@ void __init create_boot_cache(struct kmem_cache *s, const char *name, align = max(align, size); s->align = calculate_alignment(flags, align, size); + if (!IS_ENABLED(CONFIG_HARDENED_USERCOPY)) + useroffset = usersize = 0; + s->useroffset = useroffset; s->usersize = usersize; -- 2.38.1