lib/Kconfig.kasan - linux - Git at Google

 # SPDX-License-Identifier: GPL-2.0-only

 # This config refers to the generic KASAN mode.
 config HAVE_ARCH_KASAN
 	bool

 config HAVE_ARCH_KASAN_SW_TAGS
 	bool

 config HAVE_ARCH_KASAN_HW_TAGS
 	bool

 config HAVE_ARCH_KASAN_VMALLOC
 	bool

 config ARCH_DISABLE_KASAN_INLINE
 	bool
 	help
 	  Disables both inline and stack instrumentation. Selected by
 	  architectures that do not support these instrumentation types.

 config CC_HAS_KASAN_GENERIC
 	def_bool $(cc-option, -fsanitize=kernel-address)

 config CC_HAS_KASAN_SW_TAGS
 	def_bool $(cc-option, -fsanitize=kernel-hwaddress)

 # This option is only required for software KASAN modes.
 # Old GCC versions do not have proper support for no_sanitize_address.
 # See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89124 for details.
 config CC_HAS_WORKING_NOSANITIZE_ADDRESS
 	def_bool !CC_IS_GCC || GCC_VERSION >= 80300

 menuconfig KASAN
 	bool "KASAN: dynamic memory safety error detector"
 	depends on (((HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC) || \
 		     (HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS)) && \
 		    CC_HAS_WORKING_NOSANITIZE_ADDRESS) || \
 		   HAVE_ARCH_KASAN_HW_TAGS
 	depends on (SLUB && SYSFS && !SLUB_TINY) || (SLAB && !DEBUG_SLAB)
 	select STACKDEPOT_ALWAYS_INIT
 	help
 	  Enables KASAN (Kernel Address Sanitizer) - a dynamic memory safety
 	  error detector designed to find out-of-bounds and use-after-free bugs.

 	  See Documentation/dev-tools/kasan.rst for details.

 	  For better error reports, also enable CONFIG_STACKTRACE.

 if KASAN

 choice
 	prompt "KASAN mode"
 	default KASAN_GENERIC
 	help
 	  KASAN has three modes:

 	  1. Generic KASAN (supported by many architectures, enabled with
 	     CONFIG_KASAN_GENERIC, similar to userspace ASan),
 	  2. Software Tag-Based KASAN (arm64 only, based on software memory
 	     tagging, enabled with CONFIG_KASAN_SW_TAGS, similar to userspace
 	     HWASan), and
 	  3. Hardware Tag-Based KASAN (arm64 only, based on hardware memory
 	     tagging, enabled with CONFIG_KASAN_HW_TAGS).

 	  See Documentation/dev-tools/kasan.rst for details about each mode.

 config KASAN_GENERIC
 	bool "Generic KASAN"
 	depends on HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC
 	depends on CC_HAS_WORKING_NOSANITIZE_ADDRESS
 	select SLUB_DEBUG if SLUB
 	select CONSTRUCTORS
 	help
 	  Enables Generic KASAN.

 	  Requires GCC 8.3.0+ or Clang.

 	  Consumes about 1/8th of available memory at kernel start and adds an
 	  overhead of ~50% for dynamic allocations.
 	  The performance slowdown is ~x3.

 	  (Incompatible with CONFIG_DEBUG_SLAB: the kernel does not boot.)

 config KASAN_SW_TAGS
 	bool "Software Tag-Based KASAN"
 	depends on HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS
 	depends on CC_HAS_WORKING_NOSANITIZE_ADDRESS
 	select SLUB_DEBUG if SLUB
 	select CONSTRUCTORS
 	help
 	  Enables Software Tag-Based KASAN.

 	  Requires GCC 11+ or Clang.

 	  Supported only on arm64 CPUs and relies on Top Byte Ignore.

 	  Consumes about 1/16th of available memory at kernel start and
 	  add an overhead of ~20% for dynamic allocations.

 	  May potentially introduce problems related to pointer casting and
 	  comparison, as it embeds a tag into the top byte of each pointer.

 	  (Incompatible with CONFIG_DEBUG_SLAB: the kernel does not boot.)

 config KASAN_HW_TAGS
 	bool "Hardware Tag-Based KASAN"
 	depends on HAVE_ARCH_KASAN_HW_TAGS
 	depends on SLUB
 	help
 	  Enables Hardware Tag-Based KASAN.

 	  Requires GCC 10+ or Clang 12+.

 	  Supported only on arm64 CPUs starting from ARMv8.5 and relies on
 	  Memory Tagging Extension and Top Byte Ignore.

 	  Consumes about 1/32nd of available memory.

 	  May potentially introduce problems related to pointer casting and
 	  comparison, as it embeds a tag into the top byte of each pointer.

 endchoice

 choice
 	prompt "Instrumentation type"
 	depends on KASAN_GENERIC || KASAN_SW_TAGS
 	default KASAN_OUTLINE

 config KASAN_OUTLINE
 	bool "Outline instrumentation"
 	help
 	  Makes the compiler insert function calls that check whether the memory
 	  is accessible before each memory access. Slower than KASAN_INLINE, but
 	  does not bloat the size of the kernel's .text section so much.

 config KASAN_INLINE
 	bool "Inline instrumentation"
 	depends on !ARCH_DISABLE_KASAN_INLINE
 	help
 	  Makes the compiler directly insert memory accessibility checks before
 	  each memory access. Faster than KASAN_OUTLINE (gives ~x2 boost for
 	  some workloads), but makes the kernel's .text size much bigger.

 endchoice

 config KASAN_STACK
 	bool "Stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
 	depends on KASAN_GENERIC || KASAN_SW_TAGS
 	depends on !ARCH_DISABLE_KASAN_INLINE
 	default y if CC_IS_GCC
 	help
 	  Disables stack instrumentation and thus KASAN's ability to detect
 	  out-of-bounds bugs in stack variables.

 	  With Clang, stack instrumentation has a problem that causes excessive
 	  stack usage, see https://bugs.llvm.org/show_bug.cgi?id=38809. Thus,
 	  with Clang, this option is deemed unsafe.

 	  This option is always disabled when compile-testing with Clang to
 	  avoid cluttering the log with stack overflow warnings.

 	  With GCC, enabling stack instrumentation is assumed to be safe.

 	  If the architecture disables inline instrumentation via
 	  ARCH_DISABLE_KASAN_INLINE, stack instrumentation gets disabled
 	  as well, as it adds inline-style instrumentation that is run
 	  unconditionally.

 config KASAN_VMALLOC
 	bool "Check accesses to vmalloc allocations"
 	depends on HAVE_ARCH_KASAN_VMALLOC
 	help
 	  Makes KASAN check the validity of accesses to vmalloc allocations.

 	  With software KASAN modes, all types vmalloc allocations are
 	  checked. Enabling this option leads to higher memory usage.

 	  With Hardware Tag-Based KASAN, only non-executable VM_ALLOC mappings
 	  are checked. There is no additional memory usage.

 config KASAN_KUNIT_TEST
 	tristate "KUnit-compatible tests of KASAN bug detection capabilities" if !KUNIT_ALL_TESTS
 	depends on KASAN && KUNIT && TRACEPOINTS
 	default KUNIT_ALL_TESTS
 	help
 	  A KUnit-based KASAN test suite. Triggers different kinds of
 	  out-of-bounds and use-after-free accesses. Useful for testing whether
 	  KASAN can detect certain bug types.

 	  For more information on KUnit and unit tests in general, please refer
 	  to the KUnit documentation in Documentation/dev-tools/kunit/.

 config KASAN_MODULE_TEST
 	tristate "KUnit-incompatible tests of KASAN bug detection capabilities"
 	depends on m && KASAN && !KASAN_HW_TAGS
 	help
 	  A part of the KASAN test suite that is not integrated with KUnit.
 	  Incompatible with Hardware Tag-Based KASAN.

 endif # KASAN
	# SPDX-License-Identifier: GPL-2.0-only

	# This config refers to the generic KASAN mode.
	config HAVE_ARCH_KASAN
	bool

	config HAVE_ARCH_KASAN_SW_TAGS
	bool

	config HAVE_ARCH_KASAN_HW_TAGS
	bool

	config HAVE_ARCH_KASAN_VMALLOC
	bool

	config ARCH_DISABLE_KASAN_INLINE
	bool
	help
	Disables both inline and stack instrumentation. Selected by
	architectures that do not support these instrumentation types.

	config CC_HAS_KASAN_GENERIC
	def_bool $(cc-option, -fsanitize=kernel-address)

	config CC_HAS_KASAN_SW_TAGS
	def_bool $(cc-option, -fsanitize=kernel-hwaddress)

	# This option is only required for software KASAN modes.
	# Old GCC versions do not have proper support for no_sanitize_address.
	# See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89124 for details.
	config CC_HAS_WORKING_NOSANITIZE_ADDRESS
	def_bool !CC_IS_GCC \|\| GCC_VERSION >= 80300

	menuconfig KASAN
	bool "KASAN: dynamic memory safety error detector"
	depends on (((HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC) \|\| \
	(HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS)) && \
	CC_HAS_WORKING_NOSANITIZE_ADDRESS) \|\| \
	HAVE_ARCH_KASAN_HW_TAGS
	depends on (SLUB && SYSFS && !SLUB_TINY) \|\| (SLAB && !DEBUG_SLAB)
	select STACKDEPOT_ALWAYS_INIT
	help
	Enables KASAN (Kernel Address Sanitizer) - a dynamic memory safety
	error detector designed to find out-of-bounds and use-after-free bugs.

	See Documentation/dev-tools/kasan.rst for details.

	For better error reports, also enable CONFIG_STACKTRACE.

	if KASAN

	choice
	prompt "KASAN mode"
	default KASAN_GENERIC
	help
	KASAN has three modes:

	1. Generic KASAN (supported by many architectures, enabled with
	CONFIG_KASAN_GENERIC, similar to userspace ASan),
	2. Software Tag-Based KASAN (arm64 only, based on software memory
	tagging, enabled with CONFIG_KASAN_SW_TAGS, similar to userspace
	HWASan), and
	3. Hardware Tag-Based KASAN (arm64 only, based on hardware memory
	tagging, enabled with CONFIG_KASAN_HW_TAGS).

	See Documentation/dev-tools/kasan.rst for details about each mode.

	config KASAN_GENERIC
	bool "Generic KASAN"
	depends on HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC
	depends on CC_HAS_WORKING_NOSANITIZE_ADDRESS
	select SLUB_DEBUG if SLUB
	select CONSTRUCTORS
	help
	Enables Generic KASAN.

	Requires GCC 8.3.0+ or Clang.

	Consumes about 1/8th of available memory at kernel start and adds an
	overhead of ~50% for dynamic allocations.
	The performance slowdown is ~x3.

	(Incompatible with CONFIG_DEBUG_SLAB: the kernel does not boot.)

	config KASAN_SW_TAGS
	bool "Software Tag-Based KASAN"
	depends on HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS
	depends on CC_HAS_WORKING_NOSANITIZE_ADDRESS
	select SLUB_DEBUG if SLUB
	select CONSTRUCTORS
	help
	Enables Software Tag-Based KASAN.

	Requires GCC 11+ or Clang.

	Supported only on arm64 CPUs and relies on Top Byte Ignore.

	Consumes about 1/16th of available memory at kernel start and
	add an overhead of ~20% for dynamic allocations.

	May potentially introduce problems related to pointer casting and
	comparison, as it embeds a tag into the top byte of each pointer.

	(Incompatible with CONFIG_DEBUG_SLAB: the kernel does not boot.)

	config KASAN_HW_TAGS
	bool "Hardware Tag-Based KASAN"
	depends on HAVE_ARCH_KASAN_HW_TAGS
	depends on SLUB
	help
	Enables Hardware Tag-Based KASAN.

	Requires GCC 10+ or Clang 12+.

	Supported only on arm64 CPUs starting from ARMv8.5 and relies on
	Memory Tagging Extension and Top Byte Ignore.

	Consumes about 1/32nd of available memory.

	May potentially introduce problems related to pointer casting and
	comparison, as it embeds a tag into the top byte of each pointer.

	endchoice

	choice
	prompt "Instrumentation type"
	depends on KASAN_GENERIC \|\| KASAN_SW_TAGS
	default KASAN_OUTLINE

	config KASAN_OUTLINE
	bool "Outline instrumentation"
	help
	Makes the compiler insert function calls that check whether the memory
	is accessible before each memory access. Slower than KASAN_INLINE, but
	does not bloat the size of the kernel's .text section so much.

	config KASAN_INLINE
	bool "Inline instrumentation"
	depends on !ARCH_DISABLE_KASAN_INLINE
	help
	Makes the compiler directly insert memory accessibility checks before
	each memory access. Faster than KASAN_OUTLINE (gives ~x2 boost for
	some workloads), but makes the kernel's .text size much bigger.

	endchoice

	config KASAN_STACK
	bool "Stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
	depends on KASAN_GENERIC \|\| KASAN_SW_TAGS
	depends on !ARCH_DISABLE_KASAN_INLINE
	default y if CC_IS_GCC
	help
	Disables stack instrumentation and thus KASAN's ability to detect
	out-of-bounds bugs in stack variables.

	With Clang, stack instrumentation has a problem that causes excessive
	stack usage, see https://bugs.llvm.org/show_bug.cgi?id=38809. Thus,
	with Clang, this option is deemed unsafe.

	This option is always disabled when compile-testing with Clang to
	avoid cluttering the log with stack overflow warnings.

	With GCC, enabling stack instrumentation is assumed to be safe.

	If the architecture disables inline instrumentation via
	ARCH_DISABLE_KASAN_INLINE, stack instrumentation gets disabled
	as well, as it adds inline-style instrumentation that is run
	unconditionally.

	config KASAN_VMALLOC
	bool "Check accesses to vmalloc allocations"
	depends on HAVE_ARCH_KASAN_VMALLOC
	help
	Makes KASAN check the validity of accesses to vmalloc allocations.

	With software KASAN modes, all types vmalloc allocations are
	checked. Enabling this option leads to higher memory usage.

	With Hardware Tag-Based KASAN, only non-executable VM_ALLOC mappings
	are checked. There is no additional memory usage.

	config KASAN_KUNIT_TEST
	tristate "KUnit-compatible tests of KASAN bug detection capabilities" if !KUNIT_ALL_TESTS
	depends on KASAN && KUNIT && TRACEPOINTS
	default KUNIT_ALL_TESTS
	help
	A KUnit-based KASAN test suite. Triggers different kinds of
	out-of-bounds and use-after-free accesses. Useful for testing whether
	KASAN can detect certain bug types.

	For more information on KUnit and unit tests in general, please refer
	to the KUnit documentation in Documentation/dev-tools/kunit/.

	config KASAN_MODULE_TEST
	tristate "KUnit-incompatible tests of KASAN bug detection capabilities"
	depends on m && KASAN && !KASAN_HW_TAGS
	help
	A part of the KASAN test suite that is not integrated with KUnit.
	Incompatible with Hardware Tag-Based KASAN.

	endif # KASAN