All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Kees Cook <keescook@chromium.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@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-sh@vger.kernel.org, kernel-hardening@lists.openwall.com
Subject: [PATCH 0/3] Makefile: Introduce CONFIG_CC_STACKPROTECTOR_AUTO
Date: Mon, 02 Oct 2017 19:20:04 +0000	[thread overview]
Message-ID: <1506972007-80614-1-git-send-email-keescook@chromium.org> (raw)

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.


This has lived over the weekend in 0-day, which noticed that sh needed
a small fix (which has actually been needed since the addition of the
_STRONG stack-protector, some time ago).

Thanks,

-Kees


WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Kees Cook <keescook@chromium.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@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-sh@vger.kernel.org, kernel-hardening@lists.openwall.com
Subject: [PATCH 0/3] Makefile: Introduce CONFIG_CC_STACKPROTECTOR_AUTO
Date: Mon,  2 Oct 2017 12:20:04 -0700	[thread overview]
Message-ID: <1506972007-80614-1-git-send-email-keescook@chromium.org> (raw)

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.


This has lived over the weekend in 0-day, which noticed that sh needed
a small fix (which has actually been needed since the addition of the
_STRONG stack-protector, some time ago).

Thanks,

-Kees

WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Kees Cook <keescook@chromium.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@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-sh@vger.kernel.org, kernel-hardening@lists.openwall.com
Subject: [kernel-hardening] [PATCH 0/3] Makefile: Introduce CONFIG_CC_STACKPROTECTOR_AUTO
Date: Mon,  2 Oct 2017 12:20:04 -0700	[thread overview]
Message-ID: <1506972007-80614-1-git-send-email-keescook@chromium.org> (raw)

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.


This has lived over the weekend in 0-day, which noticed that sh needed
a small fix (which has actually been needed since the addition of the
_STRONG stack-protector, some time ago).

Thanks,

-Kees

             reply	other threads:[~2017-10-02 19:20 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-02 19:20 Kees Cook [this message]
2017-10-02 19:20 ` [kernel-hardening] [PATCH 0/3] Makefile: Introduce CONFIG_CC_STACKPROTECTOR_AUTO 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
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=1506972007-80614-1-git-send-email-keescook@chromium.org \
    --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=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.