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