[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171114163306.3pr4a4s36t7mbj2f@salmiak>
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.
