Date: Wed, 5 Jul 2017 10:14:43 +0200
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
Message-ID: <20170705081443.GA23453@1wt.eu>
References: <1499126133.2707.20.camel@decadent.org.uk>
 <CA+55aFzMX72+Kb=zNgjCf6UfPt+C+e7WDp_rpbSLuOVx1k7iqg@mail.gmail.com>
 <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>
 <CA+55aFzjibuaV=GBZQN8KOaCpf1P3B1abJCYGaxEM9RVpf9fXg@mail.gmail.com>
 <20170705063645.GA10354@dhcp22.suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170705063645.GA10354@dhcp22.suse.cz>
User-Agent: Mutt/1.6.1 (2016-04-27)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 840
Lines: 17

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.

Willy