Merge tag 'for-linus' of git://github.com/openrisc/linux
[platform/kernel/linux-rpi.git] / 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
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
158 config 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
166 config 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
179 config 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
191 config 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
199 endif # KASAN