Re: [PATCH v11 05/24] kasan: add CONFIG_KASAN_GENERIC and CONFIG_KASAN_SW_TAGS

Andrey Konovalov
2018-11-27T16:12:50Z

On Fri, Nov 23, 2018 at 6:43 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> 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@virtuozzo.com>
>> Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
>> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
>> ---
>> 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.

Will do in v12, thanks!