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 DE7BAC433EF for ; Tue, 14 Dec 2021 16:48:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BA1C46B007D; Tue, 14 Dec 2021 11:38:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B50E36B007E; Tue, 14 Dec 2021 11:38:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9A3866B0080; Tue, 14 Dec 2021 11:38:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0034.hostedemail.com [216.40.44.34]) by kanga.kvack.org (Postfix) with ESMTP id 8B8B26B007D for ; Tue, 14 Dec 2021 11:38:21 -0500 (EST) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 5651B180DD590 for ; Tue, 14 Dec 2021 16:38:11 +0000 (UTC) X-FDA: 78916957182.06.8B11644 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf14.hostedemail.com (Postfix) with ESMTP id B0765100010 for ; Tue, 14 Dec 2021 16:38:09 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id AD8A3B81B57; Tue, 14 Dec 2021 16:38:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD433C34601; Tue, 14 Dec 2021 16:38:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1639499888; bh=BiOMJrBttOea17b5tIemSIlhVRlcynMIgkPFw/EBLG0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dpl6WsS8qRHuu0xvc94JKoBsVUJ/sRhEXhvI9ommwHFg5ZE+JUxmCsFoHeriM9935 bH7nngLxCbp4L5npi5XlQ4X4JriozG2I9tkMbv9OCEmmh+Ve0dO81T9g3vmvG4VPUW XLOIv18Lg5j3RfsoRPecTywT66FEUkKAW9gUbTPw= Date: Tue, 14 Dec 2021 17:38:06 +0100 From: Greg Kroah-Hartman To: Alexander Potapenko Cc: Alexander Viro , Andrew Morton , Andrey Konovalov , Andy Lutomirski , Ard Biesheuvel , Arnd Bergmann , Borislav Petkov , Christoph Hellwig , Christoph Lameter , David Rientjes , Dmitry Vyukov , Eric Dumazet , Herbert Xu , Ilya Leoshkevich , Ingo Molnar , Jens Axboe , Joonsoo Kim , Kees Cook , Marco Elver , Matthew Wilcox , "Michael S. Tsirkin" , Pekka Enberg , Peter Zijlstra , Petr Mladek , Steven Rostedt , Thomas Gleixner , Vasily Gorbik , Vegard Nossum , Vlastimil Babka , linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 41/43] security: kmsan: fix interoperability with auto-initialization Message-ID: References: <20211214162050.660953-1-glider@google.com> <20211214162050.660953-42-glider@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211214162050.660953-42-glider@google.com> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: B0765100010 X-Stat-Signature: hk1zo3ryj764wiyr3kktyabhqg99bxtz Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=dpl6WsS8; spf=pass (imf14.hostedemail.com: domain of gregkh@linuxfoundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org; dmarc=pass (policy=none) header.from=linuxfoundation.org X-HE-Tag: 1639499889-539440 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, Dec 14, 2021 at 05:20:48PM +0100, Alexander Potapenko wrote: > Heap and stack initialization is great, but not when we are trying > uses of uninitialized memory. When the kernel is built with KMSAN, > having kernel memory initialization enabled may introduce false > negatives. > > We disable CONFIG_INIT_STACK_ALL_PATTERN and CONFIG_INIT_STACK_ALL_ZERO > under CONFIG_KMSAN, making it impossible to auto-initialize stack > variables in KMSAN builds. We also disable CONFIG_INIT_ON_ALLOC_DEFAULT_ON > and CONFIG_INIT_ON_FREE_DEFAULT_ON to prevent accidental use of heap > auto-initialization. > > We however still let the users enable heap auto-initialization at > boot-time (by setting init_on_alloc=1 or init_on_free=1), in which case > a warning is printed. > > Signed-off-by: Alexander Potapenko > --- > Link: https://linux-review.googlesource.com/id/I86608dd867018683a14ae1870f1928ad925f42e9 > --- > mm/page_alloc.c | 4 ++++ > security/Kconfig.hardening | 4 ++++ > 2 files changed, 8 insertions(+) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index fa8029b714a81..4218dea0c76a2 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -855,6 +855,10 @@ void init_mem_debugging_and_hardening(void) > else > static_branch_disable(&init_on_free); > > + if (IS_ENABLED(CONFIG_KMSAN) && > + (_init_on_alloc_enabled_early || _init_on_free_enabled_early)) > + pr_info("mem auto-init: please make sure init_on_alloc and init_on_free are disabled when running KMSAN\n"); > + > #ifdef CONFIG_DEBUG_PAGEALLOC > if (!debug_pagealloc_enabled()) > return; > diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening > index d051f8ceefddd..bd13a46024457 100644 > --- a/security/Kconfig.hardening > +++ b/security/Kconfig.hardening > @@ -106,6 +106,7 @@ choice > config INIT_STACK_ALL_PATTERN > bool "pattern-init everything (strongest)" > depends on CC_HAS_AUTO_VAR_INIT_PATTERN > + depends on !KMSAN > help > Initializes everything on the stack (including padding) > with a specific debug value. This is intended to eliminate > @@ -124,6 +125,7 @@ choice > config INIT_STACK_ALL_ZERO > bool "zero-init everything (strongest and safest)" > depends on CC_HAS_AUTO_VAR_INIT_ZERO > + depends on !KMSAN So this means KMSAN is a developer debugging feature only and should never be turned on on a real device/server that has users? thanks, greg k-h