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 depends on !KMSAN 110 help 111 Initializes everything on the stack (including padding) 112 with a specific debug value. This is intended to eliminate 113 all classes of uninitialized stack variable exploits and 114 information exposures, even variables that were warned about 115 having been left uninitialized. 116 117 Pattern initialization is known to provoke many existing bugs 118 related to uninitialized locals, e.g. pointers receive 119 non-NULL values, buffer sizes and indices are very big. The 120 pattern is situation-specific; Clang on 64-bit uses 0xAA 121 repeating for all types and padding except float and double 122 which use 0xFF repeating (-NaN). Clang on 32-bit uses 0xFF 123 repeating for all types and padding. 124 125 config INIT_STACK_ALL_ZERO 126 bool "zero-init everything (strongest and safest)" 127 depends on CC_HAS_AUTO_VAR_INIT_ZERO 128 depends on !KMSAN 129 help 130 Initializes everything on the stack (including padding) 131 with a zero value. This is intended to eliminate all 132 classes of uninitialized stack variable exploits and 133 information exposures, even variables that were warned 134 about having been left uninitialized. 135 136 Zero initialization provides safe defaults for strings 137 (immediately NUL-terminated), pointers (NULL), indices 138 (index 0), and sizes (0 length), so it is therefore more 139 suitable as a production security mitigation than pattern 140 initialization. 141 142endchoice 143 144config GCC_PLUGIN_STRUCTLEAK_VERBOSE 145 bool "Report forcefully initialized variables" 146 depends on GCC_PLUGIN_STRUCTLEAK 147 depends on !COMPILE_TEST # too noisy 148 help 149 This option will cause a warning to be printed each time the 150 structleak plugin finds a variable it thinks needs to be 151 initialized. Since not all existing initializers are detected 152 by the plugin, this can produce false positive warnings. 153 154config GCC_PLUGIN_STACKLEAK 155 bool "Poison kernel stack before returning from syscalls" 156 depends on GCC_PLUGINS 157 depends on HAVE_ARCH_STACKLEAK 158 help 159 This option makes the kernel erase the kernel stack before 160 returning from system calls. This has the effect of leaving 161 the stack initialized to the poison value, which both reduces 162 the lifetime of any sensitive stack contents and reduces 163 potential for uninitialized stack variable exploits or information 164 exposures (it does not cover functions reaching the same stack 165 depth as prior functions during the same syscall). This blocks 166 most uninitialized stack variable attacks, with the performance 167 impact being driven by the depth of the stack usage, rather than 168 the function calling complexity. 169 170 The performance impact on a single CPU system kernel compilation 171 sees a 1% slowdown, other systems and workloads may vary and you 172 are advised to test this feature on your expected workload before 173 deploying it. 174 175 This plugin was ported from grsecurity/PaX. More information at: 176 * https://grsecurity.net/ 177 * https://pax.grsecurity.net/ 178 179config GCC_PLUGIN_STACKLEAK_VERBOSE 180 bool "Report stack depth analysis instrumentation" if EXPERT 181 depends on GCC_PLUGIN_STACKLEAK 182 depends on !COMPILE_TEST # too noisy 183 help 184 This option will cause a warning to be printed each time the 185 stackleak plugin finds a function it thinks needs to be 186 instrumented. This is useful for comparing coverage between 187 builds. 188 189config STACKLEAK_TRACK_MIN_SIZE 190 int "Minimum stack frame size of functions tracked by STACKLEAK" 191 default 100 192 range 0 4096 193 depends on GCC_PLUGIN_STACKLEAK 194 help 195 The STACKLEAK gcc plugin instruments the kernel code for tracking 196 the lowest border of the kernel stack (and for some other purposes). 197 It inserts the stackleak_track_stack() call for the functions with 198 a stack frame size greater than or equal to this parameter. 199 If unsure, leave the default value 100. 200 201config STACKLEAK_METRICS 202 bool "Show STACKLEAK metrics in the /proc file system" 203 depends on GCC_PLUGIN_STACKLEAK 204 depends on PROC_FS 205 help 206 If this is set, STACKLEAK metrics for every task are available in 207 the /proc file system. In particular, /proc/<pid>/stack_depth 208 shows the maximum kernel stack consumption for the current and 209 previous syscalls. Although this information is not precise, it 210 can be useful for estimating the STACKLEAK performance impact for 211 your workloads. 212 213config STACKLEAK_RUNTIME_DISABLE 214 bool "Allow runtime disabling of kernel stack erasing" 215 depends on GCC_PLUGIN_STACKLEAK 216 help 217 This option provides 'stack_erasing' sysctl, which can be used in 218 runtime to control kernel stack erasing for kernels built with 219 CONFIG_GCC_PLUGIN_STACKLEAK. 220 221config INIT_ON_ALLOC_DEFAULT_ON 222 bool "Enable heap memory zeroing on allocation by default" 223 depends on !KMSAN 224 help 225 This has the effect of setting "init_on_alloc=1" on the kernel 226 command line. This can be disabled with "init_on_alloc=0". 227 When "init_on_alloc" is enabled, all page allocator and slab 228 allocator memory will be zeroed when allocated, eliminating 229 many kinds of "uninitialized heap memory" flaws, especially 230 heap content exposures. The performance impact varies by 231 workload, but most cases see <1% impact. Some synthetic 232 workloads have measured as high as 7%. 233 234config INIT_ON_FREE_DEFAULT_ON 235 bool "Enable heap memory zeroing on free by default" 236 depends on !KMSAN 237 help 238 This has the effect of setting "init_on_free=1" on the kernel 239 command line. This can be disabled with "init_on_free=0". 240 Similar to "init_on_alloc", when "init_on_free" is enabled, 241 all page allocator and slab allocator memory will be zeroed 242 when freed, eliminating many kinds of "uninitialized heap memory" 243 flaws, especially heap content exposures. The primary difference 244 with "init_on_free" is that data lifetime in memory is reduced, 245 as anything freed is wiped immediately, making live forensics or 246 cold boot memory attacks unable to recover freed memory contents. 247 The performance impact varies by workload, but is more expensive 248 than "init_on_alloc" due to the negative cache effects of 249 touching "cold" memory areas. Most cases see 3-5% impact. Some 250 synthetic workloads have measured as high as 8%. 251 252config CC_HAS_ZERO_CALL_USED_REGS 253 def_bool $(cc-option,-fzero-call-used-regs=used-gpr) 254 255config ZERO_CALL_USED_REGS 256 bool "Enable register zeroing on function exit" 257 depends on CC_HAS_ZERO_CALL_USED_REGS 258 help 259 At the end of functions, always zero any caller-used register 260 contents. This helps ensure that temporary values are not 261 leaked beyond the function boundary. This means that register 262 contents are less likely to be available for side channels 263 and information exposures. Additionally, this helps reduce the 264 number of useful ROP gadgets by about 20% (and removes compiler 265 generated "write-what-where" gadgets) in the resulting kernel 266 image. This has a less than 1% performance impact on most 267 workloads. Image size growth depends on architecture, and should 268 be evaluated for suitability. For example, x86_64 grows by less 269 than 1%, and arm64 grows by about 5%. 270 271endmenu 272 273config CC_HAS_RANDSTRUCT 274 def_bool $(cc-option,-frandomize-layout-seed-file=/dev/null) 275 276choice 277 prompt "Randomize layout of sensitive kernel structures" 278 default RANDSTRUCT_FULL if COMPILE_TEST && (GCC_PLUGINS || CC_HAS_RANDSTRUCT) 279 default RANDSTRUCT_NONE 280 help 281 If you enable this, the layouts of structures that are entirely 282 function pointers (and have not been manually annotated with 283 __no_randomize_layout), or structures that have been explicitly 284 marked with __randomize_layout, will be randomized at compile-time. 285 This can introduce the requirement of an additional information 286 exposure vulnerability for exploits targeting these structure 287 types. 288 289 Enabling this feature will introduce some performance impact, 290 slightly increase memory usage, and prevent the use of forensic 291 tools like Volatility against the system (unless the kernel 292 source tree isn't cleaned after kernel installation). 293 294 The seed used for compilation is in scripts/basic/randomize.seed. 295 It remains after a "make clean" to allow for external modules to 296 be compiled with the existing seed and will be removed by a 297 "make mrproper" or "make distclean". This file should not be made 298 public, or the structure layout can be determined. 299 300 config RANDSTRUCT_NONE 301 bool "Disable structure layout randomization" 302 help 303 Build normally: no structure layout randomization. 304 305 config RANDSTRUCT_FULL 306 bool "Fully randomize structure layout" 307 depends on CC_HAS_RANDSTRUCT || GCC_PLUGINS 308 select MODVERSIONS if MODULES 309 help 310 Fully randomize the member layout of sensitive 311 structures as much as possible, which may have both a 312 memory size and performance impact. 313 314 One difference between the Clang and GCC plugin 315 implementations is the handling of bitfields. The GCC 316 plugin treats them as fully separate variables, 317 introducing sometimes significant padding. Clang tries 318 to keep adjacent bitfields together, but with their bit 319 ordering randomized. 320 321 config RANDSTRUCT_PERFORMANCE 322 bool "Limit randomization of structure layout to cache-lines" 323 depends on GCC_PLUGINS 324 select MODVERSIONS if MODULES 325 help 326 Randomization of sensitive kernel structures will make a 327 best effort at restricting randomization to cacheline-sized 328 groups of members. It will further not randomize bitfields 329 in structures. This reduces the performance hit of RANDSTRUCT 330 at the cost of weakened randomization. 331endchoice 332 333config RANDSTRUCT 334 def_bool !RANDSTRUCT_NONE 335 336config GCC_PLUGIN_RANDSTRUCT 337 def_bool GCC_PLUGINS && RANDSTRUCT 338 help 339 Use GCC plugin to randomize structure layout. 340 341 This plugin was ported from grsecurity/PaX. More 342 information at: 343 * https://grsecurity.net/ 344 * https://pax.grsecurity.net/ 345 346endmenu 347