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 KSTACK_ERASE 86 bool "Poison kernel stack before returning from syscalls" 87 depends on HAVE_ARCH_KSTACK_ERASE 88 depends on GCC_PLUGINS 89 help 90 This option makes the kernel erase the kernel stack before 91 returning from system calls. This has the effect of leaving 92 the stack initialized to the poison value, which both reduces 93 the lifetime of any sensitive stack contents and reduces 94 potential for uninitialized stack variable exploits or information 95 exposures (it does not cover functions reaching the same stack 96 depth as prior functions during the same syscall). This blocks 97 most uninitialized stack variable attacks, with the performance 98 impact being driven by the depth of the stack usage, rather than 99 the function calling complexity. 100 101 The performance impact on a single CPU system kernel compilation 102 sees a 1% slowdown, other systems and workloads may vary and you 103 are advised to test this feature on your expected workload before 104 deploying it. 105 106config GCC_PLUGIN_STACKLEAK 107 def_bool KSTACK_ERASE 108 depends on GCC_PLUGINS 109 help 110 This plugin was ported from grsecurity/PaX. More information at: 111 * https://grsecurity.net/ 112 * https://pax.grsecurity.net/ 113 114config GCC_PLUGIN_STACKLEAK_VERBOSE 115 bool "Report stack depth analysis instrumentation" if EXPERT 116 depends on GCC_PLUGIN_STACKLEAK 117 depends on !COMPILE_TEST # too noisy 118 help 119 This option will cause a warning to be printed each time the 120 stackleak plugin finds a function it thinks needs to be 121 instrumented. This is useful for comparing coverage between 122 builds. 123 124config KSTACK_ERASE_TRACK_MIN_SIZE 125 int "Minimum stack frame size of functions tracked by KSTACK_ERASE" 126 default 100 127 range 0 4096 128 depends on KSTACK_ERASE 129 help 130 The KSTACK_ERASE option instruments the kernel code for tracking 131 the lowest border of the kernel stack (and for some other purposes). 132 It inserts the __sanitizer_cov_stack_depth() call for the functions 133 with a stack frame size greater than or equal to this parameter. 134 If unsure, leave the default value 100. 135 136config KSTACK_ERASE_METRICS 137 bool "Show KSTACK_ERASE metrics in the /proc file system" 138 depends on KSTACK_ERASE 139 depends on PROC_FS 140 help 141 If this is set, KSTACK_ERASE metrics for every task are available 142 in the /proc file system. In particular, /proc/<pid>/stack_depth 143 shows the maximum kernel stack consumption for the current and 144 previous syscalls. Although this information is not precise, it 145 can be useful for estimating the KSTACK_ERASE performance impact 146 for your workloads. 147 148config KSTACK_ERASE_RUNTIME_DISABLE 149 bool "Allow runtime disabling of kernel stack erasing" 150 depends on KSTACK_ERASE 151 help 152 This option provides 'stack_erasing' sysctl, which can be used in 153 runtime to control kernel stack erasing for kernels built with 154 CONFIG_KSTACK_ERASE. 155 156config INIT_ON_ALLOC_DEFAULT_ON 157 bool "Enable heap memory zeroing on allocation by default" 158 depends on !KMSAN 159 help 160 This has the effect of setting "init_on_alloc=1" on the kernel 161 command line. This can be disabled with "init_on_alloc=0". 162 When "init_on_alloc" is enabled, all page allocator and slab 163 allocator memory will be zeroed when allocated, eliminating 164 many kinds of "uninitialized heap memory" flaws, especially 165 heap content exposures. The performance impact varies by 166 workload, but most cases see <1% impact. Some synthetic 167 workloads have measured as high as 7%. 168 169config INIT_ON_FREE_DEFAULT_ON 170 bool "Enable heap memory zeroing on free by default" 171 depends on !KMSAN 172 help 173 This has the effect of setting "init_on_free=1" on the kernel 174 command line. This can be disabled with "init_on_free=0". 175 Similar to "init_on_alloc", when "init_on_free" is enabled, 176 all page allocator and slab allocator memory will be zeroed 177 when freed, eliminating many kinds of "uninitialized heap memory" 178 flaws, especially heap content exposures. The primary difference 179 with "init_on_free" is that data lifetime in memory is reduced, 180 as anything freed is wiped immediately, making live forensics or 181 cold boot memory attacks unable to recover freed memory contents. 182 The performance impact varies by workload, but is more expensive 183 than "init_on_alloc" due to the negative cache effects of 184 touching "cold" memory areas. Most cases see 3-5% impact. Some 185 synthetic workloads have measured as high as 8%. 186 187config CC_HAS_ZERO_CALL_USED_REGS 188 def_bool $(cc-option,-fzero-call-used-regs=used-gpr) 189 # https://github.com/ClangBuiltLinux/linux/issues/1766 190 # https://github.com/llvm/llvm-project/issues/59242 191 depends on !CC_IS_CLANG || CLANG_VERSION > 150006 192 193config ZERO_CALL_USED_REGS 194 bool "Enable register zeroing on function exit" 195 depends on CC_HAS_ZERO_CALL_USED_REGS 196 help 197 At the end of functions, always zero any caller-used register 198 contents. This helps ensure that temporary values are not 199 leaked beyond the function boundary. This means that register 200 contents are less likely to be available for side channels 201 and information exposures. Additionally, this helps reduce the 202 number of useful ROP gadgets by about 20% (and removes compiler 203 generated "write-what-where" gadgets) in the resulting kernel 204 image. This has a less than 1% performance impact on most 205 workloads. Image size growth depends on architecture, and should 206 be evaluated for suitability. For example, x86_64 grows by less 207 than 1%, and arm64 grows by about 5%. 208 209endmenu 210 211menu "Bounds checking" 212 213config FORTIFY_SOURCE 214 bool "Harden common str/mem functions against buffer overflows" 215 depends on ARCH_HAS_FORTIFY_SOURCE 216 # https://github.com/llvm/llvm-project/issues/53645 217 depends on !X86_32 || !CC_IS_CLANG || CLANG_VERSION >= 160000 218 help 219 Detect overflows of buffers in common string and memory functions 220 where the compiler can determine and validate the buffer sizes. 221 222config HARDENED_USERCOPY 223 bool "Harden memory copies between kernel and userspace" 224 imply STRICT_DEVMEM 225 help 226 This option checks for obviously wrong memory regions when 227 copying memory to/from the kernel (via copy_to_user() and 228 copy_from_user() functions) by rejecting memory ranges that 229 are larger than the specified heap object, span multiple 230 separately allocated pages, are not on the process stack, 231 or are part of the kernel text. This prevents entire classes 232 of heap overflow exploits and similar kernel memory exposures. 233 234config HARDENED_USERCOPY_DEFAULT_ON 235 bool "Harden memory copies by default" 236 depends on HARDENED_USERCOPY 237 default HARDENED_USERCOPY 238 help 239 This has the effect of setting "hardened_usercopy=on" on the kernel 240 command line. This can be disabled with "hardened_usercopy=off". 241 242endmenu 243 244menu "Hardening of kernel data structures" 245 246config LIST_HARDENED 247 bool "Check integrity of linked list manipulation" 248 help 249 Minimal integrity checking in the linked-list manipulation routines 250 to catch memory corruptions that are not guaranteed to result in an 251 immediate access fault. 252 253 If unsure, say N. 254 255config BUG_ON_DATA_CORRUPTION 256 bool "Trigger a BUG when data corruption is detected" 257 select LIST_HARDENED 258 help 259 Select this option if the kernel should BUG when it encounters 260 data corruption in kernel memory structures when they get checked 261 for validity. 262 263 If unsure, say N. 264 265endmenu 266 267config CC_HAS_RANDSTRUCT 268 def_bool $(cc-option,-frandomize-layout-seed-file=/dev/null) 269 # Randstruct was first added in Clang 15, but it isn't safe to use until 270 # Clang 16 due to https://github.com/llvm/llvm-project/issues/60349 271 depends on !CC_IS_CLANG || CLANG_VERSION >= 160000 272 273choice 274 prompt "Randomize layout of sensitive kernel structures" 275 default RANDSTRUCT_FULL if COMPILE_TEST && (GCC_PLUGINS || CC_HAS_RANDSTRUCT) 276 default RANDSTRUCT_NONE 277 help 278 If you enable this, the layouts of structures that are entirely 279 function pointers (and have not been manually annotated with 280 __no_randomize_layout), or structures that have been explicitly 281 marked with __randomize_layout, will be randomized at compile-time. 282 This can introduce the requirement of an additional information 283 exposure vulnerability for exploits targeting these structure 284 types. 285 286 Enabling this feature will introduce some performance impact, 287 slightly increase memory usage, and prevent the use of forensic 288 tools like Volatility against the system (unless the kernel 289 source tree isn't cleaned after kernel installation). 290 291 The seed used for compilation is in scripts/basic/randomize.seed. 292 It remains after a "make clean" to allow for external modules to 293 be compiled with the existing seed and will be removed by a 294 "make mrproper" or "make distclean". This file should not be made 295 public, or the structure layout can be determined. 296 297 config RANDSTRUCT_NONE 298 bool "Disable structure layout randomization" 299 help 300 Build normally: no structure layout randomization. 301 302 config RANDSTRUCT_FULL 303 bool "Fully randomize structure layout" 304 depends on CC_HAS_RANDSTRUCT || GCC_PLUGINS 305 select MODVERSIONS if MODULES && !COMPILE_TEST 306 help 307 Fully randomize the member layout of sensitive 308 structures as much as possible, which may have both a 309 memory size and performance impact. 310 311 One difference between the Clang and GCC plugin 312 implementations is the handling of bitfields. The GCC 313 plugin treats them as fully separate variables, 314 introducing sometimes significant padding. Clang tries 315 to keep adjacent bitfields together, but with their bit 316 ordering randomized. 317 318 config RANDSTRUCT_PERFORMANCE 319 bool "Limit randomization of structure layout to cache-lines" 320 depends on GCC_PLUGINS 321 select MODVERSIONS if MODULES && !COMPILE_TEST 322 help 323 Randomization of sensitive kernel structures will make a 324 best effort at restricting randomization to cacheline-sized 325 groups of members. It will further not randomize bitfields 326 in structures. This reduces the performance hit of RANDSTRUCT 327 at the cost of weakened randomization. 328endchoice 329 330config RANDSTRUCT 331 def_bool !RANDSTRUCT_NONE 332 333config GCC_PLUGIN_RANDSTRUCT 334 def_bool GCC_PLUGINS && RANDSTRUCT 335 help 336 Use GCC plugin to randomize structure layout. 337 338 This plugin was ported from grsecurity/PaX. More 339 information at: 340 * https://grsecurity.net/ 341 * https://pax.grsecurity.net/ 342 343endmenu 344