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 X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3149AC433DB for ; Thu, 18 Mar 2021 05:49:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A87EB64ED2 for ; Thu, 18 Mar 2021 05:49:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A87EB64ED2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E275C6B0070; Thu, 18 Mar 2021 01:49:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DD4F46B0071; Thu, 18 Mar 2021 01:49:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C4F4D6B0072; Thu, 18 Mar 2021 01:49:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0194.hostedemail.com [216.40.44.194]) by kanga.kvack.org (Postfix) with ESMTP id 9FFEA6B0070 for ; Thu, 18 Mar 2021 01:49:01 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 58C99181AF5EA for ; Thu, 18 Mar 2021 05:49:01 +0000 (UTC) X-FDA: 77931916482.14.FD61EA1 Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) by imf27.hostedemail.com (Postfix) with ESMTP id E8F988019140 for ; Thu, 18 Mar 2021 05:49:00 +0000 (UTC) Received: by mail-pj1-f49.google.com with SMTP id lr1-20020a17090b4b81b02900ea0a3f38c1so6361434pjb.0 for ; Wed, 17 Mar 2021 22:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=/IGZVuweRu6CPPw463C/ZxJu8oJGSzsf9afcHvnBJbo=; b=kkUCdYFXfa12B6BvXLlo0LOabXx2k0J0Cd0fL/lFLZnQqDr0eNdHOsnGkxs51cKXQo w0sgaKhjaB8PdvZalUU8In0B8HXRkgkThJpbdk0D1MQG11k1dqFL7N6qByfXRsCUtb2b OHRKQofIfe8E4jAGeGs+qWnWWPDBZiQwB1DDg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=/IGZVuweRu6CPPw463C/ZxJu8oJGSzsf9afcHvnBJbo=; b=X2ib2CMQ6JKNY+HivzGzh99ngfC9kZ1xp0lS/FKUC6+ojPpanJfg3gg8KGAx3IV/q5 fqdI0SRx93pGVo0Tpc/PFVQZNWg5YCDevRBjJlKAs7ePQvbk3WMTLVW1dO7WAbYHwLrf 1iY1tSUNS+ejNhxPKYIvA/rdeWBNyzzowxbrDZ2ciTan1Byr3FX0w+BeHwOGuwj3pfML iUAPi0lj9ZdHbZ1VpbJnkKjPfFBTzRPohwQtFpXQH7Hpg0PqELbVVmOI9zNWbBJtQmaj b5DM75lk0AdrIS7YsQRXMT21oSWxvhRQj9LbQtU6eLCWgUp/v7CgftLgXBAZQHWepGLe Uo2w== X-Gm-Message-State: AOAM532Ew8WXHCZoo3EDc575xoQKOf870a7dwNsHfFNcaoSZmwldwYOe 6E34xK7txbFKSasrGFtDUkj+Pg== X-Google-Smtp-Source: ABdhPJxwOia9xLbDgqEHN0e3SfA53aZUhmK7jqQInSgOgFKW9c3RVpCSuua+thzc48IZ5KBPXMsxWg== X-Received: by 2002:a17:90b:4c4d:: with SMTP id np13mr2573124pjb.81.1616046539924; Wed, 17 Mar 2021 22:48:59 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id o9sm969136pfh.47.2021.03.17.22.48.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Mar 2021 22:48:59 -0700 (PDT) Date: Wed, 17 Mar 2021 22:48:58 -0700 From: Kees Cook To: Vlastimil Babka Cc: Georgi Djakov , linux-mm@kvack.org, akpm@linux-foundation.org, cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, corbet@lwn.net, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/slub: Add slub_debug option to panic on memory corruption Message-ID: <202103172244.D5ADB06A96@keescook> References: <20210309134720.29052-1-georgi.djakov@linaro.org> <390d8a2f-ead9-48a9-99eb-65c73bd18422@suse.cz> <6bfebf01-5f52-49bd-380b-04785c474c81@linaro.org> <8fd43de6-71e4-cfe7-8208-32753cf1c363@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <8fd43de6-71e4-cfe7-8208-32753cf1c363@suse.cz> X-Stat-Signature: coouzjbftryfjq1sxb1icw9qqwqaq757 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: E8F988019140 Received-SPF: none (chromium.org>: No applicable sender policy available) receiver=imf27; identity=mailfrom; envelope-from=""; helo=mail-pj1-f49.google.com; client-ip=209.85.216.49 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616046540-410122 Content-Transfer-Encoding: quoted-printable 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 Tue, Mar 09, 2021 at 07:18:32PM +0100, Vlastimil Babka wrote: > On 3/9/21 7:14 PM, Georgi Djakov wrote: > > Hi Vlastimil, > >=20 > > Thanks for the comment! > >=20 > > On 3/9/21 17:09, Vlastimil Babka wrote: > >> On 3/9/21 2:47 PM, Georgi Djakov wrote: > >>> Being able to stop the system immediately when a memory corruption > >>> is detected is crucial to finding the source of it. This is very > >>> useful when the memory can be inspected with kdump or other tools. > >> > >> Is this in some testing scenarios where you would also use e.g. pani= c_on_warn? > >> We could hook to that. If not, we could introduce a new > >> panic_on_memory_corruption that would apply also for debug_pagealloc= and whatnot? > >=20 > > I would prefer that we not tie it with panic_on_warn - there might be= lots of > > new code in multiple subsystems, so hitting some WARNing while testin= g is not > > something unexpected. > >=20 > > Introducing an additional panic_on_memory_corruption would work, but = i noticed > > that we already have slub_debug and thought to re-use that. But indee= d, =D0=B0dding > > an option to panic in for example bad_page() sounds also useful, if t= hat's what > > you suggest. >=20 > Yes, that would be another example. > Also CCing Kees for input, as besides the "kdump ASAP for debugging" ca= se, I can > imagine security hardening folks could be interested in the "somebody m= ight have > just failed to pwn the kernel, better panic than let them continue" ang= le. But > I'm naive wrt security, so it might be a stupid idea :) I've really wanted such things, but Linus has been pretty adamant about not wanting to provide new "panic" paths (or even BUG usage[1]). It seems that panic_on_warn remains the way to get this behavior, with the understanding that WARN should only be produced on expected-to-be-impossible situations[1]. Hitting a WARN while testing should result in either finding and fixing a real bug, or removing the WARN in favor of pr_warn(). :) -Kees [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#bug-an= d-bug-on --=20 Kees Cook