linux-kernel - Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX

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-next>] [day] [month] [year] [list]

Message-ID: <20170221103401.GA31018@e104818-lin.cambridge.arm.com>
Date:   Tue, 21 Feb 2017 10:34:02 +0000
From:   Catalin Marinas <catalin.marinas@....com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Andy Lutomirski <luto@...capital.net>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        Andi Kleen <ak@...ux.intel.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Arnd Bergmann <arnd@...db.de>,
        Dave Hansen <dave.hansen@...el.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "H. Peter Anvin" <hpa@...or.com>, linux-mm <linux-mm@...ck.org>
Subject: Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and
 PR_GET_MAX_VADDR

On Fri, Feb 17, 2017 at 03:21:27PM -0800, Linus Torvalds wrote:
> On Feb 17, 2017 3:02 PM, "Andy Lutomirski" <luto@...capital.net> wrote:
> >   What I'm trying to say is: if we're going to do the route of 48-bit
> >   limit unless a specific mmap call requests otherwise, can we at least
> >   have an interface that doesn't suck?
> 
> No, I'm not suggesting specific mmap calls at all. I'm suggesting the complete
> opposite: not having some magical "max address" at all in the VM layer. Keep
> all the existing TASK_SIZE defines as-is, and just make those be the new 56-bit
> limit.
> 
> But to then not make most processes use it, just make the default x86
> arch_get_free_area() return an address limited to the old 47-bit limit. So
> effectively all legacy programs work exactly the same way they always did.

arch_get_unmapped_area() changes would not cover STACK_TOP which is
currently defined as TASK_SIZE (on both x86 and arm64). I don't think it
matters much (normally such upper bits tricks are done on heap objects)
but you may find some weird user program that passes pointers to the
stack around and expects bits 48-63 to be masked out. If that's a real
issue, we could also limit STACK_TOP to 47-bit (48-bit on arm64).

-- 
Catalin