security/Kconfig.hardening

menu "Kernel hardening options"

menu "Memory initialization"

choice
	prompt "Initialize kernel stack variables at function entry"
	default INIT_STACK_NONE
	help
	  This option enables initialization of stack variables at
	  function entry time. This has the possibility to have the
	  greatest coverage (since all functions can have their
	  variables initialized), but the performance impact depends
	  on the function calling complexity of a given workload's
	  syscalls.

	  This chooses the level of coverage over classes of potentially
	  uninitialized variables. The selected class will be
	  initialized before use in a function.

	config INIT_STACK_NONE
		bool "no automatic initialization (weakest)"
		help
		  Disable automatic stack variable initialization.
		  This leaves the kernel vulnerable to the standard
		  classes of uninitialized stack variable exploits
		  and information exposures.

	config INIT_STACK_ALL_PATTERN
		bool "0xAA-init everything on the stack (strongest)"
		help
		  Initializes everything on the stack with a 0xAA
		  pattern. This is intended to eliminate all classes
		  of uninitialized stack variable exploits and information
		  exposures, even variables that were warned to have been
		  left uninitialized.

		  Pattern initialization is known to provoke many existing bugs
		  related to uninitialized locals, e.g. pointers receive
		  non-NULL values, buffer sizes and indices are very big.

	config INIT_STACK_ALL_ZERO
		bool "zero-init everything on the stack (strongest and safest)"
		help
		  Initializes everything on the stack with a zero
		  value. This is intended to eliminate all classes
		  of uninitialized stack variable exploits and information
		  exposures, even variables that were warned to have been
		  left uninitialized.

		  Zero initialization provides safe defaults for strings,
		  pointers, indices and sizes, and is therefore
		  more suitable as a security mitigation measure.

endchoice

config INIT_ON_ALLOC_DEFAULT_ON
	bool "Enable heap memory zeroing on allocation by default"
	help
	  This has the effect of setting "init_on_alloc=1" on the kernel
	  command line. This can be disabled with "init_on_alloc=0".
	  When "init_on_alloc" is enabled, all page allocator and slab
	  allocator memory will be zeroed when allocated, eliminating
	  many kinds of "uninitialized heap memory" flaws, especially
	  heap content exposures. The performance impact varies by
	  workload, but most cases see <1% impact. Some synthetic
	  workloads have measured as high as 7%.

config INIT_ON_FREE_DEFAULT_ON
	bool "Enable heap memory zeroing on free by default"
	help
	  This has the effect of setting "init_on_free=1" on the kernel
	  command line. This can be disabled with "init_on_free=0".
	  Similar to "init_on_alloc", when "init_on_free" is enabled,
	  all page allocator and slab allocator memory will be zeroed
	  when freed, eliminating many kinds of "uninitialized heap memory"
	  flaws, especially heap content exposures. The primary difference
	  with "init_on_free" is that data lifetime in memory is reduced,
	  as anything freed is wiped immediately, making live forensics or
	  cold boot memory attacks unable to recover freed memory contents.
	  The performance impact varies by workload, but is more expensive
	  than "init_on_alloc" due to the negative cache effects of
	  touching "cold" memory areas. Most cases see 3-5% impact. Some
	  synthetic workloads have measured as high as 8%.

endmenu

endmenu