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