1 # SPDX-License-Identifier: GPL-2.0-only
2 # This config refers to the generic KASAN mode.
6 config HAVE_ARCH_KASAN_SW_TAGS
9 config HAVE_ARCH_KASAN_VMALLOC
12 config CC_HAS_KASAN_GENERIC
13 def_bool $(cc-option, -fsanitize=kernel-address)
15 config CC_HAS_KASAN_SW_TAGS
16 def_bool $(cc-option, -fsanitize=kernel-hwaddress)
18 config CC_HAS_WORKING_NOSANITIZE_ADDRESS
19 def_bool !CC_IS_GCC || GCC_VERSION >= 80300
22 bool "KASAN: runtime memory debugger"
23 depends on (HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC) || \
24 (HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS)
25 depends on (SLUB && SYSFS) || (SLAB && !DEBUG_SLAB)
26 depends on CC_HAS_WORKING_NOSANITIZE_ADDRESS
28 Enables KASAN (KernelAddressSANitizer) - runtime memory debugger,
29 designed to find out-of-bounds accesses and use-after-free bugs.
30 See Documentation/dev-tools/kasan.rst for details.
37 KASAN has two modes: generic KASAN (similar to userspace ASan,
38 x86_64/arm64/xtensa, enabled with CONFIG_KASAN_GENERIC) and
39 software tag-based KASAN (a version based on software memory
40 tagging, arm64 only, similar to userspace HWASan, enabled with
41 CONFIG_KASAN_SW_TAGS).
42 Both generic and tag-based KASAN are strictly debugging features.
46 depends on HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC
47 depends on (SLUB && SYSFS) || (SLAB && !DEBUG_SLAB)
48 select SLUB_DEBUG if SLUB
52 Enables generic KASAN mode.
53 Supported in both GCC and Clang. With GCC it requires version 4.9.2
54 or later for basic support and version 5.0 or later for detection of
55 out-of-bounds accesses for stack and global variables and for inline
56 instrumentation mode (CONFIG_KASAN_INLINE). With Clang it requires
57 version 3.7.0 or later and it doesn't support detection of
58 out-of-bounds accesses for global variables yet.
59 This mode consumes about 1/8th of available memory at kernel start
60 and introduces an overhead of ~x1.5 for the rest of the allocations.
61 The performance slowdown is ~x3.
62 For better error detection enable CONFIG_STACKTRACE.
63 Currently CONFIG_KASAN_GENERIC doesn't work with CONFIG_DEBUG_SLAB
64 (the resulting kernel does not boot).
67 bool "Software tag-based mode"
68 depends on HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS
69 depends on (SLUB && SYSFS) || (SLAB && !DEBUG_SLAB)
70 select SLUB_DEBUG if SLUB
74 Enables software tag-based KASAN mode.
75 This mode requires Top Byte Ignore support by the CPU and therefore
76 is only supported for arm64.
77 This mode requires Clang version 7.0.0 or later.
78 This mode consumes about 1/16th of available memory at kernel start
79 and introduces an overhead of ~20% for the rest of the allocations.
80 This mode may potentially introduce problems relating to pointer
81 casting and comparison, as it embeds tags into the top byte of each
83 For better error detection enable CONFIG_STACKTRACE.
84 Currently CONFIG_KASAN_SW_TAGS doesn't work with CONFIG_DEBUG_SLAB
85 (the resulting kernel does not boot).
90 prompt "Instrumentation type"
95 bool "Outline instrumentation"
97 Before every memory access compiler insert function call
98 __asan_load*/__asan_store*. These functions performs check
99 of shadow memory. This is slower than inline instrumentation,
100 however it doesn't bloat size of kernel's .text section so
104 bool "Inline instrumentation"
106 Compiler directly inserts code checking shadow memory before
107 memory accesses. This is faster than outline (in some workloads
108 it gives about x2 boost over outline instrumentation), but
109 make kernel's .text size much bigger.
110 For CONFIG_KASAN_GENERIC this requires GCC 5.0 or later.
114 config KASAN_STACK_ENABLE
115 bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
118 The LLVM stack address sanitizer has a know problem that
119 causes excessive stack usage in a lot of functions, see
120 https://bugs.llvm.org/show_bug.cgi?id=38809
121 Disabling asan-stack makes it safe to run kernels build
122 with clang-8 with KASAN enabled, though it loses some of
124 This feature is always disabled when compile-testing with clang
125 to avoid cluttering the output in stack overflow warnings,
126 but clang users can still enable it for builds without
127 CONFIG_COMPILE_TEST. On gcc it is assumed to always be safe
128 to use and enabled by default.
132 default 1 if KASAN_STACK_ENABLE || CC_IS_GCC
135 config KASAN_S390_4_LEVEL_PAGING
136 bool "KASan: use 4-level paging"
137 depends on KASAN && S390
139 Compiling the kernel with KASan disables automatic 3-level vs
140 4-level paging selection. 3-level paging is used by default (up
141 to 3TB of RAM with KASan enabled). This options allows to force
142 4-level paging instead.
144 config KASAN_SW_TAGS_IDENTIFY
145 bool "Enable memory corruption identification"
146 depends on KASAN_SW_TAGS
148 This option enables best-effort identification of bug type
149 (use-after-free or out-of-bounds) at the cost of increased
153 bool "Back mappings in vmalloc space with real shadow memory"
154 depends on KASAN && HAVE_ARCH_KASAN_VMALLOC
156 By default, the shadow region for vmalloc space is the read-only
157 zero page. This means that KASAN cannot detect errors involving
160 Enabling this option will hook in to vmap/vmalloc and back those
161 mappings with real shadow memory allocated on demand. This allows
162 for KASAN to detect more sorts of errors (and to support vmapped
163 stacks), but at the cost of higher memory usage.
166 tristate "Module for testing KASAN for bug detection"
167 depends on m && KASAN
169 This is a test module doing various nasty things like
170 out of bounds accesses, use after free. It is useful for testing
171 kernel debugging features like KASAN.