Date: Mon, 2 Oct 2017 12:20:04 -0700 From: Kees Cook <keescook@...omium.org> To: Andrew Morton <akpm@...ux-foundation.org> Cc: Kees Cook <keescook@...omium.org>, Masahiro Yamada <yamada.masahiro@...ionext.com>, Michal Marek <mmarek@...e.com>, Yoshinori Sato <ysato@...rs.sourceforge.jp>, Rich Felker <dalias@...c.org>, Ingo Molnar <mingo@...nel.org>, "David S. Miller" <davem@...emloft.net>, Nicholas Piggin <npiggin@...il.com>, Al Viro <viro@...iv.linux.org.uk>, Laura Abbott <labbott@...hat.com>, linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org, linux-sh@...r.kernel.org, kernel-hardening@...ts.openwall.com Subject: [PATCH 0/3] Makefile: Introduce CONFIG_CC_STACKPROTECTOR_AUTO 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.