mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-11-24 19:50:53 +07:00
709a972efb
CONFIG_INIT_STACK_ALL turns on stack initialization based on
-ftrivial-auto-var-init in Clang builds, which has greater coverage
than CONFIG_GCC_PLUGINS_STRUCTLEAK_BYREF_ALL.
-ftrivial-auto-var-init Clang option provides trivial initializers for
uninitialized local variables, variable fields and padding.
It has three possible values:
pattern - uninitialized locals are filled with a fixed pattern
(mostly 0xAA on 64-bit platforms, see https://reviews.llvm.org/D54604
for more details, but 0x000000AA for 32-bit pointers) likely to cause
crashes when uninitialized value is used;
zero (it's still debated whether this flag makes it to the official
Clang release) - uninitialized locals are filled with zeroes;
uninitialized (default) - uninitialized locals are left intact.
This patch uses only the "pattern" mode when CONFIG_INIT_STACK_ALL is
enabled.
Developers have the possibility to opt-out of this feature on a
per-variable basis by using __attribute__((uninitialized)), but such
use should be well justified in comments.
Co-developed-by: Alexander Potapenko <glider@google.com>
Signed-off-by: Alexander Potapenko <glider@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Tested-by: Alexander Potapenko <glider@google.com>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
165 lines
6.1 KiB
Plaintext
165 lines
6.1 KiB
Plaintext
menu "Kernel hardening options"
|
|
|
|
config GCC_PLUGIN_STRUCTLEAK
|
|
bool
|
|
help
|
|
While the kernel is built with warnings enabled for any missed
|
|
stack variable initializations, this warning is silenced for
|
|
anything passed by reference to another function, under the
|
|
occasionally misguided assumption that the function will do
|
|
the initialization. As this regularly leads to exploitable
|
|
flaws, this plugin is available to identify and zero-initialize
|
|
such variables, depending on the chosen level of coverage.
|
|
|
|
This plugin was originally 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_USER
|
|
bool "zero-init structs marked for userspace (weak)"
|
|
depends on GCC_PLUGINS
|
|
select GCC_PLUGIN_STRUCTLEAK
|
|
help
|
|
Zero-initialize any structures on the stack containing
|
|
a __user attribute. This can prevent some classes of
|
|
uninitialized stack variable exploits and information
|
|
exposures, like CVE-2013-2141:
|
|
https://git.kernel.org/linus/b9e146d8eb3b9eca
|
|
|
|
config GCC_PLUGIN_STRUCTLEAK_BYREF
|
|
bool "zero-init structs passed by reference (strong)"
|
|
depends on GCC_PLUGINS
|
|
select GCC_PLUGIN_STRUCTLEAK
|
|
help
|
|
Zero-initialize any structures on the stack that may
|
|
be passed by reference and had not already been
|
|
explicitly initialized. This can prevent most classes
|
|
of uninitialized stack variable exploits and information
|
|
exposures, like CVE-2017-1000410:
|
|
https://git.kernel.org/linus/06e7e776ca4d3654
|
|
|
|
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 GCC_PLUGIN_STACKLEAK
|
|
bool "Poison kernel stack before returning from syscalls"
|
|
depends on GCC_PLUGINS
|
|
depends on HAVE_ARCH_STACKLEAK
|
|
help
|
|
This option makes the kernel erase the kernel stack before
|
|
returning from system calls. This has the effect of leaving
|
|
the stack initialized to the poison value, which both reduces
|
|
the lifetime of any sensitive stack contents and reduces
|
|
potential for uninitialized stack variable exploits or information
|
|
exposures (it does not cover functions reaching the same stack
|
|
depth as prior functions during the same syscall). This blocks
|
|
most uninitialized stack variable attacks, with the performance
|
|
impact being driven by the depth of the stack usage, rather than
|
|
the function calling complexity.
|
|
|
|
The performance impact on a single CPU system kernel compilation
|
|
sees a 1% slowdown, other systems and workloads may vary and you
|
|
are advised to test this feature on your expected workload before
|
|
deploying it.
|
|
|
|
This plugin was ported from grsecurity/PaX. More information at:
|
|
* https://grsecurity.net/
|
|
* https://pax.grsecurity.net/
|
|
|
|
config STACKLEAK_TRACK_MIN_SIZE
|
|
int "Minimum stack frame size of functions tracked by STACKLEAK"
|
|
default 100
|
|
range 0 4096
|
|
depends on GCC_PLUGIN_STACKLEAK
|
|
help
|
|
The STACKLEAK gcc plugin instruments the kernel code for tracking
|
|
the lowest border of the kernel stack (and for some other purposes).
|
|
It inserts the stackleak_track_stack() call for the functions with
|
|
a stack frame size greater than or equal to this parameter.
|
|
If unsure, leave the default value 100.
|
|
|
|
config STACKLEAK_METRICS
|
|
bool "Show STACKLEAK metrics in the /proc file system"
|
|
depends on GCC_PLUGIN_STACKLEAK
|
|
depends on PROC_FS
|
|
help
|
|
If this is set, STACKLEAK metrics for every task are available in
|
|
the /proc file system. In particular, /proc/<pid>/stack_depth
|
|
shows the maximum kernel stack consumption for the current and
|
|
previous syscalls. Although this information is not precise, it
|
|
can be useful for estimating the STACKLEAK performance impact for
|
|
your workloads.
|
|
|
|
config STACKLEAK_RUNTIME_DISABLE
|
|
bool "Allow runtime disabling of kernel stack erasing"
|
|
depends on GCC_PLUGIN_STACKLEAK
|
|
help
|
|
This option provides 'stack_erasing' sysctl, which can be used in
|
|
runtime to control kernel stack erasing for kernels built with
|
|
CONFIG_GCC_PLUGIN_STACKLEAK.
|
|
|
|
endmenu
|
|
|
|
endmenu
|