linux/scripts/gcc-plugins/Kconfig

230 lines
8.3 KiB
Plaintext
Raw Normal View History

preferred-plugin-hostcc := $(if-success,[ $(gcc-version) -ge 40800 ],$(HOSTCXX),$(HOSTCC))
config PLUGIN_HOSTCC
string
default "$(shell,$(srctree)/scripts/gcc-plugin.sh "$(preferred-plugin-hostcc)" "$(HOSTCXX)" "$(CC)")" if CC_IS_GCC
help
Host compiler used to build GCC plugins. This can be $(HOSTCXX),
$(HOSTCC), or a null string if GCC plugin is unsupported.
config HAVE_GCC_PLUGINS
bool
help
An arch should select this symbol if it supports building with
GCC plugins.
menuconfig GCC_PLUGINS
bool "GCC plugins"
depends on HAVE_GCC_PLUGINS
depends on PLUGIN_HOSTCC != ""
help
GCC plugins are loadable modules that provide extra features to the
compiler. They are useful for runtime instrumentation and static analysis.
See Documentation/gcc-plugins.txt for details.
if GCC_PLUGINS
config GCC_PLUGIN_CYC_COMPLEXITY
bool "Compute the cyclomatic complexity of a function" if EXPERT
depends on !COMPILE_TEST # too noisy
help
The complexity M of a function's control flow graph is defined as:
M = E - N + 2P
where
E = the number of edges
N = the number of nodes
P = the number of connected components (exit nodes).
Enabling this plugin reports the complexity to stderr during the
build. It mainly serves as a simple example of how to create a
gcc plugin for the kernel.
config GCC_PLUGIN_SANCOV
bool
help
This plugin inserts a __sanitizer_cov_trace_pc() call at the start of
basic blocks. It supports all gcc versions with plugin support (from
gcc-4.5 on). It is based on the commit "Add fuzzing coverage support"
by Dmitry Vyukov <dvyukov@google.com>.
config GCC_PLUGIN_LATENT_ENTROPY
bool "Generate some entropy during boot and runtime"
help
By saying Y here the kernel will instrument some kernel code to
extract some entropy from both original and artificially created
program state. This will help especially embedded systems where
there is little 'natural' source of entropy normally. The cost
is some slowdown of the boot process (about 0.5%) and fork and
irq processing.
Note that entropy extracted this way is not cryptographically
secure!
This plugin was ported from grsecurity/PaX. More information at:
* https://grsecurity.net/
* https://pax.grsecurity.net/
config GCC_PLUGIN_STRUCTLEAK
gcc-plugins: structleak: Generalize to all variable types This adjusts structleak to also work with non-struct types when they are passed by reference, since those variables may leak just like anything else. This is exposed via an improved set of Kconfig options. (This does mean structleak is slightly misnamed now.) Building with CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL should give the kernel complete initialization coverage of all stack variables passed by reference, including padding (see lib/test_stackinit.c). Using CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE to count added initializations under defconfig: ..._BYREF: 5945 added initializations ..._BYREF_ALL: 16606 added initializations There is virtually no change to text+data size (both have less than 0.05% growth): text data bss dec hex filename 19502103 5051456 1917000 26470559 193e89f vmlinux.stock 19513412 5051456 1908808 26473676 193f4cc vmlinux.byref 19516974 5047360 1900616 26464950 193d2b6 vmlinux.byref_all The measured performance difference is in the noise for hackbench and kernel build benchmarks: Stock: 5x hackbench -g 20 -l 1000 Mean: 10.649s Std Dev: 0.339 5x kernel build (4-way parallel) Mean: 261.98s Std Dev: 1.53 CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF: 5x hackbench -g 20 -l 1000 Mean: 10.540s Std Dev: 0.233 5x kernel build (4-way parallel) Mean: 260.52s Std Dev: 1.31 CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL: 5x hackbench -g 20 -l 1000 Mean: 10.320 Std Dev: 0.413 5x kernel build (4-way parallel) Mean: 260.10 Std Dev: 0.86 This does not yet solve missing padding initialization for structures on the stack that are never passed by reference (which should be a tiny minority). Hopefully this will be more easily addressed by upstream compiler fixes after clarifying the C11 padding initialization specification. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-01-24 00:19:29 +01:00
bool "Zero initialize stack variables"
help
gcc-plugins: structleak: Generalize to all variable types This adjusts structleak to also work with non-struct types when they are passed by reference, since those variables may leak just like anything else. This is exposed via an improved set of Kconfig options. (This does mean structleak is slightly misnamed now.) Building with CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL should give the kernel complete initialization coverage of all stack variables passed by reference, including padding (see lib/test_stackinit.c). Using CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE to count added initializations under defconfig: ..._BYREF: 5945 added initializations ..._BYREF_ALL: 16606 added initializations There is virtually no change to text+data size (both have less than 0.05% growth): text data bss dec hex filename 19502103 5051456 1917000 26470559 193e89f vmlinux.stock 19513412 5051456 1908808 26473676 193f4cc vmlinux.byref 19516974 5047360 1900616 26464950 193d2b6 vmlinux.byref_all The measured performance difference is in the noise for hackbench and kernel build benchmarks: Stock: 5x hackbench -g 20 -l 1000 Mean: 10.649s Std Dev: 0.339 5x kernel build (4-way parallel) Mean: 261.98s Std Dev: 1.53 CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF: 5x hackbench -g 20 -l 1000 Mean: 10.540s Std Dev: 0.233 5x kernel build (4-way parallel) Mean: 260.52s Std Dev: 1.31 CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL: 5x hackbench -g 20 -l 1000 Mean: 10.320 Std Dev: 0.413 5x kernel build (4-way parallel) Mean: 260.10 Std Dev: 0.86 This does not yet solve missing padding initialization for structures on the stack that are never passed by reference (which should be a tiny minority). Hopefully this will be more easily addressed by upstream compiler fixes after clarifying the C11 padding initialization specification. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-01-24 00:19:29 +01:00
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/
gcc-plugins: structleak: Generalize to all variable types This adjusts structleak to also work with non-struct types when they are passed by reference, since those variables may leak just like anything else. This is exposed via an improved set of Kconfig options. (This does mean structleak is slightly misnamed now.) Building with CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL should give the kernel complete initialization coverage of all stack variables passed by reference, including padding (see lib/test_stackinit.c). Using CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE to count added initializations under defconfig: ..._BYREF: 5945 added initializations ..._BYREF_ALL: 16606 added initializations There is virtually no change to text+data size (both have less than 0.05% growth): text data bss dec hex filename 19502103 5051456 1917000 26470559 193e89f vmlinux.stock 19513412 5051456 1908808 26473676 193f4cc vmlinux.byref 19516974 5047360 1900616 26464950 193d2b6 vmlinux.byref_all The measured performance difference is in the noise for hackbench and kernel build benchmarks: Stock: 5x hackbench -g 20 -l 1000 Mean: 10.649s Std Dev: 0.339 5x kernel build (4-way parallel) Mean: 261.98s Std Dev: 1.53 CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF: 5x hackbench -g 20 -l 1000 Mean: 10.540s Std Dev: 0.233 5x kernel build (4-way parallel) Mean: 260.52s Std Dev: 1.31 CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL: 5x hackbench -g 20 -l 1000 Mean: 10.320 Std Dev: 0.413 5x kernel build (4-way parallel) Mean: 260.10 Std Dev: 0.86 This does not yet solve missing padding initialization for structures on the stack that are never passed by reference (which should be a tiny minority). Hopefully this will be more easily addressed by upstream compiler fixes after clarifying the C11 padding initialization specification. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-01-24 00:19:29 +01:00
choice
prompt "Coverage"
depends on GCC_PLUGIN_STRUCTLEAK
gcc-plugins: structleak: Generalize to all variable types This adjusts structleak to also work with non-struct types when they are passed by reference, since those variables may leak just like anything else. This is exposed via an improved set of Kconfig options. (This does mean structleak is slightly misnamed now.) Building with CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL should give the kernel complete initialization coverage of all stack variables passed by reference, including padding (see lib/test_stackinit.c). Using CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE to count added initializations under defconfig: ..._BYREF: 5945 added initializations ..._BYREF_ALL: 16606 added initializations There is virtually no change to text+data size (both have less than 0.05% growth): text data bss dec hex filename 19502103 5051456 1917000 26470559 193e89f vmlinux.stock 19513412 5051456 1908808 26473676 193f4cc vmlinux.byref 19516974 5047360 1900616 26464950 193d2b6 vmlinux.byref_all The measured performance difference is in the noise for hackbench and kernel build benchmarks: Stock: 5x hackbench -g 20 -l 1000 Mean: 10.649s Std Dev: 0.339 5x kernel build (4-way parallel) Mean: 261.98s Std Dev: 1.53 CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF: 5x hackbench -g 20 -l 1000 Mean: 10.540s Std Dev: 0.233 5x kernel build (4-way parallel) Mean: 260.52s Std Dev: 1.31 CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL: 5x hackbench -g 20 -l 1000 Mean: 10.320 Std Dev: 0.413 5x kernel build (4-way parallel) Mean: 260.10 Std Dev: 0.86 This does not yet solve missing padding initialization for structures on the stack that are never passed by reference (which should be a tiny minority). Hopefully this will be more easily addressed by upstream compiler fixes after clarifying the C11 padding initialization specification. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-01-24 00:19:29 +01:00
default GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
help
gcc-plugins: structleak: Generalize to all variable types This adjusts structleak to also work with non-struct types when they are passed by reference, since those variables may leak just like anything else. This is exposed via an improved set of Kconfig options. (This does mean structleak is slightly misnamed now.) Building with CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL should give the kernel complete initialization coverage of all stack variables passed by reference, including padding (see lib/test_stackinit.c). Using CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE to count added initializations under defconfig: ..._BYREF: 5945 added initializations ..._BYREF_ALL: 16606 added initializations There is virtually no change to text+data size (both have less than 0.05% growth): text data bss dec hex filename 19502103 5051456 1917000 26470559 193e89f vmlinux.stock 19513412 5051456 1908808 26473676 193f4cc vmlinux.byref 19516974 5047360 1900616 26464950 193d2b6 vmlinux.byref_all The measured performance difference is in the noise for hackbench and kernel build benchmarks: Stock: 5x hackbench -g 20 -l 1000 Mean: 10.649s Std Dev: 0.339 5x kernel build (4-way parallel) Mean: 261.98s Std Dev: 1.53 CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF: 5x hackbench -g 20 -l 1000 Mean: 10.540s Std Dev: 0.233 5x kernel build (4-way parallel) Mean: 260.52s Std Dev: 1.31 CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL: 5x hackbench -g 20 -l 1000 Mean: 10.320 Std Dev: 0.413 5x kernel build (4-way parallel) Mean: 260.10 Std Dev: 0.86 This does not yet solve missing padding initialization for structures on the stack that are never passed by reference (which should be a tiny minority). Hopefully this will be more easily addressed by upstream compiler fixes after clarifying the C11 padding initialization specification. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-01-24 00:19:29 +01:00
This chooses the level of coverage over classes of potentially
uninitialized variables. The selected class will be
zero-initialized before use.
config GCC_PLUGIN_STRUCTLEAK_USER
bool "structs marked for userspace"
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 "structs passed by reference"
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 "anything passed by reference"
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.
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_RANDSTRUCT
bool "Randomize layout of sensitive kernel structures"
select MODVERSIONS if MODULES
help
If you say Y here, the layouts of structures that are entirely
function pointers (and have not been manually annotated with
__no_randomize_layout), or structures that have been explicitly
marked with __randomize_layout, will be randomized at compile-time.
This can introduce the requirement of an additional information
exposure vulnerability for exploits targeting these structure
types.
Enabling this feature will introduce some performance impact,
slightly increase memory usage, and prevent the use of forensic
tools like Volatility against the system (unless the kernel
source tree isn't cleaned after kernel installation).
The seed used for compilation is located at
scripts/gcc-plgins/randomize_layout_seed.h. It remains after
a make clean to allow for external modules to be compiled with
the existing seed and will be removed by a make mrproper or
make distclean.
Note that the implementation requires gcc 4.7 or newer.
This plugin was ported from grsecurity/PaX. More information at:
* https://grsecurity.net/
* https://pax.grsecurity.net/
config GCC_PLUGIN_RANDSTRUCT_PERFORMANCE
bool "Use cacheline-aware structure randomization"
depends on GCC_PLUGIN_RANDSTRUCT
depends on !COMPILE_TEST # do not reduce test coverage
help
If you say Y here, the RANDSTRUCT randomization will make a
best effort at restricting randomization to cacheline-sized
groups of elements. It will further not randomize bitfields
in structures. This reduces the performance hit of RANDSTRUCT
at the cost of weakened randomization.
x86/entry: Add STACKLEAK erasing the kernel stack at the end of syscalls The STACKLEAK feature (initially developed by PaX Team) has the following benefits: 1. Reduces the information that can be revealed through kernel stack leak bugs. The idea of erasing the thread stack at the end of syscalls is similar to CONFIG_PAGE_POISONING and memzero_explicit() in kernel crypto, which all comply with FDP_RIP.2 (Full Residual Information Protection) of the Common Criteria standard. 2. Blocks some uninitialized stack variable attacks (e.g. CVE-2017-17712, CVE-2010-2963). That kind of bugs should be killed by improving C compilers in future, which might take a long time. This commit introduces the code filling the used part of the kernel stack with a poison value before returning to userspace. Full STACKLEAK feature also contains the gcc plugin which comes in a separate commit. The STACKLEAK feature is ported from grsecurity/PaX. More information at: https://grsecurity.net/ https://pax.grsecurity.net/ This code is modified from Brad Spengler/PaX Team's code in the last public patch of grsecurity/PaX based on our understanding of the code. Changes or omissions from the original code are ours and don't reflect the original grsecurity/PaX code. Performance impact: Hardware: Intel Core i7-4770, 16 GB RAM Test #1: building the Linux kernel on a single core 0.91% slowdown Test #2: hackbench -s 4096 -l 2000 -g 15 -f 25 -P 4.2% slowdown So the STACKLEAK description in Kconfig includes: "The tradeoff is 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". Signed-off-by: Alexander Popov <alex.popov@linux.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2018-08-17 00:16:58 +02:00
config GCC_PLUGIN_STACKLEAK
bool "Erase the 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. That reduces the information which
kernel stack leak bugs can reveal and blocks some uninitialized
stack variable attacks.
The tradeoff is 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.
config GCC_PLUGIN_ARM_SSP_PER_TASK
bool
depends on GCC_PLUGINS && ARM
endif