From: Kees Cook <keescook@chromium.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Michal Marek <mmarek@suse.com>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Rich Felker <dalias@libc.org>, Ingo Molnar <mingo@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Nicholas Piggin <npiggin@gmail.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Laura Abbott <labbott@redhat.com>,
linux-kbuild <linux-kbuild@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-sh <linux-sh@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>
Subject: Re: [kernel-hardening] [PATCH 0/3] Makefile: Introduce CONFIG_CC_STACKPROTECTOR_AUTO
Date: Tue, 03 Oct 2017 15:51:12 +0000 [thread overview]
Message-ID: <CAGXu5jKuGuP4FJVEbWbMfwkoqFvS22d6HpFhqbxcz8vys0yByg@mail.gmail.com> (raw)
In-Reply-To: <20171003100433.GA4931@leverpostej>
On Tue, Oct 3, 2017 at 3:04 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> Hi Kees,
>
> On Mon, Oct 02, 2017 at 12:20:04PM -0700, Kees Cook wrote:
>> As described in the final patch:
>>
>> Nearly all modern compilers support a stack-protector option, and nearly
>> all modern distributions enable the kernel stack-protector, so enabling
>> this by default in kernel builds would make sense. However, Kconfig does
>> not have knowledge of available compiler features, so it isn't safe to
>> force on, as this would unconditionally break builds for the compilers
>> or architectures that don't have support. Instead, this introduces a new
>> option, CONFIG_CC_STACKPROTECTOR_AUTO, which attempts to discover the best
>> possible stack-protector available, and will allow builds to proceed even
>> if the compiler doesn't support any stack-protector.
>>
>> This option is made the default so that kernels built with modern
>> compilers will be protected-by-default against stack buffer overflows,
>> avoiding things like the recent BlueBorne attack. Selection of a specific
>> stack-protector option remains available, including disabling it.
>
> I gave this a spin atop of v4.14-rc3 with a few arm64 toolchains I had
> installed:
>
> * Linaro 17.08 GCC 7.1 // strong
> * Linaro 17.05 GCC 6.1 // strong
> * Linaro 15.08 GCC 5.1 // strong
> * Linaro 14.09 GCC 4.9 // strong
> * Linaro 13.06 GCC 4.8 // none
> * Linaro 13.01 GCC 4.7 // none
>
> AFAICT, the detection is correct, and arm64 toolchains only gained stack
> protector support in GCC 4.9. I manually tested GCC 4.8 and 4.7, and
> got:
>
> warning: -fstack-protector not supported for this target [enabled by default]
>
> ... so that looks good to me.
>
> One thing I noticed was taht even when the build system detects no
> support for stack-protector, it still passes -DCONFIG_CC_STACKPROTECTOR
> to the toolchain. Is that expected?
Oops, that's a mistake. I had a think-o in the Makefile logic. I will
send a follow-up to fix it.
-Kees
--
Kees Cook
Pixel Security
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Michal Marek <mmarek@suse.com>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Rich Felker <dalias@libc.org>, Ingo Molnar <mingo@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Nicholas Piggin <npiggin@gmail.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Laura Abbott <labbott@redhat.com>,
linux-kbuild <linux-kbuild@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-sh <linux-sh@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>
Subject: Re: [kernel-hardening] [PATCH 0/3] Makefile: Introduce CONFIG_CC_STACKPROTECTOR_AUTO
Date: Tue, 3 Oct 2017 08:51:12 -0700 [thread overview]
Message-ID: <CAGXu5jKuGuP4FJVEbWbMfwkoqFvS22d6HpFhqbxcz8vys0yByg@mail.gmail.com> (raw)
In-Reply-To: <20171003100433.GA4931@leverpostej>
On Tue, Oct 3, 2017 at 3:04 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> Hi Kees,
>
> On Mon, Oct 02, 2017 at 12:20:04PM -0700, Kees Cook wrote:
>> As described in the final patch:
>>
>> Nearly all modern compilers support a stack-protector option, and nearly
>> all modern distributions enable the kernel stack-protector, so enabling
>> this by default in kernel builds would make sense. However, Kconfig does
>> not have knowledge of available compiler features, so it isn't safe to
>> force on, as this would unconditionally break builds for the compilers
>> or architectures that don't have support. Instead, this introduces a new
>> option, CONFIG_CC_STACKPROTECTOR_AUTO, which attempts to discover the best
>> possible stack-protector available, and will allow builds to proceed even
>> if the compiler doesn't support any stack-protector.
>>
>> This option is made the default so that kernels built with modern
>> compilers will be protected-by-default against stack buffer overflows,
>> avoiding things like the recent BlueBorne attack. Selection of a specific
>> stack-protector option remains available, including disabling it.
>
> I gave this a spin atop of v4.14-rc3 with a few arm64 toolchains I had
> installed:
>
> * Linaro 17.08 GCC 7.1 // strong
> * Linaro 17.05 GCC 6.1 // strong
> * Linaro 15.08 GCC 5.1 // strong
> * Linaro 14.09 GCC 4.9 // strong
> * Linaro 13.06 GCC 4.8 // none
> * Linaro 13.01 GCC 4.7 // none
>
> AFAICT, the detection is correct, and arm64 toolchains only gained stack
> protector support in GCC 4.9. I manually tested GCC 4.8 and 4.7, and
> got:
>
> warning: -fstack-protector not supported for this target [enabled by default]
>
> ... so that looks good to me.
>
> One thing I noticed was taht even when the build system detects no
> support for stack-protector, it still passes -DCONFIG_CC_STACKPROTECTOR
> to the toolchain. Is that expected?
Oops, that's a mistake. I had a think-o in the Makefile logic. I will
send a follow-up to fix it.
-Kees
--
Kees Cook
Pixel Security
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Michal Marek <mmarek@suse.com>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Rich Felker <dalias@libc.org>, Ingo Molnar <mingo@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Nicholas Piggin <npiggin@gmail.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Laura Abbott <labbott@redhat.com>,
linux-kbuild <linux-kbuild@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-sh <linux-sh@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>
Subject: Re: [kernel-hardening] [PATCH 0/3] Makefile: Introduce CONFIG_CC_STACKPROTECTOR_AUTO
Date: Tue, 3 Oct 2017 08:51:12 -0700 [thread overview]
Message-ID: <CAGXu5jKuGuP4FJVEbWbMfwkoqFvS22d6HpFhqbxcz8vys0yByg@mail.gmail.com> (raw)
In-Reply-To: <20171003100433.GA4931@leverpostej>
On Tue, Oct 3, 2017 at 3:04 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> Hi Kees,
>
> On Mon, Oct 02, 2017 at 12:20:04PM -0700, Kees Cook wrote:
>> As described in the final patch:
>>
>> Nearly all modern compilers support a stack-protector option, and nearly
>> all modern distributions enable the kernel stack-protector, so enabling
>> this by default in kernel builds would make sense. However, Kconfig does
>> not have knowledge of available compiler features, so it isn't safe to
>> force on, as this would unconditionally break builds for the compilers
>> or architectures that don't have support. Instead, this introduces a new
>> option, CONFIG_CC_STACKPROTECTOR_AUTO, which attempts to discover the best
>> possible stack-protector available, and will allow builds to proceed even
>> if the compiler doesn't support any stack-protector.
>>
>> This option is made the default so that kernels built with modern
>> compilers will be protected-by-default against stack buffer overflows,
>> avoiding things like the recent BlueBorne attack. Selection of a specific
>> stack-protector option remains available, including disabling it.
>
> I gave this a spin atop of v4.14-rc3 with a few arm64 toolchains I had
> installed:
>
> * Linaro 17.08 GCC 7.1 // strong
> * Linaro 17.05 GCC 6.1 // strong
> * Linaro 15.08 GCC 5.1 // strong
> * Linaro 14.09 GCC 4.9 // strong
> * Linaro 13.06 GCC 4.8 // none
> * Linaro 13.01 GCC 4.7 // none
>
> AFAICT, the detection is correct, and arm64 toolchains only gained stack
> protector support in GCC 4.9. I manually tested GCC 4.8 and 4.7, and
> got:
>
> warning: -fstack-protector not supported for this target [enabled by default]
>
> ... so that looks good to me.
>
> One thing I noticed was taht even when the build system detects no
> support for stack-protector, it still passes -DCONFIG_CC_STACKPROTECTOR
> to the toolchain. Is that expected?
Oops, that's a mistake. I had a think-o in the Makefile logic. I will
send a follow-up to fix it.
-Kees
--
Kees Cook
Pixel Security
next prev parent reply other threads:[~2017-10-03 15:51 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-02 19:20 [PATCH 0/3] Makefile: Introduce CONFIG_CC_STACKPROTECTOR_AUTO Kees Cook
2017-10-02 19:20 ` [kernel-hardening] " Kees Cook
2017-10-02 19:20 ` Kees Cook
2017-10-02 19:20 ` [PATCH 1/3] sh/boot: Add static stack-protector to pre-kernel Kees Cook
2017-10-02 19:20 ` [kernel-hardening] " Kees Cook
2017-10-02 19:20 ` Kees Cook
2017-10-02 19:20 ` [PATCH 2/3] Makefile: Move stackprotector availability out of Kconfig Kees Cook
2017-10-02 19:20 ` [kernel-hardening] " Kees Cook
2017-10-02 19:20 ` Kees Cook
2017-10-04 14:33 ` Masahiro Yamada
2017-10-04 14:33 ` [kernel-hardening] " Masahiro Yamada
2017-10-04 14:33 ` Masahiro Yamada
2017-10-04 15:13 ` [kernel-hardening] " Greg KH
2017-10-04 15:13 ` Greg KH
2017-10-04 16:22 ` Kees Cook
2017-10-04 16:22 ` Kees Cook
2017-10-04 16:22 ` Kees Cook
2017-10-04 17:15 ` Greg KH
2017-10-04 17:15 ` Greg KH
2017-10-04 17:15 ` Greg KH
2017-10-02 19:20 ` [PATCH 3/3] Makefile: Introduce CONFIG_CC_STACKPROTECTOR_AUTO Kees Cook
2017-10-02 19:20 ` [kernel-hardening] " Kees Cook
2017-10-02 19:20 ` Kees Cook
2017-10-03 10:04 ` [kernel-hardening] [PATCH 0/3] " Mark Rutland
2017-10-03 10:04 ` Mark Rutland
2017-10-03 15:51 ` Kees Cook [this message]
2017-10-03 15:51 ` Kees Cook
2017-10-03 15:51 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGXu5jKuGuP4FJVEbWbMfwkoqFvS22d6HpFhqbxcz8vys0yByg@mail.gmail.com \
--to=keescook@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=dalias@libc.org \
--cc=davem@davemloft.net \
--cc=kernel-hardening@lists.openwall.com \
--cc=labbott@redhat.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=mmarek@suse.com \
--cc=npiggin@gmail.com \
--cc=viro@zeniv.linux.org.uk \
--cc=yamada.masahiro@socionext.com \
--cc=ysato@users.sourceforge.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.