From: glider@google.com
To: yamada.masahiro@socionext.com, keescook@chromium.org, jmorris@namei.org
Cc: maze@google.com, ndesaulniers@google.com,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org,
Alexander Potapenko <glider@google.com>
Subject: [PATCH] [RFC] security: allow using Clang's zero initialization for stack variables
Date: Sun, 14 Jun 2020 16:45:34 +0200 [thread overview]
Message-ID: <20200614144534.237035-1-glider@google.com> (raw)
In addition to -ftrivial-auto-var-init=pattern (used by
CONFIG_INIT_STACK_ALL now) Clang also supports zero initialization for
locals enabled by -ftrivial-auto-var-init=zero.
The future of this flag is still being debated, see
https://bugs.llvm.org/show_bug.cgi?id=45497
Right now it is guarded by another flag,
-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang,
which means it may not be supported by future Clang releases.
Another possible resolution is that -ftrivial-auto-var-init=zero will
persist (as certain users have already started depending on it), but the
name of the guard flag will change.
In the meantime, zero initialization has proven itself as a good
production mitigation measure against uninitialized locals. Unlike
pattern initialization, which has a higher chance of triggering existing
bugs, zero initialization provides safe defaults for strings, pointers,
indexes, and sizes. On the other hand, pattern initialization remains
safer for return values.
Performance-wise, the difference between pattern and zero initialization
is usually negligible, although the generated code for zero
initialization is more compact.
The proposed config, CONFIG_USE_CLANG_ZERO_INITIALIZATION, makes
CONFIG_INIT_STACK_ALL use zero initialization if the corresponding flags
are supported by Clang.
Cc: Kees Cook <keescook@chromium.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Alexander Potapenko <glider@google.com>
---
Makefile | 15 ++++++++++++++-
security/Kconfig.hardening | 16 ++++++++++++++++
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index fd31992bf918..2860bad7e39a 100644
--- a/Makefile
+++ b/Makefile
@@ -802,9 +802,22 @@ KBUILD_CFLAGS += -fomit-frame-pointer
endif
endif
-# Initialize all stack variables with a pattern, if desired.
+# Initialize all stack variables, if desired.
ifdef CONFIG_INIT_STACK_ALL
+
+# Use pattern initialization by default.
+ifndef CONFIG_USE_CLANG_ZERO_INITIALIZATION
KBUILD_CFLAGS += -ftrivial-auto-var-init=pattern
+else
+
+ifdef CONFIG_CC_HAS_AUTO_VAR_ZERO_INIT
+# Future support for zero initialization is still being debated, see
+# https://bugs.llvm.org/show_bug.cgi?id=45497. These flags are subject to being
+# renamed or dropped.
+KBUILD_CFLAGS += -ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
+endif
+
+endif
endif
DEBUG_CFLAGS := $(call cc-option, -fno-var-tracking-assignments)
diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening
index af4c979b38ee..299d27c6d78c 100644
--- a/security/Kconfig.hardening
+++ b/security/Kconfig.hardening
@@ -22,6 +22,9 @@ menu "Memory initialization"
config CC_HAS_AUTO_VAR_INIT
def_bool $(cc-option,-ftrivial-auto-var-init=pattern)
+config CC_HAS_AUTO_VAR_ZERO_INIT
+ def_bool $(cc-option,-ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang)
+
choice
prompt "Initialize kernel stack variables at function entry"
default GCC_PLUGIN_STRUCTLEAK_BYREF_ALL if COMPILE_TEST && GCC_PLUGINS
@@ -100,6 +103,19 @@ choice
endchoice
+config USE_CLANG_ZERO_INITIALIZATION
+ bool "Use Clang's zero initialization for local variables"
+ depends on CC_HAS_AUTO_VAR_ZERO_INIT
+ depends on INIT_STACK_ALL
+ help
+ If set, uses zeros instead of 0xAA to initialize local variables in
+ INIT_STACK_ALL. Zeroing the stack provides safer defaults for strings,
+ pointers, indexes, and sizes. The downsides are less-safe defaults for
+ return values, and exposing fewer bugs where the underlying code
+ relies on zero initialization.
+ The corresponding flag isn't officially supported by Clang and may
+ sooner or later go away or get renamed.
+
config GCC_PLUGIN_STRUCTLEAK_VERBOSE
bool "Report forcefully initialized variables"
depends on GCC_PLUGIN_STRUCTLEAK
--
2.27.0.290.gba653c62da-goog
next reply other threads:[~2020-06-14 14:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-14 14:45 glider [this message]
2020-06-14 17:04 ` [PATCH] [RFC] security: allow using Clang's zero initialization for stack variables Kees Cook
2020-06-14 17:16 ` Alexander Potapenko
2020-06-14 18:43 ` 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=20200614144534.237035-1-glider@google.com \
--to=glider@google.com \
--cc=jmorris@namei.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=maze@google.com \
--cc=ndesaulniers@google.com \
--cc=yamada.masahiro@socionext.com \
/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.