Received: by 2002:a05:7412:419a:b0:f3:1519:9f41 with SMTP id i26csp449934rdh; Thu, 23 Nov 2023 08:12:48 -0800 (PST) X-Google-Smtp-Source: AGHT+IFRyiFFvyUpSz3pUEZr+DN4dejT1Mx7oUEDsWCZTOILMfwLqk8XPyiMtzX443OJqVYkld7i X-Received: by 2002:a05:6808:1994:b0:3b2:ec66:d868 with SMTP id bj20-20020a056808199400b003b2ec66d868mr8022051oib.41.1700755968101; Thu, 23 Nov 2023 08:12:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700755968; cv=none; d=google.com; s=arc-20160816; b=IH5qlEe/VUdxjqcpekdE1eL4xBLVpvqHCnM4BoD1YwRu2WtTuwAtkERML7vgslKrZo vsTbH8DQKVr3f+MXDL/7+hdWpP1L0JCHYTvC36lLxzwTvGpfGwjc5iZZ0uFEmdSCoGGR HX+pBijrfhibY4jfSAw/J+ZHme1iDYLL1jUydf43bOQxqIVsWJTVuoRTVl/c0KwQbJWy gToPB/RhQd2NgceeeKg9f+7iMRwX13nJm+aoQAUIOJJYBvcLNZXKVm6diijnArszz1TN +csjCEoh+Y5lpwWh6XZf2oEpH7b3DW55NI/hb/xJaIi63SdOwOqHZCkHA6i3WkQrT3DQ Qp0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=vGyQEtxcPZXDfK5MLunRkVEU0dG6NY5S9HKgUKbsr1Y=; fh=zSh3cOr2bWV32wuLsS2CGXx0HFRiFXLMfTT1kX0bQEI=; b=TjkoFLRtpTvJBQsh04UGMYnxNUwQfT+99UjK18W5fGhF4UdbNRTzU/2BWOkJu7NoJn 8USSAuY8bAQB8X5lagHofw3l7/MGD+AnlgaGufm10AmjK5pn7PSNAsEI+wc5x9xv1vOn 0zqMS0JbKC/BLrE4CY89vlx4G9ITdlFnAuDsTNb1D5Y5BH5IgKwB/33DTT88XbiymORV M2+8MNLgW26Vya5I3Tk4gsBuQenOx3F4F3Glu+UjUawcPa/UR52GBx0+HVcBVUXXnnDR qnvAk+9r9vMFyJWVmUlPqcqTHrNGHCNIjposkdt5Sg81b2ekwziykzvdYr+G3Q1pOSAs xGjw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=DKoCw+MH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from morse.vger.email (morse.vger.email. [23.128.96.31]) by mx.google.com with ESMTPS id 24-20020a631658000000b005b9a4673310si1511942pgw.326.2023.11.23.08.12.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Nov 2023 08:12:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=DKoCw+MH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id 20F89808A96C; Thu, 23 Nov 2023 08:12:32 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229811AbjKWQMQ (ORCPT + 99 others); Thu, 23 Nov 2023 11:12:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229687AbjKWQMP (ORCPT ); Thu, 23 Nov 2023 11:12:15 -0500 Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD999D65 for ; Thu, 23 Nov 2023 08:12:20 -0800 (PST) Received: by mail-qv1-xf2f.google.com with SMTP id 6a1803df08f44-67a0dd02364so1778846d6.3 for ; Thu, 23 Nov 2023 08:12:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700755940; x=1701360740; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=vGyQEtxcPZXDfK5MLunRkVEU0dG6NY5S9HKgUKbsr1Y=; b=DKoCw+MHJS0U+4NYeqOj347Wc1dH5pN2oYybdIXkQr0udFII+4/v9lGpKV9deTcGM2 tPBfeoqEcEsplKO8Ux3wWL5SxaWswHJnipc22D5w6KK3JV5siH4EPZ07E5DewFs9hZMS SnXho2oeUnJSXcPauCclQZz7TtVUDWTMFYwbmVE+tusiNRcl464lwXGUs4bxhzUee7Z+ 4YSkyji1UtZl4HMlfYu3O+DSD6Xw9MB8OTWSRurY2EmD9uYO+JDrbnPScEg+6tNBGYqC CKDCG7c07yvUIC89mjhxaalAYBCr0iz4hq6tpfIpIykND4o1YWcCJsMUm7M2ks+FeS1/ 9/PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700755940; x=1701360740; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vGyQEtxcPZXDfK5MLunRkVEU0dG6NY5S9HKgUKbsr1Y=; b=RVGnV5n5mhVFoqqroJomEtXzkBXZxowxItq8X4RO/EDmlgslD6LssY8oszJw2PNUKy C/ItZj+0BYTApU1LX0fsLiuGR+097kj4g8scr7pxcZXcJT1dIh2MmMlONUUADOtHYP3p 3k0oE3KJdBzwZyPqJx671n/uW0Y7kDRwdeswDqmk7z2RvZDuI2KmxGptafIg7HvjhleS XbFQKAkbIdNcnVmjOzW2/mfFnFyHGnUVE0z++OHBtqhLry1mRAb4ebMbD7tyuQjUlSER aplCSnEgHIEaBuT6GL8xX1gnl8lByrRJ0AkIQX3CCUDFAK6ULaFyd+nvoW+1Fdk3qZj7 O9iw== X-Gm-Message-State: AOJu0Yz+qdZmmf6wF3ijx4BDgCzFdjr+LL77pdsbkOqzazaLFWmsCtbt xE68zKVqCGrAM2CvyY2Sdd8b7R5p0WJSQsYPlNBfDXJJoDfyww== X-Received: by 2002:a05:6214:21e2:b0:672:aecf:581a with SMTP id p2-20020a05621421e200b00672aecf581amr6478936qvj.47.1700755939932; Thu, 23 Nov 2023 08:12:19 -0800 (PST) MIME-Version: 1.0 References: <20231122231202.121277-1-andrey.konovalov@linux.dev> In-Reply-To: From: Andrey Konovalov Date: Thu, 23 Nov 2023 17:12:08 +0100 Message-ID: Subject: Re: [PATCH mm] slub, kasan: improve interaction of KASAN and slub_debug poisoning To: Feng Tang Cc: "andrey.konovalov@linux.dev" , Andrew Morton , Marco Elver , Alexander Potapenko , Dmitry Vyukov , Vlastimil Babka , "kasan-dev@googlegroups.com" , Evgenii Stepanov , Oscar Salvador , Hyeonggon Yoo <42.hyeyoo@gmail.com>, "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Andrey Konovalov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Thu, 23 Nov 2023 08:12:32 -0800 (PST) On Thu, Nov 23, 2023 at 7:35=E2=80=AFAM Feng Tang wro= te: > Hi Feng, > > --- a/mm/slub.c > > +++ b/mm/slub.c > > @@ -870,20 +870,20 @@ static inline void set_orig_size(struct kmem_cach= e *s, > > void *object, unsigned int orig_size) > > { > > void *p =3D 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 offs= et 0. > > + * If this meta data size is larger than 'orig_size', it will ove= rlap > > + * the data redzone in [orig_size+1, object_size]. Thus, we adjus= t > > + * 'orig_size' to be as at least as big as KASAN's meta data. > > */ > > - if (kasan_metadata_size(s, true) > orig_size) > > - orig_size =3D s->object_size; > > -#endif > > + kasan_meta_size =3D kasan_metadata_size(s, true); > > + if (kasan_meta_size > orig_size) > > + orig_size =3D kasan_meta_size; > > 'orig_size' is to save the orignal request size for kmalloc object, > and its main purpose is to detect the memory wastage of kmalloc > objects, see commit 6edf2576a6cc "mm/slub: enable debugging memory > wasting of kmalloc" > > Setting "orig_size =3D s->object_size" was to skip the wastage check > and the redzone sanity check for this 'wasted space'. Yes, I get that. The point of my change was to allow slub_debug detecting overwrites in the [kasan_meta_size, object_size) range when KASAN stores its free meta in the [0, kasan_meta_size) range. If orig_size is set to object_size, writes to that area will not be detected. I also thought that using kasan_meta_size instead of object_size for orig_size might give the reader better understanding of the memory layout. > So it's better not to set 'kasan_meta_size' to orig_size. I don't have a strong preference here: slub_debug and KASAN are not really meant to be used together anyway. So if you prefer, I can revert this change and keep using object_size as before. > And from the below code, IIUC, the orig_size is not used in fixing > the boot problem found by Hyeonggon? No, this is a just a partially-related clean up. It just seemed natural to include it into the fix, as it also touches the code around a kasan_metadata_size call. Thanks!