Files
kernel_xiaomi_sm8250/security/Kconfig.hardening
Alexander Potapenko 8e89bf80ce ANDROID: fix allmodconfig build
commit e0c6791d04 ("BACKPORT: security: Create "kernel hardening" config area")
introduced an x86 build breakage in allmodconfig mode.
Copying the definition of GCC_PLUGIN_STRUCTLEAK_BYREF_ALL from upstream
version of security/Kconfig.hardening fixes the build.

Change-Id: I2def59283b829b8af8fa343eb1d4ebaa3f2e145d
Reported-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Alexander Potapenko <glider@google.com>
Bug: 143965122
Fixes: e0c6791d04 ("BACKPORT: security: Create "kernel hardening" config area)
Test: manual - run `make allmodconfig && make -j64`
Signed-off-by: Todd Kjos <tkjos@google.com>
2019-11-12 18:14:31 +00:00

110 lines
4.2 KiB
Plaintext

# SPDX-License-Identifier: GPL-2.0-only
menu "Kernel hardening options"
config GCC_PLUGIN_STRUCTLEAK
bool "Force initialization of variables containing userspace addresses"
help
This plugin zero-initializes any structures containing a
__user attribute. This can prevent some classes of information
exposures.
This plugin was ported from grsecurity/PaX. More information at:
* https://grsecurity.net/
* https://pax.grsecurity.net/
menu "Memory initialization"
config CC_HAS_AUTO_VAR_INIT
def_bool $(cc-option,-ftrivial-auto-var-init=pattern)
choice
prompt "Initialize kernel stack variables at function entry"
default GCC_PLUGIN_STRUCTLEAK_BYREF_ALL if COMPILE_TEST && GCC_PLUGINS
default INIT_STACK_ALL if COMPILE_TEST && CC_HAS_AUTO_VAR_INIT
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 GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
bool "zero-init anything 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.
config INIT_STACK_ALL
bool "0xAA-init everything on the stack (strongest)"
depends on CC_HAS_AUTO_VAR_INIT
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.
endchoice
config GCC_PLUGIN_STRUCTLEAK_VERBOSE
bool "Report forcefully initialized variables"
depends on GCC_PLUGIN_STRUCTLEAK
depends on !COMPILE_TEST # too noisy
help
This option will cause a warning to be printed each time the
structleak plugin finds a variable it thinks needs to be
initialized. Since not all existing initializers are detected
by the plugin, this can produce false positive warnings.
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