Merge tag 'meminit-v5.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

Pull compiler-based variable initialization updates from Kees Cook:
 "This is effectively part of my gcc-plugins tree, but as this adds some
  Clang support, it felt weird to still call it "gcc-plugins". :)

  This consolidates Kconfig for the existing stack variable
  initialization (via structleak and stackleak gcc plugins) and adds
  Alexander Potapenko's support for Clang's new similar functionality.

  Summary:

   - Consolidate memory initialization Kconfigs (Kees)

   - Implement support for Clang's stack variable auto-init (Alexander)"

* tag 'meminit-v5.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
  security: Implement Clang's stack initialization
  security: Move stackleak config to Kconfig.hardening
  security: Create "kernel hardening" config area

2 files changed, 166 insertions, 0 deletions

diff --git a/security/Kconfig b/security/Kconfig
index 353cfef71d4e..aeac3676dd4d 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -287,5 +287,7 @@ config LSM
 
           If unsure, leave this as the default.
 
+source "security/Kconfig.hardening"
+
 endmenu
 
diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening
new file mode 100644
index 000000000000..0a1d4ca314f4
--- /dev/null
+++ b/security/Kconfig.hardening
@@ -0,0 +1,164 @@
+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