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 SYSFS && !SLUB_TINY 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 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 92config KASAN_SW_TAGS 93 bool "Software Tag-Based KASAN" 94 depends on HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS 95 depends on CC_HAS_WORKING_NOSANITIZE_ADDRESS 96 select SLUB_DEBUG 97 select CONSTRUCTORS 98 help 99 Enables Software Tag-Based KASAN. 100 101 Requires GCC 11+ or Clang. 102 103 Supported only on arm64 CPUs and relies on Top Byte Ignore. 104 105 Consumes about 1/16th of available memory at kernel start and 106 add an overhead of ~20% for dynamic allocations. 107 108 May potentially introduce problems related to pointer casting and 109 comparison, as it embeds a tag into the top byte of each pointer. 110 111config KASAN_HW_TAGS 112 bool "Hardware Tag-Based KASAN" 113 depends on HAVE_ARCH_KASAN_HW_TAGS 114 help 115 Enables Hardware Tag-Based KASAN. 116 117 Requires GCC 10+ or Clang 12+. 118 119 Supported only on arm64 CPUs starting from ARMv8.5 and relies on 120 Memory Tagging Extension and Top Byte Ignore. 121 122 Consumes about 1/32nd of available memory. 123 124 May potentially introduce problems related to pointer casting and 125 comparison, as it embeds a tag into the top byte of each pointer. 126 127endchoice 128 129choice 130 prompt "Instrumentation type" 131 depends on KASAN_GENERIC || KASAN_SW_TAGS 132 default KASAN_INLINE if !ARCH_DISABLE_KASAN_INLINE 133 134config KASAN_OUTLINE 135 bool "Outline instrumentation" 136 help 137 Makes the compiler insert function calls that check whether the memory 138 is accessible before each memory access. Slower than KASAN_INLINE, but 139 does not bloat the size of the kernel's .text section so much. 140 141config KASAN_INLINE 142 bool "Inline instrumentation" 143 depends on !ARCH_DISABLE_KASAN_INLINE 144 help 145 Makes the compiler directly insert memory accessibility checks before 146 each memory access. Faster than KASAN_OUTLINE (gives ~x2 boost for 147 some workloads), but makes the kernel's .text size much bigger. 148 149endchoice 150 151config KASAN_STACK 152 bool "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 Disables stack instrumentation and thus KASAN's ability to detect 158 out-of-bounds bugs in stack variables. 159 160 With Clang, stack instrumentation has a problem that causes excessive 161 stack usage, see https://bugs.llvm.org/show_bug.cgi?id=38809. Thus, 162 with Clang, this option is deemed unsafe. 163 164 This option is always disabled when compile-testing with Clang to 165 avoid cluttering the log with stack overflow warnings. 166 167 With GCC, enabling stack instrumentation is assumed to be safe. 168 169 If the architecture disables inline instrumentation via 170 ARCH_DISABLE_KASAN_INLINE, stack instrumentation gets disabled 171 as well, as it adds inline-style instrumentation that is run 172 unconditionally. 173 174config KASAN_VMALLOC 175 bool "Check accesses to vmalloc allocations" 176 depends on HAVE_ARCH_KASAN_VMALLOC 177 help 178 Makes KASAN check the validity of accesses to vmalloc allocations. 179 180 With software KASAN modes, all types vmalloc allocations are 181 checked. Enabling this option leads to higher memory usage. 182 183 With Hardware Tag-Based KASAN, only non-executable VM_ALLOC mappings 184 are checked. There is no additional memory usage. 185 186config KASAN_KUNIT_TEST 187 tristate "KUnit-compatible tests of KASAN bug detection capabilities" if !KUNIT_ALL_TESTS 188 depends on KASAN && KUNIT && TRACEPOINTS 189 default KUNIT_ALL_TESTS 190 help 191 A KUnit-based KASAN test suite. Triggers different kinds of 192 out-of-bounds and use-after-free accesses. Useful for testing whether 193 KASAN can detect certain bug types. 194 195 For more information on KUnit and unit tests in general, please refer 196 to the KUnit documentation in Documentation/dev-tools/kunit/. 197 198config KASAN_MODULE_TEST 199 tristate "KUnit-incompatible tests of KASAN bug detection capabilities" 200 depends on m && KASAN && !KASAN_HW_TAGS 201 help 202 A part of the KASAN test suite that is not integrated with KUnit. 203 Incompatible with Hardware Tag-Based KASAN. 204 205config KASAN_EXTRA_INFO 206 bool "Record and report more information" 207 depends on KASAN 208 help 209 Record and report more information to help us find the cause of the 210 bug and to help us correlate the error with other system events. 211 212 Currently, the CPU number and timestamp are additionally 213 recorded for each heap block at allocation and free time, and 214 8 bytes will be added to each metadata structure that records 215 allocation or free information. 216 217 In Generic KASAN, each kmalloc-8 and kmalloc-16 object will add 218 16 bytes of additional memory consumption, and each kmalloc-32 219 object will add 8 bytes of additional memory consumption, not 220 affecting other larger objects. 221 222 In SW_TAGS KASAN and HW_TAGS KASAN, depending on the stack_ring_size 223 boot parameter, it will add 8 * stack_ring_size bytes of additional 224 memory consumption. 225 226endif # KASAN 227