[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1477951334.8761.15.camel@gmail.com>
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: 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)
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.
