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

Groups > linux.kernel > #1512921

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

Show all headers | View raw

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

On Mon, 2016-10-31 at 22:22 +0100, Jann Horn wrote:
> On Mon, Oct 31, 2016 at 10:10:41PM +0100, Florian Weimer wrote:
> > * Daniel Micay:
> > 
> > > > It makes a lot of sense on x86_64 where it means the canary is
> > > > still 56 bits. Also, you want -fstack-check for protecting again
> > > > stack overflows rather than stack *buffer* overflow. SSP won't
> > > > really help you in that regard. Sadly, while -fstack-check now
> > > > works well in GCC 6 with little performance cost, it's not
> > > > really a
> > 
> > I think GCC still does not treat the return address push on
> > architectures which have such a CALL instruction as an implicit
> > stack
> > probe.
> > 
> > > > complete feature (and Clang impls it as a no-op!).
> > 
> > How many guard pages at the end of the stack does the kernel
> > guarantee?  I saw some -fstack-check-generated code which seemed to
> > jump over a single guard page.
> 
> Until recently: Zero, no guard pages below stacks, stack overflow
> goes straight into some other allocation.
> Now: One guard page, thanks to a lot of work by Andy Lutomirski.
> (I think that change is in the current 4.9-rc3 kernel, but not in
> any stable kernel yet.)

I think Florian is talking about the main thread stack in userspace.

Thus the next part about how it doesn't actually *guarantee* a guard
page at all right now for that. Userspace has to work around that if
it's worried about it (it can't really happen in practice though, but
it's not great that mmap with a hint + no MAP_FIXED can break it).

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