Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 19 Apr 2019 10:51:40 +0200
From:   Ingo Molnar <mingo@kernel.org>
To:     "Saidi, Ali" <alisaidi@amazon.com>
Cc:     Kees Cook <keescook@chromium.org>, Michal Hocko <mhocko@suse.com>,
        Matthew Wilcox <willy@infradead.org>,
        Jann Horn <jannh@google.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "Liguori, Anthony" <aliguori@amazon.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        X86 ML <x86@kernel.org>, Will Deacon <will.deacon@arm.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "Woodhouse, David" <dwmw@amazon.co.uk>,
        Andy Lutomirski <luto@kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 2/2] x86/mmap: handle worst-case heap randomization in
 mmap_base
Message-ID: <20190419085140.GA50390@gmail.com>
References: <20190312173248.13490-1-alisaidi@amazon.com>
 <20190312173248.13490-3-alisaidi@amazon.com>
 <CAGXu5jJ5sj3emOT2QPxQkNQk0qbU6zEfu9=Omfhx_p0nCKPSjA@mail.gmail.com>
 <CAGXu5jKcBmj0kwAqjqROXuOi=90=Upy8-J8WviGMjD6FV_Guxg@mail.gmail.com>
 <34381CFC-A90F-4979-9802-2BA0E6539C68@amazon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <34381CFC-A90F-4979-9802-2BA0E6539C68@amazon.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


* Saidi, Ali <alisaidi@amazon.com> wrote:

> ﻿On 3/27/19, 2:52 PM, "linux-arm-kernel on behalf of Kees Cook" <linux-arm-kernel-bounces@lists.infradead.org on behalf of keescook@chromium.org> wrote:
> 
>     Adding some more people to CC... what do people think about this
>     moving of the brk to ELF_ET_DYN_BASE in this corner-case? Anything
>     that worked before should still work (i.e. the ultimately-launched
>     binary already had the brk very far from its text, so this should be
>     no different from a COMPAT_BRK standpoint). The only risk I see here
>     is that if someone started to suddenly depend on the entire memory
>     space above the mmap region being available when launching binaries
>     via a direct loader execs... which seems highly unlikely, I'd hope:
>     this would mean a binary would not work when execed normally.
> 
> Kees' proposal addresses the issue for me. Anyone have concerns on this proposed solution?

I'd suggest incorporating all feedback and sending a v2 series - it's 
much easier to get people's attention via code submitted. ;-)

Thanks,

	Ingo