MIME-Version: 1.0
In-Reply-To: <1499257314.2707.36.camel@decadent.org.uk>
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> <20170705081443.GA23453@1wt.eu> <1499257314.2707.36.camel@decadent.org.uk>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed, 5 Jul 2017 09:06:01 -0700
Message-ID: <CA+55aFwpSVZRKfNLSR+QfJA_2LfRnxuLNbp6Ld6nac1XziDspA@mail.gmail.com>
Subject: Re: [PATCH] mm: larger stack guard gap, between vmas
To: Ben Hutchings <ben@decadent.org.uk>
Cc: Willy Tarreau <w@1wt.eu>, 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>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 889
Lines: 23

On Wed, Jul 5, 2017 at 5:21 AM, Ben Hutchings <ben@decadent.org.uk> wrote:
>
> How about, instead of looking at permissions, we remember whether vmas
> were allocated with MAP_FIXED and ignore those when evaluating the gap?

No, I think that's a bad idea. There's tons of good reasons to use
MAP_FIXED, and real programs do it all the time.

I'd much rather just do something special for the Java case, either
recognizing that particular pattern, or (and this is likely what we'll
have to do) just have a per-process stack limit that

 (a) will be reset by suid transitions etc security boundaries

 (b) you can just set back to 4kB for the specific Java case.

because I'd rather make this be a very conscious thing rather than a
random hack.

The PROT_NONE thing made tons of conceptual sense ("let people do
their own guard mappings"). The MAP_FIXED thing does not.

             Linus