Merge tag 'net-next-6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev...
[platform/kernel/linux-starfive.git] / security / Kconfig.hardening
1 # SPDX-License-Identifier: GPL-2.0-only
2 menu "Kernel hardening options"
3
4 config GCC_PLUGIN_STRUCTLEAK
5         bool
6         help
7           While the kernel is built with warnings enabled for any missed
8           stack variable initializations, this warning is silenced for
9           anything passed by reference to another function, under the
10           occasionally misguided assumption that the function will do
11           the initialization. As this regularly leads to exploitable
12           flaws, this plugin is available to identify and zero-initialize
13           such variables, depending on the chosen level of coverage.
14
15           This plugin was originally ported from grsecurity/PaX. More
16           information at:
17            * https://grsecurity.net/
18            * https://pax.grsecurity.net/
19
20 menu "Memory initialization"
21
22 config CC_HAS_AUTO_VAR_INIT_PATTERN
23         def_bool $(cc-option,-ftrivial-auto-var-init=pattern)
24
25 config CC_HAS_AUTO_VAR_INIT_ZERO_BARE
26         def_bool $(cc-option,-ftrivial-auto-var-init=zero)
27
28 config CC_HAS_AUTO_VAR_INIT_ZERO_ENABLER
29         # Clang 16 and later warn about using the -enable flag, but it
30         # is required before then.
31         def_bool $(cc-option,-ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang)
32         depends on !CC_HAS_AUTO_VAR_INIT_ZERO_BARE
33
34 config CC_HAS_AUTO_VAR_INIT_ZERO
35         def_bool CC_HAS_AUTO_VAR_INIT_ZERO_BARE || CC_HAS_AUTO_VAR_INIT_ZERO_ENABLER
36
37 choice
38         prompt "Initialize kernel stack variables at function entry"
39         default GCC_PLUGIN_STRUCTLEAK_BYREF_ALL if COMPILE_TEST && GCC_PLUGINS
40         default INIT_STACK_ALL_PATTERN if COMPILE_TEST && CC_HAS_AUTO_VAR_INIT_PATTERN
41         default INIT_STACK_ALL_ZERO if CC_HAS_AUTO_VAR_INIT_ZERO
42         default INIT_STACK_NONE
43         help
44           This option enables initialization of stack variables at
45           function entry time. This has the possibility to have the
46           greatest coverage (since all functions can have their
47           variables initialized), but the performance impact depends
48           on the function calling complexity of a given workload's
49           syscalls.
50
51           This chooses the level of coverage over classes of potentially
52           uninitialized variables. The selected class of variable will be
53           initialized before use in a function.
54
55         config INIT_STACK_NONE
56                 bool "no automatic stack variable initialization (weakest)"
57                 help
58                   Disable automatic stack variable initialization.
59                   This leaves the kernel vulnerable to the standard
60                   classes of uninitialized stack variable exploits
61                   and information exposures.
62
63         config GCC_PLUGIN_STRUCTLEAK_USER
64                 bool "zero-init structs marked for userspace (weak)"
65                 # Plugin can be removed once the kernel only supports GCC 12+
66                 depends on GCC_PLUGINS && !CC_HAS_AUTO_VAR_INIT_ZERO
67                 select GCC_PLUGIN_STRUCTLEAK
68                 help
69                   Zero-initialize any structures on the stack containing
70                   a __user attribute. This can prevent some classes of
71                   uninitialized stack variable exploits and information
72                   exposures, like CVE-2013-2141:
73                   https://git.kernel.org/linus/b9e146d8eb3b9eca
74
75         config GCC_PLUGIN_STRUCTLEAK_BYREF
76                 bool "zero-init structs passed by reference (strong)"
77                 # Plugin can be removed once the kernel only supports GCC 12+
78                 depends on GCC_PLUGINS && !CC_HAS_AUTO_VAR_INIT_ZERO
79                 depends on !(KASAN && KASAN_STACK)
80                 select GCC_PLUGIN_STRUCTLEAK
81                 help
82                   Zero-initialize any structures on the stack that may
83                   be passed by reference and had not already been
84                   explicitly initialized. This can prevent most classes
85                   of uninitialized stack variable exploits and information
86                   exposures, like CVE-2017-1000410:
87                   https://git.kernel.org/linus/06e7e776ca4d3654
88
89                   As a side-effect, this keeps a lot of variables on the
90                   stack that can otherwise be optimized out, so combining
91                   this with CONFIG_KASAN_STACK can lead to a stack overflow
92                   and is disallowed.
93
94         config GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
95                 bool "zero-init everything passed by reference (very strong)"
96                 # Plugin can be removed once the kernel only supports GCC 12+
97                 depends on GCC_PLUGINS && !CC_HAS_AUTO_VAR_INIT_ZERO
98                 depends on !(KASAN && KASAN_STACK)
99                 select GCC_PLUGIN_STRUCTLEAK
100                 help
101                   Zero-initialize any stack variables that may be passed
102                   by reference and had not already been explicitly
103                   initialized. This is intended to eliminate all classes
104                   of uninitialized stack variable exploits and information
105                   exposures.
106
107                   As a side-effect, this keeps a lot of variables on the
108                   stack that can otherwise be optimized out, so combining
109                   this with CONFIG_KASAN_STACK can lead to a stack overflow
110                   and is disallowed.
111
112         config INIT_STACK_ALL_PATTERN
113                 bool "pattern-init everything (strongest)"
114                 depends on CC_HAS_AUTO_VAR_INIT_PATTERN
115                 help
116                   Initializes everything on the stack (including padding)
117                   with a specific debug value. This is intended to eliminate
118                   all classes of uninitialized stack variable exploits and
119                   information exposures, even variables that were warned about
120                   having been left uninitialized.
121
122                   Pattern initialization is known to provoke many existing bugs
123                   related to uninitialized locals, e.g. pointers receive
124                   non-NULL values, buffer sizes and indices are very big. The
125                   pattern is situation-specific; Clang on 64-bit uses 0xAA
126                   repeating for all types and padding except float and double
127                   which use 0xFF repeating (-NaN). Clang on 32-bit uses 0xFF
128                   repeating for all types and padding.
129
130         config INIT_STACK_ALL_ZERO
131                 bool "zero-init everything (strongest and safest)"
132                 depends on CC_HAS_AUTO_VAR_INIT_ZERO
133                 help
134                   Initializes everything on the stack (including padding)
135                   with a zero value. This is intended to eliminate all
136                   classes of uninitialized stack variable exploits and
137                   information exposures, even variables that were warned
138                   about having been left uninitialized.
139
140                   Zero initialization provides safe defaults for strings
141                   (immediately NUL-terminated), pointers (NULL), indices
142                   (index 0), and sizes (0 length), so it is therefore more
143                   suitable as a production security mitigation than pattern
144                   initialization.
145
146 endchoice
147
148 config GCC_PLUGIN_STRUCTLEAK_VERBOSE
149         bool "Report forcefully initialized variables"
150         depends on GCC_PLUGIN_STRUCTLEAK
151         depends on !COMPILE_TEST        # too noisy
152         help
153           This option will cause a warning to be printed each time the
154           structleak plugin finds a variable it thinks needs to be
155           initialized. Since not all existing initializers are detected
156           by the plugin, this can produce false positive warnings.
157
158 config GCC_PLUGIN_STACKLEAK
159         bool "Poison kernel stack before returning from syscalls"
160         depends on GCC_PLUGINS
161         depends on HAVE_ARCH_STACKLEAK
162         help
163           This option makes the kernel erase the kernel stack before
164           returning from system calls. This has the effect of leaving
165           the stack initialized to the poison value, which both reduces
166           the lifetime of any sensitive stack contents and reduces
167           potential for uninitialized stack variable exploits or information
168           exposures (it does not cover functions reaching the same stack
169           depth as prior functions during the same syscall). This blocks
170           most uninitialized stack variable attacks, with the performance
171           impact being driven by the depth of the stack usage, rather than
172           the function calling complexity.
173
174           The performance impact on a single CPU system kernel compilation
175           sees a 1% slowdown, other systems and workloads may vary and you
176           are advised to test this feature on your expected workload before
177           deploying it.
178
179           This plugin was ported from grsecurity/PaX. More information at:
180            * https://grsecurity.net/
181            * https://pax.grsecurity.net/
182
183 config GCC_PLUGIN_STACKLEAK_VERBOSE
184         bool "Report stack depth analysis instrumentation" if EXPERT
185         depends on GCC_PLUGIN_STACKLEAK
186         depends on !COMPILE_TEST        # too noisy
187         help
188           This option will cause a warning to be printed each time the
189           stackleak plugin finds a function it thinks needs to be
190           instrumented. This is useful for comparing coverage between
191           builds.
192
193 config STACKLEAK_TRACK_MIN_SIZE
194         int "Minimum stack frame size of functions tracked by STACKLEAK"
195         default 100
196         range 0 4096
197         depends on GCC_PLUGIN_STACKLEAK
198         help
199           The STACKLEAK gcc plugin instruments the kernel code for tracking
200           the lowest border of the kernel stack (and for some other purposes).
201           It inserts the stackleak_track_stack() call for the functions with
202           a stack frame size greater than or equal to this parameter.
203           If unsure, leave the default value 100.
204
205 config STACKLEAK_METRICS
206         bool "Show STACKLEAK metrics in the /proc file system"
207         depends on GCC_PLUGIN_STACKLEAK
208         depends on PROC_FS
209         help
210           If this is set, STACKLEAK metrics for every task are available in
211           the /proc file system. In particular, /proc/<pid>/stack_depth
212           shows the maximum kernel stack consumption for the current and
213           previous syscalls. Although this information is not precise, it
214           can be useful for estimating the STACKLEAK performance impact for
215           your workloads.
216
217 config STACKLEAK_RUNTIME_DISABLE
218         bool "Allow runtime disabling of kernel stack erasing"
219         depends on GCC_PLUGIN_STACKLEAK
220         help
221           This option provides 'stack_erasing' sysctl, which can be used in
222           runtime to control kernel stack erasing for kernels built with
223           CONFIG_GCC_PLUGIN_STACKLEAK.
224
225 config INIT_ON_ALLOC_DEFAULT_ON
226         bool "Enable heap memory zeroing on allocation by default"
227         help
228           This has the effect of setting "init_on_alloc=1" on the kernel
229           command line. This can be disabled with "init_on_alloc=0".
230           When "init_on_alloc" is enabled, all page allocator and slab
231           allocator memory will be zeroed when allocated, eliminating
232           many kinds of "uninitialized heap memory" flaws, especially
233           heap content exposures. The performance impact varies by
234           workload, but most cases see <1% impact. Some synthetic
235           workloads have measured as high as 7%.
236
237 config INIT_ON_FREE_DEFAULT_ON
238         bool "Enable heap memory zeroing on free by default"
239         help
240           This has the effect of setting "init_on_free=1" on the kernel
241           command line. This can be disabled with "init_on_free=0".
242           Similar to "init_on_alloc", when "init_on_free" is enabled,
243           all page allocator and slab allocator memory will be zeroed
244           when freed, eliminating many kinds of "uninitialized heap memory"
245           flaws, especially heap content exposures. The primary difference
246           with "init_on_free" is that data lifetime in memory is reduced,
247           as anything freed is wiped immediately, making live forensics or
248           cold boot memory attacks unable to recover freed memory contents.
249           The performance impact varies by workload, but is more expensive
250           than "init_on_alloc" due to the negative cache effects of
251           touching "cold" memory areas. Most cases see 3-5% impact. Some
252           synthetic workloads have measured as high as 8%.
253
254 config CC_HAS_ZERO_CALL_USED_REGS
255         def_bool $(cc-option,-fzero-call-used-regs=used-gpr)
256
257 config ZERO_CALL_USED_REGS
258         bool "Enable register zeroing on function exit"
259         depends on CC_HAS_ZERO_CALL_USED_REGS
260         help
261           At the end of functions, always zero any caller-used register
262           contents. This helps ensure that temporary values are not
263           leaked beyond the function boundary. This means that register
264           contents are less likely to be available for side channels
265           and information exposures. Additionally, this helps reduce the
266           number of useful ROP gadgets by about 20% (and removes compiler
267           generated "write-what-where" gadgets) in the resulting kernel
268           image. This has a less than 1% performance impact on most
269           workloads. Image size growth depends on architecture, and should
270           be evaluated for suitability. For example, x86_64 grows by less
271           than 1%, and arm64 grows by about 5%.
272
273 endmenu
274
275 config CC_HAS_RANDSTRUCT
276         def_bool $(cc-option,-frandomize-layout-seed-file=/dev/null)
277
278 choice
279         prompt "Randomize layout of sensitive kernel structures"
280         default RANDSTRUCT_FULL if COMPILE_TEST && (GCC_PLUGINS || CC_HAS_RANDSTRUCT)
281         default RANDSTRUCT_NONE
282         help
283           If you enable this, the layouts of structures that are entirely
284           function pointers (and have not been manually annotated with
285           __no_randomize_layout), or structures that have been explicitly
286           marked with __randomize_layout, will be randomized at compile-time.
287           This can introduce the requirement of an additional information
288           exposure vulnerability for exploits targeting these structure
289           types.
290
291           Enabling this feature will introduce some performance impact,
292           slightly increase memory usage, and prevent the use of forensic
293           tools like Volatility against the system (unless the kernel
294           source tree isn't cleaned after kernel installation).
295
296           The seed used for compilation is in scripts/basic/randomize.seed.
297           It remains after a "make clean" to allow for external modules to
298           be compiled with the existing seed and will be removed by a
299           "make mrproper" or "make distclean". This file should not be made
300           public, or the structure layout can be determined.
301
302         config RANDSTRUCT_NONE
303                 bool "Disable structure layout randomization"
304                 help
305                   Build normally: no structure layout randomization.
306
307         config RANDSTRUCT_FULL
308                 bool "Fully randomize structure layout"
309                 depends on CC_HAS_RANDSTRUCT || GCC_PLUGINS
310                 select MODVERSIONS if MODULES
311                 help
312                   Fully randomize the member layout of sensitive
313                   structures as much as possible, which may have both a
314                   memory size and performance impact.
315
316                   One difference between the Clang and GCC plugin
317                   implementations is the handling of bitfields. The GCC
318                   plugin treats them as fully separate variables,
319                   introducing sometimes significant padding. Clang tries
320                   to keep adjacent bitfields together, but with their bit
321                   ordering randomized.
322
323         config RANDSTRUCT_PERFORMANCE
324                 bool "Limit randomization of structure layout to cache-lines"
325                 depends on GCC_PLUGINS
326                 select MODVERSIONS if MODULES
327                 help
328                   Randomization of sensitive kernel structures will make a
329                   best effort at restricting randomization to cacheline-sized
330                   groups of members. It will further not randomize bitfields
331                   in structures. This reduces the performance hit of RANDSTRUCT
332                   at the cost of weakened randomization.
333 endchoice
334
335 config RANDSTRUCT
336         def_bool !RANDSTRUCT_NONE
337
338 config GCC_PLUGIN_RANDSTRUCT
339         def_bool GCC_PLUGINS && RANDSTRUCT
340         help
341           Use GCC plugin to randomize structure layout.
342
343           This plugin was ported from grsecurity/PaX. More
344           information at:
345            * https://grsecurity.net/
346            * https://pax.grsecurity.net/
347
348 endmenu