Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752931AbdGFFdM (ORCPT ); Thu, 6 Jul 2017 01:33:12 -0400 Received: from la.guarana.org ([173.254.219.205]:55096 "EHLO la.guarana.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752892AbdGFFdL (ORCPT ); Thu, 6 Jul 2017 01:33:11 -0400 Date: Thu, 6 Jul 2017 01:33:04 -0400 From: Kevin Easton To: Michal Hocko Cc: Ben Hutchings , Linus Torvalds , Willy Tarreau , Hugh Dickins , Oleg Nesterov , "Jason A. Donenfeld" , Rik van Riel , Larry Woodman , "Kirill A. Shutemov" , Tony Luck , "James E.J. Bottomley" , Helge Diller , James Hogan , Laura Abbott , Greg KH , "security@kernel.org" , Qualys Security Advisory , LKML , Ximin Luo Subject: Re: [PATCH] mm: larger stack guard gap, between vmas Message-ID: <20170706053304.GA18064@la.guarana.org> References: <20170704084122.GC14722@dhcp22.suse.cz> <20170704093538.GF14722@dhcp22.suse.cz> <20170704094728.GB22013@1wt.eu> <20170704104211.GG14722@dhcp22.suse.cz> <20170704113611.GA4732@decadent.org.uk> <1499209315.2707.29.camel@decadent.org.uk> <1499257180.2707.34.camel@decadent.org.uk> <20170705142354.GB21220@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170705142354.GB21220@dhcp22.suse.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2186 Lines: 51 On Wed, Jul 05, 2017 at 04:23:56PM +0200, Michal Hocko wrote: > On Wed 05-07-17 13:19:40, Ben Hutchings wrote: > > On Tue, 2017-07-04 at 16:31 -0700, Linus Torvalds wrote: > > > On Tue, Jul 4, 2017 at 4:01 PM, Ben Hutchings > > > wrote: > > > > > > > > We have: > > > > > > > > bottom = 0xff803fff > > > > sp =?????0xffffb178 > > > > > > > > The relevant mappings are: > > > > > > > > ff7fc000-ff7fd000 rwxp 00000000 00:00 0 > > > > fffdd000-ffffe000 rw-p 00000000 00:00 > > > > 0??????????????????????????????????[stack] > > > > > > Ugh. So that stack is actually 8MB in size, but the alloca() is about > > > to use up almost all of it, and there's only about 28kB left between > > > "bottom" and that 'rwx' mapping. > > > > > > Still, that rwx mapping is interesting: it is a single page, and it > > > really is almost exactly 8MB below the stack. > > > > > > In fact, the top of stack (at 0xffffe000) is *exactly* 8MB+4kB from > > > the top of that odd one-page allocation (0xff7fd000). > > > > > > Can you find out where that is allocated? Perhaps a breakpoint on > > > mmap, with a condition to catch that particular one? > > [...] > > > > Found it, and it's now clear why only i386 is affected: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/tip/src/os/linux/vm/os_linux.cpp#l4852 > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/tip/src/os_cpu/linux_x86/vm/os_linux_x86.cpp#l881 > > This is really worrying. This doesn't look like a gap at all. It is a > mapping which actually contains a code and so we should absolutely not > allow to scribble over it. So I am afraid the only way forward is to > allow per process stack gap and run this particular program to have a > smaller gap. We basically have two ways. Either /proc//$file or > a prctl inherited on exec. The later is a smaller code. What do you > think? On the plus side, the code in that page (a single RET) is only executed once when the workaround function is called. Notice that 'codebuf' is never even returned out of that function. The only reason they even leave that page mapped is to stop the exec shield limit from being lowered on them again. - Kevin