Commit 158f2552 authored by Daniel Axtens's avatar Daniel Axtens Committed by Linus Torvalds
Browse files

kasan: allow an architecture to disable inline instrumentation

Patch series "KASAN core changes for ppc64 radix KASAN", v16.

Building on the work of Christophe, Aneesh and Balbir, I've ported KASAN
to 64-bit Book3S kernels running on the Radix MMU.  I've been trying this
for a while, but we keep having collisions between the kasan code in the
mm tree and the code I want to put in to the ppc tree.

This series just contains the kasan core changes that we need.  There
should be no noticeable changes to other platforms.

This patch (of 4):

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.

Link: https://lkml.kernel.org/r/20210624034050.511391-1-dja@axtens.net
Link: https://lkml.kernel.org/r/20210624034050.511391-2-dja@axtens.net


Signed-off-by: default avatarDaniel Axtens <dja@axtens.net>
Reviewed-by: default avatarMarco Elver <elver@google.com>
Reviewed-by: default avatarAndrey Konovalov <andreyknvl@gmail.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Balbir Singh <bsingharora@gmail.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
parent 3ff16d30
Loading
Loading
Loading
Loading
+12 −0
Original line number Diff line number Diff line
@@ -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"