Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1823223rwb; Fri, 11 Nov 2022 00:27:23 -0800 (PST) X-Google-Smtp-Source: AA0mqf7DF+Ae7YP/QbKcLSgnmx5oNLpsc1hZxNfcTfYXlB9PyhLTVlypv6sCCQG9D9lhmQVVbQ7g X-Received: by 2002:a17:902:7588:b0:186:e01d:8f2f with SMTP id j8-20020a170902758800b00186e01d8f2fmr1313051pll.40.1668155243628; Fri, 11 Nov 2022 00:27:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668155243; cv=none; d=google.com; s=arc-20160816; b=Nr5KetKAJK3DhJl3IzjxMay4UbWPwNyVSD2yjY+ciyiEvJceagPHdPCzZORkdPxIAX IU4GdlfB6VqyVbeTK/sM7YvVFX6jNSVneMA2P7xQgWXx+EGw6YvTsKL0OJfZ3FfdFXxk n/to6TFVOIO/yfzocVfhK4pu652+tZtFNqpr/P74rC8WLoZwNvN+aoN5deOuH11N4vN9 Qw2jMiQmDe0RsTikA9drZF4TKTyhIxEuLjjcniRM/enDFXqhRBeeNSEVWUJUEHW4JR8y W/u5sqBhH5VZ0GO9yf0pgkBBA+AAB/X0EoVI+ByWJ1+Cd2u41NcslBgFEYzSgYCjwyY0 NAbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature:dkim-signature; bh=rKsv2kApUh0znibD5DPAFWgQv7vvm/xaww+iNqXUWGU=; b=o80/pLGIJlCpa7Nwnu/lKad589AG+MuWuEJb0cnMf8s6i1EqNwywym6N9zPL90Abnx uUZswZVkC6qFiF6ayQ7SLijRUISl5SPv8HWIhCg+m27tDhU7QhdLd3N9gYQUj4Yk9600 Vi5Y2tn1TFsTNC/QeXtw4mYDSOjvkc4PXoDuU46TtZlTV706mI1kxS879Wse8SS4WGrc nTji0lNWtDgrodivEnEpNAPlFo40ycfBGp8GUiJ7ihwuX20124vBD+CJJSckx3cRpTq2 wmmKca2oX+hbJ10Zo1c1kamQfSU1Jw5FnUEtUVjGCdWhthIVkl7ZLJrLdv/nllN9HII3 idgg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=G2Mdh1hQ; dkim=neutral (no key) header.i=@suse.cz header.b=WIuaxZ8t; 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 t186-20020a6381c3000000b0043a20d3388esi1854244pgd.321.2022.11.11.00.27.11; Fri, 11 Nov 2022 00:27:23 -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=G2Mdh1hQ; dkim=neutral (no key) header.i=@suse.cz header.b=WIuaxZ8t; 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 S231895AbiKKIMa (ORCPT + 93 others); Fri, 11 Nov 2022 03:12:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42890 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232577AbiKKIMX (ORCPT ); Fri, 11 Nov 2022 03:12:23 -0500 Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 349F5729B9 for ; Fri, 11 Nov 2022 00:12:22 -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-out1.suse.de (Postfix) with ESMTPS id DD62E22987; Fri, 11 Nov 2022 08:12:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1668154340; 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=rKsv2kApUh0znibD5DPAFWgQv7vvm/xaww+iNqXUWGU=; b=G2Mdh1hQw2eLj8LzwM7qY9czs4X4GPfI3e8T59x+EjCQtkufmuzIEpD2K0pfTk6l+/BiP+ JNQvxiCsrPSJZXZkYaJRv0xTlUbDhiwBJzmPKgy3ML2CkASzSgDEGaK0qGLp73yOh1AL91 M2CxWRdpJ2kVeoSBscMY3KmTTDzpPJs= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1668154340; 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=rKsv2kApUh0znibD5DPAFWgQv7vvm/xaww+iNqXUWGU=; b=WIuaxZ8tofIql51ub9eoeLcUB0YxIYEBCwxq8YaKITq46feTAdn/ldCWe7mWsAErOOVJqm Wzu6ARswVIWwfgDw== 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 3698E13357; Fri, 11 Nov 2022 08:12:20 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id LnadDOQDbmNcNwAAMHmgww (envelope-from ); Fri, 11 Nov 2022 08:12:20 +0000 Message-ID: <59a0b85a-9001-8c7d-8b98-fd8a87e636fa@suse.cz> Date: Fri, 11 Nov 2022 09:12:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH v7 3/3] mm/slub: extend redzone check to extra allocated kmalloc space than requested Content-Language: en-US To: Feng Tang Cc: Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Dmitry Vyukov , Andrey Konovalov , Kees Cook , Dave Hansen , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com References: <20221021032405.1825078-1-feng.tang@intel.com> <20221021032405.1825078-4-feng.tang@intel.com> From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_SOFTFAIL 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 On 11/11/22 07:46, Feng Tang wrote: > On Thu, Nov 10, 2022 at 04:48:35PM +0100, Vlastimil Babka wrote: >> On 10/21/22 05:24, Feng Tang wrote: >> > kmalloc will round up the request size to a fixed size (mostly power >> > of 2), so there could be a extra space than what is requested, whose >> > size is the actual buffer size minus original request size. >> > >> > To better detect out of bound access or abuse of this space, add >> > redzone sanity check for it. >> > >> > In current kernel, some kmalloc user already knows the existence of >> > the space and utilizes it after calling 'ksize()' to know the real >> > size of the allocated buffer. So we skip the sanity check for objects >> > which have been called with ksize(), as treating them as legitimate >> > users. >> >> Hm so once Kees's effort is finished and all ksize() users behave correctly, >> we can drop all that skip_orig_size_check() code, right? > > Yes, will update the commit log. > >> > In some cases, the free pointer could be saved inside the latter >> > part of object data area, which may overlap the redzone part(for >> > small sizes of kmalloc objects). As suggested by Hyeonggon Yoo, >> > force the free pointer to be in meta data area when kmalloc redzone >> > debug is enabled, to make all kmalloc objects covered by redzone >> > check. >> > >> > Suggested-by: Vlastimil Babka >> > Signed-off-by: Feng Tang >> > Acked-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> >> >> Looks fine, but a suggestion below: >> > [...] >> > @@ -966,13 +982,27 @@ static __printf(3, 4) void slab_err(struct kmem_cache *s, struct slab *slab, >> > static void init_object(struct kmem_cache *s, void *object, u8 val) >> > { >> > u8 *p = kasan_reset_tag(object); >> > + unsigned int orig_size = s->object_size; >> > >> > - if (s->flags & SLAB_RED_ZONE) >> > + if (s->flags & SLAB_RED_ZONE) { >> > memset(p - s->red_left_pad, val, s->red_left_pad); >> > >> > + if (slub_debug_orig_size(s) && val == SLUB_RED_ACTIVE) { >> > + orig_size = get_orig_size(s, object); >> > + >> > + /* >> > + * Redzone the extra allocated space by kmalloc >> > + * than requested. >> > + */ >> > + if (orig_size < s->object_size) >> > + memset(p + orig_size, val, >> > + s->object_size - orig_size); >> >> Wondering if we can remove this if - memset and instead below: >> >> > + } >> > + } >> > + >> > if (s->flags & __OBJECT_POISON) { >> > - memset(p, POISON_FREE, s->object_size - 1); >> > - p[s->object_size - 1] = POISON_END; >> > + memset(p, POISON_FREE, orig_size - 1); >> > + p[orig_size - 1] = POISON_END; >> > } >> > >> > if (s->flags & SLAB_RED_ZONE) >> >> This continues by: >> memset(p + s->object_size, val, s->inuse - s->object_size); >> Instead we could do this, no? >> memset(p + orig_size, val, s->inuse - orig_size); > > Yep, the code is much simpler and cleaner! thanks > > I also change the name from 'orig_size' to 'poison_size', as below: > > Thanks, > Feng Thanks! Now merged all to slab/for-6.2/kmalloc_redzone and for-next