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