linux-kernel - Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP

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: <alpine.DEB.2.20.1711132010470.2097@nanos>
Date:   Mon, 13 Nov 2017 20:14:54 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "Kirill A. Shutemov" <kirill@...temov.name>
cc:     "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>,
        Andy Lutomirski <luto@...capital.net>,
        Cyrill Gorcunov <gorcunov@...nvz.org>,
        Nicholas Piggin <npiggin@...il.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across
 DEFAULT_MAP_WINDOW border

On Mon, 13 Nov 2017, Thomas Gleixner wrote:
> On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
> 
> > On Mon, Nov 13, 2017 at 04:43:26PM +0100, Thomas Gleixner wrote:
> > > On Tue, 7 Nov 2017, Kirill A. Shutemov wrote:
> > > 
> > > > In case of 5-level paging, we don't put any mapping above 47-bit, unless
> > > > userspace explicitly asked for it.
> > > > 
> > > > Userspace can ask for allocation from full address space by specifying
> > > > hint address above 47-bit.
> > > > 
> > > > Nicholas noticed that current implementation violates this interface:
> > > > we can get vma partly in high addresses if we ask for a mapping at very
> > > > end of 47-bit address space.
> > > > 
> > > > Let's make sure that, when consider hint address for non-MAP_FIXED
> > > > mapping, start and end of resulting vma are on the same side of 47-bit
> > > > border.
> > > 
> > > What happens for mappings with MAP_FIXED which cross the border?
> > 
> > It will succeed with 5-level paging.
> 
> And why is this allowed?
> 
> > It should be safe as with 4-level paging such request would fail and it's
> > reasonable to expect that userspace is not relying on the failure to
> > function properly.
> 
> Huch?
> 
> The first rule when looking at user space is that is broken or
> hostile. Reasonable and user space are mutually exclusive.

Aside of that in case of get_unmapped_area:

If va_unmapped_area() fails, then the address and the len which caused the
overlap check to trigger are handed in to arch_get_unmapped_area(), which
again can create an invalid mapping if I'm not missing something.

If mappings which overlap the boundary are invalid then we have to make
sure at all ends that they wont happen.

Thanks,

	tglx