From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu, 1 Nov 2018 18:46:27 +0000 (-0700)
Subject: Merge tag 'stackleak-v4.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git... 
X-Git-Tag: v4.20-rc1~34
X-Git-Url: https://asedeno.scripts.mit.edu/gitweb/?a=commitdiff_plain;h=2d6bb6adb714b133db92ccd4bfc9c20f75f71f3f;p=linux.git

Merge tag 'stackleak-v4.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

Pull stackleak gcc plugin from Kees Cook:
 "Please pull this new GCC plugin, stackleak, for v4.20-rc1. This plugin
  was ported from grsecurity by Alexander Popov. It provides efficient
  stack content poisoning at syscall exit. This creates a defense
  against at least two classes of flaws:

   - Uninitialized stack usage. (We continue to work on improving the
     compiler to do this in other ways: e.g. unconditional zero init was
     proposed to GCC and Clang, and more plugin work has started too).

   - Stack content exposure. By greatly reducing the lifetime of valid
     stack contents, exposures via either direct read bugs or unknown
     cache side-channels become much more difficult to exploit. This
     complements the existing buddy and heap poisoning options, but
     provides the coverage for stacks.

  The x86 hooks are included in this series (which have been reviewed by
  Ingo, Dave Hansen, and Thomas Gleixner). The arm64 hooks have already
  been merged through the arm64 tree (written by Laura Abbott and
  reviewed by Mark Rutland and Will Deacon).

  With VLAs having been removed this release, there is no need for
  alloca() protection, so it has been removed from the plugin"

* tag 'stackleak-v4.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
  arm64: Drop unneeded stackleak_check_alloca()
  stackleak: Allow runtime disabling of kernel stack erasing
  doc: self-protection: Add information about STACKLEAK feature
  fs/proc: Show STACKLEAK metrics in the /proc file system
  lkdtm: Add a test for STACKLEAK
  gcc-plugins: Add STACKLEAK plugin for tracking the kernel stack
  x86/entry: Add STACKLEAK erasing the kernel stack at the end of syscalls
---

2d6bb6adb714b133db92ccd4bfc9c20f75f71f3f
diff --cc Documentation/x86/x86_64/mm.txt
index 702898633b00,600bc2afa27d..73aaaa3da436
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@@ -146,3 -79,3 +146,6 @@@ Their order is preserved but their bas
  Be very careful vs. KASLR when changing anything here. The KASLR address
  range must not overlap with anything except the KASAN shadow area, which is
  correct as KASAN disables KASLR.
++
++For both 4- and 5-level layouts, the STACKLEAK_POISON value in the last 2MB
++hole: ffffffffffff4111
diff --cc drivers/misc/lkdtm/core.c
index 5a755590d3dc,aca26d81e9b8..2837dc77478e
--- a/drivers/misc/lkdtm/core.c
+++ b/drivers/misc/lkdtm/core.c
@@@ -183,7 -183,7 +183,8 @@@ static const struct crashtype crashtype
  	CRASHTYPE(USERCOPY_STACK_FRAME_FROM),
  	CRASHTYPE(USERCOPY_STACK_BEYOND),
  	CRASHTYPE(USERCOPY_KERNEL),
 +	CRASHTYPE(USERCOPY_KERNEL_DS),
+ 	CRASHTYPE(STACKLEAK_ERASING),
  };
  
  
diff --cc drivers/misc/lkdtm/lkdtm.h
index 07db641d71d0,b611b157c84f..3c6fd327e166
--- a/drivers/misc/lkdtm/lkdtm.h
+++ b/drivers/misc/lkdtm/lkdtm.h
@@@ -82,6 -82,8 +82,9 @@@ void lkdtm_USERCOPY_STACK_FRAME_TO(void
  void lkdtm_USERCOPY_STACK_FRAME_FROM(void);
  void lkdtm_USERCOPY_STACK_BEYOND(void);
  void lkdtm_USERCOPY_KERNEL(void);
 +void lkdtm_USERCOPY_KERNEL_DS(void);
  
+ /* lkdtm_stackleak.c */
+ void lkdtm_STACKLEAK_ERASING(void);
+ 
  #endif