1# SPDX-License-Identifier: GPL-2.0-only 2 3# This config refers to the generic KASAN mode. 4config HAVE_ARCH_KASAN 5 bool 6 7config HAVE_ARCH_KASAN_SW_TAGS 8 bool 9 10config HAVE_ARCH_KASAN_HW_TAGS 11 bool 12 13config HAVE_ARCH_KASAN_VMALLOC 14 bool 15 16config ARCH_DISABLE_KASAN_INLINE 17 bool 18 help 19 Disables both inline and stack instrumentation. Selected by 20 architectures that do not support these instrumentation types. 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 do not 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: dynamic memory safety error detector" 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 && !SLUB_TINY) || (SLAB && !DEBUG_SLAB) 41 select STACKDEPOT_ALWAYS_INIT 42 help 43 Enables KASAN (Kernel Address Sanitizer) - a dynamic memory safety 44 error detector designed to find out-of-bounds and use-after-free bugs. 45 46 See Documentation/dev-tools/kasan.rst for details. 47 48 For better error reports, also enable CONFIG_STACKTRACE. 49 50if KASAN 51 52config CC_HAS_KASAN_MEMINTRINSIC_PREFIX 53 def_bool (CC_IS_CLANG && $(cc-option,-fsanitize=kernel-address -mllvm -asan-kernel-mem-intrinsic-prefix=1)) || \ 54 (CC_IS_GCC && $(cc-option,-fsanitize=kernel-address --param asan-kernel-mem-intrinsic-prefix=1)) 55 # Don't define it if we don't need it: compilation of the test uses 56 # this variable to decide how the compiler should treat builtins. 57 depends on !KASAN_HW_TAGS 58 help 59 The compiler is able to prefix memintrinsics with __asan or __hwasan. 60 61choice 62 prompt "KASAN mode" 63 default KASAN_GENERIC 64 help 65 KASAN has three modes: 66 67 1. Generic KASAN (supported by many architectures, enabled with 68 CONFIG_KASAN_GENERIC, similar to userspace ASan), 69 2. Software Tag-Based KASAN (arm64 only, based on software memory 70 tagging, enabled with CONFIG_KASAN_SW_TAGS, similar to userspace 71 HWASan), and 72 3. Hardware Tag-Based KASAN (arm64 only, based on hardware memory 73 tagging, enabled with CONFIG_KASAN_HW_TAGS). 74 75 See Documentation/dev-tools/kasan.rst for details about each mode. 76 77config KASAN_GENERIC 78 bool "Generic KASAN" 79 depends on HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC 80 depends on CC_HAS_WORKING_NOSANITIZE_ADDRESS 81 select SLUB_DEBUG if SLUB 82 select CONSTRUCTORS 83 help 84 Enables Generic KASAN. 85 86 Requires GCC 8.3.0+ or Clang. 87 88 Consumes about 1/8th of available memory at kernel start and adds an 89 overhead of ~50% for dynamic allocations. 90 The performance slowdown is ~x3. 91 92 (Incompatible with CONFIG_DEBUG_SLAB: the kernel does not boot.) 93 94config KASAN_SW_TAGS 95 bool "Software Tag-Based KASAN" 96 depends on HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS 97 depends on CC_HAS_WORKING_NOSANITIZE_ADDRESS 98 select SLUB_DEBUG if SLUB 99 select CONSTRUCTORS 100 help 101 Enables Software Tag-Based KASAN. 102 103 Requires GCC 11+ or Clang. 104 105 Supported only on arm64 CPUs and relies on Top Byte Ignore. 106 107 Consumes about 1/16th of available memory at kernel start and 108 add an overhead of ~20% for dynamic allocations. 109 110 May potentially introduce problems related to pointer casting and 111 comparison, as it embeds a tag into the top byte of each pointer. 112 113 (Incompatible with CONFIG_DEBUG_SLAB: the kernel does not boot.) 114 115config KASAN_HW_TAGS 116 bool "Hardware Tag-Based KASAN" 117 depends on HAVE_ARCH_KASAN_HW_TAGS 118 depends on SLUB 119 help 120 Enables Hardware Tag-Based KASAN. 121 122 Requires GCC 10+ or Clang 12+. 123 124 Supported only on arm64 CPUs starting from ARMv8.5 and relies on 125 Memory Tagging Extension and Top Byte Ignore. 126 127 Consumes about 1/32nd of available memory. 128 129 May potentially introduce problems related to pointer casting and 130 comparison, as it embeds a tag into the top byte of each pointer. 131 132endchoice 133 134choice 135 prompt "Instrumentation type" 136 depends on KASAN_GENERIC || KASAN_SW_TAGS 137 default KASAN_OUTLINE 138 139config KASAN_OUTLINE 140 bool "Outline instrumentation" 141 help 142 Makes the compiler insert function calls that check whether the memory 143 is accessible before each memory access. Slower than KASAN_INLINE, but 144 does not bloat the size of the kernel's .text section so much. 145 146config KASAN_INLINE 147 bool "Inline instrumentation" 148 depends on !ARCH_DISABLE_KASAN_INLINE 149 help 150 Makes the compiler directly insert memory accessibility checks before 151 each memory access. Faster than KASAN_OUTLINE (gives ~x2 boost for 152 some workloads), but makes the kernel's .text size much bigger. 153 154endchoice 155 156config KASAN_STACK 157 bool "Stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST 158 depends on KASAN_GENERIC || KASAN_SW_TAGS 159 depends on !ARCH_DISABLE_KASAN_INLINE 160 default y if CC_IS_GCC 161 help 162 Disables stack instrumentation and thus KASAN's ability to detect 163 out-of-bounds bugs in stack variables. 164 165 With Clang, stack instrumentation has a problem that causes excessive 166 stack usage, see https://bugs.llvm.org/show_bug.cgi?id=38809. Thus, 167 with Clang, this option is deemed unsafe. 168 169 This option is always disabled when compile-testing with Clang to 170 avoid cluttering the log with stack overflow warnings. 171 172 With GCC, enabling stack instrumentation is assumed to be safe. 173 174 If the architecture disables inline instrumentation via 175 ARCH_DISABLE_KASAN_INLINE, stack instrumentation gets disabled 176 as well, as it adds inline-style instrumentation that is run 177 unconditionally. 178 179config KASAN_VMALLOC 180 bool "Check accesses to vmalloc allocations" 181 depends on HAVE_ARCH_KASAN_VMALLOC 182 help 183 Makes KASAN check the validity of accesses to vmalloc allocations. 184 185 With software KASAN modes, all types vmalloc allocations are 186 checked. Enabling this option leads to higher memory usage. 187 188 With Hardware Tag-Based KASAN, only non-executable VM_ALLOC mappings 189 are checked. There is no additional 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 && TRACEPOINTS 194 default KUNIT_ALL_TESTS 195 help 196 A KUnit-based KASAN test suite. Triggers different kinds of 197 out-of-bounds and use-after-free accesses. Useful for testing whether 198 KASAN can detect certain bug types. 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 A part of the KASAN test suite that is not integrated with KUnit. 208 Incompatible with Hardware Tag-Based KASAN. 209 210endif # KASAN 211