2018-02-26 21:15:59

by Ilya Smith

[permalink] [raw]
Subject: [RFC PATCH] Take mmap_min_addr into account while choosing unmapped address for x86-64.

It prevent situation when vm_unmapped_area chose address between
PAGE_SIZE and mmap_min_addr range. In this case mmap will fail with
EPERM without a good reason.

As test-case of such situation we may hard-code address between
PAGE_SIZE and 65536 inside unmapped_area_topdown function.

Signed-off-by: Ilya Smith <[email protected]>
---
arch/x86/kernel/sys_x86_64.c | 5 +++--
arch/x86/mm/mmap.c | 4 ++++
2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/sys_x86_64.c b/arch/x86/kernel/sys_x86_64.c
index 676774b9bb8d..1752fe5cb735 100644
--- a/arch/x86/kernel/sys_x86_64.c
+++ b/arch/x86/kernel/sys_x86_64.c
@@ -17,6 +17,7 @@
#include <linux/random.h>
#include <linux/uaccess.h>
#include <linux/elf.h>
+#include <linux/security.h>

#include <asm/elf.h>
#include <asm/compat.h>
@@ -185,7 +186,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
return addr;

/* requested length too big for entire address space */
- if (len > TASK_SIZE)
+ if (len > TASK_SIZE - mmap_min_addr)
return -ENOMEM;

/* No address checking. See comment at mmap_address_hint_valid() */
@@ -210,7 +211,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,

info.flags = VM_UNMAPPED_AREA_TOPDOWN;
info.length = len;
- info.low_limit = PAGE_SIZE;
+ info.low_limit = max(PAGE_SIZE, mmap_min_addr);
info.high_limit = get_mmap_base(0);

/*
diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c
index 155ecbac9e28..b6d0c317639e 100644
--- a/arch/x86/mm/mmap.c
+++ b/arch/x86/mm/mmap.c
@@ -31,6 +31,7 @@
#include <linux/sched/signal.h>
#include <linux/sched/mm.h>
#include <linux/compat.h>
+#include <linux/security.h>
#include <asm/elf.h>

#include "physaddr.h"
@@ -220,6 +221,9 @@ bool mmap_address_hint_valid(unsigned long addr, unsigned long len)
if (TASK_SIZE - len < addr)
return false;

+ if (addr < mmap_min_addr)
+ return false;
+
return (addr > DEFAULT_MAP_WINDOW) == (addr + len > DEFAULT_MAP_WINDOW);
}

--
2.14.1



2018-02-27 08:59:05

by Michal Hocko

[permalink] [raw]
Subject: Re: [RFC PATCH] Take mmap_min_addr into account while choosing unmapped address for x86-64.

On Tue 27-02-18 00:12:57, Ilya Smith wrote:
[...]
> diff --git a/arch/x86/kernel/sys_x86_64.c b/arch/x86/kernel/sys_x86_64.c
> index 676774b9bb8d..1752fe5cb735 100644
> --- a/arch/x86/kernel/sys_x86_64.c
> +++ b/arch/x86/kernel/sys_x86_64.c
> @@ -17,6 +17,7 @@
> #include <linux/random.h>
> #include <linux/uaccess.h>
> #include <linux/elf.h>
> +#include <linux/security.h>
>
> #include <asm/elf.h>
> #include <asm/compat.h>
> @@ -185,7 +186,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
> return addr;
>
> /* requested length too big for entire address space */
> - if (len > TASK_SIZE)
> + if (len > TASK_SIZE - mmap_min_addr)
> return -ENOMEM;
>
> /* No address checking. See comment at mmap_address_hint_valid() */
> @@ -210,7 +211,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
>
> info.flags = VM_UNMAPPED_AREA_TOPDOWN;
> info.length = len;
> - info.low_limit = PAGE_SIZE;
> + info.low_limit = max(PAGE_SIZE, mmap_min_addr);
> info.high_limit = get_mmap_base(0);
>
> /*

mmap_min_addr handling is a bit mess... As you say, we would return
EPERM rather than ENOMEM which can be confusing but depleting the
address space like that is quite unlikely on 64b unless I am missing.
It is good to be in sync here with the generic implementation though,
IMO.

> diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c
> index 155ecbac9e28..b6d0c317639e 100644
> --- a/arch/x86/mm/mmap.c
> +++ b/arch/x86/mm/mmap.c
> @@ -31,6 +31,7 @@
> #include <linux/sched/signal.h>
> #include <linux/sched/mm.h>
> #include <linux/compat.h>
> +#include <linux/security.h>
> #include <asm/elf.h>
>
> #include "physaddr.h"
> @@ -220,6 +221,9 @@ bool mmap_address_hint_valid(unsigned long addr, unsigned long len)
> if (TASK_SIZE - len < addr)
> return false;
>
> + if (addr < mmap_min_addr)
> + return false;
> +
> return (addr > DEFAULT_MAP_WINDOW) == (addr + len > DEFAULT_MAP_WINDOW);

But is this one necessary? We do sanitze hint address before going to
get_unmapped_address AFAIR.

--
Michal Hocko
SUSE Labs

2018-02-27 13:29:13

by Ilya Smith

[permalink] [raw]
Subject: Re: [RFC PATCH] Take mmap_min_addr into account while choosing unmapped address for x86-64.

>
> mmap_min_addr handling is a bit mess... As you say, we would return
> EPERM rather than ENOMEM which can be confusing but depleting the
> address space like that is quite unlikely on 64b unless I am missing.
> It is good to be in sync here with the generic implementation though,
> IMO.
>

If we take a look on mm/mmap.c:
#ifndef HAVE_ARCH_UNMAPPED_AREA_TOPDOWN
unsigned long
arch_get_unmapped_area_topdown(

if (len > TASK_SIZE - mmap_min_addr)
return -ENOMEM;

info.low_limit = max(PAGE_SIZE, mmap_min_addr);

And this one looks like a generic implementation.
But for many other architectures like arch/parisc/kernel/sys_parisc.c
or arch/x86/kernel/sys_x86_64.c

info.low_limit = PAGE_SIZE;

What is looks like an issue for me.

Here is C code could be used as test-case:

#include <errno.h>
#include <stdio.h>
#include <sys/mman.h>

int main() {
char buffer[1024];

unsigned long len = 1ULL << 46;
while(len) {
void *ptr = mmap(4096, len, 0, MAP_PRIVATE | MAP_ANONYMOUS , -1, 0);
if (ptr == MAP_FAILED) {
if (errno == EPERM)
break;
if (errno == ENOMEM) {
len >>= 1;
continue;
}
return -1;
}
}
if (errno == EPERM) {
printf("Test failed, you have wrong ret code EPERM\n");
sprintf(buffer, "cat /proc/%d/maps", getpid());
system(buffer);
return -1;
}
return 0;
}


>>
>> + if (addr < mmap_min_addr)
>> + return false;
>> +
>> return (addr > DEFAULT_MAP_WINDOW) == (addr + len > DEFAULT_MAP_WINDOW);
>
> But is this one necessary? We do sanitze hint address before going to
> get_unmapped_address AFAIR.
>
I’m agree, looks like I was trying to fix something that already fine.

Thanks,
Ilya


2018-02-28 07:18:56

by Michal Hocko

[permalink] [raw]
Subject: Re: [RFC PATCH] Take mmap_min_addr into account while choosing unmapped address for x86-64.

On Tue 27-02-18 16:27:29, Ilya Smith wrote:
> >
> > mmap_min_addr handling is a bit mess... As you say, we would return
> > EPERM rather than ENOMEM which can be confusing but depleting the
> > address space like that is quite unlikely on 64b unless I am missing.
> > It is good to be in sync here with the generic implementation though,
> > IMO.
> >
>
> If we take a look on mm/mmap.c:
> #ifndef HAVE_ARCH_UNMAPPED_AREA_TOPDOWN
> unsigned long
> arch_get_unmapped_area_topdown(
> …
> if (len > TASK_SIZE - mmap_min_addr)
> return -ENOMEM;
> …
> info.low_limit = max(PAGE_SIZE, mmap_min_addr);
>
> And this one looks like a generic implementation.
> But for many other architectures like arch/parisc/kernel/sys_parisc.c
> or arch/x86/kernel/sys_x86_64.c
>
> info.low_limit = PAGE_SIZE;

Yeah, this is what I meant when saying that mmap_min_addr is a bit of a
mess. I am wondering whether the low_limit should be checked inside
vm_unmapped_area. We would still need some mmap_min_addr handling at
arch_get_unmapped_area_topdown layer which is still suboptimal but I do
not see an easy way around without reworking how the arch specific parts
are implemented currently.
--
Michal Hocko
SUSE Labs