mirror of
https://github.com/rd-stuffs/msm-4.14.git
synced 2025-02-20 11:45:48 +08:00
a7eda6eddc
Upstream commit f0fe00d4972a8cd4b98cc2c29758615e4d51cdfe. In addition to -ftrivial-auto-var-init=pattern (used by CONFIG_INIT_STACK_ALL now) Clang also supports zero initialization for locals enabled by -ftrivial-auto-var-init=zero. The future of this flag is still being debated (see https://bugs.llvm.org/show_bug.cgi?id=45497). Right now it is guarded by another flag, -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang, which means it may not be supported by future Clang releases. Another possible resolution is that -ftrivial-auto-var-init=zero will persist (as certain users have already started depending on it), but the name of the guard flag will change. In the meantime, zero initialization has proven itself as a good production mitigation measure against uninitialized locals. Unlike pattern initialization, which has a higher chance of triggering existing bugs, zero initialization provides safe defaults for strings, pointers, indexes, and sizes. On the other hand, pattern initialization remains safer for return values. Chrome OS and Android are moving to using zero initialization for production builds. Performance-wise, the difference between pattern and zero initialization is usually negligible, although the generated code for zero initialization is more compact. This patch renames CONFIG_INIT_STACK_ALL to CONFIG_INIT_STACK_ALL_PATTERN and introduces another config option, CONFIG_INIT_STACK_ALL_ZERO, that enables zero initialization for locals if the corresponding flags are supported by Clang. Cc: Kees Cook <keescook@chromium.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Alexander Potapenko <glider@google.com> Link: https://lore.kernel.org/r/20200616083435.223038-1-glider@google.com Reviewed-by: Maciej Żenczykowski <maze@google.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Alexander Potapenko <glider@google.com> Change-Id: I2c76341a2b5f207b0b751293f2022b5ef99dbc45
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
|