227 lines · plain
1# SPDX-License-Identifier: GPL-2.0-only2 3# This config refers to the generic KASAN mode.4config HAVE_ARCH_KASAN5 bool6 7config HAVE_ARCH_KASAN_SW_TAGS8 bool9 10config HAVE_ARCH_KASAN_HW_TAGS11 bool12 13config HAVE_ARCH_KASAN_VMALLOC14 bool15 16config ARCH_DISABLE_KASAN_INLINE17 bool18 help19 Disables both inline and stack instrumentation. Selected by20 architectures that do not support these instrumentation types.21 22config CC_HAS_KASAN_GENERIC23 def_bool $(cc-option, -fsanitize=kernel-address)24 25config CC_HAS_KASAN_SW_TAGS26 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_ADDRESS32 def_bool !CC_IS_GCC || GCC_VERSION >= 8030033 34menuconfig KASAN35 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_TAGS40 depends on SYSFS && !SLUB_TINY41 select STACKDEPOT_ALWAYS_INIT42 help43 Enables KASAN (Kernel Address Sanitizer) - a dynamic memory safety44 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 KASAN51 52config CC_HAS_KASAN_MEMINTRINSIC_PREFIX53 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 uses56 # this variable to decide how the compiler should treat builtins.57 depends on !KASAN_HW_TAGS58 help59 The compiler is able to prefix memintrinsics with __asan or __hwasan.60 61choice62 prompt "KASAN mode"63 default KASAN_GENERIC64 help65 KASAN has three modes:66 67 1. Generic KASAN (supported by many architectures, enabled with68 CONFIG_KASAN_GENERIC, similar to userspace ASan),69 2. Software Tag-Based KASAN (arm64 only, based on software memory70 tagging, enabled with CONFIG_KASAN_SW_TAGS, similar to userspace71 HWASan), and72 3. Hardware Tag-Based KASAN (arm64 only, based on hardware memory73 tagging, enabled with CONFIG_KASAN_HW_TAGS).74 75 See Documentation/dev-tools/kasan.rst for details about each mode.76 77config KASAN_GENERIC78 bool "Generic KASAN"79 depends on HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC80 depends on CC_HAS_WORKING_NOSANITIZE_ADDRESS81 select SLUB_DEBUG82 select CONSTRUCTORS83 help84 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 an89 overhead of ~50% for dynamic allocations.90 The performance slowdown is ~x3.91 92config KASAN_SW_TAGS93 bool "Software Tag-Based KASAN"94 depends on HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS95 depends on CC_HAS_WORKING_NOSANITIZE_ADDRESS96 select SLUB_DEBUG97 select CONSTRUCTORS98 help99 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 and106 add an overhead of ~20% for dynamic allocations.107 108 May potentially introduce problems related to pointer casting and109 comparison, as it embeds a tag into the top byte of each pointer.110 111config KASAN_HW_TAGS112 bool "Hardware Tag-Based KASAN"113 depends on HAVE_ARCH_KASAN_HW_TAGS114 help115 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 on120 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 and125 comparison, as it embeds a tag into the top byte of each pointer.126 127endchoice128 129choice130 prompt "Instrumentation type"131 depends on KASAN_GENERIC || KASAN_SW_TAGS132 default KASAN_INLINE if !ARCH_DISABLE_KASAN_INLINE133 134config KASAN_OUTLINE135 bool "Outline instrumentation"136 help137 Makes the compiler insert function calls that check whether the memory138 is accessible before each memory access. Slower than KASAN_INLINE, but139 does not bloat the size of the kernel's .text section so much.140 141config KASAN_INLINE142 bool "Inline instrumentation"143 depends on !ARCH_DISABLE_KASAN_INLINE144 help145 Makes the compiler directly insert memory accessibility checks before146 each memory access. Faster than KASAN_OUTLINE (gives ~x2 boost for147 some workloads), but makes the kernel's .text size much bigger.148 149endchoice150 151config KASAN_STACK152 bool "Stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST153 depends on KASAN_GENERIC || KASAN_SW_TAGS154 depends on !ARCH_DISABLE_KASAN_INLINE155 default y if CC_IS_GCC156 help157 Disables stack instrumentation and thus KASAN's ability to detect158 out-of-bounds bugs in stack variables.159 160 With Clang, stack instrumentation has a problem that causes excessive161 stack usage, see https://llvm.org/pr38809. Thus,162 with Clang, this option is deemed unsafe.163 164 This option is always disabled when compile-testing with Clang to165 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 via170 ARCH_DISABLE_KASAN_INLINE, stack instrumentation gets disabled171 as well, as it adds inline-style instrumentation that is run172 unconditionally.173 174config KASAN_VMALLOC175 bool "Check accesses to vmalloc allocations"176 depends on HAVE_ARCH_KASAN_VMALLOC177 help178 Makes KASAN check the validity of accesses to vmalloc allocations.179 180 With software KASAN modes, all types vmalloc allocations are181 checked. Enabling this option leads to higher memory usage.182 183 With Hardware Tag-Based KASAN, only non-executable VM_ALLOC mappings184 are checked. There is no additional memory usage.185 186config KASAN_KUNIT_TEST187 tristate "KUnit-compatible tests of KASAN bug detection capabilities" if !KUNIT_ALL_TESTS188 depends on KASAN && KUNIT && TRACEPOINTS189 default KUNIT_ALL_TESTS190 help191 A KUnit-based KASAN test suite. Triggers different kinds of192 out-of-bounds and use-after-free accesses. Useful for testing whether193 KASAN can detect certain bug types.194 195 For more information on KUnit and unit tests in general, please refer196 to the KUnit documentation in Documentation/dev-tools/kunit/.197 198config KASAN_MODULE_TEST199 tristate "KUnit-incompatible tests of KASAN bug detection capabilities"200 depends on m && KASAN && !KASAN_HW_TAGS201 help202 A part of the KASAN test suite that is not integrated with KUnit.203 Incompatible with Hardware Tag-Based KASAN.204 205config KASAN_EXTRA_INFO206 bool "Record and report more information"207 depends on KASAN208 help209 Record and report more information to help us find the cause of the210 bug and to help us correlate the error with other system events.211 212 Currently, the CPU number and timestamp are additionally213 recorded for each heap block at allocation and free time, and214 8 bytes will be added to each metadata structure that records215 allocation or free information.216 217 In Generic KASAN, each kmalloc-8 and kmalloc-16 object will add218 16 bytes of additional memory consumption, and each kmalloc-32219 object will add 8 bytes of additional memory consumption, not220 affecting other larger objects.221 222 In SW_TAGS KASAN and HW_TAGS KASAN, depending on the stack_ring_size223 boot parameter, it will add 8 * stack_ring_size bytes of additional224 memory consumption.225 226endif # KASAN227