| # 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 |
| An architecture might not support inline instrumentation. |
| When this option is selected, inline and stack instrumentation are |
| disabled. |
| |
| 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 |
| depends on CC_HAS_WORKING_NOSANITIZE_ADDRESS |
| 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 |
| depends on CC_HAS_WORKING_NOSANITIZE_ADDRESS |
| 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" |
| depends on !ARCH_DISABLE_KASAN_INLINE |
| 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 |
| depends on !ARCH_DISABLE_KASAN_INLINE |
| 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. |
| If the architecture disables inline instrumentation, stack |
| instrumentation is also disabled as it adds inline-style |
| instrumentation that is run unconditionally. |
| |
| 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_TAGS_IDENTIFY |
| bool "Enable memory corruption identification" |
| depends on KASAN_SW_TAGS || KASAN_HW_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 "Check accesses to vmalloc allocations" |
| depends on HAVE_ARCH_KASAN_VMALLOC |
| help |
| This mode makes KASAN check accesses to vmalloc allocations for |
| validity. |
| |
| With software KASAN modes, checking is done for all types of vmalloc |
| allocations. Enabling this option leads to higher memory usage. |
| |
| With hardware tag-based KASAN, only 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 |
| 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 |
