linux-toradex.git/scripts/gcc-plugins/Kconfig, branch toradex_5.3.y

docs: move gcc_plugins.txt to core-api and rename to .rst

2019-07-15T12:20:27+00:00

The gcc_plugins.txt file is already a ReST file. Move it
to the core-api book while renaming it.

Signed-off-by: Mauro Carvalho Chehab 
Acked-by: Kees Cook

treewide: Add SPDX license identifier - Makefile/Kconfig

2019-05-21T08:50:46+00:00

Add SPDX license identifiers to all Make/Kconfig files which:

 - Have no license information of any form

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

  GPL-2.0-only

Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

security: Move stackleak config to Kconfig.hardening

2019-04-24T21:00:56+00:00

This moves the stackleak plugin options to Kconfig.hardening's memory
initialization menu.

Signed-off-by: Kees Cook 
Reviewed-by: Alexander Popov 
Acked-by: Masahiro Yamada

security: Create "kernel hardening" config area

2019-04-24T20:45:49+00:00

Right now kernel hardening options are scattered around various Kconfig
files. This can be a central place to collect these kinds of options
going forward. This is initially populated with the memory initialization
options from the gcc-plugins.

Signed-off-by: Kees Cook 
Acked-by: Masahiro Yamada

Merge tag 'gcc-plugins-v5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

2019-03-09T17:06:15+00:00

Pull gcc-plugins updates from Kees Cook:
 "This adds additional type coverage to the existing structleak plugin
  and adds a large set of selftests to help evaluate stack variable
  zero-initialization coverage.

  That can be used to test whatever instrumentation might be performing
  zero-initialization: either with the structleak plugin or with Clang's
  coming "-ftrivial-auto-var-init=zero" option.

  Summary:

   - Add scalar and array initialization coverage

   - Refactor Kconfig to make options more clear

   - Add self-test module for testing automatic initialization"

* tag 'gcc-plugins-v5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
  lib: Introduce test_stackinit module
  gcc-plugins: structleak: Generalize to all variable types

kasan: remove use after scope bugs detection.

2019-03-06T05:07:13+00:00

Use after scope bugs detector seems to be almost entirely useless for
the linux kernel.  It exists over two years, but I've seen only one
valid bug so far [1].  And the bug was fixed before it has been
reported.  There were some other use-after-scope reports, but they were
false-positives due to different reasons like incompatibility with
structleak plugin.

This feature significantly increases stack usage, especially with GCC <
9 version, and causes a 32K stack overflow.  It probably adds
performance penalty too.

Given all that, let's remove use-after-scope detector entirely.

While preparing this patch I've noticed that we mistakenly enable
use-after-scope detection for clang compiler regardless of
CONFIG_KASAN_EXTRA setting.  This is also fixed now.

[1] http://lkml.kernel.org/r/<20171129052106.rhgbjhhis53hkgfn@wfg-t540p.sh.intel.com>

Link: http://lkml.kernel.org/r/20190111185842.13978-1-aryabinin@virtuozzo.com
Signed-off-by: Andrey Ryabinin 
Acked-by: Will Deacon 		[arm64]
Cc: Qian Cai 
Cc: Alexander Potapenko 
Cc: Dmitry Vyukov 
Cc: Catalin Marinas 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

gcc-plugins: structleak: Generalize to all variable types

2019-03-04T17:29:41+00:00

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 
Reviewed-by: Ard Biesheuvel

ARM: smp: add support for per-task stack canaries

2018-12-12T21:20:07+00:00

On ARM, we currently only change the value of the stack canary when
switching tasks if the kernel was built for UP. On SMP kernels, this
is impossible since the stack canary value is obtained via a global
symbol reference, which means
a) all running tasks on all CPUs must use the same value
b) we can only modify the value when no kernel stack frames are live
   on any CPU, which is effectively never.

So instead, use a GCC plugin to add a RTL pass that replaces each
reference to the address of the __stack_chk_guard symbol with an
expression that produces the address of the 'stack_canary' field
that is added to struct thread_info. This way, each task will use
its own randomized value.

Cc: Russell King 
Cc: Kees Cook 
Cc: Emese Revfy 
Cc: Arnd Bergmann 
Cc: Laura Abbott 
Cc: kernel-hardening@lists.openwall.com
Acked-by: Nicolas Pitre 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Kees Cook

stackleak: Allow runtime disabling of kernel stack erasing

2018-09-04T17:35:48+00:00

Introduce CONFIG_STACKLEAK_RUNTIME_DISABLE option, which provides
'stack_erasing' sysctl. It can be used in runtime to control kernel
stack erasing for kernels built with CONFIG_GCC_PLUGIN_STACKLEAK.

Suggested-by: Ingo Molnar 
Signed-off-by: Alexander Popov 
Tested-by: Laura Abbott 
Signed-off-by: Kees Cook

fs/proc: Show STACKLEAK metrics in the /proc file system

2018-09-04T17:35:48+00:00

Introduce CONFIG_STACKLEAK_METRICS providing STACKLEAK information about
tasks via the /proc file system. In particular, /proc//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.

Suggested-by: Ingo Molnar 
Signed-off-by: Alexander Popov 
Tested-by: Laura Abbott 
Signed-off-by: Kees Cook