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