All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Ingo Molnar <mingo@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Andy Lutomirski <luto@amacapital.net>,
	Cyrill Gorcunov <gorcunov@openvz.org>,
	Nicholas Piggin <npiggin@gmail.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border
Date: Mon, 13 Nov 2017 22:17:30 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1711132215200.2097@nanos> (raw)
In-Reply-To: <20171113200005.xzbhenukotzicwd2@node.shutemov.name>

On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
> On Mon, Nov 13, 2017 at 05:57:03PM +0100, 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.
> 
> That's basically the same assumption we made to implement current
> interface of allocation memory above 47-bits.
> 
> The premise is that nobody in right mind would try mmap(addr, MAP_FIXED)
> where addr >= (1UL << 47) as it will always fail. So we can allow this to
> succeed on 5-level paging machine as a way to allocate from larger address
> space.
> 
> By the same logic we can allow allocation for cases where addr is below
> (1UL << 47), but addr+size is above the limit.

Makes some sense, but it would be nice to have this documented exactly in
arch_get_unmapped_area_topdown(), i.e. the function where you are adding
the border check to. Otherwise 3 month from now somebody will look at that
and ask exactly the same question again.

Thanks,

	tglx

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx@linutronix.de>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Ingo Molnar <mingo@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Andy Lutomirski <luto@amacapital.net>,
	Cyrill Gorcunov <gorcunov@openvz.org>,
	Nicholas Piggin <npiggin@gmail.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border
Date: Mon, 13 Nov 2017 22:17:30 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1711132215200.2097@nanos> (raw)
In-Reply-To: <20171113200005.xzbhenukotzicwd2@node.shutemov.name>

On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
> On Mon, Nov 13, 2017 at 05:57:03PM +0100, 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.
> 
> That's basically the same assumption we made to implement current
> interface of allocation memory above 47-bits.
> 
> The premise is that nobody in right mind would try mmap(addr, MAP_FIXED)
> where addr >= (1UL << 47) as it will always fail. So we can allow this to
> succeed on 5-level paging machine as a way to allocate from larger address
> space.
> 
> By the same logic we can allow allocation for cases where addr is below
> (1UL << 47), but addr+size is above the limit.

Makes some sense, but it would be nice to have this documented exactly in
arch_get_unmapped_area_topdown(), i.e. the function where you are adding
the border check to. Otherwise 3 month from now somebody will look at that
and ask exactly the same question again.

Thanks,

	tglx

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-11-13 21:17 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-07 13:05 [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border Kirill A. Shutemov
2017-11-07 13:05 ` Kirill A. Shutemov
2017-11-13 15:43 ` Thomas Gleixner
2017-11-13 15:43   ` Thomas Gleixner
2017-11-13 16:41   ` Kirill A. Shutemov
2017-11-13 16:41     ` Kirill A. Shutemov
2017-11-13 16:57     ` Thomas Gleixner
2017-11-13 16:57       ` Thomas Gleixner
2017-11-13 19:14       ` Thomas Gleixner
2017-11-13 19:14         ` Thomas Gleixner
2017-11-13 20:06         ` Kirill A. Shutemov
2017-11-13 20:06           ` Kirill A. Shutemov
2017-11-13 21:14           ` Thomas Gleixner
2017-11-13 21:14             ` Thomas Gleixner
2017-11-14 12:05             ` Kirill A. Shutemov
2017-11-14 12:05               ` Kirill A. Shutemov
2017-11-14 12:11               ` Thomas Gleixner
2017-11-14 12:11                 ` Thomas Gleixner
2017-11-13 20:00       ` Kirill A. Shutemov
2017-11-13 20:00         ` Kirill A. Shutemov
2017-11-13 21:17         ` Thomas Gleixner [this message]
2017-11-13 21:17           ` Thomas Gleixner
2017-11-14 12:06           ` Kirill A. Shutemov
2017-11-14 12:06             ` Kirill A. Shutemov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.20.1711132215200.2097@nanos \
    --to=tglx@linutronix.de \
    --cc=gorcunov@openvz.org \
    --cc=hpa@zytor.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=npiggin@gmail.com \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.