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 227EAC64EC7 for ; Wed, 15 Feb 2023 09:41:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 91B266B0072; Wed, 15 Feb 2023 04:41:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A3EF6B0073; Wed, 15 Feb 2023 04:41:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 743E16B0074; Wed, 15 Feb 2023 04:41:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 61FC16B0072 for ; Wed, 15 Feb 2023 04:41:37 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3205F1C6BFE for ; Wed, 15 Feb 2023 09:41:37 +0000 (UTC) X-FDA: 80469033834.08.5AA58E3 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf10.hostedemail.com (Postfix) with ESMTP id 2DFADC0007 for ; Wed, 15 Feb 2023 09:41:33 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=1qnGuDE8; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=b3iht4bq; dmarc=none; spf=pass (imf10.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 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=1676454094; 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=rj4QsSGZ5Ti6ptzVHUWoMKmIN/uODtiAOITM+xUG0ig=; b=WsqtyRsjrk/ZD4wjIRtY0ZGBFBwr12BM9M2w6SLQXgHPZdBJDyZAKAtrMdk8EBmJjRMJes C3kAmFirIZ8E8ZEWJnRMlzvKmh8b9R5I3NUQn+Pk4rq4zJ9D6SEl7CnqEPFLZiixFtXfP4 KNJoMWq8mRsALLtkvQHzn0hJel4H5fQ= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=1qnGuDE8; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=b3iht4bq; dmarc=none; spf=pass (imf10.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676454094; a=rsa-sha256; cv=none; b=YU4t+aTCrnVhUup86Tl9i7CVJQo4RpfluQsp1AQVDN2TSb2wypTT7FPyhf5MB8RjU3BmFY 8amz1OTgdI2WGyp5xxb5xzD74JDQU2gMt5xWAHKqxGmuCotk+5TZ/wWOsubLwiCNlzZ+d2 A17zrm9UaDYvJRfYqXRCeDfLyM/iCCk= 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-out1.suse.de (Postfix) with ESMTPS id 800CE22593; Wed, 15 Feb 2023 09:41:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1676454092; 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; bh=rj4QsSGZ5Ti6ptzVHUWoMKmIN/uODtiAOITM+xUG0ig=; b=1qnGuDE8Kd6iPK+w2Uaqi0kNRDl0aaIp4xwfABv4MBhpIcJGeUoCdLBwhweTukDmiut4/b YmKcUt7CtMLj6AMFIoPBznYEWOvMHhiWW2HvKj/vhEFFlmsM4E6NsBHdetjq+V7nCXLZvy RHCLrBM0e05V6GF8MWJqSzudNRc0dEE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1676454092; 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; bh=rj4QsSGZ5Ti6ptzVHUWoMKmIN/uODtiAOITM+xUG0ig=; b=b3iht4bq2jf1bjHFLUvFLxPGHssskD+epp7k3/5Fc1W8C1DNKeLaACA1zFJ5qXVn2qZS2h 2hfN33n7ufd8R2CQ== 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 5537313483; Wed, 15 Feb 2023 09:41:32 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id wcUMFMyo7GPIfAAAMHmgww (envelope-from ); Wed, 15 Feb 2023 09:41:32 +0000 Message-ID: <884f051f-d1ed-756f-aef3-6ed3005de090@suse.cz> Date: Wed, 15 Feb 2023 10:41:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH] mm/slab: always use cache from obj To: lijiazi Cc: Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, "Jiazi.Li" , linux-mm@kvack.org, Kees Cook , Kernel Hardening References: <20230214101949.7461-1-jiazi.li@transsion.com> <20230215053748.GA11780@Jiazi.Li> Content-Language: en-US From: Vlastimil Babka In-Reply-To: <20230215053748.GA11780@Jiazi.Li> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 2DFADC0007 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: 93ar6k7ijky4qseby4ku5zwo8157u4ta X-HE-Tag: 1676454093-641636 X-HE-Meta: U2FsdGVkX1/bSc7pI/ts/oXpfPthFvXniOsB2z7URwT4zy75eQNLXANR8uGqmiOhvqRW2/k1g2kSaIaOYDYyU93yucH7ox3RVOgD5/gijSDMAnm0ULdU7blw8harEZImavuOl+5s/RtKrp4JdYoZCZLgi6iYQN7wdEwxK6H/MLD71OzuiPm2sLgpnR8yjYZ8SnVYkToLfsXjqmz2P+YsaQYuu3tICj39GbMlCnCBXG8h4NMbRM5fJTq+A92Q6Xb+AeA1Mea5Lw/189HMdMq1CjOBt+uNybJ0sR+d1QL8WVNYB2XsB88LLus+Ok2oTIGsLr3ivk5jnH44TyxkoR7Fa2iLGZ9EKpOxL/+Qzb7CkNceeSvWP+TfPwxx6Wpb511uzZWIUpSDsMHixZX6B6zszl0cGvSjIPJob6JZKbLkngz2Qry0Znp9+Odtoe3+BGcLQrZGq1yi28w9DlTR+ZA0m4Yflasko2qemFf9sagigVuVGiGwL7ieR+Hk0nAvCetNHcNpSFVZwaS99R1VZuyq8XGAV47jFQ7McEjJrQhckaolCKX2qOtkYV64rJW1YgDJbtvhjyCOFkF3UcA3ZZFgm02DC642MgFdyOzdQEUWBUc0dqApDcjyuzhRzf/1c5iN/N/CkuoyUbqjzxZkpq9IfSNsBAxAkPA6OCG4JRm98niEEgULNdDprh3x0GXjPVzsX4zQOBDw4pXSCpQe+ZUFhZluu1RkoMhRtlnUKUpHBGSyFaCLcOi2ZiHcJHG5vHXaMoL4HRJZW6gN7IAob7kIM6DG03XS0mL3g3oSK0RYe1lIdsFdCmSAvsvq7OeStzr79LXFUNvod7nzMbW9SCTE3jVLcwHEf4f4TQjb5JUHoTdaEE0uhCdFdXSmW8mvJhbkpJpaxSe+XTEcCyXVqN8HMCGfMP1hslwqIGaSMHfq3zu7yqjwoeFXfa3GEJY2xM0XC9W4at2Ed0j1BSmNGFL YM1jXYSF 3soJCLmADKvSJTU3CqzxbP2NImO3chywJqunWe/HnafUhjGOlRWevb7yNUfOhMwzfUW4zHliqMWsmd4J/vWGxQtZ1WWqvkQyxirBgnCpNm8oUol4czb1fOHxk3wPDVfRq+oriZWQRakhQS/f9BlWqFKDChtFi+k3c1QFg7oopY7X3lM7kEc/snqFn6i4kNxvyIzaSHZVb6fKfsvX/cQ1Nrg2a2wRkaR1oyFqb8q5CYLa2UgI3e9Hn8ZUofO62PpvaU0HkAMcFe5NoEMzbA/+r4UuFGy09+d/thQJlhxWL+45JpKZVXWf7p9yGq8ypqfolECi8l43QyavtxiwVH8pi1QeM0w== 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 2/15/23 06:49, lijiazi wrote: > On Tue, Feb 14, 2023 at 11:33:21AM +0100, Vlastimil Babka wrote: >> On 2/14/23 11:19, Jiazi.Li wrote: >> > If free obj to a wrong cache, in addition random, different offset >> > and object_size will also cause problems: >> > 1. The offset of a cache with a ctor is not zero, free an object from >> > this cache to cache with offset zero, will write next freepointer to >> > wrong location, resulting in confusion of freelist. >> >> Kernels hardened against freelist corruption will enable >> CONFIG_SLAB_FREELIST_HARDENED, so that's already covered, no? >> > Yes, HARDENED already covered. >> > 2. If wrong cache want init on free, and cache->object_size is large >> > than obj size, which may lead to overwrite issue. >> >> In general, being defensive against usage errors is part of either hardening >> or debugging, which is what the existing code takes into account. >> > My consideration is for the wrong cache problem on version without > HARDENED or debugging, it is likely to cause kernel panic, and such > problem is difficult to analyze on non-debug version. > When reproducing this problem on debug version, it will not cause kernel > panic, but only print the WARN log, then use correct cache to free obj. > Because we want to reproduce kernel panic problem, so may ignore WARN > log and think that can not reproduce problem on debug version. If you need the panic in order to e.g. capture a crash dump, you could enable slab debugging and boot with panic_on_warn to make the WARN result in panic. > Thanks for your reply, I will enable CONFIG_SLAB_FREELIST_HARDENED on > non-debug version later. >> > Compared with adding a lot of if-else, it may be better to use obj's >> > cache directly. >> > >> > Signed-off-by: Jiazi.Li >> > --- >> > mm/slab.h | 4 ---- >> > 1 file changed, 4 deletions(-) >> > >> > diff --git a/mm/slab.h b/mm/slab.h >> > index 63fb4c00d529..ed39b2e4f27b 100644 >> > --- a/mm/slab.h >> > +++ b/mm/slab.h >> > @@ -670,10 +670,6 @@ static inline struct kmem_cache *cache_from_obj(struct kmem_cache *s, void *x) >> > { >> > struct kmem_cache *cachep; >> > >> > - if (!IS_ENABLED(CONFIG_SLAB_FREELIST_HARDENED) && >> > - !kmem_cache_debug_flags(s, SLAB_CONSISTENCY_CHECKS)) >> > - return s; >> > - >> > cachep = virt_to_cache(x); >> > if (WARN(cachep && cachep != s, >> > "%s: Wrong slab cache. %s but object is from %s\n", >>