From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754252AbdGJS35 (ORCPT <rfc822;w@1wt.eu>);
        Mon, 10 Jul 2017 14:29:57 -0400
Received: from mx1.redhat.com ([209.132.183.28]:41650 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1753973AbdGJS3z (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 10 Jul 2017 14:29:55 -0400
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D539063E2F
Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=riel@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com D539063E2F
Message-ID: <1499711385.6130.41.camel@redhat.com>
Subject: Re: [RFC][PATCH] exec: Use init rlimits for setuid exec
From: Rik van Riel <riel@redhat.com>
To: Michal Hocko <mhocko@kernel.org>, Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
        Andy Lutomirski <luto@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>,
        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>
Date: Mon, 10 Jul 2017 14:29:45 -0400
In-Reply-To: <20170710181600.GG7071@dhcp22.suse.cz>
References: <20170706043235.GA36170@beast>
         <CA+55aFwwvJRTvpDBZ2KsXvRB_EWEcHesuXmHgSJFB3PTMBd1Bg@mail.gmail.com>
         <CAGXu5jJ8_tTZGmS9mA6d5G+FBy0uj8=XHrOTs15NYnDjgCE=iQ@mail.gmail.com>
         <CA+55aFz+ZexQFWwLXLprDaz-VcGCZmHed0vr-+=jsKrdMDAKLA@mail.gmail.com>
         <CAGXu5jK9U8Wo=u0N4cZY_xt9TJ5Hyd2O4buxHu5eAqjCUz-PoA@mail.gmail.com>
         <20170710084415.GE19185@dhcp22.suse.cz>
         <CAGXu5jK5m1pVSon=uGy=dLgVi89k33+Lm-XHZ4xiNY-QdUxtng@mail.gmail.com>
         <20170710162751.GC7071@dhcp22.suse.cz>
         <20170710181600.GG7071@dhcp22.suse.cz>
Organization: Red Hat, Inc
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 10 Jul 2017 18:29:54 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 2017-07-10 at 20:16 +0200, Michal Hocko wrote:

> OK, I misread the code. 32b applications on 64b systems do top down
> by
> default and only if they override this by ADDR_COMPAT_LAYOUT
> personality. For some reason I thought that 32b userspace goes a
> different path and makes sure that they are always doing bottom up.
> 
> Anyway even if somebody really needs to grow stack really large we
> have
> the personality to give them the legacy layout.

I think what will happen when rlimit_stack is RLIMIT_INFINITY
is that mmap_base will end up placing mm->mmap_base at 512MB
(task_size / 6 * 5 below the top of address space) for 32 bit
kernels, and we eventually fall back to a bottom-up search
if the space below mmap_base is exhausted (if it ever is).