1. 15 Jun, 2018 5 commits
  2. 14 Jun, 2018 2 commits
    • Masahiro Yamada's avatar
      Kbuild: rename HAVE_CC_STACKPROTECTOR config variable · d148eac0
      Masahiro Yamada authored
      HAVE_CC_STACKPROTECTOR should be selected by architectures with stack
      canary implementation.  It is not about the compiler support.
      
      For the consistency with commit 050e9baa
      
       ("Kbuild: rename
      CC_STACKPROTECTOR[_STRONG] config variables"), remove 'CC_' from the
      config symbol.
      
      I moved the 'select' lines to keep the alphabetical sorting.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d148eac0
    • Linus Torvalds's avatar
      Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables · 050e9baa
      Linus Torvalds authored
      
      
      The changes to automatically test for working stack protector compiler
      support in the Kconfig files removed the special STACKPROTECTOR_AUTO
      option that picked the strongest stack protector that the compiler
      supported.
      
      That was all a nice cleanup - it makes no sense to have the AUTO case
      now that the Kconfig phase can just determine the compiler support
      directly.
      
      HOWEVER.
      
      It also meant that doing "make oldconfig" would now _disable_ the strong
      stackprotector if you had AUTO enabled, because in a legacy config file,
      the sane stack protector configuration would look like
      
        CONFIG_HAVE_CC_STACKPROTECTOR=y
        # CONFIG_CC_STACKPROTECTOR_NONE is not set
        # CONFIG_CC_STACKPROTECTOR_REGULAR is not set
        # CONFIG_CC_STACKPROTECTOR_STRONG is not set
        CONFIG_CC_STACKPROTECTOR_AUTO=y
      
      and when you ran this through "make oldconfig" with the Kbuild changes,
      it would ask you about the regular CONFIG_CC_STACKPROTECTOR (that had
      been renamed from CONFIG_CC_STACKPROTECTOR_REGULAR to just
      CONFIG_CC_STACKPROTECTOR), but it would think that the STRONG version
      used to be disabled (because it was really enabled by AUTO), and would
      disable it in the new config, resulting in:
      
        CONFIG_HAVE_CC_STACKPROTECTOR=y
        CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
        CONFIG_CC_STACKPROTECTOR=y
        # CONFIG_CC_STACKPROTECTOR_STRONG is not set
        CONFIG_CC_HAS_SANE_STACKPROTECTOR=y
      
      That's dangerously subtle - people could suddenly find themselves with
      the weaker stack protector setup without even realizing.
      
      The solution here is to just rename not just the old RECULAR stack
      protector option, but also the strong one.  This does that by just
      removing the CC_ prefix entirely for the user choices, because it really
      is not about the compiler support (the compiler support now instead
      automatially impacts _visibility_ of the options to users).
      
      This results in "make oldconfig" actually asking the user for their
      choice, so that we don't have any silent subtle security model changes.
      The end result would generally look like this:
      
        CONFIG_HAVE_CC_STACKPROTECTOR=y
        CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
        CONFIG_STACKPROTECTOR=y
        CONFIG_STACKPROTECTOR_STRONG=y
        CONFIG_CC_HAS_SANE_STACKPROTECTOR=y
      
      where the "CC_" versions really are about internal compiler
      infrastructure, not the user selections.
      Acked-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      050e9baa
  3. 11 Jun, 2018 1 commit
  4. 08 Jun, 2018 11 commits
  5. 07 Jun, 2018 1 commit
  6. 06 Jun, 2018 5 commits
  7. 05 Jun, 2018 4 commits
  8. 04 Jun, 2018 10 commits
  9. 03 Jun, 2018 1 commit
    • Dan Williams's avatar
      acpi, nfit: Remove ecc_unit_size · d4dd7091
      Dan Williams authored
      
      
      The "Clear Error Unit" may be smaller than the ECC unit size on some
      devices. For example, poison may be tracked at 64-byte alignment even
      though the ECC unit is larger. Unless / until the ACPI specification
      provides a non-ambiguous way to communicate this property do not expose
      this to userspace.
      
      Software that had been using this property must already be prepared for
      the case where the property is not provided on older kernels, so it is
      safe to remove this attribute.
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      d4dd7091