From: Andrey Konovalov <andreyknvl@gmail.com> To: Daniel Axtens <dja@axtens.net> Cc: LKML <linux-kernel@vger.kernel.org>, Linux Memory Management List <linux-mm@kvack.org>, kasan-dev <kasan-dev@googlegroups.com>, Marco Elver <elver@google.com>, Andrew Morton <akpm@linux-foundation.org>, linuxppc-dev@lists.ozlabs.org, christophe.leroy@csgroup.eu, aneesh.kumar@linux.ibm.com, bsingharora@gmail.com Subject: Re: [PATCH v15 1/4] kasan: allow an architecture to disable inline instrumentation Date: Sun, 20 Jun 2021 14:15:47 +0300 [thread overview] Message-ID: <CA+fCnZecs6jVgMmVq0N1iGRO4Cm+rbm5xyj_sMdKkxhX6-nvaA@mail.gmail.com> (raw) In-Reply-To: <20210617093032.103097-2-dja@axtens.net> On Thu, Jun 17, 2021 at 12:30 PM Daniel Axtens <dja@axtens.net> 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 <elver@google.com> > Signed-off-by: Daniel Axtens <dja@axtens.net> > --- > 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. This seems too wordy. How about: "An architecture might not support inline instrumentation. When this option is selected, inline and stack instrumentation are disabled." > + > + Drop the extra empty line. > 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 this => stack instrumentation > + 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 >
WARNING: multiple messages have this Message-ID (diff)
From: Andrey Konovalov <andreyknvl@gmail.com> To: Daniel Axtens <dja@axtens.net> Cc: Marco Elver <elver@google.com>, aneesh.kumar@linux.ibm.com, LKML <linux-kernel@vger.kernel.org>, kasan-dev <kasan-dev@googlegroups.com>, Linux Memory Management List <linux-mm@kvack.org>, Andrew Morton <akpm@linux-foundation.org>, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v15 1/4] kasan: allow an architecture to disable inline instrumentation Date: Sun, 20 Jun 2021 14:15:47 +0300 [thread overview] Message-ID: <CA+fCnZecs6jVgMmVq0N1iGRO4Cm+rbm5xyj_sMdKkxhX6-nvaA@mail.gmail.com> (raw) In-Reply-To: <20210617093032.103097-2-dja@axtens.net> On Thu, Jun 17, 2021 at 12:30 PM Daniel Axtens <dja@axtens.net> 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 <elver@google.com> > Signed-off-by: Daniel Axtens <dja@axtens.net> > --- > 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. This seems too wordy. How about: "An architecture might not support inline instrumentation. When this option is selected, inline and stack instrumentation are disabled." > + > + Drop the extra empty line. > 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 this => stack instrumentation > + 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 >
next prev parent reply other threads:[~2021-06-20 11:16 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-17 9:30 [PATCH v15 0/4] KASAN core changes for ppc64 radix KASAN Daniel Axtens 2021-06-17 9:30 ` Daniel Axtens 2021-06-17 9:30 ` [PATCH v15 1/4] kasan: allow an architecture to disable inline instrumentation Daniel Axtens 2021-06-17 9:30 ` Daniel Axtens 2021-06-20 11:15 ` Andrey Konovalov [this message] 2021-06-20 11:15 ` Andrey Konovalov 2021-06-20 11:15 ` Andrey Konovalov 2021-06-17 9:30 ` [PATCH v15 2/4] kasan: allow architectures to provide an outline readiness check Daniel Axtens 2021-06-17 9:30 ` Daniel Axtens 2021-06-20 11:16 ` Andrey Konovalov 2021-06-20 11:16 ` Andrey Konovalov 2021-06-20 11:16 ` Andrey Konovalov 2021-06-23 9:25 ` Daniel Axtens 2021-06-23 9:25 ` Daniel Axtens 2021-06-17 9:30 ` [PATCH v15 3/4] mm: define default MAX_PTRS_PER_* in include/pgtable.h Daniel Axtens 2021-06-17 9:30 ` Daniel Axtens 2021-06-20 11:17 ` Andrey Konovalov 2021-06-20 11:17 ` Andrey Konovalov 2021-06-20 11:17 ` Andrey Konovalov 2021-06-17 9:30 ` [PATCH v15 4/4] kasan: use MAX_PTRS_PER_* for early shadow tables Daniel Axtens 2021-06-17 9:30 ` Daniel Axtens 2021-06-20 11:17 ` Andrey Konovalov 2021-06-20 11:17 ` Andrey Konovalov 2021-06-20 11:17 ` Andrey Konovalov 2021-06-17 14:04 ` [PATCH v15 0/4] KASAN core changes for ppc64 radix KASAN Balbir Singh 2021-06-17 14:04 ` Balbir Singh
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CA+fCnZecs6jVgMmVq0N1iGRO4Cm+rbm5xyj_sMdKkxhX6-nvaA@mail.gmail.com \ --to=andreyknvl@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=aneesh.kumar@linux.ibm.com \ --cc=bsingharora@gmail.com \ --cc=christophe.leroy@csgroup.eu \ --cc=dja@axtens.net \ --cc=elver@google.com \ --cc=kasan-dev@googlegroups.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linuxppc-dev@lists.ozlabs.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.