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=-12.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 A2587C49EA7 for ; Fri, 25 Jun 2021 13:45:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4650F61973 for ; Fri, 25 Jun 2021 13:45:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4650F61973 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 558E56B0036; Fri, 25 Jun 2021 09:45:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 506C16B005D; Fri, 25 Jun 2021 09:45:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3813F6B006C; Fri, 25 Jun 2021 09:45:26 -0400 (EDT) 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 EFDC36B0036 for ; Fri, 25 Jun 2021 09:45:25 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 233EC8249980 for ; Fri, 25 Jun 2021 13:45:26 +0000 (UTC) X-FDA: 78292368252.10.7E4EAD7 Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by imf26.hostedemail.com (Postfix) with ESMTP id DD1C84202A1A for ; Fri, 25 Jun 2021 13:45:25 +0000 (UTC) Received: by mail-ed1-f47.google.com with SMTP id i24so13468335edx.4 for ; Fri, 25 Jun 2021 06:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iL+ONoFlGB91h/2MUDT1aNEjicjs7hNRvFGJskZUmDk=; b=kiJfd8p4xmlfbbZeSAn7Lzj+f+Dlybzapab68m2GbQ4GvW+A/165hn6+a7u63+lL5M fmiLROxHMEoHu+rgaB8iM+cA7KHd25HadOrD0bN+0W8TumCO/d3Y897stl/sl9kr1Ji4 lIZ0EYrGQk2nvmZKHixDg2iWcBGDsiGaql1sDyCuc1bKIFm5Avth0s+MgpnNAV9GJftx WJhC+gEsldsGSxaUb4snna01s+M1LtJb5Sbs2NGlahU1QE4mwG7MTczxaOcuCMdvhdVg vX6FUgy2TMfumXgLOfXFWl+5wTxxmMewDH7X/QET8Kut41gxOLuanOpo3n3TZqTwzrK6 wWhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iL+ONoFlGB91h/2MUDT1aNEjicjs7hNRvFGJskZUmDk=; b=FUuY4lUVyt+QEPsfp2hY9InVTt7tGhs2EFKM2lbTAofha1FK3GswDPlgjC84MqvSd9 X1vE3PfidY70qxRv9eNEQovs+pu0Mr8HWHM/uC5d2nA2+ZB4px1EGiUEEU0X35EipyUp SfhRp3/V+J7Le8UL6NHyzAqplBMJ0acV7UJXeS7QNmr1e6VM5jZGYjHVOsw3SWxnPt3c 2sZZoCWAQQUzHePUJl6BvpXYp0metTBYB4Vx6UR4tGQwfGBh+UT2paHoy/s1FvL18N9c XK4KKhYXnWLT4y21XMk905D9Hi5g1QEW0/qpBzNDsszGfwLCftT7OHNwzSVtok+kcZvv 5yAQ== X-Gm-Message-State: AOAM533HvcvvB8Wlb314d02CYWt9qY8HFJKA34qMaLTtgXMniBdUnv4i 3SHd1KrxWeJhnkbz9hLEUanirJifLByZOrolXpQ= X-Google-Smtp-Source: ABdhPJx/7wjtLCAR6FYQikOX37FFylP8a7qQdtDOPEXfXKCSIS4vRYSHLyq4FbUNXPoqlm8HtjDFpeUqLxV3DCkiGxE= X-Received: by 2002:a05:6402:4408:: with SMTP id y8mr14915135eda.55.1624628724627; Fri, 25 Jun 2021 06:45:24 -0700 (PDT) MIME-Version: 1.0 References: <20210624034050.511391-1-dja@axtens.net> <20210624034050.511391-2-dja@axtens.net> In-Reply-To: <20210624034050.511391-2-dja@axtens.net> From: Andrey Konovalov Date: Fri, 25 Jun 2021 16:45:02 +0300 Message-ID: Subject: Re: [PATCH v16 1/4] kasan: allow an architecture to disable inline instrumentation To: Daniel Axtens Cc: LKML , Linux Memory Management List , kasan-dev , Marco Elver , Andrew Morton , linuxppc-dev@lists.ozlabs.org, christophe.leroy@csgroup.eu, aneesh.kumar@linux.ibm.com, bsingharora@gmail.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: DD1C84202A1A X-Stat-Signature: 4drrufy9tnruh7amm4of1u691fy5za6w Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=kiJfd8p4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com X-HE-Tag: 1624628725-797814 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 Thu, Jun 24, 2021 at 6:41 AM Daniel Axtens wrote: > > For annoying architectural reasons, it's very difficult to support inline > instrumentation on powerpc64.* > > Add a Kconfig flag to allow an arch to disable inline. (It's a bit > annoying to be 'backwards', but I'm not aware of any way to have > an arch force a symbol to be 'n', rather than 'y'.) > > We also disable stack instrumentation in this case as it does things that > are functionally equivalent to inline instrumentation, namely adding > code that touches the shadow directly without going through a C helper. > > * on ppc64 atm, the shadow lives in virtual memory and isn't accessible in > real mode. However, before we turn on virtual memory, we parse the device > tree to determine which platform and MMU we're running under. That calls > generic DT code, which is instrumented. Inline instrumentation in DT would > unconditionally attempt to touch the shadow region, which we won't have > set up yet, and would crash. We can make outline mode wait for the arch to > be ready, but we can't change what the compiler inserts for inline mode. > > Reviewed-by: Marco Elver > Signed-off-by: Daniel Axtens > --- > lib/Kconfig.kasan | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan > index cffc2ebbf185..c3b228828a80 100644 > --- a/lib/Kconfig.kasan > +++ b/lib/Kconfig.kasan > @@ -12,6 +12,13 @@ config HAVE_ARCH_KASAN_HW_TAGS > config HAVE_ARCH_KASAN_VMALLOC > bool > > +config ARCH_DISABLE_KASAN_INLINE > + bool > + help > + An architecture might not support inline instrumentation. > + When this option is selected, inline and stack instrumentation are > + disabled. > + > config CC_HAS_KASAN_GENERIC > def_bool $(cc-option, -fsanitize=kernel-address) > > @@ -130,6 +137,7 @@ config KASAN_OUTLINE > > config KASAN_INLINE > bool "Inline instrumentation" > + depends on !ARCH_DISABLE_KASAN_INLINE > help > Compiler directly inserts code checking shadow memory before > memory accesses. This is faster than outline (in some workloads > @@ -141,6 +149,7 @@ endchoice > config KASAN_STACK > bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST > depends on KASAN_GENERIC || KASAN_SW_TAGS > + depends on !ARCH_DISABLE_KASAN_INLINE > default y if CC_IS_GCC > help > The LLVM stack address sanitizer has a know problem that > @@ -154,6 +163,9 @@ config KASAN_STACK > but clang users can still enable it for builds without > CONFIG_COMPILE_TEST. On gcc it is assumed to always be safe > to use and enabled by default. > + If the architecture disables inline instrumentation, stack > + instrumentation is also disabled as it adds inline-style > + instrumentation that is run unconditionally. > > config KASAN_SW_TAGS_IDENTIFY > bool "Enable memory corruption identification" > -- > 2.30.2 > Reviewed-by: Andrey Konovalov Thanks, Daniel!