1# SPDX-License-Identifier: GPL-2.0-only 2menu "Kernel hardening options" 3 4menu "Memory initialization" 5 6config CC_HAS_AUTO_VAR_INIT_PATTERN 7 def_bool $(cc-option,-ftrivial-auto-var-init=pattern) 8 9config CC_HAS_AUTO_VAR_INIT_ZERO_BARE 10 def_bool $(cc-option,-ftrivial-auto-var-init=zero) 11 12config CC_HAS_AUTO_VAR_INIT_ZERO_ENABLER 13 # Clang 16 and later warn about using the -enable flag, but it 14 # is required before then. 15 def_bool $(cc-option,-ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang) 16 depends on !CC_HAS_AUTO_VAR_INIT_ZERO_BARE 17 18config CC_HAS_AUTO_VAR_INIT_ZERO 19 def_bool CC_HAS_AUTO_VAR_INIT_ZERO_BARE || CC_HAS_AUTO_VAR_INIT_ZERO_ENABLER 20 21choice 22 prompt "Initialize kernel stack variables at function entry" 23 default INIT_STACK_ALL_PATTERN if COMPILE_TEST && CC_HAS_AUTO_VAR_INIT_PATTERN 24 default INIT_STACK_ALL_ZERO if CC_HAS_AUTO_VAR_INIT_ZERO 25 default INIT_STACK_NONE 26 help 27 This option enables initialization of stack variables at 28 function entry time. This has the possibility to have the 29 greatest coverage (since all functions can have their 30 variables initialized), but the performance impact depends 31 on the function calling complexity of a given workload's 32 syscalls. 33 34 This chooses the level of coverage over classes of potentially 35 uninitialized variables. The selected class of variable will be 36 initialized before use in a function. 37 38 config INIT_STACK_NONE 39 bool "no automatic stack variable initialization (weakest)" 40 help 41 Disable automatic stack variable initialization. 42 This leaves the kernel vulnerable to the standard 43 classes of uninitialized stack variable exploits 44 and information exposures. 45 46 config INIT_STACK_ALL_PATTERN 47 bool "pattern-init everything (strongest)" 48 depends on CC_HAS_AUTO_VAR_INIT_PATTERN 49 depends on !KMSAN 50 help 51 Initializes everything on the stack (including padding) 52 with a specific debug value. This is intended to eliminate 53 all classes of uninitialized stack variable exploits and 54 information exposures, even variables that were warned about 55 having been left uninitialized. 56 57 Pattern initialization is known to provoke many existing bugs 58 related to uninitialized locals, e.g. pointers receive 59 non-NULL values, buffer sizes and indices are very big. The 60 pattern is situation-specific; Clang on 64-bit uses 0xAA 61 repeating for all types and padding except float and double 62 which use 0xFF repeating (-NaN). Clang on 32-bit uses 0xFF 63 repeating for all types and padding. 64 GCC uses 0xFE repeating for all types, and zero for padding. 65 66 config INIT_STACK_ALL_ZERO 67 bool "zero-init everything (strongest and safest)" 68 depends on CC_HAS_AUTO_VAR_INIT_ZERO 69 depends on !KMSAN 70 help 71 Initializes everything on the stack (including padding) 72 with a zero value. This is intended to eliminate all 73 classes of uninitialized stack variable exploits and 74 information exposures, even variables that were warned 75 about having been left uninitialized. 76 77 Zero initialization provides safe defaults for strings 78 (immediately NUL-terminated), pointers (NULL), indices 79 (index 0), and sizes (0 length), so it is therefore more 80 suitable as a production security mitigation than pattern 81 initialization. 82 83endchoice 84 85config CC_HAS_SANCOV_STACK_DEPTH_CALLBACK 86 def_bool $(cc-option,-fsanitize-coverage-stack-depth-callback-min=1) 87 88config KSTACK_ERASE 89 bool "Poison kernel stack before returning from syscalls" 90 depends on HAVE_ARCH_KSTACK_ERASE 91 depends on GCC_PLUGINS || CC_HAS_SANCOV_STACK_DEPTH_CALLBACK 92 help 93 This option makes the kernel erase the kernel stack before 94 returning from system calls. This has the effect of leaving 95 the stack initialized to the poison value, which both reduces 96 the lifetime of any sensitive stack contents and reduces 97 potential for uninitialized stack variable exploits or information 98 exposures (it does not cover functions reaching the same stack 99 depth as prior functions during the same syscall). This blocks 100 most uninitialized stack variable attacks, with the performance 101 impact being driven by the depth of the stack usage, rather than 102 the function calling complexity. 103 104 The performance impact on a single CPU system kernel compilation 105 sees a 1% slowdown, other systems and workloads may vary and you 106 are advised to test this feature on your expected workload before 107 deploying it. 108 109config GCC_PLUGIN_STACKLEAK 110 def_bool KSTACK_ERASE 111 depends on GCC_PLUGINS 112 help 113 This plugin was ported from grsecurity/PaX. More information at: 114 * https://grsecurity.net/ 115 * https://pax.grsecurity.net/ 116 117config GCC_PLUGIN_STACKLEAK_VERBOSE 118 bool "Report stack depth analysis instrumentation" if EXPERT 119 depends on GCC_PLUGIN_STACKLEAK 120 depends on !COMPILE_TEST # too noisy 121 help 122 This option will cause a warning to be printed each time the 123 stackleak plugin finds a function it thinks needs to be 124 instrumented. This is useful for comparing coverage between 125 builds. 126 127config KSTACK_ERASE_TRACK_MIN_SIZE 128 int "Minimum stack frame size of functions tracked by KSTACK_ERASE" 129 default 100 130 range 0 4096 131 depends on KSTACK_ERASE 132 help 133 The KSTACK_ERASE option instruments the kernel code for tracking 134 the lowest border of the kernel stack (and for some other purposes). 135 It inserts the __sanitizer_cov_stack_depth() call for the functions 136 with a stack frame size greater than or equal to this parameter. 137 If unsure, leave the default value 100. 138 139config KSTACK_ERASE_METRICS 140 bool "Show KSTACK_ERASE metrics in the /proc file system" 141 depends on KSTACK_ERASE 142 depends on PROC_FS 143 help 144 If this is set, KSTACK_ERASE metrics for every task are available 145 in the /proc file system. In particular, /proc/<pid>/stack_depth 146 shows the maximum kernel stack consumption for the current and 147 previous syscalls. Although this information is not precise, it 148 can be useful for estimating the KSTACK_ERASE performance impact 149 for your workloads. 150 151config KSTACK_ERASE_RUNTIME_DISABLE 152 bool "Allow runtime disabling of kernel stack erasing" 153 depends on KSTACK_ERASE 154 help 155 This option provides 'stack_erasing' sysctl, which can be used in 156 runtime to control kernel stack erasing for kernels built with 157 CONFIG_KSTACK_ERASE. 158 159config INIT_ON_ALLOC_DEFAULT_ON 160 bool "Enable heap memory zeroing on allocation by default" 161 depends on !KMSAN 162 help 163 This has the effect of setting "init_on_alloc=1" on the kernel 164 command line. This can be disabled with "init_on_alloc=0". 165 When "init_on_alloc" is enabled, all page allocator and slab 166 allocator memory will be zeroed when allocated, eliminating 167 many kinds of "uninitialized heap memory" flaws, especially 168 heap content exposures. The performance impact varies by 169 workload, but most cases see <1% impact. Some synthetic 170 workloads have measured as high as 7%. 171 172config INIT_ON_FREE_DEFAULT_ON 173 bool "Enable heap memory zeroing on free by default" 174 depends on !KMSAN 175 help 176 This has the effect of setting "init_on_free=1" on the kernel 177 command line. This can be disabled with "init_on_free=0". 178 Similar to "init_on_alloc", when "init_on_free" is enabled, 179 all page allocator and slab allocator memory will be zeroed 180 when freed, eliminating many kinds of "uninitialized heap memory" 181 flaws, especially heap content exposures. The primary difference 182 with "init_on_free" is that data lifetime in memory is reduced, 183 as anything freed is wiped immediately, making live forensics or 184 cold boot memory attacks unable to recover freed memory contents. 185 The performance impact varies by workload, but is more expensive 186 than "init_on_alloc" due to the negative cache effects of 187 touching "cold" memory areas. Most cases see 3-5% impact. Some 188 synthetic workloads have measured as high as 8%. 189 190config CC_HAS_ZERO_CALL_USED_REGS 191 # supported by gcc-11 or newer and all supported versions of clang 192 def_bool $(cc-option,-fzero-call-used-regs=used-gpr) 193 194config ZERO_CALL_USED_REGS 195 bool "Enable register zeroing on function exit" 196 depends on CC_HAS_ZERO_CALL_USED_REGS 197 help 198 At the end of functions, always zero any caller-used register 199 contents. This helps ensure that temporary values are not 200 leaked beyond the function boundary. This means that register 201 contents are less likely to be available for side channels 202 and information exposures. Additionally, this helps reduce the 203 number of useful ROP gadgets by about 20% (and removes compiler 204 generated "write-what-where" gadgets) in the resulting kernel 205 image. This has a less than 1% performance impact on most 206 workloads. Image size growth depends on architecture, and should 207 be evaluated for suitability. For example, x86_64 grows by less 208 than 1%, and arm64 grows by about 5%. 209 210endmenu 211 212menu "Bounds checking" 213 214config FORTIFY_SOURCE 215 bool "Harden common str/mem functions against buffer overflows" 216 depends on ARCH_HAS_FORTIFY_SOURCE 217 help 218 Detect overflows of buffers in common string and memory functions 219 where the compiler can determine and validate the buffer sizes. 220 221config HARDENED_USERCOPY 222 bool "Harden memory copies between kernel and userspace" 223 imply STRICT_DEVMEM 224 help 225 This option checks for obviously wrong memory regions when 226 copying memory to/from the kernel (via copy_to_user() and 227 copy_from_user() functions) by rejecting memory ranges that 228 are larger than the specified heap object, span multiple 229 separately allocated pages, are not on the process stack, 230 or are part of the kernel text. This prevents entire classes 231 of heap overflow exploits and similar kernel memory exposures. 232 233config HARDENED_USERCOPY_DEFAULT_ON 234 bool "Harden memory copies by default" 235 depends on HARDENED_USERCOPY 236 default HARDENED_USERCOPY 237 help 238 This has the effect of setting "hardened_usercopy=on" on the kernel 239 command line. This can be disabled with "hardened_usercopy=off". 240 241endmenu 242 243menu "Hardening of kernel data structures" 244 245config LIST_HARDENED 246 bool "Check integrity of linked list manipulation" 247 help 248 Minimal integrity checking in the linked-list manipulation routines 249 to catch memory corruptions that are not guaranteed to result in an 250 immediate access fault. 251 252 If unsure, say N. 253 254config RUST_BITMAP_HARDENED 255 bool "Check integrity of bitmap Rust API" 256 depends on RUST 257 help 258 Enables additional assertions in the Rust Bitmap API to catch 259 arguments that are not guaranteed to result in an immediate access 260 fault. 261 262 If unsure, say N. 263 264config BUG_ON_DATA_CORRUPTION 265 bool "Trigger a BUG when data corruption is detected" 266 select LIST_HARDENED 267 help 268 Select this option if the kernel should BUG when it encounters 269 data corruption in kernel memory structures when they get checked 270 for validity. 271 272 If unsure, say N. 273 274endmenu 275 276config CC_HAS_RANDSTRUCT 277 def_bool $(cc-option,-frandomize-layout-seed-file=/dev/null) 278 # Randstruct was first added in Clang 15, but it isn't safe to use until 279 # Clang 16 due to https://github.com/llvm/llvm-project/issues/60349 280 depends on !CC_IS_CLANG || CLANG_VERSION >= 160000 281 282choice 283 prompt "Randomize layout of sensitive kernel structures" 284 default RANDSTRUCT_FULL if COMPILE_TEST && (GCC_PLUGINS || CC_HAS_RANDSTRUCT) 285 default RANDSTRUCT_NONE 286 help 287 If you enable this, the layouts of structures that are entirely 288 function pointers (and have not been manually annotated with 289 __no_randomize_layout), or structures that have been explicitly 290 marked with __randomize_layout, will be randomized at compile-time. 291 This can introduce the requirement of an additional information 292 exposure vulnerability for exploits targeting these structure 293 types. 294 295 Enabling this feature will introduce some performance impact, 296 slightly increase memory usage, and prevent the use of forensic 297 tools like Volatility against the system (unless the kernel 298 source tree isn't cleaned after kernel installation). 299 300 The seed used for compilation is in scripts/basic/randomize.seed. 301 It remains after a "make clean" to allow for external modules to 302 be compiled with the existing seed and will be removed by a 303 "make mrproper" or "make distclean". This file should not be made 304 public, or the structure layout can be determined. 305 306 config RANDSTRUCT_NONE 307 bool "Disable structure layout randomization" 308 help 309 Build normally: no structure layout randomization. 310 311 config RANDSTRUCT_FULL 312 bool "Fully randomize structure layout" 313 depends on CC_HAS_RANDSTRUCT || GCC_PLUGINS 314 select MODVERSIONS if MODULES && !COMPILE_TEST 315 help 316 Fully randomize the member layout of sensitive 317 structures as much as possible, which may have both a 318 memory size and performance impact. 319 320 One difference between the Clang and GCC plugin 321 implementations is the handling of bitfields. The GCC 322 plugin treats them as fully separate variables, 323 introducing sometimes significant padding. Clang tries 324 to keep adjacent bitfields together, but with their bit 325 ordering randomized. 326 327 config RANDSTRUCT_PERFORMANCE 328 bool "Limit randomization of structure layout to cache-lines" 329 depends on GCC_PLUGINS 330 select MODVERSIONS if MODULES && !COMPILE_TEST 331 help 332 Randomization of sensitive kernel structures will make a 333 best effort at restricting randomization to cacheline-sized 334 groups of members. It will further not randomize bitfields 335 in structures. This reduces the performance hit of RANDSTRUCT 336 at the cost of weakened randomization. 337endchoice 338 339config RANDSTRUCT 340 def_bool !RANDSTRUCT_NONE 341 342config GCC_PLUGIN_RANDSTRUCT 343 def_bool GCC_PLUGINS && RANDSTRUCT 344 help 345 Use GCC plugin to randomize structure layout. 346 347 This plugin was ported from grsecurity/PaX. More 348 information at: 349 * https://grsecurity.net/ 350 * https://pax.grsecurity.net/ 351 352endmenu 353