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