Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751905AbdGEQUr (ORCPT <rfc822;w@1wt.eu>);
        Wed, 5 Jul 2017 12:20:47 -0400
Received: from mail-oi0-f67.google.com ([209.85.218.67]:34369 "EHLO
        mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751850AbdGEQUn (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 5 Jul 2017 12:20:43 -0400
MIME-Version: 1.0
In-Reply-To: <CALCETrW5P8ZhuOJ4bL0x+hx52RdFkG4_x0qAQofrdBi2JavxmA@mail.gmail.com>
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>
 <1499257180.2707.34.camel@decadent.org.uk> <20170705142354.GB21220@dhcp22.suse.cz>
 <CALCETrW5P8ZhuOJ4bL0x+hx52RdFkG4_x0qAQofrdBi2JavxmA@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed, 5 Jul 2017 09:20:41 -0700
X-Google-Sender-Auth: JVTNJehnRSbs4zaniaPWt-6zcSw
Message-ID: <CA+55aFwn3bbfxXMTafQVXz0nx5hWTUzQFdaqOFvJSY96Muc3VA@mail.gmail.com>
Subject: Re: [PATCH] mm: larger stack guard gap, between vmas
To: Andy Lutomirski <luto@kernel.org>
Cc: Michal Hocko <mhocko@kernel.org>, Ben Hutchings <ben@decadent.org.uk>,
        Willy Tarreau <w@1wt.eu>, 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>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1211
Lines: 28

On Wed, Jul 5, 2017 at 9:15 AM, Andy Lutomirski <luto@kernel.org> wrote:
> On Wed, Jul 5, 2017 at 7:23 AM, Michal Hocko <mhocko@kernel.org> wrote:
>>
>> This is really worrying. This doesn't look like a gap at all. It is a
>> mapping which actually contains a code and so we should absolutely not
>> allow to scribble over it. So I am afraid the only way forward is to
>> allow per process stack gap and run this particular program to have a
>> smaller gap. We basically have two ways. Either /proc/<pid>/$file or
>> a prctl inherited on exec. The later is a smaller code. What do you
>> think?
>
> Why inherit on exec?

.. because the whole point is that you have an existing binary that breaks.

So you need to be able to wrap it in "let's lower the stack gap, then
run that known-problematic binary".

If you think the problem is solved by recompiling existing binaries,
then why are we doing this kernel hack to begin with? The *real*
solution was always to just fix the damn compiler and ABI.

That *real* solution is simple and needs no kernel support at all.

In other words, *ALL* of the kernel work in this area is purely to
support existing binaries. Don't overlook that fact.

                 Linus