[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211209201616.GU614@gate.crashing.org>
Date: Thu, 9 Dec 2021 14:16:16 -0600
From: Segher Boessenkool <segher@...nel.crashing.org>
To: Marco Elver <elver@...gle.com>
Cc: Kees Cook <keescook@...omium.org>,
Thomas Gleixner <tglx@...utronix.de>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Elena Reshetova <elena.reshetova@...el.com>,
Mark Rutland <mark.rutland@....com>,
Peter Zijlstra <peterz@...radead.org>,
Alexander Potapenko <glider@...gle.com>,
Jann Horn <jannh@...gle.com>,
Peter Collingbourne <pcc@...gle.com>,
kasan-dev@...glegroups.com, linux-kernel@...r.kernel.org,
llvm@...ts.linux.dev, linux-toolchains@...r.kernel.org
Subject: Re: randomize_kstack: To init or not to init?
On Thu, Dec 09, 2021 at 10:58:01AM +0100, Marco Elver wrote:
> 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.
The space allocated by alloca is not an automatic variable, so of course
it is not affected by this compiler flag. And it should not, this flag
is explicitly for *small fixed-size* stack variables (initialising
others can be much too expensive).
> C. Introduce a new __builtin_alloca_uninitialized().
That is completely backwards. That is the normal behaviour of alloca
already. Also you can get __builtin_alloca inserted by the compiler
(for a variable length array for example), and you typically do not want
those initialised either, for the same reasons.
Segher
Powered by blists - more mailing lists