12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788 |
- 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
|