lkml.org 
[lkml]   [2018]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v2 11/21] stack-protector: test compiler capability in Kconfig and drop AUTO mode
    On Mon, Apr 9, 2018 at 1:54 AM, Masahiro Yamada
    <yamada.masahiro@socionext.com> wrote:
    > 2018-03-28 20:18 GMT+09:00 Kees Cook <keescook@chromium.org>:
    >> On Mon, Mar 26, 2018 at 10:29 PM, Masahiro Yamada
    >> <yamada.masahiro@socionext.com> wrote:
    >>> diff --git a/arch/Kconfig b/arch/Kconfig
    >>> index 8e0d665..b42378d 100644
    >>> --- a/arch/Kconfig
    >>> +++ b/arch/Kconfig
    >>> @@ -535,13 +535,13 @@ config HAVE_CC_STACKPROTECTOR
    >>> bool
    >>> help
    >>> An arch should select this symbol if:
    >>> - - its compiler supports the -fstack-protector option
    >>
    >> Please leave this note: it's still valid. An arch must still have
    >> compiler support for this to be sensible.
    >>
    >
    > No.
    >
    > "its compiler supports the -fstack-protector option"
    > is tested by $(cc-option -fstack-protector)
    >
    > ARCH does not need to know the GCC support level.

    That's not correct: if you enable stack protector for a kernel
    architecture that doesn't having it enabled, it's unlikely for the
    resulting kernel to boot. An architecture must handle the changes that
    the compiler introduces when adding -fstack-protector (for example,
    having the stack protector canary value defined, having the failure
    function defined, handling context switches changing canaries, etc).

    -Kees

    --
    Kees Cook
    Pixel Security

    \
     
     \ /
      Last update: 2018-04-09 17:04    [W:2.321 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site