lib/Kconfig.kasan

   1 # SPDX-License-Identifier: GPL-2.0-only
   2 # This config refers to the generic KASAN mode.
   3 config HAVE_ARCH_KASAN
   4         bool
   5
   6 config HAVE_ARCH_KASAN_SW_TAGS
   7         bool
   8
   9 config HAVE_ARCH_KASAN_HW_TAGS
  10         bool
  11
  12 config HAVE_ARCH_KASAN_VMALLOC
  13         bool
  14
  15 config CC_HAS_KASAN_GENERIC
  16         def_bool $(cc-option, -fsanitize=kernel-address)
  17
  18 config 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.
  24 config CC_HAS_WORKING_NOSANITIZE_ADDRESS
  25         def_bool !CC_IS_GCC || GCC_VERSION >= 80300
  26
  27 menuconfig 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
  40 if KASAN
  41
  42 choice
  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
  59 config 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
  79 config 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
 102 config 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
 115 endchoice
 116
 117 choice
 118         prompt "Instrumentation type"
 119         depends on KASAN_GENERIC || KASAN_SW_TAGS
 120         default KASAN_OUTLINE
 121
 122 config 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
 131 config 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
 139 endchoice
 140
 141 config 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
 157 config KASAN_STACK
 158         int
 159         default 1 if KASAN_STACK_ENABLE || CC_IS_GCC
 160         default 0
 161
 162 config KASAN_SW_TAGS_IDENTIFY
 163         bool "Enable memory corruption identification"
 164         depends on KASAN_SW_TAGS
 165         help
 166           This option enables best-effort identification of bug type
 167           (use-after-free or out-of-bounds) at the cost of increased
 168           memory consumption.
 169
 170 config KASAN_VMALLOC
 171         bool "Back mappings in vmalloc space with real shadow memory"
 172         depends on KASAN_GENERIC && HAVE_ARCH_KASAN_VMALLOC
 173         help
 174           By default, the shadow region for vmalloc space is the read-only
 175           zero page. This means that KASAN cannot detect errors involving
 176           vmalloc space.
 177
 178           Enabling this option will hook in to vmap/vmalloc and back those
 179           mappings with real shadow memory allocated on demand. This allows
 180           for KASAN to detect more sorts of errors (and to support vmapped
 181           stacks), but at the cost of higher memory usage.
 182
 183 config KASAN_KUNIT_TEST
 184         tristate "KUnit-compatible tests of KASAN bug detection capabilities" if !KUNIT_ALL_TESTS
 185         depends on KASAN && KUNIT
 186         default KUNIT_ALL_TESTS
 187         help
 188           This is a KUnit test suite doing various nasty things like
 189           out of bounds and use after free accesses. It is useful for testing
 190           kernel debugging features like KASAN.
 191
 192           For more information on KUnit and unit tests in general, please refer
 193           to the KUnit documentation in Documentation/dev-tools/kunit
 194
 195 config TEST_KASAN_MODULE
 196         tristate "KUnit-incompatible tests of KASAN bug detection capabilities"
 197         depends on m && KASAN
 198         help
 199           This is a part of the KASAN test suite that is incompatible with
 200           KUnit. Currently includes tests that do bad copy_from/to_user
 201           accesses.
 202
 203 endif # KASAN