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