Date: Thu, 6 Jul 2017 10:24:06 +0200
From: Willy Tarreau <w@1wt.eu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ben Hutchings <ben@decadent.org.uk>, Michal Hocko <mhocko@kernel.org>,
        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>,
        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: <20170706082406.GA25812@1wt.eu>
References: <20170704113611.GA4732@decadent.org.uk>
 <1499209315.2707.29.camel@decadent.org.uk>
 <CA+55aFzjibuaV=GBZQN8KOaCpf1P3B1abJCYGaxEM9RVpf9fXg@mail.gmail.com>
 <1499257180.2707.34.camel@decadent.org.uk>
 <20170705142354.GB21220@dhcp22.suse.cz>
 <1499268300.2707.41.camel@decadent.org.uk>
 <20170705165845.GB4732@decadent.org.uk>
 <CA+55aFz=xj_1uBB9yY6rjUfH2_nHbUriPWtzxz=Wj_6Rj8tgtw@mail.gmail.com>
 <1499297724.2707.56.camel@decadent.org.uk>
 <CA+55aFzCAgBsWGuhPwaX655E6isQgG8U7ZKe4opKxbq6OJ6GHQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+55aFzCAgBsWGuhPwaX655E6isQgG8U7ZKe4opKxbq6OJ6GHQ@mail.gmail.com>
User-Agent: Mutt/1.6.1 (2016-04-27)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1119
Lines: 23

On Wed, Jul 05, 2017 at 04:51:06PM -0700, Linus Torvalds wrote:
> On Wed, Jul 5, 2017 at 4:35 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> >>
> >> And I think your second patch breaks that "use a really large value to
> >> approximate infinity" case that definitely has existed as a pattern.
> >
> > Right.  Well that seems to leave us with remembering the MAP_FIXED flag
> > and using that as the condition to ignore the previous mapping.
> 
> I'm not particularly happy about having a MAP_FIXED special case, but
> yeah, I'm not seeing a lot of alternatives.

We can possibly refine it like this :
  - use PROT_NONE as a mark for the end of the stack and consider the
    application doing this knows exactly what it's doing ;

  - use other MAP_FIXED as a limit for a shorter gap (ie 4kB), considering
    that 1) it used to work like this for many years, and 2) if an application
    is forcing a MAP_FIXED just below the stack and at the same time uses
    large alloca() or VLA it's definitely bogus and looking for unfixable
    trouble. Not allowing this means we break existing applications anyway.

Willy