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=-23.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL 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 5C478C2B9F4 for ; Thu, 17 Jun 2021 07:06:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0997D61369 for ; Thu, 17 Jun 2021 07:06:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0997D61369 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9C1FB6B0071; Thu, 17 Jun 2021 03:06:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 998A46B0072; Thu, 17 Jun 2021 03:06:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 83A066B0073; Thu, 17 Jun 2021 03:06:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0254.hostedemail.com [216.40.44.254]) by kanga.kvack.org (Postfix) with ESMTP id 53CF96B0071 for ; Thu, 17 Jun 2021 03:06:41 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id F1E401ADA1 for ; Thu, 17 Jun 2021 07:06:40 +0000 (UTC) X-FDA: 78262332960.06.578F2B2 Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) by imf17.hostedemail.com (Postfix) with ESMTP id D243740002C1 for ; Thu, 17 Jun 2021 07:06:32 +0000 (UTC) Received: by mail-oi1-f174.google.com with SMTP id t140so5509550oih.0 for ; Thu, 17 Jun 2021 00:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x3f7kXNEAio7wn8rN5Q4qZlH4cBywzmH0Nokkyx4dn0=; b=TUHB1N3eQfQ+/6r1GQXAlEPc8aNokCkZd1BTVoHNgFnFfyyaHuQ8Tf7NNKqMlBvak5 YbMSSm+I9FLnG6TB8exQz/e5/DYGCNOU/HrQl7W9jHCTKMaPj48hgCrwO9HAqgsa6PUU LgzrPRiShRHFjIi0iMpIAfWuzyxY+yn074UknITQ6pWASp1mjiJ0xWYaLULgti2EgPfe CFsnD12vzglyKQp2quLeZjsZzcUBopxr/0CtrPKM2M5H+yt81jGEmvHjQ1GSTNFrUFim x4jAoOqmxpNRbiiJmDV+4C3HGdD1V9gQCdcX2DPFH21+kPNkDgzSy0vHY/OkTpHX6gs3 BhYg== 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=x3f7kXNEAio7wn8rN5Q4qZlH4cBywzmH0Nokkyx4dn0=; b=e8zwzh3nhJEiDNJx4laGJaJT37bNWurmqqMCDeFegPTxhv58s8Mmlt6SpoItYLqA7L mpv//lExob9WrFHo1xuy/IfALmW+BjmfjgW/zEKZJm0sXacyCtCE0L+gDpXb4n9SLjlG Z7DN9P78QEFIcIPVGrGHcMUX+WDGqgVkbMYw6xVTglTWbVg8Bn2FQLzH8Y5rBwdBf0fH 8vw/kZ527L9oc/CLQ9DcOGgx3qbi416gslWzdRW0QKVBS4LsysqnGYueluF4DhEMw3/o kloiVpoT98iKotoGqeLuEtvCSIdJUNlZqqTkonHaZst8k15oyltESM3X+PIowcVqDX8j 0dvQ== X-Gm-Message-State: AOAM533GicMqXbptbBi+6I/bmgA0+/aO8iTiYI4fAieqCxPpyXIZWY0t mSgGe8v3CP5a/5/lyIkO8nrYYlupqbYrAU1S4ht1EA== X-Google-Smtp-Source: ABdhPJyZGKvGnxD2CIdMiQREsVQ1HcwtZM1JRfUu9L6kEngXp5CZ452oDL3g8DnPzot/p3uA3kuCYblnTqzbZUjMv6k= X-Received: by 2002:a05:6808:bd5:: with SMTP id o21mr2268625oik.172.1623913599850; Thu, 17 Jun 2021 00:06:39 -0700 (PDT) MIME-Version: 1.0 References: <20210617063956.94061-1-dja@axtens.net> <20210617063956.94061-2-dja@axtens.net> In-Reply-To: <20210617063956.94061-2-dja@axtens.net> From: Marco Elver Date: Thu, 17 Jun 2021 09:06:28 +0200 Message-ID: Subject: Re: [PATCH v14 1/4] kasan: allow an architecture to disable inline instrumentation To: Daniel Axtens Cc: LKML , Linux Memory Management List , kasan-dev , Andrew Morton , Andrey Konovalov , linuxppc-dev@lists.ozlabs.org, Christophe Leroy , aneesh.kumar@linux.ibm.com, Balbir Singh Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: D243740002C1 X-Stat-Signature: o7ukw9ney68adcbnxp6c8gcex985g6c1 Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=TUHB1N3e; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf17.hostedemail.com: domain of elver@google.com designates 209.85.167.174 as permitted sender) smtp.mailfrom=elver@google.com X-HE-Tag: 1623913592-568890 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, 17 Jun 2021 at 08:40, 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. > > Signed-off-by: Daniel Axtens Reviewed-by: Marco Elver > --- > lib/Kconfig.kasan | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan > index cffc2ebbf185..cb5e02d09e11 100644 > --- a/lib/Kconfig.kasan > +++ b/lib/Kconfig.kasan > @@ -12,6 +12,15 @@ config HAVE_ARCH_KASAN_HW_TAGS > config HAVE_ARCH_KASAN_VMALLOC > bool > > +config ARCH_DISABLE_KASAN_INLINE > + bool > + help > + Sometimes an architecture might not be able to support inline > + instrumentation but might be able to support outline instrumentation. > + This option allows an architecture to prevent inline and stack > + instrumentation from being enabled. > + > + > config CC_HAS_KASAN_GENERIC > def_bool $(cc-option, -fsanitize=kernel-address) > > @@ -130,6 +139,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 +151,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 +165,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, this 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 > > -- > You received this message because you are subscribed to the Google Groups "kasan-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20210617063956.94061-2-dja%40axtens.net.