|
Message-ID: <CA+DvKQ+uQD0qyMvwqaRd_sMLBHE5q9pcfOQ+VknBW2==q0NJJA@mail.gmail.com> Date: Tue, 6 Mar 2018 10:16:24 -0500 From: Daniel Micay <danielmicay@...il.com> To: Ingo Molnar <mingo@...nel.org> Cc: Kees Cook <keescook@...omium.org>, Linus Torvalds <torvalds@...ux-foundation.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>, Ard Biesheuvel <ard.biesheuvel@...aro.org>, 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>, Arnd Bergmann <arnd@...db.de>, 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() There are cases that clearing the stack can cover but I don't think it has high importance if all locals were being default initialized to zero. The new stack will end up with gaps from alignment, variables that weren't fully used, etc. where data from an old stack is present. Unless there's something really important left over like a private key, it shouldn't make issues like a before read overflow on the stack much worse. There's an important missing feature which does get covered by this plugin: variable-length arrays can skip past the VMAP_STACK guard pages (as could alloca / large frames if they were actually used). The ideal would probably be both GCC and Clang providing a working, safe implementation of stack probes to enable with VMAP_STACK but they don't do that. I'm not sure it makes sense for the kernel to be working around that downstream though. It's strange because Clang has had a working implementation on Windows for ages where the ABI requires it but for some reason they never provided the option elsewhere. Zeroing locals isn't very expensive because the compiler has a chance to optimize it out when it can figure out it isn't needed and they're almost always used. If there are cases it hurts, it might be possible to fix that by inlining an initialization function so it can see the initialization. From my tests doing it in the entirety of the kernel and Android userspace via a Clang patch (which we use in production), SSP has a much more significant cost. Filling them with a non-zero value is also a nice way to find bugs and I think that will still be true with KMSan available via Clang. There might be cases where there's a large array where the compiler can't remove the zeroing and the call is pretty hot... but we didn't run into any substantial performance costs, although for our niche we only really care about UI latency, battery life, etc. and losing 1-2% throughput for some things is irrelevant.
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.