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 26 # GCC ignores the -enable flag, so we can test for the feature with 27 # a single invocation using the flag, but drop it as appropriate in 28 # the Makefile, depending on the presence of Clang. 29 def_bool $(cc-option,-ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang) 30 31choice 32 prompt "Initialize kernel stack variables at function entry" 33 default GCC_PLUGIN_STRUCTLEAK_BYREF_ALL if COMPILE_TEST && GCC_PLUGINS 34 default INIT_STACK_ALL_PATTERN if COMPILE_TEST && CC_HAS_AUTO_VAR_INIT_PATTERN 35 default INIT_STACK_ALL_ZERO if CC_HAS_AUTO_VAR_INIT_ZERO 36 default INIT_STACK_NONE 37 help 38 This option enables initialization of stack variables at 39 function entry time. This has the possibility to have the 40 greatest coverage (since all functions can have their 41 variables initialized), but the performance impact depends 42 on the function calling complexity of a given workload's 43 syscalls. 44 45 This chooses the level of coverage over classes of potentially 46 uninitialized variables. The selected class of variable will be 47 initialized before use in a function. 48 49 config INIT_STACK_NONE 50 bool "no automatic stack variable initialization (weakest)" 51 help 52 Disable automatic stack variable initialization. 53 This leaves the kernel vulnerable to the standard 54 classes of uninitialized stack variable exploits 55 and information exposures. 56 57 config GCC_PLUGIN_STRUCTLEAK_USER 58 bool "zero-init structs marked for userspace (weak)" 59 depends on GCC_PLUGINS 60 select GCC_PLUGIN_STRUCTLEAK 61 help 62 Zero-initialize any structures on the stack containing 63 a __user attribute. This can prevent some classes of 64 uninitialized stack variable exploits and information 65 exposures, like CVE-2013-2141: 66 https://git.kernel.org/linus/b9e146d8eb3b9eca 67 68 config GCC_PLUGIN_STRUCTLEAK_BYREF 69 bool "zero-init structs passed by reference (strong)" 70 depends on GCC_PLUGINS 71 depends on !(KASAN && KASAN_STACK) 72 select GCC_PLUGIN_STRUCTLEAK 73 help 74 Zero-initialize any structures on the stack that may 75 be passed by reference and had not already been 76 explicitly initialized. This can prevent most classes 77 of uninitialized stack variable exploits and information 78 exposures, like CVE-2017-1000410: 79 https://git.kernel.org/linus/06e7e776ca4d3654 80 81 As a side-effect, this keeps a lot of variables on the 82 stack that can otherwise be optimized out, so combining 83 this with CONFIG_KASAN_STACK can lead to a stack overflow 84 and is disallowed. 85 86 config GCC_PLUGIN_STRUCTLEAK_BYREF_ALL 87 bool "zero-init everything passed by reference (very strong)" 88 depends on GCC_PLUGINS 89 depends on !(KASAN && KASAN_STACK) 90 select GCC_PLUGIN_STRUCTLEAK 91 help 92 Zero-initialize any stack variables that may be passed 93 by reference and had not already been explicitly 94 initialized. This is intended to eliminate all classes 95 of uninitialized stack variable exploits and information 96 exposures. 97 98 As a side-effect, this keeps a lot of variables on the 99 stack that can otherwise be optimized out, so combining 100 this with CONFIG_KASAN_STACK can lead to a stack overflow 101 and is disallowed. 102 103 config INIT_STACK_ALL_PATTERN 104 bool "pattern-init everything (strongest)" 105 depends on CC_HAS_AUTO_VAR_INIT_PATTERN 106 help 107 Initializes everything on the stack (including padding) 108 with a specific debug value. This is intended to eliminate 109 all classes of uninitialized stack variable exploits and 110 information exposures, even variables that were warned about 111 having been left uninitialized. 112 113 Pattern initialization is known to provoke many existing bugs 114 related to uninitialized locals, e.g. pointers receive 115 non-NULL values, buffer sizes and indices are very big. The 116 pattern is situation-specific; Clang on 64-bit uses 0xAA 117 repeating for all types and padding except float and double 118 which use 0xFF repeating (-NaN). Clang on 32-bit uses 0xFF 119 repeating for all types and padding. 120 121 config INIT_STACK_ALL_ZERO 122 bool "zero-init everything (strongest and safest)" 123 depends on CC_HAS_AUTO_VAR_INIT_ZERO 124 help 125 Initializes everything on the stack (including padding) 126 with a zero value. This is intended to eliminate all 127 classes of uninitialized stack variable exploits and 128 information exposures, even variables that were warned 129 about having been left uninitialized. 130 131 Zero initialization provides safe defaults for strings 132 (immediately NUL-terminated), pointers (NULL), indices 133 (index 0), and sizes (0 length), so it is therefore more 134 suitable as a production security mitigation than pattern 135 initialization. 136 137endchoice 138 139config GCC_PLUGIN_STRUCTLEAK_VERBOSE 140 bool "Report forcefully initialized variables" 141 depends on GCC_PLUGIN_STRUCTLEAK 142 depends on !COMPILE_TEST # too noisy 143 help 144 This option will cause a warning to be printed each time the 145 structleak plugin finds a variable it thinks needs to be 146 initialized. Since not all existing initializers are detected 147 by the plugin, this can produce false positive warnings. 148 149config GCC_PLUGIN_STACKLEAK 150 bool "Poison kernel stack before returning from syscalls" 151 depends on GCC_PLUGINS 152 depends on HAVE_ARCH_STACKLEAK 153 help 154 This option makes the kernel erase the kernel stack before 155 returning from system calls. This has the effect of leaving 156 the stack initialized to the poison value, which both reduces 157 the lifetime of any sensitive stack contents and reduces 158 potential for uninitialized stack variable exploits or information 159 exposures (it does not cover functions reaching the same stack 160 depth as prior functions during the same syscall). This blocks 161 most uninitialized stack variable attacks, with the performance 162 impact being driven by the depth of the stack usage, rather than 163 the function calling complexity. 164 165 The performance impact on a single CPU system kernel compilation 166 sees a 1% slowdown, other systems and workloads may vary and you 167 are advised to test this feature on your expected workload before 168 deploying it. 169 170 This plugin was ported from grsecurity/PaX. More information at: 171 * https://grsecurity.net/ 172 * https://pax.grsecurity.net/ 173 174config STACKLEAK_TRACK_MIN_SIZE 175 int "Minimum stack frame size of functions tracked by STACKLEAK" 176 default 100 177 range 0 4096 178 depends on GCC_PLUGIN_STACKLEAK 179 help 180 The STACKLEAK gcc plugin instruments the kernel code for tracking 181 the lowest border of the kernel stack (and for some other purposes). 182 It inserts the stackleak_track_stack() call for the functions with 183 a stack frame size greater than or equal to this parameter. 184 If unsure, leave the default value 100. 185 186config STACKLEAK_METRICS 187 bool "Show STACKLEAK metrics in the /proc file system" 188 depends on GCC_PLUGIN_STACKLEAK 189 depends on PROC_FS 190 help 191 If this is set, STACKLEAK metrics for every task are available in 192 the /proc file system. In particular, /proc/<pid>/stack_depth 193 shows the maximum kernel stack consumption for the current and 194 previous syscalls. Although this information is not precise, it 195 can be useful for estimating the STACKLEAK performance impact for 196 your workloads. 197 198config STACKLEAK_RUNTIME_DISABLE 199 bool "Allow runtime disabling of kernel stack erasing" 200 depends on GCC_PLUGIN_STACKLEAK 201 help 202 This option provides 'stack_erasing' sysctl, which can be used in 203 runtime to control kernel stack erasing for kernels built with 204 CONFIG_GCC_PLUGIN_STACKLEAK. 205 206config INIT_ON_ALLOC_DEFAULT_ON 207 bool "Enable heap memory zeroing on allocation by default" 208 help 209 This has the effect of setting "init_on_alloc=1" on the kernel 210 command line. This can be disabled with "init_on_alloc=0". 211 When "init_on_alloc" is enabled, all page allocator and slab 212 allocator memory will be zeroed when allocated, eliminating 213 many kinds of "uninitialized heap memory" flaws, especially 214 heap content exposures. The performance impact varies by 215 workload, but most cases see <1% impact. Some synthetic 216 workloads have measured as high as 7%. 217 218config INIT_ON_FREE_DEFAULT_ON 219 bool "Enable heap memory zeroing on free by default" 220 help 221 This has the effect of setting "init_on_free=1" on the kernel 222 command line. This can be disabled with "init_on_free=0". 223 Similar to "init_on_alloc", when "init_on_free" is enabled, 224 all page allocator and slab allocator memory will be zeroed 225 when freed, eliminating many kinds of "uninitialized heap memory" 226 flaws, especially heap content exposures. The primary difference 227 with "init_on_free" is that data lifetime in memory is reduced, 228 as anything freed is wiped immediately, making live forensics or 229 cold boot memory attacks unable to recover freed memory contents. 230 The performance impact varies by workload, but is more expensive 231 than "init_on_alloc" due to the negative cache effects of 232 touching "cold" memory areas. Most cases see 3-5% impact. Some 233 synthetic workloads have measured as high as 8%. 234 235config CC_HAS_ZERO_CALL_USED_REGS 236 def_bool $(cc-option,-fzero-call-used-regs=used-gpr) 237 238config ZERO_CALL_USED_REGS 239 bool "Enable register zeroing on function exit" 240 depends on CC_HAS_ZERO_CALL_USED_REGS 241 help 242 At the end of functions, always zero any caller-used register 243 contents. This helps ensure that temporary values are not 244 leaked beyond the function boundary. This means that register 245 contents are less likely to be available for side channels 246 and information exposures. Additionally, this helps reduce the 247 number of useful ROP gadgets by about 20% (and removes compiler 248 generated "write-what-where" gadgets) in the resulting kernel 249 image. This has a less than 1% performance impact on most 250 workloads. Image size growth depends on architecture, and should 251 be evaluated for suitability. For example, x86_64 grows by less 252 than 1%, and arm64 grows by about 5%. 253 254endmenu 255 256endmenu 257