0001 # SPDX-License-Identifier: GPL-2.0-only
0002 menu "Kernel hardening options"
0003
0004 config GCC_PLUGIN_STRUCTLEAK
0005 bool
0006 help
0007 While the kernel is built with warnings enabled for any missed
0008 stack variable initializations, this warning is silenced for
0009 anything passed by reference to another function, under the
0010 occasionally misguided assumption that the function will do
0011 the initialization. As this regularly leads to exploitable
0012 flaws, this plugin is available to identify and zero-initialize
0013 such variables, depending on the chosen level of coverage.
0014
0015 This plugin was originally ported from grsecurity/PaX. More
0016 information at:
0017 * https://grsecurity.net/
0018 * https://pax.grsecurity.net/
0019
0020 menu "Memory initialization"
0021
0022 config CC_HAS_AUTO_VAR_INIT_PATTERN
0023 def_bool $(cc-option,-ftrivial-auto-var-init=pattern)
0024
0025 config CC_HAS_AUTO_VAR_INIT_ZERO_BARE
0026 def_bool $(cc-option,-ftrivial-auto-var-init=zero)
0027
0028 config CC_HAS_AUTO_VAR_INIT_ZERO_ENABLER
0029 # Clang 16 and later warn about using the -enable flag, but it
0030 # is required before then.
0031 def_bool $(cc-option,-ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang)
0032 depends on !CC_HAS_AUTO_VAR_INIT_ZERO_BARE
0033
0034 config CC_HAS_AUTO_VAR_INIT_ZERO
0035 def_bool CC_HAS_AUTO_VAR_INIT_ZERO_BARE || CC_HAS_AUTO_VAR_INIT_ZERO_ENABLER
0036
0037 choice
0038 prompt "Initialize kernel stack variables at function entry"
0039 default GCC_PLUGIN_STRUCTLEAK_BYREF_ALL if COMPILE_TEST && GCC_PLUGINS
0040 default INIT_STACK_ALL_PATTERN if COMPILE_TEST && CC_HAS_AUTO_VAR_INIT_PATTERN
0041 default INIT_STACK_ALL_ZERO if CC_HAS_AUTO_VAR_INIT_ZERO
0042 default INIT_STACK_NONE
0043 help
0044 This option enables initialization of stack variables at
0045 function entry time. This has the possibility to have the
0046 greatest coverage (since all functions can have their
0047 variables initialized), but the performance impact depends
0048 on the function calling complexity of a given workload's
0049 syscalls.
0050
0051 This chooses the level of coverage over classes of potentially
0052 uninitialized variables. The selected class of variable will be
0053 initialized before use in a function.
0054
0055 config INIT_STACK_NONE
0056 bool "no automatic stack variable initialization (weakest)"
0057 help
0058 Disable automatic stack variable initialization.
0059 This leaves the kernel vulnerable to the standard
0060 classes of uninitialized stack variable exploits
0061 and information exposures.
0062
0063 config GCC_PLUGIN_STRUCTLEAK_USER
0064 bool "zero-init structs marked for userspace (weak)"
0065 # Plugin can be removed once the kernel only supports GCC 12+
0066 depends on GCC_PLUGINS && !CC_HAS_AUTO_VAR_INIT_ZERO
0067 select GCC_PLUGIN_STRUCTLEAK
0068 help
0069 Zero-initialize any structures on the stack containing
0070 a __user attribute. This can prevent some classes of
0071 uninitialized stack variable exploits and information
0072 exposures, like CVE-2013-2141:
0073 https://git.kernel.org/linus/b9e146d8eb3b9eca
0074
0075 config GCC_PLUGIN_STRUCTLEAK_BYREF
0076 bool "zero-init structs passed by reference (strong)"
0077 # Plugin can be removed once the kernel only supports GCC 12+
0078 depends on GCC_PLUGINS && !CC_HAS_AUTO_VAR_INIT_ZERO
0079 depends on !(KASAN && KASAN_STACK)
0080 select GCC_PLUGIN_STRUCTLEAK
0081 help
0082 Zero-initialize any structures on the stack that may
0083 be passed by reference and had not already been
0084 explicitly initialized. This can prevent most classes
0085 of uninitialized stack variable exploits and information
0086 exposures, like CVE-2017-1000410:
0087 https://git.kernel.org/linus/06e7e776ca4d3654
0088
0089 As a side-effect, this keeps a lot of variables on the
0090 stack that can otherwise be optimized out, so combining
0091 this with CONFIG_KASAN_STACK can lead to a stack overflow
0092 and is disallowed.
0093
0094 config GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
0095 bool "zero-init everything passed by reference (very strong)"
0096 # Plugin can be removed once the kernel only supports GCC 12+
0097 depends on GCC_PLUGINS && !CC_HAS_AUTO_VAR_INIT_ZERO
0098 depends on !(KASAN && KASAN_STACK)
0099 select GCC_PLUGIN_STRUCTLEAK
0100 help
0101 Zero-initialize any stack variables that may be passed
0102 by reference and had not already been explicitly
0103 initialized. This is intended to eliminate all classes
0104 of uninitialized stack variable exploits and information
0105 exposures.
0106
0107 As a side-effect, this keeps a lot of variables on the
0108 stack that can otherwise be optimized out, so combining
0109 this with CONFIG_KASAN_STACK can lead to a stack overflow
0110 and is disallowed.
0111
0112 config INIT_STACK_ALL_PATTERN
0113 bool "pattern-init everything (strongest)"
0114 depends on CC_HAS_AUTO_VAR_INIT_PATTERN
0115 help
0116 Initializes everything on the stack (including padding)
0117 with a specific debug value. This is intended to eliminate
0118 all classes of uninitialized stack variable exploits and
0119 information exposures, even variables that were warned about
0120 having been left uninitialized.
0121
0122 Pattern initialization is known to provoke many existing bugs
0123 related to uninitialized locals, e.g. pointers receive
0124 non-NULL values, buffer sizes and indices are very big. The
0125 pattern is situation-specific; Clang on 64-bit uses 0xAA
0126 repeating for all types and padding except float and double
0127 which use 0xFF repeating (-NaN). Clang on 32-bit uses 0xFF
0128 repeating for all types and padding.
0129
0130 config INIT_STACK_ALL_ZERO
0131 bool "zero-init everything (strongest and safest)"
0132 depends on CC_HAS_AUTO_VAR_INIT_ZERO
0133 help
0134 Initializes everything on the stack (including padding)
0135 with a zero value. This is intended to eliminate all
0136 classes of uninitialized stack variable exploits and
0137 information exposures, even variables that were warned
0138 about having been left uninitialized.
0139
0140 Zero initialization provides safe defaults for strings
0141 (immediately NUL-terminated), pointers (NULL), indices
0142 (index 0), and sizes (0 length), so it is therefore more
0143 suitable as a production security mitigation than pattern
0144 initialization.
0145
0146 endchoice
0147
0148 config GCC_PLUGIN_STRUCTLEAK_VERBOSE
0149 bool "Report forcefully initialized variables"
0150 depends on GCC_PLUGIN_STRUCTLEAK
0151 depends on !COMPILE_TEST # too noisy
0152 help
0153 This option will cause a warning to be printed each time the
0154 structleak plugin finds a variable it thinks needs to be
0155 initialized. Since not all existing initializers are detected
0156 by the plugin, this can produce false positive warnings.
0157
0158 config GCC_PLUGIN_STACKLEAK
0159 bool "Poison kernel stack before returning from syscalls"
0160 depends on GCC_PLUGINS
0161 depends on HAVE_ARCH_STACKLEAK
0162 help
0163 This option makes the kernel erase the kernel stack before
0164 returning from system calls. This has the effect of leaving
0165 the stack initialized to the poison value, which both reduces
0166 the lifetime of any sensitive stack contents and reduces
0167 potential for uninitialized stack variable exploits or information
0168 exposures (it does not cover functions reaching the same stack
0169 depth as prior functions during the same syscall). This blocks
0170 most uninitialized stack variable attacks, with the performance
0171 impact being driven by the depth of the stack usage, rather than
0172 the function calling complexity.
0173
0174 The performance impact on a single CPU system kernel compilation
0175 sees a 1% slowdown, other systems and workloads may vary and you
0176 are advised to test this feature on your expected workload before
0177 deploying it.
0178
0179 This plugin was ported from grsecurity/PaX. More information at:
0180 * https://grsecurity.net/
0181 * https://pax.grsecurity.net/
0182
0183 config GCC_PLUGIN_STACKLEAK_VERBOSE
0184 bool "Report stack depth analysis instrumentation" if EXPERT
0185 depends on GCC_PLUGIN_STACKLEAK
0186 depends on !COMPILE_TEST # too noisy
0187 help
0188 This option will cause a warning to be printed each time the
0189 stackleak plugin finds a function it thinks needs to be
0190 instrumented. This is useful for comparing coverage between
0191 builds.
0192
0193 config STACKLEAK_TRACK_MIN_SIZE
0194 int "Minimum stack frame size of functions tracked by STACKLEAK"
0195 default 100
0196 range 0 4096
0197 depends on GCC_PLUGIN_STACKLEAK
0198 help
0199 The STACKLEAK gcc plugin instruments the kernel code for tracking
0200 the lowest border of the kernel stack (and for some other purposes).
0201 It inserts the stackleak_track_stack() call for the functions with
0202 a stack frame size greater than or equal to this parameter.
0203 If unsure, leave the default value 100.
0204
0205 config STACKLEAK_METRICS
0206 bool "Show STACKLEAK metrics in the /proc file system"
0207 depends on GCC_PLUGIN_STACKLEAK
0208 depends on PROC_FS
0209 help
0210 If this is set, STACKLEAK metrics for every task are available in
0211 the /proc file system. In particular, /proc/<pid>/stack_depth
0212 shows the maximum kernel stack consumption for the current and
0213 previous syscalls. Although this information is not precise, it
0214 can be useful for estimating the STACKLEAK performance impact for
0215 your workloads.
0216
0217 config STACKLEAK_RUNTIME_DISABLE
0218 bool "Allow runtime disabling of kernel stack erasing"
0219 depends on GCC_PLUGIN_STACKLEAK
0220 help
0221 This option provides 'stack_erasing' sysctl, which can be used in
0222 runtime to control kernel stack erasing for kernels built with
0223 CONFIG_GCC_PLUGIN_STACKLEAK.
0224
0225 config INIT_ON_ALLOC_DEFAULT_ON
0226 bool "Enable heap memory zeroing on allocation by default"
0227 help
0228 This has the effect of setting "init_on_alloc=1" on the kernel
0229 command line. This can be disabled with "init_on_alloc=0".
0230 When "init_on_alloc" is enabled, all page allocator and slab
0231 allocator memory will be zeroed when allocated, eliminating
0232 many kinds of "uninitialized heap memory" flaws, especially
0233 heap content exposures. The performance impact varies by
0234 workload, but most cases see <1% impact. Some synthetic
0235 workloads have measured as high as 7%.
0236
0237 config INIT_ON_FREE_DEFAULT_ON
0238 bool "Enable heap memory zeroing on free by default"
0239 help
0240 This has the effect of setting "init_on_free=1" on the kernel
0241 command line. This can be disabled with "init_on_free=0".
0242 Similar to "init_on_alloc", when "init_on_free" is enabled,
0243 all page allocator and slab allocator memory will be zeroed
0244 when freed, eliminating many kinds of "uninitialized heap memory"
0245 flaws, especially heap content exposures. The primary difference
0246 with "init_on_free" is that data lifetime in memory is reduced,
0247 as anything freed is wiped immediately, making live forensics or
0248 cold boot memory attacks unable to recover freed memory contents.
0249 The performance impact varies by workload, but is more expensive
0250 than "init_on_alloc" due to the negative cache effects of
0251 touching "cold" memory areas. Most cases see 3-5% impact. Some
0252 synthetic workloads have measured as high as 8%.
0253
0254 config CC_HAS_ZERO_CALL_USED_REGS
0255 def_bool $(cc-option,-fzero-call-used-regs=used-gpr)
0256
0257 config ZERO_CALL_USED_REGS
0258 bool "Enable register zeroing on function exit"
0259 depends on CC_HAS_ZERO_CALL_USED_REGS
0260 help
0261 At the end of functions, always zero any caller-used register
0262 contents. This helps ensure that temporary values are not
0263 leaked beyond the function boundary. This means that register
0264 contents are less likely to be available for side channels
0265 and information exposures. Additionally, this helps reduce the
0266 number of useful ROP gadgets by about 20% (and removes compiler
0267 generated "write-what-where" gadgets) in the resulting kernel
0268 image. This has a less than 1% performance impact on most
0269 workloads. Image size growth depends on architecture, and should
0270 be evaluated for suitability. For example, x86_64 grows by less
0271 than 1%, and arm64 grows by about 5%.
0272
0273 endmenu
0274
0275 config CC_HAS_RANDSTRUCT
0276 def_bool $(cc-option,-frandomize-layout-seed-file=/dev/null)
0277
0278 choice
0279 prompt "Randomize layout of sensitive kernel structures"
0280 default RANDSTRUCT_FULL if COMPILE_TEST && (GCC_PLUGINS || CC_HAS_RANDSTRUCT)
0281 default RANDSTRUCT_NONE
0282 help
0283 If you enable this, the layouts of structures that are entirely
0284 function pointers (and have not been manually annotated with
0285 __no_randomize_layout), or structures that have been explicitly
0286 marked with __randomize_layout, will be randomized at compile-time.
0287 This can introduce the requirement of an additional information
0288 exposure vulnerability for exploits targeting these structure
0289 types.
0290
0291 Enabling this feature will introduce some performance impact,
0292 slightly increase memory usage, and prevent the use of forensic
0293 tools like Volatility against the system (unless the kernel
0294 source tree isn't cleaned after kernel installation).
0295
0296 The seed used for compilation is in scripts/basic/randomize.seed.
0297 It remains after a "make clean" to allow for external modules to
0298 be compiled with the existing seed and will be removed by a
0299 "make mrproper" or "make distclean". This file should not be made
0300 public, or the structure layout can be determined.
0301
0302 config RANDSTRUCT_NONE
0303 bool "Disable structure layout randomization"
0304 help
0305 Build normally: no structure layout randomization.
0306
0307 config RANDSTRUCT_FULL
0308 bool "Fully randomize structure layout"
0309 depends on CC_HAS_RANDSTRUCT || GCC_PLUGINS
0310 select MODVERSIONS if MODULES
0311 help
0312 Fully randomize the member layout of sensitive
0313 structures as much as possible, which may have both a
0314 memory size and performance impact.
0315
0316 One difference between the Clang and GCC plugin
0317 implementations is the handling of bitfields. The GCC
0318 plugin treats them as fully separate variables,
0319 introducing sometimes significant padding. Clang tries
0320 to keep adjacent bitfields together, but with their bit
0321 ordering randomized.
0322
0323 config RANDSTRUCT_PERFORMANCE
0324 bool "Limit randomization of structure layout to cache-lines"
0325 depends on GCC_PLUGINS
0326 select MODVERSIONS if MODULES
0327 help
0328 Randomization of sensitive kernel structures will make a
0329 best effort at restricting randomization to cacheline-sized
0330 groups of members. It will further not randomize bitfields
0331 in structures. This reduces the performance hit of RANDSTRUCT
0332 at the cost of weakened randomization.
0333 endchoice
0334
0335 config RANDSTRUCT
0336 def_bool !RANDSTRUCT_NONE
0337
0338 config GCC_PLUGIN_RANDSTRUCT
0339 def_bool GCC_PLUGINS && RANDSTRUCT
0340 help
0341 Use GCC plugin to randomize structure layout.
0342
0343 This plugin was ported from grsecurity/PaX. More
0344 information at:
0345 * https://grsecurity.net/
0346 * https://pax.grsecurity.net/
0347
0348 endmenu
