• 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
entry.S 46.8 KB