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 HAVE_ARCH_KASAN_HW_TAGS 10 bool 11 12config HAVE_ARCH_KASAN_VMALLOC 13 bool 14 15config ARCH_DISABLE_KASAN_INLINE 16 bool 17 help 18 An architecture might not support inline instrumentation. 19 When this option is selected, inline and stack instrumentation are 20 disabled. 21 22config CC_HAS_KASAN_GENERIC 23 def_bool $(cc-option, -fsanitize=kernel-address) 24 25config CC_HAS_KASAN_SW_TAGS 26 def_bool $(cc-option, -fsanitize=kernel-hwaddress) 27 28# This option is only required for software KASAN modes. 29# Old GCC versions don't have proper support for no_sanitize_address. 30# See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89124 for details. 31config CC_HAS_WORKING_NOSANITIZE_ADDRESS 32 def_bool !CC_IS_GCC || GCC_VERSION >= 80300 33 34menuconfig KASAN 35 bool "KASAN: runtime memory debugger" 36 depends on (((HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC) || \ 37 (HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS)) && \ 38 CC_HAS_WORKING_NOSANITIZE_ADDRESS) || \ 39 HAVE_ARCH_KASAN_HW_TAGS 40 depends on (SLUB && SYSFS) || (SLAB && !DEBUG_SLAB) 41 select STACKDEPOT 42 help 43 Enables KASAN (KernelAddressSANitizer) - runtime memory debugger, 44 designed to find out-of-bounds accesses and use-after-free bugs. 45 See Documentation/dev-tools/kasan.rst for details. 46 47if KASAN 48 49choice 50 prompt "KASAN mode" 51 default KASAN_GENERIC 52 help 53 KASAN has three modes: 54 1. generic KASAN (similar to userspace ASan, 55 x86_64/arm64/xtensa, enabled with CONFIG_KASAN_GENERIC), 56 2. software tag-based KASAN (arm64 only, based on software 57 memory tagging (similar to userspace HWASan), enabled with 58 CONFIG_KASAN_SW_TAGS), and 59 3. hardware tag-based KASAN (arm64 only, based on hardware 60 memory tagging, enabled with CONFIG_KASAN_HW_TAGS). 61 62 All KASAN modes are strictly debugging features. 63 64 For better error reports enable CONFIG_STACKTRACE. 65 66config KASAN_GENERIC 67 bool "Generic mode" 68 depends on HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC 69 select SLUB_DEBUG if SLUB 70 select CONSTRUCTORS 71 help 72 Enables generic KASAN mode. 73 74 This mode is supported in both GCC and Clang. With GCC it requires 75 version 8.3.0 or later. Any supported Clang version is compatible, 76 but detection of out-of-bounds accesses for global variables is 77 supported only since Clang 11. 78 79 This mode consumes about 1/8th of available memory at kernel start 80 and introduces an overhead of ~x1.5 for the rest of the allocations. 81 The performance slowdown is ~x3. 82 83 Currently CONFIG_KASAN_GENERIC doesn't work with CONFIG_DEBUG_SLAB 84 (the resulting kernel does not boot). 85 86config KASAN_SW_TAGS 87 bool "Software tag-based mode" 88 depends on HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS 89 select SLUB_DEBUG if SLUB 90 select CONSTRUCTORS 91 help 92 Enables software tag-based KASAN mode. 93 94 This mode require software memory tagging support in the form of 95 HWASan-like compiler instrumentation. 96 97 Currently this mode is only implemented for arm64 CPUs and relies on 98 Top Byte Ignore. This mode requires Clang. 99 100 This mode consumes about 1/16th of available memory at kernel start 101 and introduces an overhead of ~20% for the rest of the allocations. 102 This mode may potentially introduce problems relating to pointer 103 casting and comparison, as it embeds tags into the top byte of each 104 pointer. 105 106 Currently CONFIG_KASAN_SW_TAGS doesn't work with CONFIG_DEBUG_SLAB 107 (the resulting kernel does not boot). 108 109config KASAN_HW_TAGS 110 bool "Hardware tag-based mode" 111 depends on HAVE_ARCH_KASAN_HW_TAGS 112 depends on SLUB 113 help 114 Enables hardware tag-based KASAN mode. 115 116 This mode requires hardware memory tagging support, and can be used 117 by any architecture that provides it. 118 119 Currently this mode is only implemented for arm64 CPUs starting from 120 ARMv8.5 and relies on Memory Tagging Extension and Top Byte Ignore. 121 122endchoice 123 124choice 125 prompt "Instrumentation type" 126 depends on KASAN_GENERIC || KASAN_SW_TAGS 127 default KASAN_OUTLINE 128 129config KASAN_OUTLINE 130 bool "Outline instrumentation" 131 help 132 Before every memory access compiler insert function call 133 __asan_load*/__asan_store*. These functions performs check 134 of shadow memory. This is slower than inline instrumentation, 135 however it doesn't bloat size of kernel's .text section so 136 much as inline does. 137 138config KASAN_INLINE 139 bool "Inline instrumentation" 140 depends on !ARCH_DISABLE_KASAN_INLINE 141 help 142 Compiler directly inserts code checking shadow memory before 143 memory accesses. This is faster than outline (in some workloads 144 it gives about x2 boost over outline instrumentation), but 145 make kernel's .text size much bigger. 146 147endchoice 148 149config KASAN_STACK 150 bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST 151 depends on KASAN_GENERIC || KASAN_SW_TAGS 152 depends on !ARCH_DISABLE_KASAN_INLINE 153 default y if CC_IS_GCC 154 help 155 The LLVM stack address sanitizer has a know problem that 156 causes excessive stack usage in a lot of functions, see 157 https://bugs.llvm.org/show_bug.cgi?id=38809 158 Disabling asan-stack makes it safe to run kernels build 159 with clang-8 with KASAN enabled, though it loses some of 160 the functionality. 161 This feature is always disabled when compile-testing with clang 162 to avoid cluttering the output in stack overflow warnings, 163 but clang users can still enable it for builds without 164 CONFIG_COMPILE_TEST. On gcc it is assumed to always be safe 165 to use and enabled by default. 166 If the architecture disables inline instrumentation, stack 167 instrumentation is also disabled as it adds inline-style 168 instrumentation that is run unconditionally. 169 170config KASAN_TAGS_IDENTIFY 171 bool "Enable memory corruption identification" 172 depends on KASAN_SW_TAGS || KASAN_HW_TAGS 173 help 174 This option enables best-effort identification of bug type 175 (use-after-free or out-of-bounds) at the cost of increased 176 memory consumption. 177 178config KASAN_VMALLOC 179 bool "Back mappings in vmalloc space with real shadow memory" 180 depends on KASAN_GENERIC && HAVE_ARCH_KASAN_VMALLOC 181 help 182 By default, the shadow region for vmalloc space is the read-only 183 zero page. This means that KASAN cannot detect errors involving 184 vmalloc space. 185 186 Enabling this option will hook in to vmap/vmalloc and back those 187 mappings with real shadow memory allocated on demand. This allows 188 for KASAN to detect more sorts of errors (and to support vmapped 189 stacks), but at the cost of higher memory usage. 190 191config KASAN_KUNIT_TEST 192 tristate "KUnit-compatible tests of KASAN bug detection capabilities" if !KUNIT_ALL_TESTS 193 depends on KASAN && KUNIT 194 default KUNIT_ALL_TESTS 195 help 196 This is a KUnit test suite doing various nasty things like 197 out of bounds and use after free accesses. It is useful for testing 198 kernel debugging features like KASAN. 199 200 For more information on KUnit and unit tests in general, please refer 201 to the KUnit documentation in Documentation/dev-tools/kunit. 202 203config KASAN_MODULE_TEST 204 tristate "KUnit-incompatible tests of KASAN bug detection capabilities" 205 depends on m && KASAN && !KASAN_HW_TAGS 206 help 207 This is a part of the KASAN test suite that is incompatible with 208 KUnit. Currently includes tests that do bad copy_from/to_user 209 accesses. 210 211endif # KASAN 212