Re: [PATCH] mm: larger stack guard gap, between vmas

From: Michal Hocko <mhocko@kernel.org>
To: Willy Tarreau <w@1wt.eu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Ben Hutchings <ben@decadent.org.uk>,
	Hugh Dickins <hughd@google.com>, Oleg Nesterov <oleg@redhat.com>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	Rik van Riel <riel@redhat.com>,
	Larry Woodman <lwoodman@redhat.com>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	Tony Luck <tony.luck@intel.com>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>,
	Helge Diller <deller@gmx.de>,
	James Hogan <james.hogan@imgtec.com>,
	Laura Abbott <labbott@redhat.com>, Greg KH <greg@kroah.com>,
	"security@kernel.org" <security@kernel.org>,
	linux-distros@vs.openwall.org,
	Qualys Security Advisory <qsa@qualys.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Ximin Luo <infinity0@debian.org>
Subject: Re: [PATCH] mm: larger stack guard gap, between vmas
Date: Wed, 5 Jul 2017 10:24:41 +0200	[thread overview]
Message-ID: <20170705082441.GC14538@dhcp22.suse.cz> (raw)
In-Reply-To: <20170705081443.GA23453@1wt.eu>

On Wed 05-07-17 10:14:43, 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.

Yes, this is what my patch does [1]. Or did I miss your point?

> That wouldn't solve the libreoffice issue though, given the lower page
> is RWX.

unfortunatelly yes. We only have limited room to address this issue
though. We could add per task (mm) stack_gap limit (controlled either
via proc or prctl) and revert back to 1 page for the specific program
but I would be really careful to add some more hack into the stack
expansion code.

[1] http://lkml.kernel.org/r/20170704093538.GF14722@dhcp22.suse.cz
-- 
Michal Hocko
SUSE Labs