Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
tjh.dev
kernel
os
linux
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 def_bool $(cc-option,-fzero-call-used-regs=used-gpr)
192 # https://github.com/ClangBuiltLinux/linux/issues/1766
193 # https://github.com/llvm/llvm-project/issues/59242
194 depends on !CC_IS_CLANG || CLANG_VERSION > 150006
195
196config ZERO_CALL_USED_REGS
197 bool "Enable register zeroing on function exit"
198 depends on CC_HAS_ZERO_CALL_USED_REGS
199 help
200 At the end of functions, always zero any caller-used register
201 contents. This helps ensure that temporary values are not
202 leaked beyond the function boundary. This means that register
203 contents are less likely to be available for side channels
204 and information exposures. Additionally, this helps reduce the
205 number of useful ROP gadgets by about 20% (and removes compiler
206 generated "write-what-where" gadgets) in the resulting kernel
207 image. This has a less than 1% performance impact on most
208 workloads. Image size growth depends on architecture, and should
209 be evaluated for suitability. For example, x86_64 grows by less
210 than 1%, and arm64 grows by about 5%.
211
212endmenu
213
214menu "Bounds checking"
215
216config FORTIFY_SOURCE
217 bool "Harden common str/mem functions against buffer overflows"
218 depends on ARCH_HAS_FORTIFY_SOURCE
219 # https://github.com/llvm/llvm-project/issues/53645
220 depends on !X86_32 || !CC_IS_CLANG || CLANG_VERSION >= 160000
221 help
222 Detect overflows of buffers in common string and memory functions
223 where the compiler can determine and validate the buffer sizes.
224
225config HARDENED_USERCOPY
226 bool "Harden memory copies between kernel and userspace"
227 imply STRICT_DEVMEM
228 help
229 This option checks for obviously wrong memory regions when
230 copying memory to/from the kernel (via copy_to_user() and
231 copy_from_user() functions) by rejecting memory ranges that
232 are larger than the specified heap object, span multiple
233 separately allocated pages, are not on the process stack,
234 or are part of the kernel text. This prevents entire classes
235 of heap overflow exploits and similar kernel memory exposures.
236
237config HARDENED_USERCOPY_DEFAULT_ON
238 bool "Harden memory copies by default"
239 depends on HARDENED_USERCOPY
240 default HARDENED_USERCOPY
241 help
242 This has the effect of setting "hardened_usercopy=on" on the kernel
243 command line. This can be disabled with "hardened_usercopy=off".
244
245endmenu
246
247menu "Hardening of kernel data structures"
248
249config LIST_HARDENED
250 bool "Check integrity of linked list manipulation"
251 help
252 Minimal integrity checking in the linked-list manipulation routines
253 to catch memory corruptions that are not guaranteed to result in an
254 immediate access fault.
255
256 If unsure, say N.
257
258config RUST_BITMAP_HARDENED
259 bool "Check integrity of bitmap Rust API"
260 depends on RUST
261 help
262 Enables additional assertions in the Rust Bitmap API to catch
263 arguments that are not guaranteed to result in an immediate access
264 fault.
265
266 If unsure, say N.
267
268config BUG_ON_DATA_CORRUPTION
269 bool "Trigger a BUG when data corruption is detected"
270 select LIST_HARDENED
271 help
272 Select this option if the kernel should BUG when it encounters
273 data corruption in kernel memory structures when they get checked
274 for validity.
275
276 If unsure, say N.
277
278endmenu
279
280config CC_HAS_RANDSTRUCT
281 def_bool $(cc-option,-frandomize-layout-seed-file=/dev/null)
282 # Randstruct was first added in Clang 15, but it isn't safe to use until
283 # Clang 16 due to https://github.com/llvm/llvm-project/issues/60349
284 depends on !CC_IS_CLANG || CLANG_VERSION >= 160000
285
286choice
287 prompt "Randomize layout of sensitive kernel structures"
288 default RANDSTRUCT_FULL if COMPILE_TEST && (GCC_PLUGINS || CC_HAS_RANDSTRUCT)
289 default RANDSTRUCT_NONE
290 help
291 If you enable this, the layouts of structures that are entirely
292 function pointers (and have not been manually annotated with
293 __no_randomize_layout), or structures that have been explicitly
294 marked with __randomize_layout, will be randomized at compile-time.
295 This can introduce the requirement of an additional information
296 exposure vulnerability for exploits targeting these structure
297 types.
298
299 Enabling this feature will introduce some performance impact,
300 slightly increase memory usage, and prevent the use of forensic
301 tools like Volatility against the system (unless the kernel
302 source tree isn't cleaned after kernel installation).
303
304 The seed used for compilation is in scripts/basic/randomize.seed.
305 It remains after a "make clean" to allow for external modules to
306 be compiled with the existing seed and will be removed by a
307 "make mrproper" or "make distclean". This file should not be made
308 public, or the structure layout can be determined.
309
310 config RANDSTRUCT_NONE
311 bool "Disable structure layout randomization"
312 help
313 Build normally: no structure layout randomization.
314
315 config RANDSTRUCT_FULL
316 bool "Fully randomize structure layout"
317 depends on CC_HAS_RANDSTRUCT || GCC_PLUGINS
318 select MODVERSIONS if MODULES && !COMPILE_TEST
319 help
320 Fully randomize the member layout of sensitive
321 structures as much as possible, which may have both a
322 memory size and performance impact.
323
324 One difference between the Clang and GCC plugin
325 implementations is the handling of bitfields. The GCC
326 plugin treats them as fully separate variables,
327 introducing sometimes significant padding. Clang tries
328 to keep adjacent bitfields together, but with their bit
329 ordering randomized.
330
331 config RANDSTRUCT_PERFORMANCE
332 bool "Limit randomization of structure layout to cache-lines"
333 depends on GCC_PLUGINS
334 select MODVERSIONS if MODULES && !COMPILE_TEST
335 help
336 Randomization of sensitive kernel structures will make a
337 best effort at restricting randomization to cacheline-sized
338 groups of members. It will further not randomize bitfields
339 in structures. This reduces the performance hit of RANDSTRUCT
340 at the cost of weakened randomization.
341endchoice
342
343config RANDSTRUCT
344 def_bool !RANDSTRUCT_NONE
345
346config GCC_PLUGIN_RANDSTRUCT
347 def_bool GCC_PLUGINS && RANDSTRUCT
348 help
349 Use GCC plugin to randomize structure layout.
350
351 This plugin was ported from grsecurity/PaX. More
352 information at:
353 * https://grsecurity.net/
354 * https://pax.grsecurity.net/
355
356endmenu