linux-kernel - Re: [PATCH 2/2] x86/mmap: handle worst-case heap randomization in mmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <037ACE94-A408-4CB0-BCA5-3FF9041E43B0@amazon.com>
Date:   Tue, 26 Mar 2019 02:13:34 +0000
From:   "Saidi, Ali" <alisaidi@...zon.com>
To:     Thomas Gleixner <tglx@...utronix.de>
CC:     Dave Hansen <dave.hansen@...ux.intel.com>,
        Kees Cook <keescook@...omium.org>,
        Peter Zijlstra <peterz@...radead.org>,
        "Catalin Marinas" <catalin.marinas@....com>,
        "x86@...nel.org" <x86@...nel.org>,
        "Will Deacon" <will.deacon@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        "Borislav Petkov" <bp@...en8.de>,
        "Woodhouse, David" <dwmw@...zon.co.uk>,
        "Andy Lutomirski" <luto@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        "Andrew Morton" <akpm@...ux-foundation.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "Liguori, Anthony" <aliguori@...zon.com>
Subject: Re: [PATCH 2/2] x86/mmap: handle worst-case heap randomization in
 mmap_base



On 3/21/19, 9:11 AM, "linux-arm-kernel on behalf of Thomas Gleixner" <linux-arm-kernel-bounces@...ts.infradead.org on behalf of tglx@...utronix.de> wrote:

    On Tue, 12 Mar 2019, Ali Saidi wrote:
    
    > Increase mmap_base by the worst-case brk randomization so that
    > the stack and heap remain apart.
    > 
    > In Linux 4.13 a change was committed that special cased the kernel ELF
    > loader when the loader is invoked directly (eab09532d400; binfmt_elf: use
    > ELF_ET_DYN_BASE only for PIE). Generally, the loader isn’t invoked
    > directly and this issue is limited to cases where it is, (e.g to set a
    > non-inheritable LD_LIBRARY_PATH, testing new versions of the loader). In
    > those rare cases, the loader doesn't take into account the amount of brk
    > randomization that will be applied by arch_randomize_brk(). This can
    > lead to the stack and heap being arbitrarily close to each other.
    
    That explains not why you need this change. What's the consequence of them
    being close to each other?
    
The process doesn't get it's requested stack size and stack allocations could end up scribbling on the heap.

Thanks,
Ali