Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 15 Nov 2017 00:09:30 +0300
From: Alexander Popov <alex.popov@...ux.com>
To: Mark Rutland <mark.rutland@....com>, Andy Lutomirski <luto@...nel.org>
Cc: "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

Thanks, Mark!

Please see my comments below.

On 14.11.2017 19:33, Mark Rutland wrote:
> 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.

Yes. Functions with a big stack frame call track_stack() to update the
lowest_stack value. If CONFIG_VMAP_STACK is disabled, track_stack() is compiled
with a check for detecting stack depth overflow. This check is what I'm asking
about.

> 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).

Yes.

Actually the used part of the kernel stack is not zeroed. It is filled by
STACKLEAK_POISON (-0xBEEF) which points to the unused hole in x86_64 virtual
memory map.

> That, and catching some stack overflows in the absence of VMAP'd stacks.

The STACKLEAK plugin also adds check_alloca() call before each alloca to block
"Stack Clash" attack against kernel stack.

More details and statistics are available in the cover letter and commit
messages in this patch series.

Best regards,
Alexander

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.