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 GCC_PLUGIN_STACKLEAK_VERBOSE 178 bool "Report stack depth analysis instrumentation" if EXPERT 179 depends on GCC_PLUGIN_STACKLEAK 180 depends on !COMPILE_TEST # too noisy 181 help 182 This option will cause a warning to be printed each time the 183 stackleak plugin finds a function it thinks needs to be 184 instrumented. This is useful for comparing coverage between 185 builds. 186 187config STACKLEAK_TRACK_MIN_SIZE 188 int "Minimum stack frame size of functions tracked by STACKLEAK" 189 default 100 190 range 0 4096 191 depends on GCC_PLUGIN_STACKLEAK 192 help 193 The STACKLEAK gcc plugin instruments the kernel code for tracking 194 the lowest border of the kernel stack (and for some other purposes). 195 It inserts the stackleak_track_stack() call for the functions with 196 a stack frame size greater than or equal to this parameter. 197 If unsure, leave the default value 100. 198 199config STACKLEAK_METRICS 200 bool "Show STACKLEAK metrics in the /proc file system" 201 depends on GCC_PLUGIN_STACKLEAK 202 depends on PROC_FS 203 help 204 If this is set, STACKLEAK metrics for every task are available in 205 the /proc file system. In particular, /proc/<pid>/stack_depth 206 shows the maximum kernel stack consumption for the current and 207 previous syscalls. Although this information is not precise, it 208 can be useful for estimating the STACKLEAK performance impact for 209 your workloads. 210 211config STACKLEAK_RUNTIME_DISABLE 212 bool "Allow runtime disabling of kernel stack erasing" 213 depends on GCC_PLUGIN_STACKLEAK 214 help 215 This option provides 'stack_erasing' sysctl, which can be used in 216 runtime to control kernel stack erasing for kernels built with 217 CONFIG_GCC_PLUGIN_STACKLEAK. 218 219config INIT_ON_ALLOC_DEFAULT_ON 220 bool "Enable heap memory zeroing on allocation by default" 221 help 222 This has the effect of setting "init_on_alloc=1" on the kernel 223 command line. This can be disabled with "init_on_alloc=0". 224 When "init_on_alloc" is enabled, all page allocator and slab 225 allocator memory will be zeroed when allocated, eliminating 226 many kinds of "uninitialized heap memory" flaws, especially 227 heap content exposures. The performance impact varies by 228 workload, but most cases see <1% impact. Some synthetic 229 workloads have measured as high as 7%. 230 231config INIT_ON_FREE_DEFAULT_ON 232 bool "Enable heap memory zeroing on free by default" 233 help 234 This has the effect of setting "init_on_free=1" on the kernel 235 command line. This can be disabled with "init_on_free=0". 236 Similar to "init_on_alloc", when "init_on_free" is enabled, 237 all page allocator and slab allocator memory will be zeroed 238 when freed, eliminating many kinds of "uninitialized heap memory" 239 flaws, especially heap content exposures. The primary difference 240 with "init_on_free" is that data lifetime in memory is reduced, 241 as anything freed is wiped immediately, making live forensics or 242 cold boot memory attacks unable to recover freed memory contents. 243 The performance impact varies by workload, but is more expensive 244 than "init_on_alloc" due to the negative cache effects of 245 touching "cold" memory areas. Most cases see 3-5% impact. Some 246 synthetic workloads have measured as high as 8%. 247 248config CC_HAS_ZERO_CALL_USED_REGS 249 def_bool $(cc-option,-fzero-call-used-regs=used-gpr) 250 251config ZERO_CALL_USED_REGS 252 bool "Enable register zeroing on function exit" 253 depends on CC_HAS_ZERO_CALL_USED_REGS 254 help 255 At the end of functions, always zero any caller-used register 256 contents. This helps ensure that temporary values are not 257 leaked beyond the function boundary. This means that register 258 contents are less likely to be available for side channels 259 and information exposures. Additionally, this helps reduce the 260 number of useful ROP gadgets by about 20% (and removes compiler 261 generated "write-what-where" gadgets) in the resulting kernel 262 image. This has a less than 1% performance impact on most 263 workloads. Image size growth depends on architecture, and should 264 be evaluated for suitability. For example, x86_64 grows by less 265 than 1%, and arm64 grows by about 5%. 266 267endmenu 268 269endmenu 270