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