[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1477948871.8761.9.camel@gmail.com>
Date: Mon, 31 Oct 2016 17:21:11 -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:10 +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.
>
> The other thing I've seen which could impact the effectiveness of
> -fstack-check: mmap *without* MAP_FIXED and a hint within stack
> allocation can create a mapping inside the stack. That's rather
> surprising, and I'm not sure if the net result is that there actually
> is a guard page in all cases.
It's not ideal but userspace can work around it. OpenJDK and ART both do
something like walking to the end of the main thread stack during init
to install their own guard region. ART then uses all but the last guard
page it installed as a red zone to handle out-of-stack (not sure about
OpenJDK).
-fstack-stack is supposed to handle a single guard by default, and
that's all there is for thread stacks by default.
> > 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, and -fstack-check relies on
them so it doesn't seem like a great solution for the kernel.
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.
