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 22:38:00 +0100
From:   Florian Weimer <fw@...eb.enyo.de>
To:     Daniel Micay <danielmicay@...il.com>
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

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