1# SPDX-License-Identifier: GPL-2.0-only 2# This config refers to the generic KASAN mode. 3config HAVE_ARCH_KASAN 4 bool 5 6config HAVE_ARCH_KASAN_SW_TAGS 7 bool 8 9config CC_HAS_KASAN_GENERIC 10 def_bool $(cc-option, -fsanitize=kernel-address) 11 12config CC_HAS_KASAN_SW_TAGS 13 def_bool $(cc-option, -fsanitize=kernel-hwaddress) 14 15config KASAN 16 bool "KASAN: runtime memory debugger" 17 depends on (HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC) || \ 18 (HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS) 19 depends on (SLUB && SYSFS) || (SLAB && !DEBUG_SLAB) 20 help 21 Enables KASAN (KernelAddressSANitizer) - runtime memory debugger, 22 designed to find out-of-bounds accesses and use-after-free bugs. 23 See Documentation/dev-tools/kasan.rst for details. 24 25choice 26 prompt "KASAN mode" 27 depends on KASAN 28 default KASAN_GENERIC 29 help 30 KASAN has two modes: generic KASAN (similar to userspace ASan, 31 x86_64/arm64/xtensa, enabled with CONFIG_KASAN_GENERIC) and 32 software tag-based KASAN (a version based on software memory 33 tagging, arm64 only, similar to userspace HWASan, enabled with 34 CONFIG_KASAN_SW_TAGS). 35 Both generic and tag-based KASAN are strictly debugging features. 36 37config KASAN_GENERIC 38 bool "Generic mode" 39 depends on HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC 40 depends on (SLUB && SYSFS) || (SLAB && !DEBUG_SLAB) 41 select SLUB_DEBUG if SLUB 42 select CONSTRUCTORS 43 select STACKDEPOT 44 help 45 Enables generic KASAN mode. 46 Supported in both GCC and Clang. With GCC it requires version 4.9.2 47 or later for basic support and version 5.0 or later for detection of 48 out-of-bounds accesses for stack and global variables and for inline 49 instrumentation mode (CONFIG_KASAN_INLINE). With Clang it requires 50 version 3.7.0 or later and it doesn't support detection of 51 out-of-bounds accesses for global variables yet. 52 This mode consumes about 1/8th of available memory at kernel start 53 and introduces an overhead of ~x1.5 for the rest of the allocations. 54 The performance slowdown is ~x3. 55 For better error detection enable CONFIG_STACKTRACE. 56 Currently CONFIG_KASAN_GENERIC doesn't work with CONFIG_DEBUG_SLAB 57 (the resulting kernel does not boot). 58 59config KASAN_SW_TAGS 60 bool "Software tag-based mode" 61 depends on HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS 62 depends on (SLUB && SYSFS) || (SLAB && !DEBUG_SLAB) 63 select SLUB_DEBUG if SLUB 64 select CONSTRUCTORS 65 select STACKDEPOT 66 help 67 Enables software tag-based KASAN mode. 68 This mode requires Top Byte Ignore support by the CPU and therefore 69 is only supported for arm64. 70 This mode requires Clang version 7.0.0 or later. 71 This mode consumes about 1/16th of available memory at kernel start 72 and introduces an overhead of ~20% for the rest of the allocations. 73 This mode may potentially introduce problems relating to pointer 74 casting and comparison, as it embeds tags into the top byte of each 75 pointer. 76 For better error detection enable CONFIG_STACKTRACE. 77 Currently CONFIG_KASAN_SW_TAGS doesn't work with CONFIG_DEBUG_SLAB 78 (the resulting kernel does not boot). 79 80endchoice 81 82choice 83 prompt "Instrumentation type" 84 depends on KASAN 85 default KASAN_OUTLINE 86 87config KASAN_OUTLINE 88 bool "Outline instrumentation" 89 help 90 Before every memory access compiler insert function call 91 __asan_load*/__asan_store*. These functions performs check 92 of shadow memory. This is slower than inline instrumentation, 93 however it doesn't bloat size of kernel's .text section so 94 much as inline does. 95 96config KASAN_INLINE 97 bool "Inline instrumentation" 98 help 99 Compiler directly inserts code checking shadow memory before 100 memory accesses. This is faster than outline (in some workloads 101 it gives about x2 boost over outline instrumentation), but 102 make kernel's .text size much bigger. 103 For CONFIG_KASAN_GENERIC this requires GCC 5.0 or later. 104 105endchoice 106 107config KASAN_STACK_ENABLE 108 bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST 109 default !(CLANG_VERSION < 90000) 110 depends on KASAN 111 help 112 The LLVM stack address sanitizer has a know problem that 113 causes excessive stack usage in a lot of functions, see 114 https://bugs.llvm.org/show_bug.cgi?id=38809 115 Disabling asan-stack makes it safe to run kernels build 116 with clang-8 with KASAN enabled, though it loses some of 117 the functionality. 118 This feature is always disabled when compile-testing with clang-8 119 or earlier to avoid cluttering the output in stack overflow 120 warnings, but clang-8 users can still enable it for builds without 121 CONFIG_COMPILE_TEST. On gcc and later clang versions it is 122 assumed to always be safe to use and enabled by default. 123 124config KASAN_STACK 125 int 126 default 1 if KASAN_STACK_ENABLE || CC_IS_GCC 127 default 0 128 129config KASAN_S390_4_LEVEL_PAGING 130 bool "KASan: use 4-level paging" 131 depends on KASAN && S390 132 help 133 Compiling the kernel with KASan disables automatic 3-level vs 134 4-level paging selection. 3-level paging is used by default (up 135 to 3TB of RAM with KASan enabled). This options allows to force 136 4-level paging instead. 137 138config TEST_KASAN 139 tristate "Module for testing KASAN for bug detection" 140 depends on m && KASAN 141 help 142 This is a test module doing various nasty things like 143 out of bounds accesses, use after free. It is useful for testing 144 kernel debugging features like KASAN. 145