1# SPDX-License-Identifier: GPL-2.0-only 2menu "Kernel hardening options" 3 4config 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 20menu "Memory initialization" 21 22config CC_HAS_AUTO_VAR_INIT_PATTERN 23 def_bool $(cc-option,-ftrivial-auto-var-init=pattern) 24 25config CC_HAS_AUTO_VAR_INIT_ZERO_BARE 26 def_bool $(cc-option,-ftrivial-auto-var-init=zero) 27 28config 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 34config CC_HAS_AUTO_VAR_INIT_ZERO 35 def_bool CC_HAS_AUTO_VAR_INIT_ZERO_BARE || CC_HAS_AUTO_VAR_INIT_ZERO_ENABLER 36 37choice 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 depends on GCC_PLUGINS 66 select GCC_PLUGIN_STRUCTLEAK 67 help 68 Zero-initialize any structures on the stack containing 69 a __user attribute. This can prevent some classes of 70 uninitialized stack variable exploits and information 71 exposures, like CVE-2013-2141: 72 https://git.kernel.org/linus/b9e146d8eb3b9eca 73 74 config GCC_PLUGIN_STRUCTLEAK_BYREF 75 bool "zero-init structs passed by reference (strong)" 76 depends on GCC_PLUGINS 77 depends on !(KASAN && KASAN_STACK=1) 78 select GCC_PLUGIN_STRUCTLEAK 79 help 80 Zero-initialize any structures on the stack that may 81 be passed by reference and had not already been 82 explicitly initialized. This can prevent most classes 83 of uninitialized stack variable exploits and information 84 exposures, like CVE-2017-1000410: 85 https://git.kernel.org/linus/06e7e776ca4d3654 86 87 As a side-effect, this keeps a lot of variables on the 88 stack that can otherwise be optimized out, so combining 89 this with CONFIG_KASAN_STACK can lead to a stack overflow 90 and is disallowed. 91 92 config GCC_PLUGIN_STRUCTLEAK_BYREF_ALL 93 bool "zero-init everything passed by reference (very strong)" 94 depends on GCC_PLUGINS 95 depends on !(KASAN && KASAN_STACK=1) 96 select GCC_PLUGIN_STRUCTLEAK 97 help 98 Zero-initialize any stack variables that may be passed 99 by reference and had not already been explicitly 100 initialized. This is intended to eliminate all classes 101 of uninitialized stack variable exploits and information 102 exposures. 103 104 As a side-effect, this keeps a lot of variables on the 105 stack that can otherwise be optimized out, so combining 106 this with CONFIG_KASAN_STACK can lead to a stack overflow 107 and is disallowed. 108 109 config INIT_STACK_ALL_PATTERN 110 bool "pattern-init everything (strongest)" 111 depends on CC_HAS_AUTO_VAR_INIT_PATTERN 112 help 113 Initializes everything on the stack (including padding) 114 with a specific debug value. This is intended to eliminate 115 all classes of uninitialized stack variable exploits and 116 information exposures, even variables that were warned about 117 having been left uninitialized. 118 119 Pattern initialization is known to provoke many existing bugs 120 related to uninitialized locals, e.g. pointers receive 121 non-NULL values, buffer sizes and indices are very big. The 122 pattern is situation-specific; Clang on 64-bit uses 0xAA 123 repeating for all types and padding except float and double 124 which use 0xFF repeating (-NaN). Clang on 32-bit uses 0xFF 125 repeating for all types and padding. 126 127 config INIT_STACK_ALL_ZERO 128 bool "zero-init everything (strongest and safest)" 129 depends on CC_HAS_AUTO_VAR_INIT_ZERO 130 help 131 Initializes everything on the stack (including padding) 132 with a zero value. This is intended to eliminate all 133 classes of uninitialized stack variable exploits and 134 information exposures, even variables that were warned 135 about having been left uninitialized. 136 137 Zero initialization provides safe defaults for strings 138 (immediately NUL-terminated), pointers (NULL), indices 139 (index 0), and sizes (0 length), so it is therefore more 140 suitable as a production security mitigation than pattern 141 initialization. 142 143endchoice 144 145config GCC_PLUGIN_STRUCTLEAK_VERBOSE 146 bool "Report forcefully initialized variables" 147 depends on GCC_PLUGIN_STRUCTLEAK 148 depends on !COMPILE_TEST # too noisy 149 help 150 This option will cause a warning to be printed each time the 151 structleak plugin finds a variable it thinks needs to be 152 initialized. Since not all existing initializers are detected 153 by the plugin, this can produce false positive warnings. 154 155config GCC_PLUGIN_STACKLEAK 156 bool "Poison kernel stack before returning from syscalls" 157 depends on GCC_PLUGINS 158 depends on HAVE_ARCH_STACKLEAK 159 help 160 This option makes the kernel erase the kernel stack before 161 returning from system calls. This has the effect of leaving 162 the stack initialized to the poison value, which both reduces 163 the lifetime of any sensitive stack contents and reduces 164 potential for uninitialized stack variable exploits or information 165 exposures (it does not cover functions reaching the same stack 166 depth as prior functions during the same syscall). This blocks 167 most uninitialized stack variable attacks, with the performance 168 impact being driven by the depth of the stack usage, rather than 169 the function calling complexity. 170 171 The performance impact on a single CPU system kernel compilation 172 sees a 1% slowdown, other systems and workloads may vary and you 173 are advised to test this feature on your expected workload before 174 deploying it. 175 176 This plugin was ported from grsecurity/PaX. More information at: 177 * https://grsecurity.net/ 178 * https://pax.grsecurity.net/ 179 180config STACKLEAK_TRACK_MIN_SIZE 181 int "Minimum stack frame size of functions tracked by STACKLEAK" 182 default 100 183 range 0 4096 184 depends on GCC_PLUGIN_STACKLEAK 185 help 186 The STACKLEAK gcc plugin instruments the kernel code for tracking 187 the lowest border of the kernel stack (and for some other purposes). 188 It inserts the stackleak_track_stack() call for the functions with 189 a stack frame size greater than or equal to this parameter. 190 If unsure, leave the default value 100. 191 192config STACKLEAK_METRICS 193 bool "Show STACKLEAK metrics in the /proc file system" 194 depends on GCC_PLUGIN_STACKLEAK 195 depends on PROC_FS 196 help 197 If this is set, STACKLEAK metrics for every task are available in 198 the /proc file system. In particular, /proc/<pid>/stack_depth 199 shows the maximum kernel stack consumption for the current and 200 previous syscalls. Although this information is not precise, it 201 can be useful for estimating the STACKLEAK performance impact for 202 your workloads. 203 204config STACKLEAK_RUNTIME_DISABLE 205 bool "Allow runtime disabling of kernel stack erasing" 206 depends on GCC_PLUGIN_STACKLEAK 207 help 208 This option provides 'stack_erasing' sysctl, which can be used in 209 runtime to control kernel stack erasing for kernels built with 210 CONFIG_GCC_PLUGIN_STACKLEAK. 211 212config INIT_ON_ALLOC_DEFAULT_ON 213 bool "Enable heap memory zeroing on allocation by default" 214 help 215 This has the effect of setting "init_on_alloc=1" on the kernel 216 command line. This can be disabled with "init_on_alloc=0". 217 When "init_on_alloc" is enabled, all page allocator and slab 218 allocator memory will be zeroed when allocated, eliminating 219 many kinds of "uninitialized heap memory" flaws, especially 220 heap content exposures. The performance impact varies by 221 workload, but most cases see <1% impact. Some synthetic 222 workloads have measured as high as 7%. 223 224config INIT_ON_FREE_DEFAULT_ON 225 bool "Enable heap memory zeroing on free by default" 226 help 227 This has the effect of setting "init_on_free=1" on the kernel 228 command line. This can be disabled with "init_on_free=0". 229 Similar to "init_on_alloc", when "init_on_free" is enabled, 230 all page allocator and slab allocator memory will be zeroed 231 when freed, eliminating many kinds of "uninitialized heap memory" 232 flaws, especially heap content exposures. The primary difference 233 with "init_on_free" is that data lifetime in memory is reduced, 234 as anything freed is wiped immediately, making live forensics or 235 cold boot memory attacks unable to recover freed memory contents. 236 The performance impact varies by workload, but is more expensive 237 than "init_on_alloc" due to the negative cache effects of 238 touching "cold" memory areas. Most cases see 3-5% impact. Some 239 synthetic workloads have measured as high as 8%. 240 241endmenu 242 243endmenu 244