linux/lib/Kconfig.kasan
<<
>>
Prefs
   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 CC_HAS_KASAN_GENERIC
  16        def_bool $(cc-option, -fsanitize=kernel-address)
  17
  18config 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.
  24config CC_HAS_WORKING_NOSANITIZE_ADDRESS
  25        def_bool !CC_IS_GCC || GCC_VERSION >= 80300
  26
  27menuconfig 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
  40if KASAN
  41
  42choice
  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
  59config 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
  79config 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
 102config 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
 115endchoice
 116
 117choice
 118        prompt "Instrumentation type"
 119        depends on KASAN_GENERIC || KASAN_SW_TAGS
 120        default KASAN_OUTLINE
 121
 122config 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
 131config 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
 139endchoice
 140
 141config KASAN_STACK
 142        bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
 143        depends on KASAN_GENERIC || KASAN_SW_TAGS
 144        default y if CC_IS_GCC
 145        help
 146          The LLVM stack address sanitizer has a know problem that
 147          causes excessive stack usage in a lot of functions, see
 148          https://bugs.llvm.org/show_bug.cgi?id=38809
 149          Disabling asan-stack makes it safe to run kernels build
 150          with clang-8 with KASAN enabled, though it loses some of
 151          the functionality.
 152          This feature is always disabled when compile-testing with clang
 153          to avoid cluttering the output in stack overflow warnings,
 154          but clang users can still enable it for builds without
 155          CONFIG_COMPILE_TEST.  On gcc it is assumed to always be safe
 156          to use and enabled by default.
 157
 158config KASAN_SW_TAGS_IDENTIFY
 159        bool "Enable memory corruption identification"
 160        depends on KASAN_SW_TAGS
 161        help
 162          This option enables best-effort identification of bug type
 163          (use-after-free or out-of-bounds) at the cost of increased
 164          memory consumption.
 165
 166config KASAN_VMALLOC
 167        bool "Back mappings in vmalloc space with real shadow memory"
 168        depends on KASAN_GENERIC && HAVE_ARCH_KASAN_VMALLOC
 169        help
 170          By default, the shadow region for vmalloc space is the read-only
 171          zero page. This means that KASAN cannot detect errors involving
 172          vmalloc space.
 173
 174          Enabling this option will hook in to vmap/vmalloc and back those
 175          mappings with real shadow memory allocated on demand. This allows
 176          for KASAN to detect more sorts of errors (and to support vmapped
 177          stacks), but at the cost of higher memory usage.
 178
 179config KASAN_KUNIT_TEST
 180        tristate "KUnit-compatible tests of KASAN bug detection capabilities" if !KUNIT_ALL_TESTS
 181        depends on KASAN && KUNIT
 182        default KUNIT_ALL_TESTS
 183        help
 184          This is a KUnit test suite doing various nasty things like
 185          out of bounds and use after free accesses. It is useful for testing
 186          kernel debugging features like KASAN.
 187
 188          For more information on KUnit and unit tests in general, please refer
 189          to the KUnit documentation in Documentation/dev-tools/kunit.
 190
 191config KASAN_MODULE_TEST
 192        tristate "KUnit-incompatible tests of KASAN bug detection capabilities"
 193        depends on m && KASAN && !KASAN_HW_TAGS
 194        help
 195          This is a part of the KASAN test suite that is incompatible with
 196          KUnit. Currently includes tests that do bad copy_from/to_user
 197          accesses.
 198
 199endif # KASAN
 200