[PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[Kirill A. Shutemov]

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.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reported-by: Nicholas Piggin <npiggin@gmail.com>
---
 arch/x86/kernel/sys_x86_64.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/sys_x86_64.c b/arch/x86/kernel/sys_x86_64.c
index a63fe77b3217..64b1a0d22247 100644
--- a/arch/x86/kernel/sys_x86_64.c
+++ b/arch/x86/kernel/sys_x86_64.c
@@ -198,11 +198,19 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
 	/* requesting a specific address */
 	if (addr) {
 		addr = PAGE_ALIGN(addr);
+		if (TASK_SIZE - len < addr)
+			goto get_unmapped_area;
+
+		/* The mapping shouldn't cross DEFAULT_MAP_WINDOW border */
+		if ((addr > DEFAULT_MAP_WINDOW) !=
+				(addr + len > DEFAULT_MAP_WINDOW))
+			goto get_unmapped_area;
+
 		vma = find_vma(mm, addr);
-		if (TASK_SIZE - len >= addr &&
-				(!vma || addr + len <= vm_start_gap(vma)))
+		if (!vma || addr + len <= vm_start_gap(vma))
 			return addr;
 	}
+get_unmapped_area:
 
 	info.flags = VM_UNMAPPED_AREA_TOPDOWN;
 	info.length = len;
-- 
2.14.2

[PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[Kirill A. Shutemov]

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.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reported-by: Nicholas Piggin <npiggin@gmail.com>
---
 arch/x86/kernel/sys_x86_64.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/sys_x86_64.c b/arch/x86/kernel/sys_x86_64.c
index a63fe77b3217..64b1a0d22247 100644
--- a/arch/x86/kernel/sys_x86_64.c
+++ b/arch/x86/kernel/sys_x86_64.c
@@ -198,11 +198,19 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
 	/* requesting a specific address */
 	if (addr) {
 		addr = PAGE_ALIGN(addr);
+		if (TASK_SIZE - len < addr)
+			goto get_unmapped_area;
+
+		/* The mapping shouldn't cross DEFAULT_MAP_WINDOW border */
+		if ((addr > DEFAULT_MAP_WINDOW) !=
+				(addr + len > DEFAULT_MAP_WINDOW))
+			goto get_unmapped_area;
+
 		vma = find_vma(mm, addr);
-		if (TASK_SIZE - len >= addr &&
-				(!vma || addr + len <= vm_start_gap(vma)))
+		if (!vma || addr + len <= vm_start_gap(vma))
 			return addr;
 	}
+get_unmapped_area:
 
 	info.flags = VM_UNMAPPED_AREA_TOPDOWN;
 	info.length = len;
-- 
2.14.2

--
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>

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[Thomas Gleixner]

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?

Thanks,

	tglx

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[Thomas Gleixner]

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?

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>

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[Kirill A. Shutemov]

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.

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.

-- 
 Kirill A. Shutemov

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[Kirill A. Shutemov]

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.

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.

-- 
 Kirill A. Shutemov

--
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>

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[Thomas Gleixner]

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.

Thanks,

	tglx

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[Thomas Gleixner]

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.

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>

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[Thomas Gleixner]

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

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[Thomas Gleixner]

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



--
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>

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[Kirill A. Shutemov]

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.

-- 
 Kirill A. Shutemov

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[Kirill A. Shutemov]

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.

-- 
 Kirill A. Shutemov

--
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>

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[Kirill A. Shutemov]

On Mon, Nov 13, 2017 at 08:14:54PM +0100, Thomas Gleixner wrote:
> 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.

They are not invalid.

The patch tries to address following theoretical issue:

We have an application that tries, for some reason, to allocate memory
with mmap(addr), without MAP_FIXED, where addr is near the borderline of
47-bit address space and addr+len is above the border.

On 4-level paging machine this request would succeed, but the address will
always be within 47-bit VA -- cannot allocate by hint address, ignore it.

If the application cannot handle high address this might be an issue on
5-level paging machine as such call would succeed *and* allocate memory by
the specified hint address. In this case part of the mapping would be
above the border line and may lead to misbehaviour.

I hope this makes any sense :)

-- 
 Kirill A. Shutemov

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[Kirill A. Shutemov]

On Mon, Nov 13, 2017 at 08:14:54PM +0100, Thomas Gleixner wrote:
> 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.

They are not invalid.

The patch tries to address following theoretical issue:

We have an application that tries, for some reason, to allocate memory
with mmap(addr), without MAP_FIXED, where addr is near the borderline of
47-bit address space and addr+len is above the border.

On 4-level paging machine this request would succeed, but the address will
always be within 47-bit VA -- cannot allocate by hint address, ignore it.

If the application cannot handle high address this might be an issue on
5-level paging machine as such call would succeed *and* allocate memory by
the specified hint address. In this case part of the mapping would be
above the border line and may lead to misbehaviour.

I hope this makes any sense :)

-- 
 Kirill A. Shutemov

--
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>

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[Thomas Gleixner]

On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
> On Mon, Nov 13, 2017 at 08:14:54PM +0100, Thomas Gleixner wrote:
> > > > 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.
> 
> They are not invalid.
> 
> The patch tries to address following theoretical issue:
> 
> We have an application that tries, for some reason, to allocate memory
> with mmap(addr), without MAP_FIXED, where addr is near the borderline of
> 47-bit address space and addr+len is above the border.
> 
> On 4-level paging machine this request would succeed, but the address will
> always be within 47-bit VA -- cannot allocate by hint address, ignore it.
> 
> If the application cannot handle high address this might be an issue on
> 5-level paging machine as such call would succeed *and* allocate memory by
> the specified hint address. In this case part of the mapping would be
> above the border line and may lead to misbehaviour.
> 
> I hope this makes any sense :)

I can see where you are heading to. Now the case I was looking at is:

arch_get_unmapped_area_topdown()

	addr0 = addr;
	
	....
	if (addr) {
		if (cross_border(addr, len))
			goto get_unmapped_area;
		...
	}
get_unmapped_area:
	...
	if (addr > DEFAULT_MAP_WINDOW && !in_compat_syscall())

	   ^^^ evaluates to false because addr < DEFAULT_MAP_WINDOW

	addr - vm_unmapped_area(&info);

	   ^^^ fails for whatever reason.

bottomup:
	return arch_get_unmapped_area(.., addr0, len, ....);


AFAICT arch_get_unmapped_area() can allocate a mapping which crosses the
border, i.e. a mapping which you want to prevent for the !MAP_FIXED case.

Thanks,

	tglx

	

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[Thomas Gleixner]

On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
> On Mon, Nov 13, 2017 at 08:14:54PM +0100, Thomas Gleixner wrote:
> > > > 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.
> 
> They are not invalid.
> 
> The patch tries to address following theoretical issue:
> 
> We have an application that tries, for some reason, to allocate memory
> with mmap(addr), without MAP_FIXED, where addr is near the borderline of
> 47-bit address space and addr+len is above the border.
> 
> On 4-level paging machine this request would succeed, but the address will
> always be within 47-bit VA -- cannot allocate by hint address, ignore it.
> 
> If the application cannot handle high address this might be an issue on
> 5-level paging machine as such call would succeed *and* allocate memory by
> the specified hint address. In this case part of the mapping would be
> above the border line and may lead to misbehaviour.
> 
> I hope this makes any sense :)

I can see where you are heading to. Now the case I was looking at is:

arch_get_unmapped_area_topdown()

	addr0 = addr;
	
	....
	if (addr) {
		if (cross_border(addr, len))
			goto get_unmapped_area;
		...
	}
get_unmapped_area:
	...
	if (addr > DEFAULT_MAP_WINDOW && !in_compat_syscall())

	   ^^^ evaluates to false because addr < DEFAULT_MAP_WINDOW

	addr - vm_unmapped_area(&info);

	   ^^^ fails for whatever reason.

bottomup:
	return arch_get_unmapped_area(.., addr0, len, ....);


AFAICT arch_get_unmapped_area() can allocate a mapping which crosses the
border, i.e. a mapping which you want to prevent for the !MAP_FIXED case.

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>

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[Thomas Gleixner]

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

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[Thomas Gleixner]

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>

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[Kirill A. Shutemov]

On Mon, Nov 13, 2017 at 10:14:36PM +0100, Thomas Gleixner wrote:
> On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
> > On Mon, Nov 13, 2017 at 08:14:54PM +0100, Thomas Gleixner wrote:
> > > > > 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.
> > 
> > They are not invalid.
> > 
> > The patch tries to address following theoretical issue:
> > 
> > We have an application that tries, for some reason, to allocate memory
> > with mmap(addr), without MAP_FIXED, where addr is near the borderline of
> > 47-bit address space and addr+len is above the border.
> > 
> > On 4-level paging machine this request would succeed, but the address will
> > always be within 47-bit VA -- cannot allocate by hint address, ignore it.
> > 
> > If the application cannot handle high address this might be an issue on
> > 5-level paging machine as such call would succeed *and* allocate memory by
> > the specified hint address. In this case part of the mapping would be
> > above the border line and may lead to misbehaviour.
> > 
> > I hope this makes any sense :)
> 
> I can see where you are heading to. Now the case I was looking at is:
> 
> arch_get_unmapped_area_topdown()
> 
> 	addr0 = addr;
> 	
> 	....
> 	if (addr) {
> 		if (cross_border(addr, len))
> 			goto get_unmapped_area;
> 		...
> 	}
> get_unmapped_area:
> 	...
> 	if (addr > DEFAULT_MAP_WINDOW && !in_compat_syscall())
> 
> 	   ^^^ evaluates to false because addr < DEFAULT_MAP_WINDOW
> 
> 	addr - vm_unmapped_area(&info);
> 
> 	   ^^^ fails for whatever reason.
> 
> bottomup:
> 	return arch_get_unmapped_area(.., addr0, len, ....);
> 
> 
> AFAICT arch_get_unmapped_area() can allocate a mapping which crosses the
> border, i.e. a mapping which you want to prevent for the !MAP_FIXED case.

No, it can't as long as addr0 is below DEFAULT_MAP_WINDOW:

arch_get_unmapped_area()
{
	...
	find_start_end(addr, flags, &begin, &end);
	// end is DEFAULT_MAP_WINDOW here, since addr is below the border
	...
	if (addr) {
		...
		// end - len is less than addr, so the condition below is
		// false.
		if (end - len >= addr &&
		    (!vma || addr + len <= vm_start_gap(vma)))
			return addr;
	}
	...
	info.high_limit = end;
	...
	return vm_unmapped_area(&info);
}

-- 
 Kirill A. Shutemov

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[Kirill A. Shutemov]

On Mon, Nov 13, 2017 at 10:14:36PM +0100, Thomas Gleixner wrote:
> On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
> > On Mon, Nov 13, 2017 at 08:14:54PM +0100, Thomas Gleixner wrote:
> > > > > 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.
> > 
> > They are not invalid.
> > 
> > The patch tries to address following theoretical issue:
> > 
> > We have an application that tries, for some reason, to allocate memory
> > with mmap(addr), without MAP_FIXED, where addr is near the borderline of
> > 47-bit address space and addr+len is above the border.
> > 
> > On 4-level paging machine this request would succeed, but the address will
> > always be within 47-bit VA -- cannot allocate by hint address, ignore it.
> > 
> > If the application cannot handle high address this might be an issue on
> > 5-level paging machine as such call would succeed *and* allocate memory by
> > the specified hint address. In this case part of the mapping would be
> > above the border line and may lead to misbehaviour.
> > 
> > I hope this makes any sense :)
> 
> I can see where you are heading to. Now the case I was looking at is:
> 
> arch_get_unmapped_area_topdown()
> 
> 	addr0 = addr;
> 	
> 	....
> 	if (addr) {
> 		if (cross_border(addr, len))
> 			goto get_unmapped_area;
> 		...
> 	}
> get_unmapped_area:
> 	...
> 	if (addr > DEFAULT_MAP_WINDOW && !in_compat_syscall())
> 
> 	   ^^^ evaluates to false because addr < DEFAULT_MAP_WINDOW
> 
> 	addr - vm_unmapped_area(&info);
> 
> 	   ^^^ fails for whatever reason.
> 
> bottomup:
> 	return arch_get_unmapped_area(.., addr0, len, ....);
> 
> 
> AFAICT arch_get_unmapped_area() can allocate a mapping which crosses the
> border, i.e. a mapping which you want to prevent for the !MAP_FIXED case.

No, it can't as long as addr0 is below DEFAULT_MAP_WINDOW:

arch_get_unmapped_area()
{
	...
	find_start_end(addr, flags, &begin, &end);
	// end is DEFAULT_MAP_WINDOW here, since addr is below the border
	...
	if (addr) {
		...
		// end - len is less than addr, so the condition below is
		// false.
		if (end - len >= addr &&
		    (!vma || addr + len <= vm_start_gap(vma)))
			return addr;
	}
	...
	info.high_limit = end;
	...
	return vm_unmapped_area(&info);
}

-- 
 Kirill A. Shutemov

--
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>

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[Kirill A. Shutemov]

On Mon, Nov 13, 2017 at 10:17:30PM +0100, Thomas Gleixner wrote:
> 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.

Okay, I'll update the patch.

-- 
 Kirill A. Shutemov

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[Kirill A. Shutemov]

On Mon, Nov 13, 2017 at 10:17:30PM +0100, Thomas Gleixner wrote:
> 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.

Okay, I'll update the patch.

-- 
 Kirill A. Shutemov

--
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>

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[Thomas Gleixner]

On Tue, 14 Nov 2017, Kirill A. Shutemov wrote:
> On Mon, Nov 13, 2017 at 10:14:36PM +0100, Thomas Gleixner wrote:
> > I can see where you are heading to. Now the case I was looking at is:
> > 
> > arch_get_unmapped_area_topdown()
> > 
> > 	addr0 = addr;
> > 	
> > 	....
> > 	if (addr) {
> > 		if (cross_border(addr, len))
> > 			goto get_unmapped_area;
> > 		...
> > 	}
> > get_unmapped_area:
> > 	...
> > 	if (addr > DEFAULT_MAP_WINDOW && !in_compat_syscall())
> > 
> > 	   ^^^ evaluates to false because addr < DEFAULT_MAP_WINDOW
> > 
> > 	addr - vm_unmapped_area(&info);
> > 
> > 	   ^^^ fails for whatever reason.
> > 
> > bottomup:
> > 	return arch_get_unmapped_area(.., addr0, len, ....);
> > 
> > 
> > AFAICT arch_get_unmapped_area() can allocate a mapping which crosses the
> > border, i.e. a mapping which you want to prevent for the !MAP_FIXED case.
> 
> No, it can't as long as addr0 is below DEFAULT_MAP_WINDOW:
> 
> arch_get_unmapped_area()
> {
> 	...
> 	find_start_end(addr, flags, &begin, &end);
> 	// end is DEFAULT_MAP_WINDOW here, since addr is below the border

Sigh, I missed that task_size_64bit() magic in find_start_end().

This is really convoluted and non intuitive. I'm so not looking forward to
debug any failure in that context.

Thanks,

	tglx

Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border

[Thomas Gleixner]

On Tue, 14 Nov 2017, Kirill A. Shutemov wrote:
> On Mon, Nov 13, 2017 at 10:14:36PM +0100, Thomas Gleixner wrote:
> > I can see where you are heading to. Now the case I was looking at is:
> > 
> > arch_get_unmapped_area_topdown()
> > 
> > 	addr0 = addr;
> > 	
> > 	....
> > 	if (addr) {
> > 		if (cross_border(addr, len))
> > 			goto get_unmapped_area;
> > 		...
> > 	}
> > get_unmapped_area:
> > 	...
> > 	if (addr > DEFAULT_MAP_WINDOW && !in_compat_syscall())
> > 
> > 	   ^^^ evaluates to false because addr < DEFAULT_MAP_WINDOW
> > 
> > 	addr - vm_unmapped_area(&info);
> > 
> > 	   ^^^ fails for whatever reason.
> > 
> > bottomup:
> > 	return arch_get_unmapped_area(.., addr0, len, ....);
> > 
> > 
> > AFAICT arch_get_unmapped_area() can allocate a mapping which crosses the
> > border, i.e. a mapping which you want to prevent for the !MAP_FIXED case.
> 
> No, it can't as long as addr0 is below DEFAULT_MAP_WINDOW:
> 
> arch_get_unmapped_area()
> {
> 	...
> 	find_start_end(addr, flags, &begin, &end);
> 	// end is DEFAULT_MAP_WINDOW here, since addr is below the border

Sigh, I missed that task_size_64bit() magic in find_start_end().

This is really convoluted and non intuitive. I'm so not looking forward to
debug any failure in that context.

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>