From: Marco Elver <elver@google.com>
To: Kees Cook <keescook@chromium.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Elena Reshetova <elena.reshetova@intel.com>,
Mark Rutland <mark.rutland@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
Alexander Potapenko <glider@google.com>,
Jann Horn <jannh@google.com>,
Peter Collingbourne <pcc@google.com>,
kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org,
llvm@lists.linux.dev, linux-toolchains@vger.kernel.org
Subject: randomize_kstack: To init or not to init?
Date: Thu, 9 Dec 2021 10:58:01 +0100 [thread overview]
Message-ID: <YbHTKUjEejZCLyhX@elver.google.com> (raw)
Clang supports CONFIG_INIT_STACK_ALL_ZERO, which appears to be the
default since dcb7c0b9461c2, which is why this came on my radar. And
Clang also performs auto-init of allocas when auto-init is on
(https://reviews.llvm.org/D60548), with no way to skip. As far as I'm
aware, GCC 12's upcoming -ftrivial-auto-var-init= doesn't yet auto-init
allocas.
add_random_kstack_offset() uses __builtin_alloca() to add a stack
offset. This means, when CONFIG_INIT_STACK_ALL_{ZERO,PATTERN} is
enabled, add_random_kstack_offset() will auto-init that unused portion
of the stack used to add an offset.
There are several problems with this:
1. These offsets can be as large as 1023 bytes. Performing
memset() on them isn't exactly cheap, and this is done on
every syscall entry.
2. Architectures adding add_random_kstack_offset() to syscall
entry implemented in C require them to be 'noinstr' (e.g. see
x86 and s390). The potential problem here is that a call to
memset may occur, which is not noinstr.
A defconfig kernel with Clang 11 and CONFIG_VMLINUX_VALIDATION shows:
| vmlinux.o: warning: objtool: do_syscall_64()+0x9d: call to memset() leaves .noinstr.text section
| vmlinux.o: warning: objtool: do_int80_syscall_32()+0xab: call to memset() leaves .noinstr.text section
| vmlinux.o: warning: objtool: __do_fast_syscall_32()+0xe2: call to memset() leaves .noinstr.text section
| vmlinux.o: warning: objtool: fixup_bad_iret()+0x2f: call to memset() leaves .noinstr.text section
Switching to INIT_STACK_ALL_NONE resolves the warnings as expected.
To figure out what the right solution is, the first thing to figure out
is, do we actually want that offset portion of the stack to be
auto-init'd?
There are several options:
A. Make memset (and probably all other mem-transfer functions)
noinstr compatible, if that is even possible. This only solves
problem #2.
B. A workaround could be using a VLA with
__attribute__((uninitialized)), but requires some restructuring
to make sure the VLA remains in scope and other trickery to
convince the compiler to not give up that stack space.
C. Introduce a new __builtin_alloca_uninitialized().
I think #C would be the most robust solution, but means this would
remain as-is for a while.
Preferences?
Thanks,
-- Marco
next reply other threads:[~2021-12-09 9:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-09 9:58 Marco Elver [this message]
2021-12-09 10:27 ` randomize_kstack: To init or not to init? Peter Zijlstra
2021-12-09 12:58 ` Marco Elver
2021-12-09 20:16 ` Segher Boessenkool
2021-12-09 20:33 ` Marco Elver
2021-12-20 7:00 ` Marco Elver
2021-12-09 20:48 ` Kees Cook
2021-12-09 20:54 ` Marco Elver
2021-12-09 21:11 ` Alexander Potapenko
2021-12-10 0:01 ` Segher Boessenkool
2021-12-09 21:14 ` Kees Cook
2021-12-09 21:16 ` Jann Horn
2021-12-09 21:40 ` Marco Elver
2021-12-11 17:01 ` David Laight
2021-12-11 20:20 ` Segher Boessenkool
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=YbHTKUjEejZCLyhX@elver.google.com \
--to=elver@google.com \
--cc=elena.reshetova@intel.com \
--cc=glider@google.com \
--cc=jannh@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-toolchains@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=pcc@google.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).