threeeye
bc1d038eac
Squashed backup commit (no shallow-clone history issues) of xiaomi-mt6833-dev/kernel_xiaomi_mt6833 (lineage-23.2 branch, upstream commit 9eece662e) plus all fixes applied to get everpal_defconfig building clean against a modern (GCC 15.2.0) toolchain -- see the previous commit message on the lineage-23.2 branch (also in this repo history is not available here since this is a squashed snapshot; full incremental history lives in the local DL380 checkout and the upstream GitHub remote). Upstream: https://github.com/xiaomi-mt6833-dev/kernel_xiaomi_mt6833 (lineage-23.2)
88 lines
3.4 KiB
Plaintext
88 lines
3.4 KiB
Plaintext
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
|