On Mon, Nov 19, 2018 at 06:26:21PM +0100, Andrey Konovalov wrote: > This commit splits the current CONFIG_KASAN config option into two: > 1. CONFIG_KASAN_GENERIC, that enables the generic KASAN mode (the one > that exists now); > 2. CONFIG_KASAN_SW_TAGS, that enables the software tag-based KASAN mode. > > The name CONFIG_KASAN_SW_TAGS is chosen as in the future we will have > another hardware tag-based KASAN mode, that will rely on hardware memory > tagging support in arm64. > > With CONFIG_KASAN_SW_TAGS enabled, compiler options are changed to > instrument kernel files with -fsantize=kernel-hwaddress (except the ones > for which KASAN_SANITIZE := n is set). > > Both CONFIG_KASAN_GENERIC and CONFIG_KASAN_SW_TAGS support both > CONFIG_KASAN_INLINE and CONFIG_KASAN_OUTLINE instrumentation modes. > > This commit also adds empty placeholder (for now) implementation of > tag-based KASAN specific hooks inserted by the compiler and adjusts > common hooks implementation to compile correctly with each of the > config options. > > Reviewed-by: Andrey Ryabinin <aryabinin@xxxxxxxxxxxxx> > Reviewed-by: Dmitry Vyukov <dvyukov@xxxxxxxxxx> > Signed-off-by: Andrey Konovalov <andreyknvl@xxxxxxxxxx> > --- > arch/arm64/Kconfig | 1 + > include/linux/compiler-clang.h | 5 +- > include/linux/compiler-gcc.h | 6 ++ > include/linux/compiler_attributes.h | 13 ---- > include/linux/kasan.h | 16 +++-- > lib/Kconfig.kasan | 96 +++++++++++++++++++++++------ > mm/kasan/Makefile | 6 +- > mm/kasan/generic.c | 2 +- > mm/kasan/kasan.h | 3 +- > mm/kasan/tags.c | 75 ++++++++++++++++++++++ > mm/slub.c | 2 +- > scripts/Makefile.kasan | 53 +++++++++------- > 12 files changed, 216 insertions(+), 62 deletions(-) > create mode 100644 mm/kasan/tags.c > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 787d7850e064..8b331dcfb48e 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -111,6 +111,7 @@ config ARM64 > select HAVE_ARCH_JUMP_LABEL > select HAVE_ARCH_JUMP_LABEL_RELATIVE > select HAVE_ARCH_KASAN if !(ARM64_16K_PAGES && ARM64_VA_BITS_48) > + select HAVE_ARCH_KASAN_SW_TAGS if !(ARM64_16K_PAGES && ARM64_VA_BITS_48) > --- a/lib/Kconfig.kasan > +++ b/lib/Kconfig.kasan > @@ -1,35 +1,95 @@ > +# This config refers to the generic KASAN mode. > config HAVE_ARCH_KASAN > bool > > +config HAVE_ARCH_KASAN_SW_TAGS > + bool > + > +config CC_HAS_KASAN_GENERIC > + def_bool $(cc-option, -fsanitize=kernel-address) > + > +config CC_HAS_KASAN_SW_TAGS > + def_bool $(cc-option, -fsanitize=kernel-hwaddress) > +if HAVE_ARCH_KASAN_SW_TAGS > + > +config KASAN_SW_TAGS > + bool "Software tag-based mode" > + depends on CC_HAS_KASAN_SW_TAGS > + depends on (SLUB && SYSFS) || (SLAB && !DEBUG_SLAB) > + select SLUB_DEBUG if SLUB > + select CONSTRUCTORS > + select STACKDEPOT > + help > + Enables software tag-based KASAN mode. > + This mode requires Top Byte Ignore support by the CPU and therefore > + is only supported for arm64. > + This mode requires Clang version 7.0.0 or later. > + This mode consumes about 1/16th of available memory at kernel start > + and introduces an overhead of ~20% for the rest of the allocations. > + This mode may potentially introduce problems relating to pointer > + casting and comparison, as it embeds tags into the top byte of each > + pointer. > + For better error detection enable CONFIG_STACKTRACE. > + Currently CONFIG_KASAN_SW_TAGS doesn't work with CONFIG_DEBUG_SLAB > + (the resulting kernel does not boot). > + > +endif IIUC as of this patch a user can select KASAN_SW_TAGS... > +ifdef CONFIG_KASAN_SW_TAGS > + > +ifdef CONFIG_KASAN_INLINE > + instrumentation_flags := -mllvm -hwasan-mapping-offset=$(KASAN_SHADOW_OFFSET) > +else > + instrumentation_flags := -mllvm -hwasan-instrument-with-calls=1 > +endif > + > +CFLAGS_KASAN := -fsanitize=kernel-hwaddress \ > + -mllvm -hwasan-instrument-stack=0 \ > + $(instrumentation_flags) > + > +endif # CONFIG_KASAN_SW_TAGS ... and therefore we start using the compiler option, even though we haven't introduced all of the necessary infrastructure yet. That doesn't sound right to me. At the very least, that breaks randconfig builds. What we can do, in-order, is: 1) introduce the core refactoring, dependent on HAVE_ARCH_KASAN_SW_TAGS 2) instroduce the new infrastructure and arch code 3) select HAVE_ARCH_KASAN_SW_TAGS ... such that at (3), all KASAN configurations are known to work. Thanks, Mark.
