Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751734AbdGEOUJ (ORCPT ); Wed, 5 Jul 2017 10:20:09 -0400 Received: from mx2.suse.de ([195.135.220.15]:56139 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751630AbdGEOUH (ORCPT ); Wed, 5 Jul 2017 10:20:07 -0400 Date: Wed, 5 Jul 2017 16:19:57 +0200 From: Michal Hocko To: Ben Hutchings Cc: Willy Tarreau , Linus Torvalds , 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" , linux-distros@vs.openwall.org, Qualys Security Advisory , LKML , Ximin Luo Subject: Re: [PATCH] mm: larger stack guard gap, between vmas Message-ID: <20170705141956.GA21220@dhcp22.suse.cz> 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> <20170705063645.GA10354@dhcp22.suse.cz> <20170705081443.GA23453@1wt.eu> <1499257314.2707.36.camel@decadent.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1499257314.2707.36.camel@decadent.org.uk> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1650 Lines: 31 On Wed 05-07-17 13:21:54, Ben Hutchings wrote: > On Wed, 2017-07-05 at 10:14 +0200, Willy Tarreau wrote: > > On Wed, Jul 05, 2017 at 08:36:46AM +0200, Michal Hocko wrote: > > > PROT_NONE would explicitly fault but we would simply > > > run over this mapping too easily and who knows what might end up below > > > it. So to me the guard gap does its job here. > > > > I tend to think that applications that implement their own stack guard > > using PROT_NONE also assume that they will never perfom unchecked stack > > allocations larger than their own guard, thus the condition above should > > never happen. Otherwise they're bogus and/or vulnerable by design and it > > is their responsibility to fix it. > > > > Thus maybe if that helps we could even relax some of the stack guard > > checks as soon as we meet a PROT_NONE area, allowing VMAs to be tightly > > packed if the application knows what it's doing. That wouldn't solve > > the libreoffice issue though, given the lower page is RWX. > > How about, instead of looking at permissions, we remember whether vmas > were allocated with MAP_FIXED and ignore those when evaluating the gap? To be honest I really hate this. The same way as any other heuristics where we try to guess the gap which will not fault to let userspace know something is wrong. And the Java example just proves the point AFAIU. The mapping we clash on is _not_ a gap. It is a real mapping we should rather not scribble over. It contains a code to execute and that is even more worrying. So I guess the _only_ sane way forward for this case is to reduce stack gap for the particular code. -- Michal Hocko SUSE Labs