|
Message-ID: <CAK8P3a12YVBK6rtXwubW-0W3XwEbF+BU21MN1Fx8OrA4-2S7vw@mail.gmail.com> Date: Tue, 6 Mar 2018 23:09:45 +0100 From: Arnd Bergmann <arnd@...db.de> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Ard Biesheuvel <ard.biesheuvel@...aro.org>, Daniel Micay <danielmicay@...il.com>, Ingo Molnar <mingo@...nel.org>, Kees Cook <keescook@...omium.org>, Dave Hansen <dave.hansen@...ux.intel.com>, Alexander Popov <alex.popov@...ux.com>, Kernel Hardening <kernel-hardening@...ts.openwall.com>, PaX Team <pageexec@...email.hu>, Brad Spengler <spender@...ecurity.net>, Andy Lutomirski <luto@...nel.org>, Tycho Andersen <tycho@...ho.ws>, Laura Abbott <labbott@...hat.com>, Mark Rutland <mark.rutland@....com>, Borislav Petkov <bp@...en8.de>, Richard Sandiford <richard.sandiford@....com>, Thomas Gleixner <tglx@...utronix.de>, "H . Peter Anvin" <hpa@...or.com>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, "Dmitry V . Levin" <ldv@...linux.org>, Emese Revfy <re.emese@...il.com>, Jonathan Corbet <corbet@....net>, Andrey Ryabinin <aryabinin@...tuozzo.com>, "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>, Thomas Garnier <thgarnie@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>, Alexei Starovoitov <ast@...nel.org>, Josef Bacik <jbacik@...com>, Masami Hiramatsu <mhiramat@...nel.org>, Nicholas Piggin <npiggin@...il.com>, Al Viro <viro@...iv.linux.org.uk>, "David S . Miller" <davem@...emloft.net>, Ding Tianhong <dingtianhong@...wei.com>, David Woodhouse <dwmw@...zon.co.uk>, Josh Poimboeuf <jpoimboe@...hat.com>, Steven Rostedt <rostedt@...dmis.org>, Dominik Brodowski <linux@...inikbrodowski.net>, Juergen Gross <jgross@...e.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Dan Williams <dan.j.williams@...el.com>, Mathias Krause <minipli@...glemail.com>, Vikas Shivappa <vikas.shivappa@...ux.intel.com>, Kyle Huey <me@...ehuey.com>, Dmitry Safonov <dsafonov@...tuozzo.com>, Will Deacon <will.deacon@....com>, X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org> Subject: Re: [PATCH RFC v9 4/7] x86/entry: Erase kernel stack in syscall_trace_enter() On Tue, Mar 6, 2018 at 10:29 PM, Linus Torvalds <torvalds@...ux-foundation.org> wrote: > On Tue, Mar 6, 2018 at 1:21 PM, Arnd Bergmann <arnd@...db.de> wrote: >> >> Right, there are two separate problems: the missing warnings >> and the actual uninitialized use. Allocating the stack slots would >> address both but only at an enormous cost. Assigning a value >> would still have a cost, as it would prevent certain other optimizations, >> and it wouldn't help find the missing initializations, >> but the cost would obviously be much lower. > > What possible optimization would it prevent? > > I cannot think of a single interesting optimization that would be > invalidated by a trivial initialization of 0 to a scalar. > > Yes, it can obviously generate some extra code for the "pass pointer > to uninitialized scalar around to be initialized", where it can now > make that stack slot be initialized to zero - so it can generate extra > code. But disabling an optimization? > > What did you have in mind? The type of optimization that causes my earlier example int g(int c) { int i; if (c) /* gcc optimizes out the condition as nothing else sets i */ i = 1; return i; } to be simplified to int g(int c) { return 1; } Obviously the specific example is a bug and we'd be better off with the zero-initialization, but it was clearly an intentional optimization. The bug report in [1] suggests that the optimization step that causes the loss of information here is "sparse conditional constant propagation" as described in [2]. I have to admit that I understand nearly nothing of that paper, but my memory from earlier discussions with gcc folks is that it will merge code paths for uninitialized variables with the normal case if there is exactly one initialization, or more generally try to eliminate any code path that leads to undefined behavior. By forcing an initialization, I would imagine that this early dead code elimination fails even for the case that a later optimization step can prove that an uninitialized variable use never occurs. Arnd [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 [2] http://www.cs.wustl.edu/~cytron/531Pages/f11/Resources/Papers/cprop.pdf
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.