linux-kernel - Re: [kernel-hardening] Re: [PATCH] fork: make whole stack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 31 Oct 2016 18:02:14 -0400
From:   Daniel Micay <danielmicay@...il.com>
To:     Florian Weimer <fw@...eb.enyo.de>
Cc:     Jann Horn <jann@...jh.net>, Kees Cook <keescook@...omium.org>,
        kernel-hardening@...ts.openwall.com,
        Andrew Morton <akpm@...ux-foundation.org>,
        Michal Hocko <mhocko@...e.com>, Ingo Molnar <mingo@...nel.org>,
        Andy Lutomirski <luto@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary
 random

On Mon, 2016-10-31 at 22:38 +0100, Florian Weimer wrote:
> * Daniel Micay:
> 
> > -fstack-stack is supposed to handle a single guard by default, and
> > that's all there is for thread stacks by default.
> 
> Okay, then I'll really have to look at the probing offsets again.
> It's been on my to-do list since about 2012, and arguably, it *is* a
> user-space thing.

This is concerning too:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66479

It might be prevented for VLAs by using -fsanitize=vla-bound -fsanitize-
trap=vla-bound but probably not alloca (or the older -fsanitize-
undefined-trap-on-error for GCC,  since for some reason it doesn't seem
to have the new way).

> And I just realized that we should probably fail at dlopen time if
> some tries to open a DSO which needs an executable stack, rather than
> silently changing all thread stacks to executable. *sigh*
> 
> > > > Note: talking about userspace after the entropy bit. The kernel
> > > > doesn't
> > > > really -fstack-check, at least in even slightly sane code...
> > > 
> > >  
> > > There used to be lots of discussions about kernel stack sizes ...
> > 
> > It should just be banning VLAs, alloca and large stack frames
> > though, if
> > it's not already. There wasn't even support for guard pages with
> > kernel
> > stacks until recently outside grsecurity,
> 
> Which is not surprising, considering that one prime motivation for
> small stacks was to conserve 32-bit address space.  But I'm glad that
> there is now a guard page.  Hopefully, it does not affect performance,
> and on 64-bit, at least there isn't the address space limit to worry
> about.

I think it might actually improve performance overall.

> > and -fstack-check relies on them so it doesn't seem like a great
> > solution for the kernel.
> 
> -fsplit-stack could enforce stack usage limits even without guard
> pages, but of course, there is some run-time overhead, and the limit
> has to come from somewhere (typically the TCB).

Yeah, that's how Rust provided stack safety on LLVM. They ended up
removing it and they only have stack safety on Windows now, since LLVM
doesn't yet provide stack probing outside Windows. So much for being a
memory safe language... it's ultimately LLVM's fault though. There were
actually working patches submitted for this by people working on Rust
but *it never landed* due to endless bikeshedding + scope creep.
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)