Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1512938

Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random

Show key headers only | View raw

[Multipart message — attachments visible in raw view] - view raw

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.

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH] fork: make whole stack_canary random Jann Horn <jann@thejh.net> - 2016-10-31 15:10 +0100
  Re: [PATCH] fork: make whole stack_canary random Kees Cook <keescook@chromium.org> - 2016-10-31 17:10 +0100
    Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary  random Jann Horn <jann@thejh.net> - 2016-10-31 17:30 +0100
      Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random Florian Weimer <fw@deneb.enyo.de> - 2016-10-31 21:50 +0100
        Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary  random Jann Horn <jann@thejh.net> - 2016-10-31 22:00 +0100
        Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary  random Daniel Micay <danielmicay@gmail.com> - 2016-10-31 22:00 +0100
          Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary  random Daniel Micay <danielmicay@gmail.com> - 2016-10-31 22:10 +0100
            Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random Florian Weimer <fw@deneb.enyo.de> - 2016-10-31 22:20 +0100
              Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary  random Jann Horn <jann@thejh.net> - 2016-10-31 22:30 +0100
                Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random Florian Weimer <fw@deneb.enyo.de> - 2016-10-31 22:30 +0100
                Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary  random Daniel Micay <danielmicay@gmail.com> - 2016-10-31 22:30 +0100
              Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary  random Daniel Micay <danielmicay@gmail.com> - 2016-10-31 22:30 +0100
                Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random Florian Weimer <fw@deneb.enyo.de> - 2016-10-31 22:40 +0100
                Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary  random Daniel Micay <danielmicay@gmail.com> - 2016-10-31 23:10 +0100
                Re: [kernel-hardening] Re: [PATCH] fork: make whole stack_canary random Florian Weimer <fw@deneb.enyo.de> - 2016-10-31 23:20 +0100

csiph-web