R0dn3yS/android_kernel_xiaomi_sm7250
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

kconfig: force INIT_STACK_NONE

Browse Source
This commit is contained in:
spakkkk 2020-12-30 22:01:40 +00:00
parent 94613113f5
commit f9fc42fa93
1 changed files with 7 additions and 76 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

83
security/Kconfig.hardening
View File

@ -34,83 +34,14 @@ config CC_HAS_AUTO_VAR_INIT_ZERO_ENABLER
config CC_HAS_AUTO_VAR_INIT_ZERO
def_bool CC_HAS_AUTO_VAR_INIT_ZERO_BARE || CC_HAS_AUTO_VAR_INIT_ZERO_ENABLER
choice
prompt "Initialize kernel stack variables at function entry"
default GCC_PLUGIN_STRUCTLEAK_BYREF_ALL if COMPILE_TEST && GCC_PLUGINS
default INIT_STACK_ALL_PATTERN if COMPILE_TEST && CC_HAS_AUTO_VAR_INIT_PATTERN
default INIT_STACK_ALL_ZERO if CC_HAS_AUTO_VAR_INIT_ZERO
default INIT_STACK_NONE
config INIT_STACK_NONE
bool "no automatic initialization (weakest)"
default y
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 of variable will be
initialized before use in a function.
config INIT_STACK_NONE
bool "no automatic stack variable 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 GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
bool "zero-init everything passed by reference (very strong)"
depends on GCC_PLUGINS
select GCC_PLUGIN_STRUCTLEAK
help
Zero-initialize any stack variables that may be passed
by reference and had not already been explicitly
initialized. This is intended to eliminate all classes
of uninitialized stack variable exploits and information
exposures.
As a side-effect, this keeps a lot of variables on the
stack that can otherwise be optimized out, so combining
this with CONFIG_KASAN_STACK can lead to a stack overflow
and is disallowed.
config INIT_STACK_ALL_PATTERN
bool "pattern-init everything (strongest)"
depends on CC_HAS_AUTO_VAR_INIT_PATTERN
help
Initializes everything on the stack (including padding)
with a specific debug value. This is intended to eliminate
all classes of uninitialized stack variable exploits and
information exposures, even variables that were warned about
having 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. The
pattern is situation-specific; Clang on 64-bit uses 0xAA
repeating for all types and padding except float and double
which use 0xFF repeating (-NaN). Clang on 32-bit uses 0xFF
repeating for all types and padding.
config INIT_STACK_ALL_ZERO
bool "zero-init everything (strongest and safest)"
depends on CC_HAS_AUTO_VAR_INIT_ZERO
help
Initializes everything on the stack (including padding)
with a zero value. This is intended to eliminate all
classes of uninitialized stack variable exploits and
information exposures, even variables that were warned
about having been left uninitialized.
Zero initialization provides safe defaults for strings
(immediately NUL-terminated), pointers (NULL), indices
(index 0), and sizes (0 length), so it is therefore more
suitable as a production security mitigation than pattern
initialization.
endchoice
Disable automatic stack variable initialization.
This leaves the kernel vulnerable to the standard
classes of uninitialized stack variable exploits
and information exposures.
config GCC_PLUGIN_STRUCTLEAK_VERBOSE
bool "Report forcefully initialized variables"