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 323CCC4167B for ; Mon, 27 Nov 2023 11:44:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B83236B02C7; Mon, 27 Nov 2023 06:44:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B33CE6B02CD; Mon, 27 Nov 2023 06:44:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9FA536B02DF; Mon, 27 Nov 2023 06:44:48 -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 8DE376B02C7 for ; Mon, 27 Nov 2023 06:44:48 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 5B71A1601F9 for ; Mon, 27 Nov 2023 11:44:48 +0000 (UTC) X-FDA: 81503552256.18.80CEC35 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf11.hostedemail.com (Postfix) with ESMTP id 1DE3240004 for ; Mon, 27 Nov 2023 11:44:44 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf11.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=1701085485; 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; bh=u98qmG+0N4uJ94Mrt8Yf0kqM6NEsRwfSj+qTsu6GUro=; b=8aZ3ZlyfY2/a7oSWWid1lbpHwdsHn4j6/SGTMpjzzAJaIWD6mEGJIyMb62/BQCAkPP+sHR fQzqaWaoqVLD1BC7RlXZOFVqQp3iA1R4wM8VFsOISGo/ojlRj8g5I3ZiFaob5/mrqxQvrf O+jTfHIXXUYdWcXSTmehWJOISk+SDJA= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf11.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=1701085485; a=rsa-sha256; cv=none; b=KgtETRkuVx7WXJjY5OOgCQB7cutBYgxu1q/msfSnRqJMuFMi3CQMNxjkW0ESpvYSuXAhAo n3V1uw47ljT6lflV+6ErWrENdNoyfqqTY/k1P9LrzkxIRoaDC2Fnhnjesl4AfjM3x2tFyJ V76jOOCnCvZ2pDZxCvgts/wImsZTzzk= 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 779451FD85; Mon, 27 Nov 2023 11:44:41 +0000 (UTC) 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 552381379A; Mon, 27 Nov 2023 11:44:41 +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 aQluFCmBZGX2bwAAD6G6ig (envelope-from ); Mon, 27 Nov 2023 11:44:41 +0000 Message-ID: <1f2f5a9f-61aa-094d-f9ed-be97e3671fb1@suse.cz> Date: Mon, 27 Nov 2023 12:44:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH mm] slub, kasan: improve interaction of KASAN and slub_debug poisoning Content-Language: en-US To: andrey.konovalov@linux.dev, Andrew Morton Cc: Andrey Konovalov , Marco Elver , Alexander Potapenko , Dmitry Vyukov , kasan-dev@googlegroups.com, Evgenii Stepanov , Oscar Salvador , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Feng Tang , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrey Konovalov References: <20231122231202.121277-1-andrey.konovalov@linux.dev> From: Vlastimil Babka In-Reply-To: <20231122231202.121277-1-andrey.konovalov@linux.dev> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spamd-Bar: ++++++++++++++ X-Rspamd-Queue-Id: 1DE3240004 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 1aaytcnqpjrs1crgy4owci9qo8joworg X-HE-Tag: 1701085484-707804 X-HE-Meta: U2FsdGVkX192JsbCfs5x+eZTa53RImDCKtt/vMyojblMKMxH3+FwMkVPNGADiIIjd/twqmempZmwBsWJBCKwe2fOtHo7bbDD4ZcSoffSCaRSTAf9m1a5eUXFS45IFhhxvCwbHFafOhDx1QHgWckPKSFaqf4s55NpnKDFFL1wX1HzCKiTXx9doGefTSEDliiqxCplSZ06lrhaWf+qpYKOCiKBwxSMQtDJ70rWBu0AQqP01vtf5GgTAjS7tZ0ztzz7OFU1/6nA+JwGxVp4TrvQLZnhKhGp0wqfTLtbd//P+aP1HY2O3szndCAwpoHug26mBeTFBWr3wcQEciC9Cv5C/L/L5aQSev0M/mvtJsywsmhpZYmU01SdPyLdTUYZNHbrkqKApy7UEr3kBO4VcyitH94h+9HGXkf3QEnH0dOLZnP3rHui18/5ARquRoJr7dGZzMIYZqDsPGToQWOe46m6bDb/QUNm3DOBIDT/SjacT9NrqBbCZW3dycwCi2kQlAzTMlB5fiYmbGXip7pz8TZFWWAtIOVLTR72uvxkvBJMXtgix5hI+9BVxDmT1Pq2OmLG0KwaXtM1ic7yyvFQTcHW5CBsvRsEeoft3vXfFzRhiA0+Mt8s0Q6jsAItDiH+2vtgPTGj3I4cpkz/Y3T7czF+tqmKWsX8csGgeNH7kBao/BJ5M6u7I5tJukiP2aSVh/ZvsTbERL/mn8WWH1q3AJ2jybMUj8/3hUNzkZz6g0sCjGUW/2Jmvq7daNc8mp3k0jx3s2SJ3AkGg15jr9WOkLwuNsssaZV6ZPRlraUnMWXOngKC2NgGyD+NzqUbM0yDr3ovpXlFvqbpUXrHxH/Hzeo/d3pLq+MOGF3S+aJqRJJEssX/chD/ApG0feIJNwgl6r81kxsgEiqfGXjTxaUCF9YdpuhKrvxaEXGRTcP6KJdrCkdOc1ANgjBAXDC/990Ye3/c2hRuaYIa1DSrkEJ6pFk 6cx24LcH QrxHL4J5TQ1h2npbOYbSr7WmGSDJHea2cHZIpo0QzoWTL5sCu5E/MsMCx3ETPUveuVN6CQfU68LUh2hNXZ1KxxNvxkJyvi4o7Eo4lv+sZAanwONeSZh0RRQSmnm97I9RiWrSkRFyFI1riIq4xXhv2gHi3U72+fRIOSQD8uq2cBg5Bv837qZnNy91HzL+XL/vCOf0NfteIkl/sPbdVqGsHMCGw9VpoQqCBVYgZxEJSCEWBjkK2+8sNNVrnQVRK7TiEkPH9 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 11/23/23 00:12, andrey.konovalov@linux.dev wrote: > From: Andrey Konovalov > > When both KASAN and slub_debug are enabled, when a free object is being > prepared in setup_object, slub_debug poisons the object data before KASAN > initializes its per-object metadata. > > Right now, in setup_object, KASAN only initializes the alloc metadata, > which is always stored outside of the object. slub_debug is aware of > this and it skips poisoning and checking that memory area. > > However, with the following patch in this series, KASAN also starts > initializing its free medata in setup_object. As this metadata might be > stored within the object, this initialization might overwrite the > slub_debug poisoning. This leads to slub_debug reports. > > Thus, skip checking slub_debug poisoning of the object data area that > overlaps with the in-object KASAN free metadata. > > Also make slub_debug poisoning of tail kmalloc redzones more precise when > KASAN is enabled: slub_debug can still poison and check the tail kmalloc > allocation area that comes after the KASAN free metadata. > > Signed-off-by: Andrey Konovalov Acked-by: Vlastimil Babka Thanks. > --- > > Andrew, please put this patch right before "kasan: use stack_depot_put > for Generic mode". > --- > mm/slub.c | 41 ++++++++++++++++++++++++++--------------- > 1 file changed, 26 insertions(+), 15 deletions(-) > > diff --git a/mm/slub.c b/mm/slub.c > index 63d281dfacdb..782bd8a6bd34 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -870,20 +870,20 @@ static inline void set_orig_size(struct kmem_cache *s, > void *object, unsigned int orig_size) > { > void *p = kasan_reset_tag(object); > + unsigned int kasan_meta_size; > > if (!slub_debug_orig_size(s)) > return; > > -#ifdef CONFIG_KASAN_GENERIC > /* > - * KASAN could save its free meta data in object's data area at > - * offset 0, if the size is larger than 'orig_size', it will > - * overlap the data redzone in [orig_size+1, object_size], and > - * the check should be skipped. > + * KASAN can save its free meta data inside of the object at offset 0. > + * If this meta data size is larger than 'orig_size', it will overlap > + * the data redzone in [orig_size+1, object_size]. Thus, we adjust > + * 'orig_size' to be as at least as big as KASAN's meta data. > */ > - if (kasan_metadata_size(s, true) > orig_size) > - orig_size = s->object_size; > -#endif > + kasan_meta_size = kasan_metadata_size(s, true); > + if (kasan_meta_size > orig_size) > + orig_size = kasan_meta_size; > > p += get_info_end(s); > p += sizeof(struct track) * 2; > @@ -1192,7 +1192,7 @@ static int check_object(struct kmem_cache *s, struct slab *slab, > { > u8 *p = object; > u8 *endobject = object + s->object_size; > - unsigned int orig_size; > + unsigned int orig_size, kasan_meta_size; > > if (s->flags & SLAB_RED_ZONE) { > if (!check_bytes_and_report(s, slab, object, "Left Redzone", > @@ -1222,12 +1222,23 @@ static int check_object(struct kmem_cache *s, struct slab *slab, > } > > if (s->flags & SLAB_POISON) { > - if (val != SLUB_RED_ACTIVE && (s->flags & __OBJECT_POISON) && > - (!check_bytes_and_report(s, slab, p, "Poison", p, > - POISON_FREE, s->object_size - 1) || > - !check_bytes_and_report(s, slab, p, "End Poison", > - p + s->object_size - 1, POISON_END, 1))) > - return 0; > + if (val != SLUB_RED_ACTIVE && (s->flags & __OBJECT_POISON)) { > + /* > + * KASAN can save its free meta data inside of the > + * object at offset 0. Thus, skip checking the part of > + * the redzone that overlaps with the meta data. > + */ > + kasan_meta_size = kasan_metadata_size(s, true); > + if (kasan_meta_size < s->object_size - 1 && > + !check_bytes_and_report(s, slab, p, "Poison", > + p + kasan_meta_size, POISON_FREE, > + s->object_size - kasan_meta_size - 1)) > + return 0; > + if (kasan_meta_size < s->object_size && > + !check_bytes_and_report(s, slab, p, "End Poison", > + p + s->object_size - 1, POISON_END, 1)) > + return 0; > + } > /* > * check_pad_bytes cleans up on its own. > */