Date: Tue, 14 Nov 2017 16:33:07 +0000 From: Mark Rutland <mark.rutland@....com> To: Andy Lutomirski <luto@...nel.org> Cc: Alexander Popov <alex.popov@...ux.com>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, Kees Cook <keescook@...omium.org>, PaX Team <pageexec@...email.hu>, Brad Spengler <spender@...ecurity.net>, Ingo Molnar <mingo@...nel.org>, Peter Zijlstra <peterz@...radead.org>, Tycho Andersen <tycho@...ker.com>, Laura Abbott <labbott@...hat.com>, Ard Biesheuvel <ard.biesheuvel@...aro.org>, Borislav Petkov <bp@...en8.de>, Thomas Gleixner <tglx@...utronix.de>, "H . Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org> Subject: Re: [PATCH RFC v5 2/5] gcc-plugins: Add STACKLEAK plugin for tracking the kernel stack On Tue, Nov 14, 2017 at 08:13:43AM -0800, Andy Lutomirski wrote: > What does the STEAKLACK plugin actually do? I haven't followed this enough. The plugin adds instrumentation to track the maximum stack depth, though only functions with a sufficiently large stackframe are instrumented. The basic idea is that this can then be used to lazily zero stack after use (just before return to userspace), to minimize the risk of problems resulting from uninitialized variables (either copied to userspace and leaking secrets, or controlled by userspace and influencing the kernel). That, and catching some stack overflows in the absence of VMAP'd stacks. Thanks, Mark.
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.