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

Groups > linux.kernel > #1512924

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

Show all headers | View raw

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

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.

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

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