123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208 |
- # 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 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 don't 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: runtime memory debugger"
- 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) || (SLAB && !DEBUG_SLAB)
- select STACKDEPOT
- help
- Enables KASAN (KernelAddressSANitizer) - runtime memory debugger,
- designed to find out-of-bounds accesses and use-after-free bugs.
- See Documentation/dev-tools/kasan.rst for details.
- if KASAN
- choice
- prompt "KASAN mode"
- default KASAN_GENERIC
- help
- KASAN has three modes:
- 1. generic KASAN (similar to userspace ASan,
- x86_64/arm64/xtensa, enabled with CONFIG_KASAN_GENERIC),
- 2. software tag-based KASAN (arm64 only, based on software
- memory tagging (similar to userspace HWASan), enabled with
- CONFIG_KASAN_SW_TAGS), and
- 3. hardware tag-based KASAN (arm64 only, based on hardware
- memory tagging, enabled with CONFIG_KASAN_HW_TAGS).
- All KASAN modes are strictly debugging features.
- For better error reports enable CONFIG_STACKTRACE.
- config KASAN_GENERIC
- bool "Generic mode"
- depends on HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC
- select SLUB_DEBUG if SLUB
- select CONSTRUCTORS
- help
- Enables generic KASAN mode.
- This mode is supported in both GCC and Clang. With GCC it requires
- version 8.3.0 or later. Any supported Clang version is compatible,
- but detection of out-of-bounds accesses for global variables is
- supported only since Clang 11.
- This mode consumes about 1/8th of available memory at kernel start
- and introduces an overhead of ~x1.5 for the rest of the allocations.
- The performance slowdown is ~x3.
- Currently CONFIG_KASAN_GENERIC doesn't work with CONFIG_DEBUG_SLAB
- (the resulting kernel does not boot).
- config KASAN_SW_TAGS
- bool "Software tag-based mode"
- depends on HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS
- select SLUB_DEBUG if SLUB
- select CONSTRUCTORS
- help
- Enables software tag-based KASAN mode.
- This mode require software memory tagging support in the form of
- HWASan-like compiler instrumentation.
- Currently this mode is only implemented for arm64 CPUs and relies on
- Top Byte Ignore. This mode requires Clang.
- This mode consumes about 1/16th of available memory at kernel start
- and introduces an overhead of ~20% for the rest of the allocations.
- This mode may potentially introduce problems relating to pointer
- casting and comparison, as it embeds tags into the top byte of each
- pointer.
- Currently CONFIG_KASAN_SW_TAGS doesn't work with CONFIG_DEBUG_SLAB
- (the resulting kernel does not boot).
- config KASAN_HW_TAGS
- bool "Hardware tag-based mode"
- depends on HAVE_ARCH_KASAN_HW_TAGS
- depends on SLUB
- help
- Enables hardware tag-based KASAN mode.
- This mode requires hardware memory tagging support, and can be used
- by any architecture that provides it.
- Currently this mode is only implemented for arm64 CPUs starting from
- ARMv8.5 and relies on Memory Tagging Extension and Top Byte Ignore.
- endchoice
- choice
- prompt "Instrumentation type"
- depends on KASAN_GENERIC || KASAN_SW_TAGS
- default KASAN_OUTLINE
- config KASAN_OUTLINE
- bool "Outline instrumentation"
- help
- Before every memory access compiler insert function call
- __asan_load*/__asan_store*. These functions performs check
- of shadow memory. This is slower than inline instrumentation,
- however it doesn't bloat size of kernel's .text section so
- much as inline does.
- config KASAN_INLINE
- bool "Inline instrumentation"
- help
- Compiler directly inserts code checking shadow memory before
- memory accesses. This is faster than outline (in some workloads
- it gives about x2 boost over outline instrumentation), but
- make kernel's .text size much bigger.
- endchoice
- config KASAN_STACK
- bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
- depends on KASAN_GENERIC || KASAN_SW_TAGS
- default y if CC_IS_GCC
- help
- The LLVM stack address sanitizer has a know problem that
- causes excessive stack usage in a lot of functions, see
- https://bugs.llvm.org/show_bug.cgi?id=38809
- Disabling asan-stack makes it safe to run kernels build
- with clang-8 with KASAN enabled, though it loses some of
- the functionality.
- This feature is always disabled when compile-testing with clang
- to avoid cluttering the output in stack overflow warnings,
- but clang users can still enable it for builds without
- CONFIG_COMPILE_TEST. On gcc it is assumed to always be safe
- to use and enabled by default.
- config KASAN_S390_4_LEVEL_PAGING
- bool "KASan: use 4-level paging"
- depends on S390
- help
- Compiling the kernel with KASan disables automatic 3-level vs
- 4-level paging selection. 3-level paging is used by default (up
- to 3TB of RAM with KASan enabled). This options allows to force
- 4-level paging instead.
- config KASAN_SW_TAGS_IDENTIFY
- bool "Enable memory corruption identification"
- depends on KASAN_SW_TAGS
- help
- This option enables best-effort identification of bug type
- (use-after-free or out-of-bounds) at the cost of increased
- memory consumption.
- config KASAN_VMALLOC
- bool "Back mappings in vmalloc space with real shadow memory"
- depends on KASAN_GENERIC && HAVE_ARCH_KASAN_VMALLOC
- help
- By default, the shadow region for vmalloc space is the read-only
- zero page. This means that KASAN cannot detect errors involving
- vmalloc space.
- Enabling this option will hook in to vmap/vmalloc and back those
- mappings with real shadow memory allocated on demand. This allows
- for KASAN to detect more sorts of errors (and to support vmapped
- stacks), but at the cost of higher memory usage.
- config KASAN_KUNIT_TEST
- tristate "KUnit-compatible tests of KASAN bug detection capabilities" if !KUNIT_ALL_TESTS
- depends on KASAN && KUNIT
- default KUNIT_ALL_TESTS
- help
- This is a KUnit test suite doing various nasty things like
- out of bounds and use after free accesses. It is useful for testing
- kernel debugging features like KASAN.
- 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
- This is a part of the KASAN test suite that is incompatible with
- KUnit. Currently includes tests that do bad copy_from/to_user
- accesses.
- endif # KASAN
|