[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1466533948.2756.56.camel@redhat.com>
Date: Tue, 21 Jun 2016 14:32:28 -0400
From: Rik van Riel <riel@...hat.com>
To: kernel-hardening@...ts.openwall.com,
Andy Lutomirski
<luto@...capital.net>
Cc: Jann Horn <jannh@...gle.com>, Andy Lutomirski <luto@...nel.org>,
X86 ML
<x86@...nel.org>,
"linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>,
linux-arch <linux-arch@...r.kernel.org>,
Borislav Petkov <bp@...en8.de>, Nadav Amit <nadav.amit@...il.com>,
Brian
Gerst <brgerst@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Josh Poimboeuf <jpoimboe@...hat.com>, Jann Horn <jann@...jh.net>,
Heiko
Carstens <heiko.carstens@...ibm.com>
Subject: Re: Re: [PATCH v3 06/13] fork: Add generic
vmalloced stack support
On Tue, 2016-06-21 at 10:13 -0700, Kees Cook wrote:
> On Tue, Jun 21, 2016 at 9:59 AM, Andy Lutomirski <luto@...capital.net
> > wrote:
> >
> > I'm tempted to explicitly disallow VM_NO_GUARD in the vmalloc
> > range.
> > It has no in-tree users for non-fixed addresses right now.
> What about the lack of pre-range guard page? That seems like a
> critical feature for this. :)
If VM_NO_GUARD is disallowed, and every vmalloc area has
a guard area behind it, then every subsequent vmalloc area
will have a guard page ahead of it.
I think disallowing VM_NO_GUARD will be all that is required.
The only thing we may want to verify on the architectures that
we care about is that there is nothing mapped immediately before
the start of the vmalloc range, otherwise the first vmalloced
area will not have a guard page below it.
I suspect all the 64 bit architectures are fine in that regard,
with enormous gaps between kernel memory ranges.
--
All Rights Reversed.
Download attachment "signature.asc" of type "application/pgp-signature" (474 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.
