Date: Tue, 4 Jul 2017 20:39:27 +0200
From: Willy Tarreau <w@1wt.eu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michal Hocko <mhocko@kernel.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: <20170704183927.GH22013@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>
 <20170704155140.GC22013@1wt.eu>
 <20170704172247.GA6178@dhcp22.suse.cz>
 <CA+55aFyAunJqeoZfcOFjPS3ZQvm_zM2xztvwxkcJ5fhk1Xzmqw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+55aFyAunJqeoZfcOFjPS3ZQvm_zM2xztvwxkcJ5fhk1Xzmqw@mail.gmail.com>
User-Agent: Mutt/1.6.1 (2016-04-27)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1280
Lines: 28

On Tue, Jul 04, 2017 at 11:37:15AM -0700, Linus Torvalds wrote:
> On Tue, Jul 4, 2017 at 10:22 AM, Michal Hocko <mhocko@kernel.org> wrote:
> >
> > Well, I've been thinking about this some more and the more I think about
> > it the less I am convinced we should try to be clever here. Why? Because
> > as soon as somebody tries to manage stacks explicitly you cannot simply
> > assume anything about the previous mapping. Say some interpret uses
> > [ mngmnt data][red zone]                 <--[- MAP_GROWSDOWN ]
> >
> > Now if we consider the red zone's (PROT_NONE) prev mapping we would fail
> > the expansion even though we haven't hit the red zone and that is
> > essentially what the Java and rust bugs are about. So we just risk yet
> > another regression.
> 
> Ack.
> 
> Let's make the initial version at least only check the first vma.
> 
> The long-term fix for this is to have the binaries do proper stack
> expansion probing anyway, and it's quite possible that people who do
> their own stack redzoning by adding a PROT_NONE thing already do that
> proper fix (eg the Java stack may simply not *have* those big crazy
> structures on it in the first place).

But what is wrong with stopping the loop as soon as the distance gets
larger than the stack_guard_gap ?

Willy