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