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
214