From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752708AbcFUTuH (ORCPT <rfc822;w@1wt.eu>);
	Tue, 21 Jun 2016 15:50:07 -0400
Received: from mout.kundenserver.de ([212.227.126.133]:55161 "EHLO
	mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752639AbcFUTuD (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 21 Jun 2016 15:50:03 -0400
From: Arnd Bergmann <arnd@arndb.de>
To: Rik van Riel <riel@redhat.com>
Cc: kernel-hardening@lists.openwall.com, Andy Lutomirski <luto@amacapital.net>,
        Jann Horn <jannh@google.com>, Andy Lutomirski <luto@kernel.org>,
        X86 ML <x86@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        linux-arch <linux-arch@vger.kernel.org>,
        Borislav Petkov <bp@alien8.de>, Nadav Amit <nadav.amit@gmail.com>,
        Brian Gerst <brgerst@gmail.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Josh Poimboeuf <jpoimboe@redhat.com>, Jann Horn <jann@thejh.net>,
        Heiko Carstens <heiko.carstens@de.ibm.com>
Subject: Re: [kernel-hardening] Re: [PATCH v3 06/13] fork: Add generic vmalloced stack support
Date: Tue, 21 Jun 2016 21:44:13 +0200
Message-ID: <3742830.xcm4l8nxyl@wuerfel>
User-Agent: KMail/5.1.3 (Linux/4.4.0-22-generic; KDE/5.18.0; x86_64; ; )
In-Reply-To: <1466533948.2756.56.camel@redhat.com>
References: <cover.1466466093.git.luto@kernel.org> <CAGXu5jJjihEU0HkSTWJymLZ5y=J03bkBHNgVf9QOSgWz6bf-SQ@mail.gmail.com> <1466533948.2756.56.camel@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Provags-ID: V03:K0:2ccfpxHoF020QkQ5QCuTYYOBa2u8JPUcBXjwRBWHmKhZZN7U122
 tYzTz0dAPEhWUjD0BQbI+mzkkTbpevuuGdpw36Zy/0AvN8eHg6RDcbAtN6MmI1gbzZfo86Y
 Kj+SfJbt5N6m/FPNHeA5UNHr8u3uC/K+Z/84BeZsousLM22586rffklVGGdmbK1rioMuhjp
 ctCPzBJIw1VLR8SFS9iIg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:LKiNLnnlXXs=:eWknBevPXBruFxGsMumnlY
 ocGb4U1U+oX2nhwG9IHnOND5dVFksyr1OgURyJAKBpOp6qAiwa4wFzF865f4tlLBYjh0qyHOV
 B8Q64cN7LRka2EKB0oLRnpFYq3oeaqHXbJdHCUUgJHC20BFD8lKCG+WjrhzaNXQQj5+aKj23p
 xIPx/SfuBIJXCtkfbsArEuicdNdoH2k9DycicNbHJVaRaibqu3QeGNFYMaWxISxhp/zI1Xg2Z
 veiKCHg9cO5ClLfCY4alKajrvlpNLIK+ycfYf9hEY16UU7Kjdfnx41Ezfnm3Kh6Ly/QVXnqQU
 ALNa5oGrkx1wjz8Y9m43xSd+ypIlfkDQpSljnBY3LRwSPgIoCnOCEIM91roy04WdtsArbdSFD
 3Lh9xZiywDoQd6SuLh9YGGb9F3Yalv1R8Y/WPabaoDoWVOzTcVRjx1Dlt96vZmVPTi3uZiY6M
 v5l87qB2U7lAeO4wxIo5iyubg3zV8GNax0H200Q/oja5O+5qxsTGVWbkLweEHafRtHNYQlouI
 6B1fYogNdNhCw3qjaPggoOETU/NoPAXDe+SnjLCIKAipLajwtqOBrh6/xCEQozx9iODYu1NaN
 LPCG3BpXabBOUXU9syiYl4/KLTazKAoLQor5IdAvb1VOGyFSQDKJifwc7UZrdd2yyz4yFQFAJ
 7dioHQCsn1UYZg9H4DcHSY1xAcHCXPw/1yw/6IhtI7yoq3rKl6aATHXFKyN3k8152Rs4fqOpM
 DHU9VsbRu2mWzvur
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tuesday, June 21, 2016 2:32:28 PM CEST Rik van Riel wrote:
> On Tue, 2016-06-21 at 10:13 -0700, Kees Cook wrote:
> > On Tue, Jun 21, 2016 at 9:59 AM, Andy Lutomirski <luto@amacapital.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.

FWIW, ARM has an 8MB guard area between the linear mapping of
physical memory and the start of the vmalloc area. I have not
checked any of the other architectures though.

	Arnd