| Message ID | 20210615014705.2234866-2-dja@axtens.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KASAN core changes for ppc64 radix KASAN | expand |
On Tue, 15 Jun 2021 at 03:47, 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. > > 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..935814f332a7 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 > > +# Sometimes an architecture might not be able to support inline instrumentation > +# but might be able to support outline instrumentation. This option allows an > +# arch to prevent inline and stack instrumentation from being enabled. This comment could be moved into 'help' of this new config option. > +# ppc64 turns on virtual memory late in boot, after calling into generic code > +# like the device-tree parser, so it uses this in conjuntion with a hook in > +# outline mode to avoid invalid access early in boot. I think the ppc64-related comment isn't necessary and can be moved to arch/ppc64 somewhere, if there isn't one already. > +config ARCH_DISABLE_KASAN_INLINE > + bool > + > 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.27.0 > > -- > 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/20210615014705.2234866-2-dja%40axtens.net.
Hi Marco, @@ -12,6 +12,15 @@ config HAVE_ARCH_KASAN_HW_TAGS >> config HAVE_ARCH_KASAN_VMALLOC >> bool >> >> +# Sometimes an architecture might not be able to support inline instrumentation >> +# but might be able to support outline instrumentation. This option allows an >> +# arch to prevent inline and stack instrumentation from being enabled. > > This comment could be moved into 'help' of this new config option. It could. I did wonder if that made sense given that this is not a user selectable option so I'm not sure if the help will ever be visible, but I see that we do this sort of thing in Kconfig.kcsan and Kconfig.kgdb. I've changed it over. >> +# ppc64 turns on virtual memory late in boot, after calling into generic code >> +# like the device-tree parser, so it uses this in conjuntion with a hook in >> +# outline mode to avoid invalid access early in boot. > > I think the ppc64-related comment isn't necessary and can be moved to > arch/ppc64 somewhere, if there isn't one already. Fair enough. I'll pull it out of this file and look for a good place to put the information in arch/powerpc in a later patch/series. Kind regards, Daniel
diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan index cffc2ebbf185..935814f332a7 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 +# Sometimes an architecture might not be able to support inline instrumentation +# but might be able to support outline instrumentation. This option allows an +# arch to prevent inline and stack instrumentation from being enabled. +# ppc64 turns on virtual memory late in boot, after calling into generic code +# like the device-tree parser, so it uses this in conjuntion with a hook in +# outline mode to avoid invalid access early in boot. +config ARCH_DISABLE_KASAN_INLINE + bool + 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"
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. Signed-off-by: Daniel Axtens <dja@axtens.net> --- lib/Kconfig.kasan | 14 ++++++++++++++ 1 file changed, 14 insertions(+)