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