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

From: Willy Tarreau <w@1wt.eu>
To: Michal Hocko <mhocko@kernel.org>
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 11:15:31 +0200	[thread overview]
Message-ID: <20170705091531.GA23526@1wt.eu> (raw)
In-Reply-To: <20170705082441.GC14538@dhcp22.suse.cz>

On Wed, Jul 05, 2017 at 10:24:41AM +0200, Michal Hocko wrote:
> > 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?

Sorry you're right, I got my mind confused when looking at the
libreoffice dump and for whatever reason ended up thinking we were
just considering that page as part of the gap and not being a marker
for the bottom. Never mind.

> > 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.

Actually one option could be to have a sysctl causing a warning to be
emitted when hitting the stack guard instead of killing the process. We
could think for example that once this warning is emitted, the guard is
reduced to 64kB (I think it was the size before) and the application can
continue to run. That could help problematic applications getting fixed
quickly. And in environments with lots of local users it would be
dissuasive enough to avoid users trying their luck on setuid binaries.

Just my two cents,
Willy