* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-22 16:36 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-22 16:36 UTC (permalink / raw)
To: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, blackzert, gregkh, deepa.kernel, mhocko, hughd,
kstewart, pombredanne, akpm, steve.capper, punit.agrawal,
paul.burton, aneesh.kumar, npiggin, keescook, bhsharma, riel,
nitin.m.gupta, kirill.shutemov, dan.j.williams, jack,
ross.zwisler, jglisse, willy, aarcange, oleg, linux-alpha,
linux-kernel, linux-snps-arc, linux-arm-kernel, linux-ia64,
linux-metag, linux-mips, linux-parisc, linuxppc-dev, linux-s390,
linux-sh, sparclinux, linux-mm
Current implementation doesn't randomize address returned by mmap.
All the entropy ends with choosing mmap_base_addr at the process
creation. After that mmap build very predictable layout of address
space. It allows to bypass ASLR in many cases. This patch make
randomization of address on any mmap call.
---
v2: Changed the way how gap was chosen. Now we don't get all possible
gaps. Random address generated and used as a tree walking direction.
Tree walked with backtracking till suitable gap will be found.
When the gap was found, address randomly shifted from next vma start.
The vm_unmapped_area_info structure was extended with new field random_shift
what might be used to set arch-depended limit on shift to next vma start.
In case of x86-64 architecture this shift is 256 pages for 32 bit applications
and 0x1000000 pages for 64 bit.
To get the entropy pseudo-random is used. This is because on Intel x86-64
processors instruction RDRAND works very slow if buffer is consumed -
after about 10000 iterations.
This feature could be enabled by setting randomize_va_space with 4.
---
Performance:
After applying this patch single mmap took about 7% longer according to
following test:
before = rdtsc();
addr = mmap(0, SIZE, PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
after = rdtsc();
diff = after - before;
munmap(addr, SIZE)
...
unsigned long long total = 0;
for(int i = 0; i < count; ++i) {
total += one_iteration();
}
printf("%lld\n", total);
Time is consumed by div instruction in computation of the address.
make kernel:
echo 2 > /proc/sys/kernel/randomize_va_space
make mrproper && make defconfig && time make
real 11m9.925s
user 10m17.829s
sys 1m4.969s
echo 4 > /proc/sys/kernel/randomize_va_space
make mrproper && make defconfig && time make
real 11m12.806s
user 10m18.305s
sys 1m4.281s
Ilya Smith (2):
Randomization of address chosen by mmap.
Architecture defined limit on memory region random shift.
arch/alpha/kernel/osf_sys.c | 1 +
arch/arc/mm/mmap.c | 1 +
arch/arm/mm/mmap.c | 2 +
arch/frv/mm/elf-fdpic.c | 1 +
arch/ia64/kernel/sys_ia64.c | 1 +
arch/ia64/mm/hugetlbpage.c | 1 +
arch/metag/mm/hugetlbpage.c | 1 +
arch/mips/mm/mmap.c | 1 +
arch/parisc/kernel/sys_parisc.c | 2 +
arch/powerpc/mm/hugetlbpage-radix.c | 1 +
arch/powerpc/mm/mmap.c | 2 +
arch/powerpc/mm/slice.c | 2 +
arch/s390/mm/mmap.c | 2 +
arch/sh/mm/mmap.c | 2 +
arch/sparc/kernel/sys_sparc_32.c | 1 +
arch/sparc/kernel/sys_sparc_64.c | 2 +
arch/sparc/mm/hugetlbpage.c | 2 +
arch/tile/mm/hugetlbpage.c | 2 +
arch/x86/kernel/sys_x86_64.c | 4 +
arch/x86/mm/hugetlbpage.c | 4 +
fs/hugetlbfs/inode.c | 1 +
include/linux/mm.h | 17 ++--
mm/mmap.c | 165 ++++++++++++++++++++++++++++++++++++
23 files changed, 213 insertions(+), 5 deletions(-)
--
2.7.4
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-22 16:36 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-22 16:36 UTC (permalink / raw)
To: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, blackzert, gregkh, deepa.kernel, mhocko, hughd,
kstewart, pombredanne, akpm, steve.capper, punit.agrawal,
paul.burton, aneesh.kumar, npiggin, keescook, bhsharma, riel,
nitin.m.gupta, kirill.shutemov, dan.j.williams, jack,
ross.zwisler, jglisse, willy, aarcange, oleg, linux-alpha,
linux-kernel, linux-snps-arc, linux-arm-kernel, linux-ia64,
linux-metag, linux-mips, linux-parisc, linuxppc-dev, linux-s390,
linux-sh, sparclinux, linux-mm
Current implementation doesn't randomize address returned by mmap.
All the entropy ends with choosing mmap_base_addr at the process
creation. After that mmap build very predictable layout of address
space. It allows to bypass ASLR in many cases. This patch make
randomization of address on any mmap call.
---
v2: Changed the way how gap was chosen. Now we don't get all possible
gaps. Random address generated and used as a tree walking direction.
Tree walked with backtracking till suitable gap will be found.
When the gap was found, address randomly shifted from next vma start.
The vm_unmapped_area_info structure was extended with new field random_shift
what might be used to set arch-depended limit on shift to next vma start.
In case of x86-64 architecture this shift is 256 pages for 32 bit applications
and 0x1000000 pages for 64 bit.
To get the entropy pseudo-random is used. This is because on Intel x86-64
processors instruction RDRAND works very slow if buffer is consumed -
after about 10000 iterations.
This feature could be enabled by setting randomize_va_space with 4.
---
Performance:
After applying this patch single mmap took about 7% longer according to
following test:
before = rdtsc();
addr = mmap(0, SIZE, PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
after = rdtsc();
diff = after - before;
munmap(addr, SIZE)
...
unsigned long long total = 0;
for(int i = 0; i < count; ++i) {
total += one_iteration();
}
printf("%lld\n", total);
Time is consumed by div instruction in computation of the address.
make kernel:
echo 2 > /proc/sys/kernel/randomize_va_space
make mrproper && make defconfig && time make
real 11m9.925s
user 10m17.829s
sys 1m4.969s
echo 4 > /proc/sys/kernel/randomize_va_space
make mrproper && make defconfig && time make
real 11m12.806s
user 10m18.305s
sys 1m4.281s
Ilya Smith (2):
Randomization of address chosen by mmap.
Architecture defined limit on memory region random shift.
arch/alpha/kernel/osf_sys.c | 1 +
arch/arc/mm/mmap.c | 1 +
arch/arm/mm/mmap.c | 2 +
arch/frv/mm/elf-fdpic.c | 1 +
arch/ia64/kernel/sys_ia64.c | 1 +
arch/ia64/mm/hugetlbpage.c | 1 +
arch/metag/mm/hugetlbpage.c | 1 +
arch/mips/mm/mmap.c | 1 +
arch/parisc/kernel/sys_parisc.c | 2 +
arch/powerpc/mm/hugetlbpage-radix.c | 1 +
arch/powerpc/mm/mmap.c | 2 +
arch/powerpc/mm/slice.c | 2 +
arch/s390/mm/mmap.c | 2 +
arch/sh/mm/mmap.c | 2 +
arch/sparc/kernel/sys_sparc_32.c | 1 +
arch/sparc/kernel/sys_sparc_64.c | 2 +
arch/sparc/mm/hugetlbpage.c | 2 +
arch/tile/mm/hugetlbpage.c | 2 +
arch/x86/kernel/sys_x86_64.c | 4 +
arch/x86/mm/hugetlbpage.c | 4 +
fs/hugetlbfs/inode.c | 1 +
include/linux/mm.h | 17 ++--
mm/mmap.c | 165 ++++++++++++++++++++++++++++++++++++
23 files changed, 213 insertions(+), 5 deletions(-)
--
2.7.4
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-22 16:36 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-22 16:36 UTC (permalink / raw)
To: linux-snps-arc
Current implementation doesn't randomize address returned by mmap.
All the entropy ends with choosing mmap_base_addr at the process
creation. After that mmap build very predictable layout of address
space. It allows to bypass ASLR in many cases. This patch make
randomization of address on any mmap call.
---
v2: Changed the way how gap was chosen. Now we don't get all possible
gaps. Random address generated and used as a tree walking direction.
Tree walked with backtracking till suitable gap will be found.
When the gap was found, address randomly shifted from next vma start.
The vm_unmapped_area_info structure was extended with new field random_shift
what might be used to set arch-depended limit on shift to next vma start.
In case of x86-64 architecture this shift is 256 pages for 32 bit applications
and 0x1000000 pages for 64 bit.
To get the entropy pseudo-random is used. This is because on Intel x86-64
processors instruction RDRAND works very slow if buffer is consumed -
after about 10000 iterations.
This feature could be enabled by setting randomize_va_space with 4.
---
Performance:
After applying this patch single mmap took about 7% longer according to
following test:
before = rdtsc();
addr = mmap(0, SIZE, PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
after = rdtsc();
diff = after - before;
munmap(addr, SIZE)
...
unsigned long long total = 0;
for(int i = 0; i < count; ++i) {
total += one_iteration();
}
printf("%lld\n", total);
Time is consumed by div instruction in computation of the address.
make kernel:
echo 2 > /proc/sys/kernel/randomize_va_space
make mrproper && make defconfig && time make
real 11m9.925s
user 10m17.829s
sys 1m4.969s
echo 4 > /proc/sys/kernel/randomize_va_space
make mrproper && make defconfig && time make
real 11m12.806s
user 10m18.305s
sys 1m4.281s
Ilya Smith (2):
Randomization of address chosen by mmap.
Architecture defined limit on memory region random shift.
arch/alpha/kernel/osf_sys.c | 1 +
arch/arc/mm/mmap.c | 1 +
arch/arm/mm/mmap.c | 2 +
arch/frv/mm/elf-fdpic.c | 1 +
arch/ia64/kernel/sys_ia64.c | 1 +
arch/ia64/mm/hugetlbpage.c | 1 +
arch/metag/mm/hugetlbpage.c | 1 +
arch/mips/mm/mmap.c | 1 +
arch/parisc/kernel/sys_parisc.c | 2 +
arch/powerpc/mm/hugetlbpage-radix.c | 1 +
arch/powerpc/mm/mmap.c | 2 +
arch/powerpc/mm/slice.c | 2 +
arch/s390/mm/mmap.c | 2 +
arch/sh/mm/mmap.c | 2 +
arch/sparc/kernel/sys_sparc_32.c | 1 +
arch/sparc/kernel/sys_sparc_64.c | 2 +
arch/sparc/mm/hugetlbpage.c | 2 +
arch/tile/mm/hugetlbpage.c | 2 +
arch/x86/kernel/sys_x86_64.c | 4 +
arch/x86/mm/hugetlbpage.c | 4 +
fs/hugetlbfs/inode.c | 1 +
include/linux/mm.h | 17 ++--
mm/mmap.c | 165 ++++++++++++++++++++++++++++++++++++
23 files changed, 213 insertions(+), 5 deletions(-)
--
2.7.4
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 1/2] Randomization of address chosen by mmap.
2018-03-22 16:36 ` Ilya Smith
(?)
@ 2018-03-22 16:36 ` Ilya Smith
-1 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-22 16:36 UTC (permalink / raw)
To: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, blackzert, gregkh, deepa.kernel, mhocko, hughd,
kstewart, pombredanne, akpm, steve.capper, punit.agrawal,
paul.burton, aneesh.kumar, npiggin, keescook, bhsharma, riel,
nitin.m.gupta, kirill.shutemov, dan.j.williams, jack,
ross.zwisler, jglisse, willy, aarcange, oleg, linux-alpha,
linux-kernel, linux-snps-arc, linux-arm-kernel, linux-ia64,
linux-metag, linux-mips, linux-parisc, linuxppc-dev, linux-s390,
linux-sh, sparclinux, linux-mm
Signed-off-by: Ilya Smith <blackzert@gmail.com>
---
include/linux/mm.h | 16 ++++--
mm/mmap.c | 164 +++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 175 insertions(+), 5 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index ad06d42..c716257 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -25,6 +25,7 @@
#include <linux/err.h>
#include <linux/page_ref.h>
#include <linux/memremap.h>
+#include <linux/sched.h>
struct mempolicy;
struct anon_vma;
@@ -2253,6 +2254,13 @@ struct vm_unmapped_area_info {
unsigned long align_offset;
};
+#ifndef CONFIG_MMU
+#define randomize_va_space 0
+#else
+extern int randomize_va_space;
+#endif
+
+extern unsigned long unmapped_area_random(struct vm_unmapped_area_info *info);
extern unsigned long unmapped_area(struct vm_unmapped_area_info *info);
extern unsigned long unmapped_area_topdown(struct vm_unmapped_area_info *info);
@@ -2268,6 +2276,9 @@ extern unsigned long unmapped_area_topdown(struct vm_unmapped_area_info *info);
static inline unsigned long
vm_unmapped_area(struct vm_unmapped_area_info *info)
{
+ /* How about 32 bit process?? */
+ if ((current->flags & PF_RANDOMIZE) && randomize_va_space > 3)
+ return unmapped_area_random(info);
if (info->flags & VM_UNMAPPED_AREA_TOPDOWN)
return unmapped_area_topdown(info);
else
@@ -2529,11 +2540,6 @@ int drop_caches_sysctl_handler(struct ctl_table *, int,
void drop_slab(void);
void drop_slab_node(int nid);
-#ifndef CONFIG_MMU
-#define randomize_va_space 0
-#else
-extern int randomize_va_space;
-#endif
const char * arch_vma_name(struct vm_area_struct *vma);
void print_vma_addr(char *prefix, unsigned long rip);
diff --git a/mm/mmap.c b/mm/mmap.c
index 9efdc021..ba9cebb 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -45,6 +45,7 @@
#include <linux/moduleparam.h>
#include <linux/pkeys.h>
#include <linux/oom.h>
+#include <linux/random.h>
#include <linux/uaccess.h>
#include <asm/cacheflush.h>
@@ -1780,6 +1781,169 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
return error;
}
+unsigned long unmapped_area_random(struct vm_unmapped_area_info *info)
+{
+ struct mm_struct *mm = current->mm;
+ struct vm_area_struct *vma = NULL;
+ struct vm_area_struct *visited_vma = NULL;
+ unsigned long entropy[2];
+ unsigned long length, low_limit, high_limit, gap_start, gap_end;
+ unsigned long addr = 0;
+
+ /* get entropy with prng */
+ prandom_bytes(&entropy, sizeof(entropy));
+ /* small hack to prevent EPERM result */
+ info->low_limit = max(info->low_limit, mmap_min_addr);
+
+ /* Adjust search length to account for worst case alignment overhead */
+ length = info->length + info->align_mask;
+ if (length < info->length)
+ return -ENOMEM;
+
+ /*
+ * Adjust search limits by the desired length.
+ * See implementation comment at top of unmapped_area().
+ */
+ gap_end = info->high_limit;
+ if (gap_end < length)
+ return -ENOMEM;
+ high_limit = gap_end - length;
+
+ low_limit = info->low_limit + info->align_mask;
+ if (low_limit >= high_limit)
+ return -ENOMEM;
+
+ /* Choose random addr in limit range */
+ addr = entropy[0] % ((high_limit - low_limit) >> PAGE_SHIFT);
+ addr = low_limit + (addr << PAGE_SHIFT);
+ addr += (info->align_offset - addr) & info->align_mask;
+
+ /* Check if rbtree root looks promising */
+ if (RB_EMPTY_ROOT(&mm->mm_rb))
+ return -ENOMEM;
+
+ vma = rb_entry(mm->mm_rb.rb_node, struct vm_area_struct, vm_rb);
+ if (vma->rb_subtree_gap < length)
+ return -ENOMEM;
+ /* use randomly chosen address to find closest suitable gap */
+ while (true) {
+ gap_start = vma->vm_prev ? vm_end_gap(vma->vm_prev) : 0;
+ gap_end = vm_start_gap(vma);
+ if (gap_end < low_limit)
+ break;
+ if (addr < vm_start_gap(vma)) {
+ /* random said check left */
+ if (vma->vm_rb.rb_left) {
+ struct vm_area_struct *left + rb_entry(vma->vm_rb.rb_left,
+ struct vm_area_struct, vm_rb);
+ if (addr <= vm_start_gap(left) &&
+ left->rb_subtree_gap >= length) {
+ vma = left;
+ continue;
+ }
+ }
+ } else if (addr >= vm_end_gap(vma)) {
+ /* random said check right */
+ if (vma->vm_rb.rb_right) {
+ struct vm_area_struct *right + rb_entry(vma->vm_rb.rb_right,
+ struct vm_area_struct, vm_rb);
+ /* it want go to the right */
+ if (right->rb_subtree_gap >= length) {
+ vma = right;
+ continue;
+ }
+ }
+ }
+ if (gap_start < low_limit) {
+ if (gap_end <= low_limit)
+ break;
+ gap_start = low_limit;
+ } else if (gap_end > info->high_limit) {
+ if (gap_start >= info->high_limit)
+ break;
+ gap_end = info->high_limit;
+ }
+ if (gap_end > gap_start &&
+ gap_end - gap_start >= length)
+ goto found;
+ visited_vma = vma;
+ break;
+ }
+ /* not found */
+ while (true) {
+ gap_start = vma->vm_prev ? vm_end_gap(vma->vm_prev) : 0;
+
+ if (gap_start <= high_limit && vma->vm_rb.rb_right) {
+ struct vm_area_struct *right + rb_entry(vma->vm_rb.rb_right,
+ struct vm_area_struct, vm_rb);
+ if (right->rb_subtree_gap >= length &&
+ right != visited_vma) {
+ vma = right;
+ continue;
+ }
+ }
+
+check_current:
+ /* Check if current node has a suitable gap */
+ gap_end = vm_start_gap(vma);
+ if (gap_end <= low_limit)
+ goto go_back;
+
+ if (gap_start < low_limit)
+ gap_start = low_limit;
+
+ if (gap_start <= high_limit &&
+ gap_end > gap_start && gap_end - gap_start >= length)
+ goto found;
+
+ /* Visit left subtree if it looks promising */
+ if (vma->vm_rb.rb_left) {
+ struct vm_area_struct *left + rb_entry(vma->vm_rb.rb_left,
+ struct vm_area_struct, vm_rb);
+ if (left->rb_subtree_gap >= length &&
+ vm_end_gap(left) > low_limit &&
+ left != visited_vma) {
+ vma = left;
+ continue;
+ }
+ }
+go_back:
+ /* Go back up the rbtree to find next candidate node */
+ while (true) {
+ struct rb_node *prev = &vma->vm_rb;
+
+ if (!rb_parent(prev))
+ return -ENOMEM;
+ visited_vma = vma;
+ vma = rb_entry(rb_parent(prev),
+ struct vm_area_struct, vm_rb);
+ if (prev = vma->vm_rb.rb_right) {
+ gap_start = vma->vm_prev ?
+ vm_end_gap(vma->vm_prev) : low_limit;
+ goto check_current;
+ }
+ }
+ }
+found:
+ /* We found a suitable gap. Clip it with the original high_limit. */
+ if (gap_end > info->high_limit)
+ gap_end = info->high_limit;
+ gap_end -= info->length;
+ gap_end -= (gap_end - info->align_offset) & info->align_mask;
+ /* only one suitable page */
+ if (gap_end = gap_start)
+ return gap_start;
+ addr = entropy[1] % (min((gap_end - gap_start) >> PAGE_SHIFT,
+ 0x10000UL));
+ addr = gap_end - (addr << PAGE_SHIFT);
+ addr += (info->align_offset - addr) & info->align_mask;
+ return addr;
+}
+
unsigned long unmapped_area(struct vm_unmapped_area_info *info)
{
/*
--
2.7.4
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [RFC PATCH v2 1/2] Randomization of address chosen by mmap.
@ 2018-03-22 16:36 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-22 16:36 UTC (permalink / raw)
To: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, blackzert, gregkh, deepa.kernel, mhocko, hughd,
kstewart, pombredanne, akpm, steve.capper, punit.agrawal,
paul.burton, aneesh.kumar, npiggin, keescook, bhsharma, riel,
nitin.m.gupta, kirill.shutemov, dan.j.williams, jack,
ross.zwisler, jglisse, willy, aarcange, oleg, linux-alpha,
linux-kernel, linux-snps-arc, linux-arm-kernel, linux-ia64,
linux-metag, linux-mips, linux-parisc, linuxppc-dev, linux-s390,
linux-sh, sparclinux, linux-mm
Signed-off-by: Ilya Smith <blackzert@gmail.com>
---
include/linux/mm.h | 16 ++++--
mm/mmap.c | 164 +++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 175 insertions(+), 5 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index ad06d42..c716257 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -25,6 +25,7 @@
#include <linux/err.h>
#include <linux/page_ref.h>
#include <linux/memremap.h>
+#include <linux/sched.h>
struct mempolicy;
struct anon_vma;
@@ -2253,6 +2254,13 @@ struct vm_unmapped_area_info {
unsigned long align_offset;
};
+#ifndef CONFIG_MMU
+#define randomize_va_space 0
+#else
+extern int randomize_va_space;
+#endif
+
+extern unsigned long unmapped_area_random(struct vm_unmapped_area_info *info);
extern unsigned long unmapped_area(struct vm_unmapped_area_info *info);
extern unsigned long unmapped_area_topdown(struct vm_unmapped_area_info *info);
@@ -2268,6 +2276,9 @@ extern unsigned long unmapped_area_topdown(struct vm_unmapped_area_info *info);
static inline unsigned long
vm_unmapped_area(struct vm_unmapped_area_info *info)
{
+ /* How about 32 bit process?? */
+ if ((current->flags & PF_RANDOMIZE) && randomize_va_space > 3)
+ return unmapped_area_random(info);
if (info->flags & VM_UNMAPPED_AREA_TOPDOWN)
return unmapped_area_topdown(info);
else
@@ -2529,11 +2540,6 @@ int drop_caches_sysctl_handler(struct ctl_table *, int,
void drop_slab(void);
void drop_slab_node(int nid);
-#ifndef CONFIG_MMU
-#define randomize_va_space 0
-#else
-extern int randomize_va_space;
-#endif
const char * arch_vma_name(struct vm_area_struct *vma);
void print_vma_addr(char *prefix, unsigned long rip);
diff --git a/mm/mmap.c b/mm/mmap.c
index 9efdc021..ba9cebb 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -45,6 +45,7 @@
#include <linux/moduleparam.h>
#include <linux/pkeys.h>
#include <linux/oom.h>
+#include <linux/random.h>
#include <linux/uaccess.h>
#include <asm/cacheflush.h>
@@ -1780,6 +1781,169 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
return error;
}
+unsigned long unmapped_area_random(struct vm_unmapped_area_info *info)
+{
+ struct mm_struct *mm = current->mm;
+ struct vm_area_struct *vma = NULL;
+ struct vm_area_struct *visited_vma = NULL;
+ unsigned long entropy[2];
+ unsigned long length, low_limit, high_limit, gap_start, gap_end;
+ unsigned long addr = 0;
+
+ /* get entropy with prng */
+ prandom_bytes(&entropy, sizeof(entropy));
+ /* small hack to prevent EPERM result */
+ info->low_limit = max(info->low_limit, mmap_min_addr);
+
+ /* Adjust search length to account for worst case alignment overhead */
+ length = info->length + info->align_mask;
+ if (length < info->length)
+ return -ENOMEM;
+
+ /*
+ * Adjust search limits by the desired length.
+ * See implementation comment at top of unmapped_area().
+ */
+ gap_end = info->high_limit;
+ if (gap_end < length)
+ return -ENOMEM;
+ high_limit = gap_end - length;
+
+ low_limit = info->low_limit + info->align_mask;
+ if (low_limit >= high_limit)
+ return -ENOMEM;
+
+ /* Choose random addr in limit range */
+ addr = entropy[0] % ((high_limit - low_limit) >> PAGE_SHIFT);
+ addr = low_limit + (addr << PAGE_SHIFT);
+ addr += (info->align_offset - addr) & info->align_mask;
+
+ /* Check if rbtree root looks promising */
+ if (RB_EMPTY_ROOT(&mm->mm_rb))
+ return -ENOMEM;
+
+ vma = rb_entry(mm->mm_rb.rb_node, struct vm_area_struct, vm_rb);
+ if (vma->rb_subtree_gap < length)
+ return -ENOMEM;
+ /* use randomly chosen address to find closest suitable gap */
+ while (true) {
+ gap_start = vma->vm_prev ? vm_end_gap(vma->vm_prev) : 0;
+ gap_end = vm_start_gap(vma);
+ if (gap_end < low_limit)
+ break;
+ if (addr < vm_start_gap(vma)) {
+ /* random said check left */
+ if (vma->vm_rb.rb_left) {
+ struct vm_area_struct *left =
+ rb_entry(vma->vm_rb.rb_left,
+ struct vm_area_struct, vm_rb);
+ if (addr <= vm_start_gap(left) &&
+ left->rb_subtree_gap >= length) {
+ vma = left;
+ continue;
+ }
+ }
+ } else if (addr >= vm_end_gap(vma)) {
+ /* random said check right */
+ if (vma->vm_rb.rb_right) {
+ struct vm_area_struct *right =
+ rb_entry(vma->vm_rb.rb_right,
+ struct vm_area_struct, vm_rb);
+ /* it want go to the right */
+ if (right->rb_subtree_gap >= length) {
+ vma = right;
+ continue;
+ }
+ }
+ }
+ if (gap_start < low_limit) {
+ if (gap_end <= low_limit)
+ break;
+ gap_start = low_limit;
+ } else if (gap_end > info->high_limit) {
+ if (gap_start >= info->high_limit)
+ break;
+ gap_end = info->high_limit;
+ }
+ if (gap_end > gap_start &&
+ gap_end - gap_start >= length)
+ goto found;
+ visited_vma = vma;
+ break;
+ }
+ /* not found */
+ while (true) {
+ gap_start = vma->vm_prev ? vm_end_gap(vma->vm_prev) : 0;
+
+ if (gap_start <= high_limit && vma->vm_rb.rb_right) {
+ struct vm_area_struct *right =
+ rb_entry(vma->vm_rb.rb_right,
+ struct vm_area_struct, vm_rb);
+ if (right->rb_subtree_gap >= length &&
+ right != visited_vma) {
+ vma = right;
+ continue;
+ }
+ }
+
+check_current:
+ /* Check if current node has a suitable gap */
+ gap_end = vm_start_gap(vma);
+ if (gap_end <= low_limit)
+ goto go_back;
+
+ if (gap_start < low_limit)
+ gap_start = low_limit;
+
+ if (gap_start <= high_limit &&
+ gap_end > gap_start && gap_end - gap_start >= length)
+ goto found;
+
+ /* Visit left subtree if it looks promising */
+ if (vma->vm_rb.rb_left) {
+ struct vm_area_struct *left =
+ rb_entry(vma->vm_rb.rb_left,
+ struct vm_area_struct, vm_rb);
+ if (left->rb_subtree_gap >= length &&
+ vm_end_gap(left) > low_limit &&
+ left != visited_vma) {
+ vma = left;
+ continue;
+ }
+ }
+go_back:
+ /* Go back up the rbtree to find next candidate node */
+ while (true) {
+ struct rb_node *prev = &vma->vm_rb;
+
+ if (!rb_parent(prev))
+ return -ENOMEM;
+ visited_vma = vma;
+ vma = rb_entry(rb_parent(prev),
+ struct vm_area_struct, vm_rb);
+ if (prev == vma->vm_rb.rb_right) {
+ gap_start = vma->vm_prev ?
+ vm_end_gap(vma->vm_prev) : low_limit;
+ goto check_current;
+ }
+ }
+ }
+found:
+ /* We found a suitable gap. Clip it with the original high_limit. */
+ if (gap_end > info->high_limit)
+ gap_end = info->high_limit;
+ gap_end -= info->length;
+ gap_end -= (gap_end - info->align_offset) & info->align_mask;
+ /* only one suitable page */
+ if (gap_end == gap_start)
+ return gap_start;
+ addr = entropy[1] % (min((gap_end - gap_start) >> PAGE_SHIFT,
+ 0x10000UL));
+ addr = gap_end - (addr << PAGE_SHIFT);
+ addr += (info->align_offset - addr) & info->align_mask;
+ return addr;
+}
+
unsigned long unmapped_area(struct vm_unmapped_area_info *info)
{
/*
--
2.7.4
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [RFC PATCH v2 1/2] Randomization of address chosen by mmap.
@ 2018-03-22 16:36 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-22 16:36 UTC (permalink / raw)
To: linux-snps-arc
Signed-off-by: Ilya Smith <blackzert at gmail.com>
---
include/linux/mm.h | 16 ++++--
mm/mmap.c | 164 +++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 175 insertions(+), 5 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index ad06d42..c716257 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -25,6 +25,7 @@
#include <linux/err.h>
#include <linux/page_ref.h>
#include <linux/memremap.h>
+#include <linux/sched.h>
struct mempolicy;
struct anon_vma;
@@ -2253,6 +2254,13 @@ struct vm_unmapped_area_info {
unsigned long align_offset;
};
+#ifndef CONFIG_MMU
+#define randomize_va_space 0
+#else
+extern int randomize_va_space;
+#endif
+
+extern unsigned long unmapped_area_random(struct vm_unmapped_area_info *info);
extern unsigned long unmapped_area(struct vm_unmapped_area_info *info);
extern unsigned long unmapped_area_topdown(struct vm_unmapped_area_info *info);
@@ -2268,6 +2276,9 @@ extern unsigned long unmapped_area_topdown(struct vm_unmapped_area_info *info);
static inline unsigned long
vm_unmapped_area(struct vm_unmapped_area_info *info)
{
+ /* How about 32 bit process?? */
+ if ((current->flags & PF_RANDOMIZE) && randomize_va_space > 3)
+ return unmapped_area_random(info);
if (info->flags & VM_UNMAPPED_AREA_TOPDOWN)
return unmapped_area_topdown(info);
else
@@ -2529,11 +2540,6 @@ int drop_caches_sysctl_handler(struct ctl_table *, int,
void drop_slab(void);
void drop_slab_node(int nid);
-#ifndef CONFIG_MMU
-#define randomize_va_space 0
-#else
-extern int randomize_va_space;
-#endif
const char * arch_vma_name(struct vm_area_struct *vma);
void print_vma_addr(char *prefix, unsigned long rip);
diff --git a/mm/mmap.c b/mm/mmap.c
index 9efdc021..ba9cebb 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -45,6 +45,7 @@
#include <linux/moduleparam.h>
#include <linux/pkeys.h>
#include <linux/oom.h>
+#include <linux/random.h>
#include <linux/uaccess.h>
#include <asm/cacheflush.h>
@@ -1780,6 +1781,169 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
return error;
}
+unsigned long unmapped_area_random(struct vm_unmapped_area_info *info)
+{
+ struct mm_struct *mm = current->mm;
+ struct vm_area_struct *vma = NULL;
+ struct vm_area_struct *visited_vma = NULL;
+ unsigned long entropy[2];
+ unsigned long length, low_limit, high_limit, gap_start, gap_end;
+ unsigned long addr = 0;
+
+ /* get entropy with prng */
+ prandom_bytes(&entropy, sizeof(entropy));
+ /* small hack to prevent EPERM result */
+ info->low_limit = max(info->low_limit, mmap_min_addr);
+
+ /* Adjust search length to account for worst case alignment overhead */
+ length = info->length + info->align_mask;
+ if (length < info->length)
+ return -ENOMEM;
+
+ /*
+ * Adjust search limits by the desired length.
+ * See implementation comment at top of unmapped_area().
+ */
+ gap_end = info->high_limit;
+ if (gap_end < length)
+ return -ENOMEM;
+ high_limit = gap_end - length;
+
+ low_limit = info->low_limit + info->align_mask;
+ if (low_limit >= high_limit)
+ return -ENOMEM;
+
+ /* Choose random addr in limit range */
+ addr = entropy[0] % ((high_limit - low_limit) >> PAGE_SHIFT);
+ addr = low_limit + (addr << PAGE_SHIFT);
+ addr += (info->align_offset - addr) & info->align_mask;
+
+ /* Check if rbtree root looks promising */
+ if (RB_EMPTY_ROOT(&mm->mm_rb))
+ return -ENOMEM;
+
+ vma = rb_entry(mm->mm_rb.rb_node, struct vm_area_struct, vm_rb);
+ if (vma->rb_subtree_gap < length)
+ return -ENOMEM;
+ /* use randomly chosen address to find closest suitable gap */
+ while (true) {
+ gap_start = vma->vm_prev ? vm_end_gap(vma->vm_prev) : 0;
+ gap_end = vm_start_gap(vma);
+ if (gap_end < low_limit)
+ break;
+ if (addr < vm_start_gap(vma)) {
+ /* random said check left */
+ if (vma->vm_rb.rb_left) {
+ struct vm_area_struct *left =
+ rb_entry(vma->vm_rb.rb_left,
+ struct vm_area_struct, vm_rb);
+ if (addr <= vm_start_gap(left) &&
+ left->rb_subtree_gap >= length) {
+ vma = left;
+ continue;
+ }
+ }
+ } else if (addr >= vm_end_gap(vma)) {
+ /* random said check right */
+ if (vma->vm_rb.rb_right) {
+ struct vm_area_struct *right =
+ rb_entry(vma->vm_rb.rb_right,
+ struct vm_area_struct, vm_rb);
+ /* it want go to the right */
+ if (right->rb_subtree_gap >= length) {
+ vma = right;
+ continue;
+ }
+ }
+ }
+ if (gap_start < low_limit) {
+ if (gap_end <= low_limit)
+ break;
+ gap_start = low_limit;
+ } else if (gap_end > info->high_limit) {
+ if (gap_start >= info->high_limit)
+ break;
+ gap_end = info->high_limit;
+ }
+ if (gap_end > gap_start &&
+ gap_end - gap_start >= length)
+ goto found;
+ visited_vma = vma;
+ break;
+ }
+ /* not found */
+ while (true) {
+ gap_start = vma->vm_prev ? vm_end_gap(vma->vm_prev) : 0;
+
+ if (gap_start <= high_limit && vma->vm_rb.rb_right) {
+ struct vm_area_struct *right =
+ rb_entry(vma->vm_rb.rb_right,
+ struct vm_area_struct, vm_rb);
+ if (right->rb_subtree_gap >= length &&
+ right != visited_vma) {
+ vma = right;
+ continue;
+ }
+ }
+
+check_current:
+ /* Check if current node has a suitable gap */
+ gap_end = vm_start_gap(vma);
+ if (gap_end <= low_limit)
+ goto go_back;
+
+ if (gap_start < low_limit)
+ gap_start = low_limit;
+
+ if (gap_start <= high_limit &&
+ gap_end > gap_start && gap_end - gap_start >= length)
+ goto found;
+
+ /* Visit left subtree if it looks promising */
+ if (vma->vm_rb.rb_left) {
+ struct vm_area_struct *left =
+ rb_entry(vma->vm_rb.rb_left,
+ struct vm_area_struct, vm_rb);
+ if (left->rb_subtree_gap >= length &&
+ vm_end_gap(left) > low_limit &&
+ left != visited_vma) {
+ vma = left;
+ continue;
+ }
+ }
+go_back:
+ /* Go back up the rbtree to find next candidate node */
+ while (true) {
+ struct rb_node *prev = &vma->vm_rb;
+
+ if (!rb_parent(prev))
+ return -ENOMEM;
+ visited_vma = vma;
+ vma = rb_entry(rb_parent(prev),
+ struct vm_area_struct, vm_rb);
+ if (prev == vma->vm_rb.rb_right) {
+ gap_start = vma->vm_prev ?
+ vm_end_gap(vma->vm_prev) : low_limit;
+ goto check_current;
+ }
+ }
+ }
+found:
+ /* We found a suitable gap. Clip it with the original high_limit. */
+ if (gap_end > info->high_limit)
+ gap_end = info->high_limit;
+ gap_end -= info->length;
+ gap_end -= (gap_end - info->align_offset) & info->align_mask;
+ /* only one suitable page */
+ if (gap_end == gap_start)
+ return gap_start;
+ addr = entropy[1] % (min((gap_end - gap_start) >> PAGE_SHIFT,
+ 0x10000UL));
+ addr = gap_end - (addr << PAGE_SHIFT);
+ addr += (info->align_offset - addr) & info->align_mask;
+ return addr;
+}
+
unsigned long unmapped_area(struct vm_unmapped_area_info *info)
{
/*
--
2.7.4
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [RFC PATCH v2 2/2] Architecture defined limit on memory region random shift.
2018-03-22 16:36 ` Ilya Smith
(?)
@ 2018-03-22 16:36 ` Ilya Smith
-1 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-22 16:36 UTC (permalink / raw)
To: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, blackzert, gregkh, deepa.kernel, mhocko, hughd,
kstewart, pombredanne, akpm, steve.capper, punit.agrawal,
paul.burton, aneesh.kumar, npiggin, keescook, bhsharma, riel,
nitin.m.gupta, kirill.shutemov, dan.j.williams, jack,
ross.zwisler, jglisse, willy, aarcange, oleg, linux-alpha,
linux-kernel, linux-snps-arc, linux-arm-kernel, linux-ia64,
linux-metag, linux-mips, linux-parisc, linuxppc-dev, linux-s390,
linux-sh, sparclinux, linux-mm
Signed-off-by: Ilya Smith <blackzert@gmail.com>
---
arch/alpha/kernel/osf_sys.c | 1 +
arch/arc/mm/mmap.c | 1 +
arch/arm/mm/mmap.c | 2 ++
arch/frv/mm/elf-fdpic.c | 1 +
arch/ia64/kernel/sys_ia64.c | 1 +
arch/ia64/mm/hugetlbpage.c | 1 +
arch/metag/mm/hugetlbpage.c | 1 +
arch/mips/mm/mmap.c | 1 +
arch/parisc/kernel/sys_parisc.c | 2 ++
arch/powerpc/mm/hugetlbpage-radix.c | 1 +
arch/powerpc/mm/mmap.c | 2 ++
arch/powerpc/mm/slice.c | 2 ++
arch/s390/mm/mmap.c | 2 ++
arch/sh/mm/mmap.c | 2 ++
arch/sparc/kernel/sys_sparc_32.c | 1 +
arch/sparc/kernel/sys_sparc_64.c | 2 ++
arch/sparc/mm/hugetlbpage.c | 2 ++
arch/tile/mm/hugetlbpage.c | 2 ++
arch/x86/kernel/sys_x86_64.c | 4 ++++
arch/x86/mm/hugetlbpage.c | 4 ++++
fs/hugetlbfs/inode.c | 1 +
include/linux/mm.h | 1 +
mm/mmap.c | 3 ++-
23 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
index fa1a392..0ab9f31 100644
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -1301,6 +1301,7 @@ arch_get_unmapped_area_1(unsigned long addr, unsigned long len,
info.high_limit = limit;
info.align_mask = 0;
info.align_offset = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
diff --git a/arch/arc/mm/mmap.c b/arch/arc/mm/mmap.c
index 2e13683..45225fc 100644
--- a/arch/arc/mm/mmap.c
+++ b/arch/arc/mm/mmap.c
@@ -75,5 +75,6 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.high_limit = TASK_SIZE;
info.align_mask = do_align ? (PAGE_MASK & (SHMLBA - 1)) : 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index eb1de66..1eb660c 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -101,6 +101,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.high_limit = TASK_SIZE;
info.align_mask = do_align ? (PAGE_MASK & (SHMLBA - 1)) : 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
@@ -152,6 +153,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
info.high_limit = mm->mmap_base;
info.align_mask = do_align ? (PAGE_MASK & (SHMLBA - 1)) : 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
/*
diff --git a/arch/frv/mm/elf-fdpic.c b/arch/frv/mm/elf-fdpic.c
index 46aa289..a2ce2ce 100644
--- a/arch/frv/mm/elf-fdpic.c
+++ b/arch/frv/mm/elf-fdpic.c
@@ -86,6 +86,7 @@ unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr, unsi
info.high_limit = (current->mm->start_stack - 0x00200000);
info.align_mask = 0;
info.align_offset = 0;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
if (!(addr & ~PAGE_MASK))
goto success;
diff --git a/arch/ia64/kernel/sys_ia64.c b/arch/ia64/kernel/sys_ia64.c
index 085adfc..15fa4fb 100644
--- a/arch/ia64/kernel/sys_ia64.c
+++ b/arch/ia64/kernel/sys_ia64.c
@@ -64,6 +64,7 @@ arch_get_unmapped_area (struct file *filp, unsigned long addr, unsigned long len
info.high_limit = TASK_SIZE;
info.align_mask = align_mask;
info.align_offset = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
diff --git a/arch/ia64/mm/hugetlbpage.c b/arch/ia64/mm/hugetlbpage.c
index d16e419..ec7822d 100644
--- a/arch/ia64/mm/hugetlbpage.c
+++ b/arch/ia64/mm/hugetlbpage.c
@@ -162,6 +162,7 @@ unsigned long hugetlb_get_unmapped_area(struct file *file, unsigned long addr, u
info.high_limit = HPAGE_REGION_BASE + RGN_MAP_LIMIT;
info.align_mask = PAGE_MASK & (HPAGE_SIZE - 1);
info.align_offset = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
diff --git a/arch/metag/mm/hugetlbpage.c b/arch/metag/mm/hugetlbpage.c
index 012ee4c..babd325 100644
--- a/arch/metag/mm/hugetlbpage.c
+++ b/arch/metag/mm/hugetlbpage.c
@@ -191,6 +191,7 @@ hugetlb_get_unmapped_area_new_pmd(unsigned long len)
info.high_limit = TASK_SIZE;
info.align_mask = PAGE_MASK & HUGEPT_MASK;
info.align_offset = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index 33d3251..5a3d384 100644
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -122,6 +122,7 @@ static unsigned long arch_get_unmapped_area_common(struct file *filp,
info.flags = 0;
info.low_limit = mm->mmap_base;
info.high_limit = TASK_SIZE;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
diff --git a/arch/parisc/kernel/sys_parisc.c b/arch/parisc/kernel/sys_parisc.c
index 378a754..abf4b05 100644
--- a/arch/parisc/kernel/sys_parisc.c
+++ b/arch/parisc/kernel/sys_parisc.c
@@ -130,6 +130,7 @@ unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.high_limit = mmap_upper_limit();
info.align_mask = last_mmap ? (PAGE_MASK & (SHM_COLOUR - 1)) : 0;
info.align_offset = shared_align_offset(last_mmap, pgoff);
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
found_addr:
@@ -192,6 +193,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
info.high_limit = mm->mmap_base;
info.align_mask = last_mmap ? (PAGE_MASK & (SHM_COLOUR - 1)) : 0;
info.align_offset = shared_align_offset(last_mmap, pgoff);
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
if (!(addr & ~PAGE_MASK))
goto found_addr;
diff --git a/arch/powerpc/mm/hugetlbpage-radix.c b/arch/powerpc/mm/hugetlbpage-radix.c
index 2486bee..1d61a88 100644
--- a/arch/powerpc/mm/hugetlbpage-radix.c
+++ b/arch/powerpc/mm/hugetlbpage-radix.c
@@ -87,6 +87,7 @@ radix__hugetlb_get_unmapped_area(struct file *file, unsigned long addr,
info.high_limit = mm->mmap_base + (high_limit - DEFAULT_MAP_WINDOW);
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
diff --git a/arch/powerpc/mm/mmap.c b/arch/powerpc/mm/mmap.c
index d503f34..7fe98c7 100644
--- a/arch/powerpc/mm/mmap.c
+++ b/arch/powerpc/mm/mmap.c
@@ -136,6 +136,7 @@ radix__arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.low_limit = mm->mmap_base;
info.high_limit = high_limit;
info.align_mask = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
@@ -180,6 +181,7 @@ radix__arch_get_unmapped_area_topdown(struct file *filp,
info.low_limit = max(PAGE_SIZE, mmap_min_addr);
info.high_limit = mm->mmap_base + (high_limit - DEFAULT_MAP_WINDOW);
info.align_mask = 0;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
if (!(addr & ~PAGE_MASK))
diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
index 23ec2c5..2005845 100644
--- a/arch/powerpc/mm/slice.c
+++ b/arch/powerpc/mm/slice.c
@@ -284,6 +284,7 @@ static unsigned long slice_find_area_bottomup(struct mm_struct *mm,
info.length = len;
info.align_mask = PAGE_MASK & ((1ul << pshift) - 1);
info.align_offset = 0;
+ info.random_shift = 0;
addr = TASK_UNMAPPED_BASE;
/*
@@ -330,6 +331,7 @@ static unsigned long slice_find_area_topdown(struct mm_struct *mm,
info.length = len;
info.align_mask = PAGE_MASK & ((1ul << pshift) - 1);
info.align_offset = 0;
+ info.random_shift = 0;
addr = mm->mmap_base;
/*
diff --git a/arch/s390/mm/mmap.c b/arch/s390/mm/mmap.c
index 831bdcf..141823f 100644
--- a/arch/s390/mm/mmap.c
+++ b/arch/s390/mm/mmap.c
@@ -95,6 +95,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.length = len;
info.low_limit = mm->mmap_base;
info.high_limit = TASK_SIZE;
+ info.random_shift = 0;
if (filp || (flags & MAP_SHARED))
info.align_mask = MMAP_ALIGN_MASK << PAGE_SHIFT;
else
@@ -146,6 +147,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
info.length = len;
info.low_limit = max(PAGE_SIZE, mmap_min_addr);
info.high_limit = mm->mmap_base;
+ info.random_shift = 0;
if (filp || (flags & MAP_SHARED))
info.align_mask = MMAP_ALIGN_MASK << PAGE_SHIFT;
else
diff --git a/arch/sh/mm/mmap.c b/arch/sh/mm/mmap.c
index 6a1a129..d9206c2 100644
--- a/arch/sh/mm/mmap.c
+++ b/arch/sh/mm/mmap.c
@@ -74,6 +74,7 @@ unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.high_limit = TASK_SIZE;
info.align_mask = do_colour_align ? (PAGE_MASK & shm_align_mask) : 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
@@ -124,6 +125,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
info.high_limit = mm->mmap_base;
info.align_mask = do_colour_align ? (PAGE_MASK & shm_align_mask) : 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
/*
diff --git a/arch/sparc/kernel/sys_sparc_32.c b/arch/sparc/kernel/sys_sparc_32.c
index 990703b7..af664ba3 100644
--- a/arch/sparc/kernel/sys_sparc_32.c
+++ b/arch/sparc/kernel/sys_sparc_32.c
@@ -66,6 +66,7 @@ unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr, unsi
info.align_mask = (flags & MAP_SHARED) ?
(PAGE_MASK & (SHMLBA - 1)) : 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
diff --git a/arch/sparc/kernel/sys_sparc_64.c b/arch/sparc/kernel/sys_sparc_64.c
index 55416db..3d12e3d 100644
--- a/arch/sparc/kernel/sys_sparc_64.c
+++ b/arch/sparc/kernel/sys_sparc_64.c
@@ -131,6 +131,7 @@ unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr, unsi
info.high_limit = min(task_size, VA_EXCLUDE_START);
info.align_mask = do_color_align ? (PAGE_MASK & (SHMLBA - 1)) : 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
if ((addr & ~PAGE_MASK) && task_size > VA_EXCLUDE_END) {
@@ -194,6 +195,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
info.high_limit = mm->mmap_base;
info.align_mask = do_color_align ? (PAGE_MASK & (SHMLBA - 1)) : 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
/*
diff --git a/arch/sparc/mm/hugetlbpage.c b/arch/sparc/mm/hugetlbpage.c
index 0112d69..6d0c032 100644
--- a/arch/sparc/mm/hugetlbpage.c
+++ b/arch/sparc/mm/hugetlbpage.c
@@ -43,6 +43,7 @@ static unsigned long hugetlb_get_unmapped_area_bottomup(struct file *filp,
info.high_limit = min(task_size, VA_EXCLUDE_START);
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
if ((addr & ~PAGE_MASK) && task_size > VA_EXCLUDE_END) {
@@ -75,6 +76,7 @@ hugetlb_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
info.high_limit = mm->mmap_base;
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
/*
diff --git a/arch/tile/mm/hugetlbpage.c b/arch/tile/mm/hugetlbpage.c
index 0986d42..2b3a9b6 100644
--- a/arch/tile/mm/hugetlbpage.c
+++ b/arch/tile/mm/hugetlbpage.c
@@ -176,6 +176,7 @@ static unsigned long hugetlb_get_unmapped_area_bottomup(struct file *file,
info.high_limit = TASK_SIZE;
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
@@ -193,6 +194,7 @@ static unsigned long hugetlb_get_unmapped_area_topdown(struct file *file,
info.high_limit = current->mm->mmap_base;
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
/*
diff --git a/arch/x86/kernel/sys_x86_64.c b/arch/x86/kernel/sys_x86_64.c
index 676774b..0eda047 100644
--- a/arch/x86/kernel/sys_x86_64.c
+++ b/arch/x86/kernel/sys_x86_64.c
@@ -163,6 +163,8 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.high_limit = end;
info.align_mask = 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = in_compat_syscall() ?
+ 256 : 0x1000000;
if (filp) {
info.align_mask = get_align_mask();
info.align_offset += get_align_bits();
@@ -224,6 +226,8 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
info.align_mask = 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = in_compat_syscall() ?
+ 256 : 0x1000000;
if (filp) {
info.align_mask = get_align_mask();
info.align_offset += get_align_bits();
diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
index 00b2966..f4f6436 100644
--- a/arch/x86/mm/hugetlbpage.c
+++ b/arch/x86/mm/hugetlbpage.c
@@ -97,6 +97,8 @@ static unsigned long hugetlb_get_unmapped_area_bottomup(struct file *file,
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
+ info.random_shift = in_compat_syscall() ?
+ 256 : 0x1000000;
return vm_unmapped_area(&info);
}
@@ -121,6 +123,8 @@ static unsigned long hugetlb_get_unmapped_area_topdown(struct file *file,
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
+ info.random_shift = in_compat_syscall() ?
+ 256 : 0x1000000;
addr = vm_unmapped_area(&info);
/*
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 8fe1b0a..83e962e 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -200,6 +200,7 @@ hugetlb_get_unmapped_area(struct file *file, unsigned long addr,
info.high_limit = TASK_SIZE;
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
#endif
diff --git a/include/linux/mm.h b/include/linux/mm.h
index c716257..f869e6d 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2252,6 +2252,7 @@ struct vm_unmapped_area_info {
unsigned long high_limit;
unsigned long align_mask;
unsigned long align_offset;
+ unsigned long random_shift;
};
#ifndef CONFIG_MMU
diff --git a/mm/mmap.c b/mm/mmap.c
index ba9cebb..425fa09 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1938,7 +1938,7 @@ unsigned long unmapped_area_random(struct vm_unmapped_area_info *info)
if (gap_end = gap_start)
return gap_start;
addr = entropy[1] % (min((gap_end - gap_start) >> PAGE_SHIFT,
- 0x10000UL));
+ info->random_shift));
addr = gap_end - (addr << PAGE_SHIFT);
addr += (info->align_offset - addr) & info->align_mask;
return addr;
@@ -2186,6 +2186,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.low_limit = mm->mmap_base;
info.high_limit = TASK_SIZE;
info.align_mask = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
#endif
--
2.7.4
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [RFC PATCH v2 2/2] Architecture defined limit on memory region random shift.
@ 2018-03-22 16:36 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-22 16:36 UTC (permalink / raw)
To: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, blackzert, gregkh, deepa.kernel, mhocko, hughd,
kstewart, pombredanne, akpm, steve.capper, punit.agrawal,
paul.burton, aneesh.kumar, npiggin, keescook, bhsharma, riel,
nitin.m.gupta, kirill.shutemov, dan.j.williams, jack,
ross.zwisler, jglisse, willy, aarcange, oleg, linux-alpha,
linux-kernel, linux-snps-arc, linux-arm-kernel, linux-ia64,
linux-metag, linux-mips, linux-parisc, linuxppc-dev, linux-s390,
linux-sh, sparclinux, linux-mm
Signed-off-by: Ilya Smith <blackzert@gmail.com>
---
arch/alpha/kernel/osf_sys.c | 1 +
arch/arc/mm/mmap.c | 1 +
arch/arm/mm/mmap.c | 2 ++
arch/frv/mm/elf-fdpic.c | 1 +
arch/ia64/kernel/sys_ia64.c | 1 +
arch/ia64/mm/hugetlbpage.c | 1 +
arch/metag/mm/hugetlbpage.c | 1 +
arch/mips/mm/mmap.c | 1 +
arch/parisc/kernel/sys_parisc.c | 2 ++
arch/powerpc/mm/hugetlbpage-radix.c | 1 +
arch/powerpc/mm/mmap.c | 2 ++
arch/powerpc/mm/slice.c | 2 ++
arch/s390/mm/mmap.c | 2 ++
arch/sh/mm/mmap.c | 2 ++
arch/sparc/kernel/sys_sparc_32.c | 1 +
arch/sparc/kernel/sys_sparc_64.c | 2 ++
arch/sparc/mm/hugetlbpage.c | 2 ++
arch/tile/mm/hugetlbpage.c | 2 ++
arch/x86/kernel/sys_x86_64.c | 4 ++++
arch/x86/mm/hugetlbpage.c | 4 ++++
fs/hugetlbfs/inode.c | 1 +
include/linux/mm.h | 1 +
mm/mmap.c | 3 ++-
23 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
index fa1a392..0ab9f31 100644
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -1301,6 +1301,7 @@ arch_get_unmapped_area_1(unsigned long addr, unsigned long len,
info.high_limit = limit;
info.align_mask = 0;
info.align_offset = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
diff --git a/arch/arc/mm/mmap.c b/arch/arc/mm/mmap.c
index 2e13683..45225fc 100644
--- a/arch/arc/mm/mmap.c
+++ b/arch/arc/mm/mmap.c
@@ -75,5 +75,6 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.high_limit = TASK_SIZE;
info.align_mask = do_align ? (PAGE_MASK & (SHMLBA - 1)) : 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index eb1de66..1eb660c 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -101,6 +101,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.high_limit = TASK_SIZE;
info.align_mask = do_align ? (PAGE_MASK & (SHMLBA - 1)) : 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
@@ -152,6 +153,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
info.high_limit = mm->mmap_base;
info.align_mask = do_align ? (PAGE_MASK & (SHMLBA - 1)) : 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
/*
diff --git a/arch/frv/mm/elf-fdpic.c b/arch/frv/mm/elf-fdpic.c
index 46aa289..a2ce2ce 100644
--- a/arch/frv/mm/elf-fdpic.c
+++ b/arch/frv/mm/elf-fdpic.c
@@ -86,6 +86,7 @@ unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr, unsi
info.high_limit = (current->mm->start_stack - 0x00200000);
info.align_mask = 0;
info.align_offset = 0;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
if (!(addr & ~PAGE_MASK))
goto success;
diff --git a/arch/ia64/kernel/sys_ia64.c b/arch/ia64/kernel/sys_ia64.c
index 085adfc..15fa4fb 100644
--- a/arch/ia64/kernel/sys_ia64.c
+++ b/arch/ia64/kernel/sys_ia64.c
@@ -64,6 +64,7 @@ arch_get_unmapped_area (struct file *filp, unsigned long addr, unsigned long len
info.high_limit = TASK_SIZE;
info.align_mask = align_mask;
info.align_offset = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
diff --git a/arch/ia64/mm/hugetlbpage.c b/arch/ia64/mm/hugetlbpage.c
index d16e419..ec7822d 100644
--- a/arch/ia64/mm/hugetlbpage.c
+++ b/arch/ia64/mm/hugetlbpage.c
@@ -162,6 +162,7 @@ unsigned long hugetlb_get_unmapped_area(struct file *file, unsigned long addr, u
info.high_limit = HPAGE_REGION_BASE + RGN_MAP_LIMIT;
info.align_mask = PAGE_MASK & (HPAGE_SIZE - 1);
info.align_offset = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
diff --git a/arch/metag/mm/hugetlbpage.c b/arch/metag/mm/hugetlbpage.c
index 012ee4c..babd325 100644
--- a/arch/metag/mm/hugetlbpage.c
+++ b/arch/metag/mm/hugetlbpage.c
@@ -191,6 +191,7 @@ hugetlb_get_unmapped_area_new_pmd(unsigned long len)
info.high_limit = TASK_SIZE;
info.align_mask = PAGE_MASK & HUGEPT_MASK;
info.align_offset = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index 33d3251..5a3d384 100644
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -122,6 +122,7 @@ static unsigned long arch_get_unmapped_area_common(struct file *filp,
info.flags = 0;
info.low_limit = mm->mmap_base;
info.high_limit = TASK_SIZE;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
diff --git a/arch/parisc/kernel/sys_parisc.c b/arch/parisc/kernel/sys_parisc.c
index 378a754..abf4b05 100644
--- a/arch/parisc/kernel/sys_parisc.c
+++ b/arch/parisc/kernel/sys_parisc.c
@@ -130,6 +130,7 @@ unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.high_limit = mmap_upper_limit();
info.align_mask = last_mmap ? (PAGE_MASK & (SHM_COLOUR - 1)) : 0;
info.align_offset = shared_align_offset(last_mmap, pgoff);
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
found_addr:
@@ -192,6 +193,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
info.high_limit = mm->mmap_base;
info.align_mask = last_mmap ? (PAGE_MASK & (SHM_COLOUR - 1)) : 0;
info.align_offset = shared_align_offset(last_mmap, pgoff);
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
if (!(addr & ~PAGE_MASK))
goto found_addr;
diff --git a/arch/powerpc/mm/hugetlbpage-radix.c b/arch/powerpc/mm/hugetlbpage-radix.c
index 2486bee..1d61a88 100644
--- a/arch/powerpc/mm/hugetlbpage-radix.c
+++ b/arch/powerpc/mm/hugetlbpage-radix.c
@@ -87,6 +87,7 @@ radix__hugetlb_get_unmapped_area(struct file *file, unsigned long addr,
info.high_limit = mm->mmap_base + (high_limit - DEFAULT_MAP_WINDOW);
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
diff --git a/arch/powerpc/mm/mmap.c b/arch/powerpc/mm/mmap.c
index d503f34..7fe98c7 100644
--- a/arch/powerpc/mm/mmap.c
+++ b/arch/powerpc/mm/mmap.c
@@ -136,6 +136,7 @@ radix__arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.low_limit = mm->mmap_base;
info.high_limit = high_limit;
info.align_mask = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
@@ -180,6 +181,7 @@ radix__arch_get_unmapped_area_topdown(struct file *filp,
info.low_limit = max(PAGE_SIZE, mmap_min_addr);
info.high_limit = mm->mmap_base + (high_limit - DEFAULT_MAP_WINDOW);
info.align_mask = 0;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
if (!(addr & ~PAGE_MASK))
diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
index 23ec2c5..2005845 100644
--- a/arch/powerpc/mm/slice.c
+++ b/arch/powerpc/mm/slice.c
@@ -284,6 +284,7 @@ static unsigned long slice_find_area_bottomup(struct mm_struct *mm,
info.length = len;
info.align_mask = PAGE_MASK & ((1ul << pshift) - 1);
info.align_offset = 0;
+ info.random_shift = 0;
addr = TASK_UNMAPPED_BASE;
/*
@@ -330,6 +331,7 @@ static unsigned long slice_find_area_topdown(struct mm_struct *mm,
info.length = len;
info.align_mask = PAGE_MASK & ((1ul << pshift) - 1);
info.align_offset = 0;
+ info.random_shift = 0;
addr = mm->mmap_base;
/*
diff --git a/arch/s390/mm/mmap.c b/arch/s390/mm/mmap.c
index 831bdcf..141823f 100644
--- a/arch/s390/mm/mmap.c
+++ b/arch/s390/mm/mmap.c
@@ -95,6 +95,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.length = len;
info.low_limit = mm->mmap_base;
info.high_limit = TASK_SIZE;
+ info.random_shift = 0;
if (filp || (flags & MAP_SHARED))
info.align_mask = MMAP_ALIGN_MASK << PAGE_SHIFT;
else
@@ -146,6 +147,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
info.length = len;
info.low_limit = max(PAGE_SIZE, mmap_min_addr);
info.high_limit = mm->mmap_base;
+ info.random_shift = 0;
if (filp || (flags & MAP_SHARED))
info.align_mask = MMAP_ALIGN_MASK << PAGE_SHIFT;
else
diff --git a/arch/sh/mm/mmap.c b/arch/sh/mm/mmap.c
index 6a1a129..d9206c2 100644
--- a/arch/sh/mm/mmap.c
+++ b/arch/sh/mm/mmap.c
@@ -74,6 +74,7 @@ unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.high_limit = TASK_SIZE;
info.align_mask = do_colour_align ? (PAGE_MASK & shm_align_mask) : 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
@@ -124,6 +125,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
info.high_limit = mm->mmap_base;
info.align_mask = do_colour_align ? (PAGE_MASK & shm_align_mask) : 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
/*
diff --git a/arch/sparc/kernel/sys_sparc_32.c b/arch/sparc/kernel/sys_sparc_32.c
index 990703b7..af664ba3 100644
--- a/arch/sparc/kernel/sys_sparc_32.c
+++ b/arch/sparc/kernel/sys_sparc_32.c
@@ -66,6 +66,7 @@ unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr, unsi
info.align_mask = (flags & MAP_SHARED) ?
(PAGE_MASK & (SHMLBA - 1)) : 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
diff --git a/arch/sparc/kernel/sys_sparc_64.c b/arch/sparc/kernel/sys_sparc_64.c
index 55416db..3d12e3d 100644
--- a/arch/sparc/kernel/sys_sparc_64.c
+++ b/arch/sparc/kernel/sys_sparc_64.c
@@ -131,6 +131,7 @@ unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr, unsi
info.high_limit = min(task_size, VA_EXCLUDE_START);
info.align_mask = do_color_align ? (PAGE_MASK & (SHMLBA - 1)) : 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
if ((addr & ~PAGE_MASK) && task_size > VA_EXCLUDE_END) {
@@ -194,6 +195,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
info.high_limit = mm->mmap_base;
info.align_mask = do_color_align ? (PAGE_MASK & (SHMLBA - 1)) : 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
/*
diff --git a/arch/sparc/mm/hugetlbpage.c b/arch/sparc/mm/hugetlbpage.c
index 0112d69..6d0c032 100644
--- a/arch/sparc/mm/hugetlbpage.c
+++ b/arch/sparc/mm/hugetlbpage.c
@@ -43,6 +43,7 @@ static unsigned long hugetlb_get_unmapped_area_bottomup(struct file *filp,
info.high_limit = min(task_size, VA_EXCLUDE_START);
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
if ((addr & ~PAGE_MASK) && task_size > VA_EXCLUDE_END) {
@@ -75,6 +76,7 @@ hugetlb_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
info.high_limit = mm->mmap_base;
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
/*
diff --git a/arch/tile/mm/hugetlbpage.c b/arch/tile/mm/hugetlbpage.c
index 0986d42..2b3a9b6 100644
--- a/arch/tile/mm/hugetlbpage.c
+++ b/arch/tile/mm/hugetlbpage.c
@@ -176,6 +176,7 @@ static unsigned long hugetlb_get_unmapped_area_bottomup(struct file *file,
info.high_limit = TASK_SIZE;
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
@@ -193,6 +194,7 @@ static unsigned long hugetlb_get_unmapped_area_topdown(struct file *file,
info.high_limit = current->mm->mmap_base;
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
/*
diff --git a/arch/x86/kernel/sys_x86_64.c b/arch/x86/kernel/sys_x86_64.c
index 676774b..0eda047 100644
--- a/arch/x86/kernel/sys_x86_64.c
+++ b/arch/x86/kernel/sys_x86_64.c
@@ -163,6 +163,8 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.high_limit = end;
info.align_mask = 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = in_compat_syscall() ?
+ 256 : 0x1000000;
if (filp) {
info.align_mask = get_align_mask();
info.align_offset += get_align_bits();
@@ -224,6 +226,8 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
info.align_mask = 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = in_compat_syscall() ?
+ 256 : 0x1000000;
if (filp) {
info.align_mask = get_align_mask();
info.align_offset += get_align_bits();
diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
index 00b2966..f4f6436 100644
--- a/arch/x86/mm/hugetlbpage.c
+++ b/arch/x86/mm/hugetlbpage.c
@@ -97,6 +97,8 @@ static unsigned long hugetlb_get_unmapped_area_bottomup(struct file *file,
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
+ info.random_shift = in_compat_syscall() ?
+ 256 : 0x1000000;
return vm_unmapped_area(&info);
}
@@ -121,6 +123,8 @@ static unsigned long hugetlb_get_unmapped_area_topdown(struct file *file,
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
+ info.random_shift = in_compat_syscall() ?
+ 256 : 0x1000000;
addr = vm_unmapped_area(&info);
/*
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 8fe1b0a..83e962e 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -200,6 +200,7 @@ hugetlb_get_unmapped_area(struct file *file, unsigned long addr,
info.high_limit = TASK_SIZE;
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
#endif
diff --git a/include/linux/mm.h b/include/linux/mm.h
index c716257..f869e6d 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2252,6 +2252,7 @@ struct vm_unmapped_area_info {
unsigned long high_limit;
unsigned long align_mask;
unsigned long align_offset;
+ unsigned long random_shift;
};
#ifndef CONFIG_MMU
diff --git a/mm/mmap.c b/mm/mmap.c
index ba9cebb..425fa09 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1938,7 +1938,7 @@ unsigned long unmapped_area_random(struct vm_unmapped_area_info *info)
if (gap_end == gap_start)
return gap_start;
addr = entropy[1] % (min((gap_end - gap_start) >> PAGE_SHIFT,
- 0x10000UL));
+ info->random_shift));
addr = gap_end - (addr << PAGE_SHIFT);
addr += (info->align_offset - addr) & info->align_mask;
return addr;
@@ -2186,6 +2186,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.low_limit = mm->mmap_base;
info.high_limit = TASK_SIZE;
info.align_mask = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
#endif
--
2.7.4
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [RFC PATCH v2 2/2] Architecture defined limit on memory region random shift.
@ 2018-03-22 16:36 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-22 16:36 UTC (permalink / raw)
To: linux-snps-arc
Signed-off-by: Ilya Smith <blackzert at gmail.com>
---
arch/alpha/kernel/osf_sys.c | 1 +
arch/arc/mm/mmap.c | 1 +
arch/arm/mm/mmap.c | 2 ++
arch/frv/mm/elf-fdpic.c | 1 +
arch/ia64/kernel/sys_ia64.c | 1 +
arch/ia64/mm/hugetlbpage.c | 1 +
arch/metag/mm/hugetlbpage.c | 1 +
arch/mips/mm/mmap.c | 1 +
arch/parisc/kernel/sys_parisc.c | 2 ++
arch/powerpc/mm/hugetlbpage-radix.c | 1 +
arch/powerpc/mm/mmap.c | 2 ++
arch/powerpc/mm/slice.c | 2 ++
arch/s390/mm/mmap.c | 2 ++
arch/sh/mm/mmap.c | 2 ++
arch/sparc/kernel/sys_sparc_32.c | 1 +
arch/sparc/kernel/sys_sparc_64.c | 2 ++
arch/sparc/mm/hugetlbpage.c | 2 ++
arch/tile/mm/hugetlbpage.c | 2 ++
arch/x86/kernel/sys_x86_64.c | 4 ++++
arch/x86/mm/hugetlbpage.c | 4 ++++
fs/hugetlbfs/inode.c | 1 +
include/linux/mm.h | 1 +
mm/mmap.c | 3 ++-
23 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
index fa1a392..0ab9f31 100644
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -1301,6 +1301,7 @@ arch_get_unmapped_area_1(unsigned long addr, unsigned long len,
info.high_limit = limit;
info.align_mask = 0;
info.align_offset = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
diff --git a/arch/arc/mm/mmap.c b/arch/arc/mm/mmap.c
index 2e13683..45225fc 100644
--- a/arch/arc/mm/mmap.c
+++ b/arch/arc/mm/mmap.c
@@ -75,5 +75,6 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.high_limit = TASK_SIZE;
info.align_mask = do_align ? (PAGE_MASK & (SHMLBA - 1)) : 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
index eb1de66..1eb660c 100644
--- a/arch/arm/mm/mmap.c
+++ b/arch/arm/mm/mmap.c
@@ -101,6 +101,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.high_limit = TASK_SIZE;
info.align_mask = do_align ? (PAGE_MASK & (SHMLBA - 1)) : 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
@@ -152,6 +153,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
info.high_limit = mm->mmap_base;
info.align_mask = do_align ? (PAGE_MASK & (SHMLBA - 1)) : 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
/*
diff --git a/arch/frv/mm/elf-fdpic.c b/arch/frv/mm/elf-fdpic.c
index 46aa289..a2ce2ce 100644
--- a/arch/frv/mm/elf-fdpic.c
+++ b/arch/frv/mm/elf-fdpic.c
@@ -86,6 +86,7 @@ unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr, unsi
info.high_limit = (current->mm->start_stack - 0x00200000);
info.align_mask = 0;
info.align_offset = 0;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
if (!(addr & ~PAGE_MASK))
goto success;
diff --git a/arch/ia64/kernel/sys_ia64.c b/arch/ia64/kernel/sys_ia64.c
index 085adfc..15fa4fb 100644
--- a/arch/ia64/kernel/sys_ia64.c
+++ b/arch/ia64/kernel/sys_ia64.c
@@ -64,6 +64,7 @@ arch_get_unmapped_area (struct file *filp, unsigned long addr, unsigned long len
info.high_limit = TASK_SIZE;
info.align_mask = align_mask;
info.align_offset = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
diff --git a/arch/ia64/mm/hugetlbpage.c b/arch/ia64/mm/hugetlbpage.c
index d16e419..ec7822d 100644
--- a/arch/ia64/mm/hugetlbpage.c
+++ b/arch/ia64/mm/hugetlbpage.c
@@ -162,6 +162,7 @@ unsigned long hugetlb_get_unmapped_area(struct file *file, unsigned long addr, u
info.high_limit = HPAGE_REGION_BASE + RGN_MAP_LIMIT;
info.align_mask = PAGE_MASK & (HPAGE_SIZE - 1);
info.align_offset = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
diff --git a/arch/metag/mm/hugetlbpage.c b/arch/metag/mm/hugetlbpage.c
index 012ee4c..babd325 100644
--- a/arch/metag/mm/hugetlbpage.c
+++ b/arch/metag/mm/hugetlbpage.c
@@ -191,6 +191,7 @@ hugetlb_get_unmapped_area_new_pmd(unsigned long len)
info.high_limit = TASK_SIZE;
info.align_mask = PAGE_MASK & HUGEPT_MASK;
info.align_offset = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index 33d3251..5a3d384 100644
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -122,6 +122,7 @@ static unsigned long arch_get_unmapped_area_common(struct file *filp,
info.flags = 0;
info.low_limit = mm->mmap_base;
info.high_limit = TASK_SIZE;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
diff --git a/arch/parisc/kernel/sys_parisc.c b/arch/parisc/kernel/sys_parisc.c
index 378a754..abf4b05 100644
--- a/arch/parisc/kernel/sys_parisc.c
+++ b/arch/parisc/kernel/sys_parisc.c
@@ -130,6 +130,7 @@ unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.high_limit = mmap_upper_limit();
info.align_mask = last_mmap ? (PAGE_MASK & (SHM_COLOUR - 1)) : 0;
info.align_offset = shared_align_offset(last_mmap, pgoff);
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
found_addr:
@@ -192,6 +193,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
info.high_limit = mm->mmap_base;
info.align_mask = last_mmap ? (PAGE_MASK & (SHM_COLOUR - 1)) : 0;
info.align_offset = shared_align_offset(last_mmap, pgoff);
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
if (!(addr & ~PAGE_MASK))
goto found_addr;
diff --git a/arch/powerpc/mm/hugetlbpage-radix.c b/arch/powerpc/mm/hugetlbpage-radix.c
index 2486bee..1d61a88 100644
--- a/arch/powerpc/mm/hugetlbpage-radix.c
+++ b/arch/powerpc/mm/hugetlbpage-radix.c
@@ -87,6 +87,7 @@ radix__hugetlb_get_unmapped_area(struct file *file, unsigned long addr,
info.high_limit = mm->mmap_base + (high_limit - DEFAULT_MAP_WINDOW);
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
diff --git a/arch/powerpc/mm/mmap.c b/arch/powerpc/mm/mmap.c
index d503f34..7fe98c7 100644
--- a/arch/powerpc/mm/mmap.c
+++ b/arch/powerpc/mm/mmap.c
@@ -136,6 +136,7 @@ radix__arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.low_limit = mm->mmap_base;
info.high_limit = high_limit;
info.align_mask = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
@@ -180,6 +181,7 @@ radix__arch_get_unmapped_area_topdown(struct file *filp,
info.low_limit = max(PAGE_SIZE, mmap_min_addr);
info.high_limit = mm->mmap_base + (high_limit - DEFAULT_MAP_WINDOW);
info.align_mask = 0;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
if (!(addr & ~PAGE_MASK))
diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
index 23ec2c5..2005845 100644
--- a/arch/powerpc/mm/slice.c
+++ b/arch/powerpc/mm/slice.c
@@ -284,6 +284,7 @@ static unsigned long slice_find_area_bottomup(struct mm_struct *mm,
info.length = len;
info.align_mask = PAGE_MASK & ((1ul << pshift) - 1);
info.align_offset = 0;
+ info.random_shift = 0;
addr = TASK_UNMAPPED_BASE;
/*
@@ -330,6 +331,7 @@ static unsigned long slice_find_area_topdown(struct mm_struct *mm,
info.length = len;
info.align_mask = PAGE_MASK & ((1ul << pshift) - 1);
info.align_offset = 0;
+ info.random_shift = 0;
addr = mm->mmap_base;
/*
diff --git a/arch/s390/mm/mmap.c b/arch/s390/mm/mmap.c
index 831bdcf..141823f 100644
--- a/arch/s390/mm/mmap.c
+++ b/arch/s390/mm/mmap.c
@@ -95,6 +95,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.length = len;
info.low_limit = mm->mmap_base;
info.high_limit = TASK_SIZE;
+ info.random_shift = 0;
if (filp || (flags & MAP_SHARED))
info.align_mask = MMAP_ALIGN_MASK << PAGE_SHIFT;
else
@@ -146,6 +147,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
info.length = len;
info.low_limit = max(PAGE_SIZE, mmap_min_addr);
info.high_limit = mm->mmap_base;
+ info.random_shift = 0;
if (filp || (flags & MAP_SHARED))
info.align_mask = MMAP_ALIGN_MASK << PAGE_SHIFT;
else
diff --git a/arch/sh/mm/mmap.c b/arch/sh/mm/mmap.c
index 6a1a129..d9206c2 100644
--- a/arch/sh/mm/mmap.c
+++ b/arch/sh/mm/mmap.c
@@ -74,6 +74,7 @@ unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.high_limit = TASK_SIZE;
info.align_mask = do_colour_align ? (PAGE_MASK & shm_align_mask) : 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
@@ -124,6 +125,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
info.high_limit = mm->mmap_base;
info.align_mask = do_colour_align ? (PAGE_MASK & shm_align_mask) : 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
/*
diff --git a/arch/sparc/kernel/sys_sparc_32.c b/arch/sparc/kernel/sys_sparc_32.c
index 990703b7..af664ba3 100644
--- a/arch/sparc/kernel/sys_sparc_32.c
+++ b/arch/sparc/kernel/sys_sparc_32.c
@@ -66,6 +66,7 @@ unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr, unsi
info.align_mask = (flags & MAP_SHARED) ?
(PAGE_MASK & (SHMLBA - 1)) : 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
diff --git a/arch/sparc/kernel/sys_sparc_64.c b/arch/sparc/kernel/sys_sparc_64.c
index 55416db..3d12e3d 100644
--- a/arch/sparc/kernel/sys_sparc_64.c
+++ b/arch/sparc/kernel/sys_sparc_64.c
@@ -131,6 +131,7 @@ unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr, unsi
info.high_limit = min(task_size, VA_EXCLUDE_START);
info.align_mask = do_color_align ? (PAGE_MASK & (SHMLBA - 1)) : 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
if ((addr & ~PAGE_MASK) && task_size > VA_EXCLUDE_END) {
@@ -194,6 +195,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
info.high_limit = mm->mmap_base;
info.align_mask = do_color_align ? (PAGE_MASK & (SHMLBA - 1)) : 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
/*
diff --git a/arch/sparc/mm/hugetlbpage.c b/arch/sparc/mm/hugetlbpage.c
index 0112d69..6d0c032 100644
--- a/arch/sparc/mm/hugetlbpage.c
+++ b/arch/sparc/mm/hugetlbpage.c
@@ -43,6 +43,7 @@ static unsigned long hugetlb_get_unmapped_area_bottomup(struct file *filp,
info.high_limit = min(task_size, VA_EXCLUDE_START);
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
if ((addr & ~PAGE_MASK) && task_size > VA_EXCLUDE_END) {
@@ -75,6 +76,7 @@ hugetlb_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
info.high_limit = mm->mmap_base;
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
/*
diff --git a/arch/tile/mm/hugetlbpage.c b/arch/tile/mm/hugetlbpage.c
index 0986d42..2b3a9b6 100644
--- a/arch/tile/mm/hugetlbpage.c
+++ b/arch/tile/mm/hugetlbpage.c
@@ -176,6 +176,7 @@ static unsigned long hugetlb_get_unmapped_area_bottomup(struct file *file,
info.high_limit = TASK_SIZE;
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
@@ -193,6 +194,7 @@ static unsigned long hugetlb_get_unmapped_area_topdown(struct file *file,
info.high_limit = current->mm->mmap_base;
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
+ info.random_shift = 0;
addr = vm_unmapped_area(&info);
/*
diff --git a/arch/x86/kernel/sys_x86_64.c b/arch/x86/kernel/sys_x86_64.c
index 676774b..0eda047 100644
--- a/arch/x86/kernel/sys_x86_64.c
+++ b/arch/x86/kernel/sys_x86_64.c
@@ -163,6 +163,8 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.high_limit = end;
info.align_mask = 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = in_compat_syscall() ?
+ 256 : 0x1000000;
if (filp) {
info.align_mask = get_align_mask();
info.align_offset += get_align_bits();
@@ -224,6 +226,8 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
info.align_mask = 0;
info.align_offset = pgoff << PAGE_SHIFT;
+ info.random_shift = in_compat_syscall() ?
+ 256 : 0x1000000;
if (filp) {
info.align_mask = get_align_mask();
info.align_offset += get_align_bits();
diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
index 00b2966..f4f6436 100644
--- a/arch/x86/mm/hugetlbpage.c
+++ b/arch/x86/mm/hugetlbpage.c
@@ -97,6 +97,8 @@ static unsigned long hugetlb_get_unmapped_area_bottomup(struct file *file,
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
+ info.random_shift = in_compat_syscall() ?
+ 256 : 0x1000000;
return vm_unmapped_area(&info);
}
@@ -121,6 +123,8 @@ static unsigned long hugetlb_get_unmapped_area_topdown(struct file *file,
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
+ info.random_shift = in_compat_syscall() ?
+ 256 : 0x1000000;
addr = vm_unmapped_area(&info);
/*
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 8fe1b0a..83e962e 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -200,6 +200,7 @@ hugetlb_get_unmapped_area(struct file *file, unsigned long addr,
info.high_limit = TASK_SIZE;
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
#endif
diff --git a/include/linux/mm.h b/include/linux/mm.h
index c716257..f869e6d 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2252,6 +2252,7 @@ struct vm_unmapped_area_info {
unsigned long high_limit;
unsigned long align_mask;
unsigned long align_offset;
+ unsigned long random_shift;
};
#ifndef CONFIG_MMU
diff --git a/mm/mmap.c b/mm/mmap.c
index ba9cebb..425fa09 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1938,7 +1938,7 @@ unsigned long unmapped_area_random(struct vm_unmapped_area_info *info)
if (gap_end == gap_start)
return gap_start;
addr = entropy[1] % (min((gap_end - gap_start) >> PAGE_SHIFT,
- 0x10000UL));
+ info->random_shift));
addr = gap_end - (addr << PAGE_SHIFT);
addr += (info->align_offset - addr) & info->align_mask;
return addr;
@@ -2186,6 +2186,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
info.low_limit = mm->mmap_base;
info.high_limit = TASK_SIZE;
info.align_mask = 0;
+ info.random_shift = 0;
return vm_unmapped_area(&info);
}
#endif
--
2.7.4
^ permalink raw reply related [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 1/2] Randomization of address chosen by mmap.
2018-03-22 16:36 ` Ilya Smith
(?)
(?)
@ 2018-03-22 20:53 ` Andrew Morton
-1 siblings, 0 replies; 185+ messages in thread
From: Andrew Morton @ 2018-03-22 20:53 UTC (permalink / raw)
To: Ilya Smith
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
On Thu, 22 Mar 2018 19:36:37 +0300 Ilya Smith <blackzert@gmail.com> wrote:
> include/linux/mm.h | 16 ++++--
> mm/mmap.c | 164 +++++++++++++++++++++++++++++++++++++++++++++++++++++
You'll be wanting to update the documentation.
Documentation/sysctl/kernel.txt and
Documentation/admin-guide/kernel-parameters.txt.
> ...
>
> @@ -2268,6 +2276,9 @@ extern unsigned long unmapped_area_topdown(struct vm_unmapped_area_info *info);
> static inline unsigned long
> vm_unmapped_area(struct vm_unmapped_area_info *info)
> {
> + /* How about 32 bit process?? */
> + if ((current->flags & PF_RANDOMIZE) && randomize_va_space > 3)
> + return unmapped_area_random(info);
The handling of randomize_va_space is peculiar. Rather than being a
bitfield which independently selects different modes, it is treated as
a scalar: the larger the value, the more stuff we randomize.
I can see the sense in that (and I wonder what randomize_va_space=5
will do). But it is... odd.
Why did you select randomize_va_space=4 for this? Is there a mode 3
already and we forgot to document it? Or did you leave a gap for
something? If the former, please feel free to fix the documentation
(in a separate, preceding patch) while you're in there ;)
> if (info->flags & VM_UNMAPPED_AREA_TOPDOWN)
> return unmapped_area_topdown(info);
> else
> @@ -2529,11 +2540,6 @@ int drop_caches_sysctl_handler(struct ctl_table *, int,
> void drop_slab(void);
> void drop_slab_node(int nid);
>
>
> ...
>
> @@ -1780,6 +1781,169 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
> return error;
> }
>
> +unsigned long unmapped_area_random(struct vm_unmapped_area_info *info)
> +{
This function is just dead code if CONFIG_MMU=n, yes? Let's add the
ifdefs to make it go away in that case.
> + struct mm_struct *mm = current->mm;
> + struct vm_area_struct *vma = NULL;
> + struct vm_area_struct *visited_vma = NULL;
> + unsigned long entropy[2];
> + unsigned long length, low_limit, high_limit, gap_start, gap_end;
> + unsigned long addr = 0;
> +
> + /* get entropy with prng */
> + prandom_bytes(&entropy, sizeof(entropy));
> + /* small hack to prevent EPERM result */
> + info->low_limit = max(info->low_limit, mmap_min_addr);
> +
>
> ...
>
> +found:
> + /* We found a suitable gap. Clip it with the original high_limit. */
> + if (gap_end > info->high_limit)
> + gap_end = info->high_limit;
> + gap_end -= info->length;
> + gap_end -= (gap_end - info->align_offset) & info->align_mask;
> + /* only one suitable page */
> + if (gap_end = gap_start)
> + return gap_start;
> + addr = entropy[1] % (min((gap_end - gap_start) >> PAGE_SHIFT,
> + 0x10000UL));
What does the magic 10000 mean? Isn't a comment needed explaining this?
> + addr = gap_end - (addr << PAGE_SHIFT);
> + addr += (info->align_offset - addr) & info->align_mask;
> + return addr;
> +}
>
> ...
>
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 1/2] Randomization of address chosen by mmap.
@ 2018-03-22 20:53 ` Andrew Morton
0 siblings, 0 replies; 185+ messages in thread
From: Andrew Morton @ 2018-03-22 20:53 UTC (permalink / raw)
To: Ilya Smith
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin
On Thu, 22 Mar 2018 19:36:37 +0300 Ilya Smith <blackzert@gmail.com> wrote:
> include/linux/mm.h | 16 ++++--
> mm/mmap.c | 164 +++++++++++++++++++++++++++++++++++++++++++++++++++++
You'll be wanting to update the documentation.
Documentation/sysctl/kernel.txt and
Documentation/admin-guide/kernel-parameters.txt.
> ...
>
> @@ -2268,6 +2276,9 @@ extern unsigned long unmapped_area_topdown(struct vm_unmapped_area_info *info);
> static inline unsigned long
> vm_unmapped_area(struct vm_unmapped_area_info *info)
> {
> + /* How about 32 bit process?? */
> + if ((current->flags & PF_RANDOMIZE) && randomize_va_space > 3)
> + return unmapped_area_random(info);
The handling of randomize_va_space is peculiar. Rather than being a
bitfield which independently selects different modes, it is treated as
a scalar: the larger the value, the more stuff we randomize.
I can see the sense in that (and I wonder what randomize_va_space=5
will do). But it is... odd.
Why did you select randomize_va_space=4 for this? Is there a mode 3
already and we forgot to document it? Or did you leave a gap for
something? If the former, please feel free to fix the documentation
(in a separate, preceding patch) while you're in there ;)
> if (info->flags & VM_UNMAPPED_AREA_TOPDOWN)
> return unmapped_area_topdown(info);
> else
> @@ -2529,11 +2540,6 @@ int drop_caches_sysctl_handler(struct ctl_table *, int,
> void drop_slab(void);
> void drop_slab_node(int nid);
>
>
> ...
>
> @@ -1780,6 +1781,169 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
> return error;
> }
>
> +unsigned long unmapped_area_random(struct vm_unmapped_area_info *info)
> +{
This function is just dead code if CONFIG_MMU=n, yes? Let's add the
ifdefs to make it go away in that case.
> + struct mm_struct *mm = current->mm;
> + struct vm_area_struct *vma = NULL;
> + struct vm_area_struct *visited_vma = NULL;
> + unsigned long entropy[2];
> + unsigned long length, low_limit, high_limit, gap_start, gap_end;
> + unsigned long addr = 0;
> +
> + /* get entropy with prng */
> + prandom_bytes(&entropy, sizeof(entropy));
> + /* small hack to prevent EPERM result */
> + info->low_limit = max(info->low_limit, mmap_min_addr);
> +
>
> ...
>
> +found:
> + /* We found a suitable gap. Clip it with the original high_limit. */
> + if (gap_end > info->high_limit)
> + gap_end = info->high_limit;
> + gap_end -= info->length;
> + gap_end -= (gap_end - info->align_offset) & info->align_mask;
> + /* only one suitable page */
> + if (gap_end == gap_start)
> + return gap_start;
> + addr = entropy[1] % (min((gap_end - gap_start) >> PAGE_SHIFT,
> + 0x10000UL));
What does the magic 10000 mean? Isn't a comment needed explaining this?
> + addr = gap_end - (addr << PAGE_SHIFT);
> + addr += (info->align_offset - addr) & info->align_mask;
> + return addr;
> +}
>
> ...
>
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 1/2] Randomization of address chosen by mmap.
@ 2018-03-22 20:53 ` Andrew Morton
0 siblings, 0 replies; 185+ messages in thread
From: Andrew Morton @ 2018-03-22 20:53 UTC (permalink / raw)
To: Ilya Smith
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
On Thu, 22 Mar 2018 19:36:37 +0300 Ilya Smith <blackzert@gmail.com> wrote:
> include/linux/mm.h | 16 ++++--
> mm/mmap.c | 164 +++++++++++++++++++++++++++++++++++++++++++++++++++++
You'll be wanting to update the documentation.
Documentation/sysctl/kernel.txt and
Documentation/admin-guide/kernel-parameters.txt.
> ...
>
> @@ -2268,6 +2276,9 @@ extern unsigned long unmapped_area_topdown(struct vm_unmapped_area_info *info);
> static inline unsigned long
> vm_unmapped_area(struct vm_unmapped_area_info *info)
> {
> + /* How about 32 bit process?? */
> + if ((current->flags & PF_RANDOMIZE) && randomize_va_space > 3)
> + return unmapped_area_random(info);
The handling of randomize_va_space is peculiar. Rather than being a
bitfield which independently selects different modes, it is treated as
a scalar: the larger the value, the more stuff we randomize.
I can see the sense in that (and I wonder what randomize_va_space=5
will do). But it is... odd.
Why did you select randomize_va_space=4 for this? Is there a mode 3
already and we forgot to document it? Or did you leave a gap for
something? If the former, please feel free to fix the documentation
(in a separate, preceding patch) while you're in there ;)
> if (info->flags & VM_UNMAPPED_AREA_TOPDOWN)
> return unmapped_area_topdown(info);
> else
> @@ -2529,11 +2540,6 @@ int drop_caches_sysctl_handler(struct ctl_table *, int,
> void drop_slab(void);
> void drop_slab_node(int nid);
>
>
> ...
>
> @@ -1780,6 +1781,169 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
> return error;
> }
>
> +unsigned long unmapped_area_random(struct vm_unmapped_area_info *info)
> +{
This function is just dead code if CONFIG_MMU=n, yes? Let's add the
ifdefs to make it go away in that case.
> + struct mm_struct *mm = current->mm;
> + struct vm_area_struct *vma = NULL;
> + struct vm_area_struct *visited_vma = NULL;
> + unsigned long entropy[2];
> + unsigned long length, low_limit, high_limit, gap_start, gap_end;
> + unsigned long addr = 0;
> +
> + /* get entropy with prng */
> + prandom_bytes(&entropy, sizeof(entropy));
> + /* small hack to prevent EPERM result */
> + info->low_limit = max(info->low_limit, mmap_min_addr);
> +
>
> ...
>
> +found:
> + /* We found a suitable gap. Clip it with the original high_limit. */
> + if (gap_end > info->high_limit)
> + gap_end = info->high_limit;
> + gap_end -= info->length;
> + gap_end -= (gap_end - info->align_offset) & info->align_mask;
> + /* only one suitable page */
> + if (gap_end == gap_start)
> + return gap_start;
> + addr = entropy[1] % (min((gap_end - gap_start) >> PAGE_SHIFT,
> + 0x10000UL));
What does the magic 10000 mean? Isn't a comment needed explaining this?
> + addr = gap_end - (addr << PAGE_SHIFT);
> + addr += (info->align_offset - addr) & info->align_mask;
> + return addr;
> +}
>
> ...
>
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 1/2] Randomization of address chosen by mmap.
@ 2018-03-22 20:53 ` Andrew Morton
0 siblings, 0 replies; 185+ messages in thread
From: Andrew Morton @ 2018-03-22 20:53 UTC (permalink / raw)
To: linux-snps-arc
On Thu, 22 Mar 2018 19:36:37 +0300 Ilya Smith <blackzert@gmail.com> wrote:
> include/linux/mm.h | 16 ++++--
> mm/mmap.c | 164 +++++++++++++++++++++++++++++++++++++++++++++++++++++
You'll be wanting to update the documentation.
Documentation/sysctl/kernel.txt and
Documentation/admin-guide/kernel-parameters.txt.
> ...
>
> @@ -2268,6 +2276,9 @@ extern unsigned long unmapped_area_topdown(struct vm_unmapped_area_info *info);
> static inline unsigned long
> vm_unmapped_area(struct vm_unmapped_area_info *info)
> {
> + /* How about 32 bit process?? */
> + if ((current->flags & PF_RANDOMIZE) && randomize_va_space > 3)
> + return unmapped_area_random(info);
The handling of randomize_va_space is peculiar. Rather than being a
bitfield which independently selects different modes, it is treated as
a scalar: the larger the value, the more stuff we randomize.
I can see the sense in that (and I wonder what randomize_va_space=5
will do). But it is... odd.
Why did you select randomize_va_space=4 for this? Is there a mode 3
already and we forgot to document it? Or did you leave a gap for
something? If the former, please feel free to fix the documentation
(in a separate, preceding patch) while you're in there ;)
> if (info->flags & VM_UNMAPPED_AREA_TOPDOWN)
> return unmapped_area_topdown(info);
> else
> @@ -2529,11 +2540,6 @@ int drop_caches_sysctl_handler(struct ctl_table *, int,
> void drop_slab(void);
> void drop_slab_node(int nid);
>
>
> ...
>
> @@ -1780,6 +1781,169 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
> return error;
> }
>
> +unsigned long unmapped_area_random(struct vm_unmapped_area_info *info)
> +{
This function is just dead code if CONFIG_MMU=n, yes? Let's add the
ifdefs to make it go away in that case.
> + struct mm_struct *mm = current->mm;
> + struct vm_area_struct *vma = NULL;
> + struct vm_area_struct *visited_vma = NULL;
> + unsigned long entropy[2];
> + unsigned long length, low_limit, high_limit, gap_start, gap_end;
> + unsigned long addr = 0;
> +
> + /* get entropy with prng */
> + prandom_bytes(&entropy, sizeof(entropy));
> + /* small hack to prevent EPERM result */
> + info->low_limit = max(info->low_limit, mmap_min_addr);
> +
>
> ...
>
> +found:
> + /* We found a suitable gap. Clip it with the original high_limit. */
> + if (gap_end > info->high_limit)
> + gap_end = info->high_limit;
> + gap_end -= info->length;
> + gap_end -= (gap_end - info->align_offset) & info->align_mask;
> + /* only one suitable page */
> + if (gap_end == gap_start)
> + return gap_start;
> + addr = entropy[1] % (min((gap_end - gap_start) >> PAGE_SHIFT,
> + 0x10000UL));
What does the magic 10000 mean? Isn't a comment needed explaining this?
> + addr = gap_end - (addr << PAGE_SHIFT);
> + addr += (info->align_offset - addr) & info->align_mask;
> + return addr;
> +}
>
> ...
>
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 2/2] Architecture defined limit on memory region random shift.
2018-03-22 16:36 ` Ilya Smith
(?)
(?)
@ 2018-03-22 20:54 ` Andrew Morton
-1 siblings, 0 replies; 185+ messages in thread
From: Andrew Morton @ 2018-03-22 20:54 UTC (permalink / raw)
To: Ilya Smith
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
Please add changelogs. An explanation of what a "limit on memory
region random shift" is would be nice ;) Why does it exist, why are we
doing this, etc. Surely there's something to be said - at present this
is just a lump of random code?
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 2/2] Architecture defined limit on memory region random shift.
@ 2018-03-22 20:54 ` Andrew Morton
0 siblings, 0 replies; 185+ messages in thread
From: Andrew Morton @ 2018-03-22 20:54 UTC (permalink / raw)
To: Ilya Smith
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin
Please add changelogs. An explanation of what a "limit on memory
region random shift" is would be nice ;) Why does it exist, why are we
doing this, etc. Surely there's something to be said - at present this
is just a lump of random code?
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 2/2] Architecture defined limit on memory region random shift.
@ 2018-03-22 20:54 ` Andrew Morton
0 siblings, 0 replies; 185+ messages in thread
From: Andrew Morton @ 2018-03-22 20:54 UTC (permalink / raw)
To: Ilya Smith
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
Please add changelogs. An explanation of what a "limit on memory
region random shift" is would be nice ;) Why does it exist, why are we
doing this, etc. Surely there's something to be said - at present this
is just a lump of random code?
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 2/2] Architecture defined limit on memory region random shift.
@ 2018-03-22 20:54 ` Andrew Morton
0 siblings, 0 replies; 185+ messages in thread
From: Andrew Morton @ 2018-03-22 20:54 UTC (permalink / raw)
To: linux-snps-arc
Please add changelogs. An explanation of what a "limit on memory
region random shift" is would be nice ;) Why does it exist, why are we
doing this, etc. Surely there's something to be said - at present this
is just a lump of random code?
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-22 16:36 ` Ilya Smith
(?)
(?)
@ 2018-03-22 20:57 ` Andrew Morton
-1 siblings, 0 replies; 185+ messages in thread
From: Andrew Morton @ 2018-03-22 20:57 UTC (permalink / raw)
To: Ilya Smith
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
On Thu, 22 Mar 2018 19:36:36 +0300 Ilya Smith <blackzert@gmail.com> wrote:
> Current implementation doesn't randomize address returned by mmap.
> All the entropy ends with choosing mmap_base_addr at the process
> creation. After that mmap build very predictable layout of address
> space. It allows to bypass ASLR in many cases.
Perhaps some more effort on the problem description would help. *Are*
people predicting layouts at present? What problems does this cause?
How are they doing this and are there other approaches to solving the
problem?
Mainly: what value does this patchset have to our users? This reader
is unable to determine that from the information which you have
provided. Full details, please.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-22 20:57 ` Andrew Morton
0 siblings, 0 replies; 185+ messages in thread
From: Andrew Morton @ 2018-03-22 20:57 UTC (permalink / raw)
To: Ilya Smith
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin
On Thu, 22 Mar 2018 19:36:36 +0300 Ilya Smith <blackzert@gmail.com> wrote:
> Current implementation doesn't randomize address returned by mmap.
> All the entropy ends with choosing mmap_base_addr at the process
> creation. After that mmap build very predictable layout of address
> space. It allows to bypass ASLR in many cases.
Perhaps some more effort on the problem description would help. *Are*
people predicting layouts at present? What problems does this cause?
How are they doing this and are there other approaches to solving the
problem?
Mainly: what value does this patchset have to our users? This reader
is unable to determine that from the information which you have
provided. Full details, please.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-22 20:57 ` Andrew Morton
0 siblings, 0 replies; 185+ messages in thread
From: Andrew Morton @ 2018-03-22 20:57 UTC (permalink / raw)
To: Ilya Smith
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
On Thu, 22 Mar 2018 19:36:36 +0300 Ilya Smith <blackzert@gmail.com> wrote:
> Current implementation doesn't randomize address returned by mmap.
> All the entropy ends with choosing mmap_base_addr at the process
> creation. After that mmap build very predictable layout of address
> space. It allows to bypass ASLR in many cases.
Perhaps some more effort on the problem description would help. *Are*
people predicting layouts at present? What problems does this cause?
How are they doing this and are there other approaches to solving the
problem?
Mainly: what value does this patchset have to our users? This reader
is unable to determine that from the information which you have
provided. Full details, please.
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-22 20:57 ` Andrew Morton
0 siblings, 0 replies; 185+ messages in thread
From: Andrew Morton @ 2018-03-22 20:57 UTC (permalink / raw)
To: linux-snps-arc
On Thu, 22 Mar 2018 19:36:36 +0300 Ilya Smith <blackzert@gmail.com> wrote:
> Current implementation doesn't randomize address returned by mmap.
> All the entropy ends with choosing mmap_base_addr at the process
> creation. After that mmap build very predictable layout of address
> space. It allows to bypass ASLR in many cases.
Perhaps some more effort on the problem description would help. *Are*
people predicting layouts at present? What problems does this cause?
How are they doing this and are there other approaches to solving the
problem?
Mainly: what value does this patchset have to our users? This reader
is unable to determine that from the information which you have
provided. Full details, please.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-22 16:36 ` Ilya Smith
(?)
(?)
@ 2018-03-23 12:48 ` Matthew Wilcox
-1 siblings, 0 replies; 185+ messages in thread
From: Matthew Wilcox @ 2018-03-23 12:48 UTC (permalink / raw)
To: Ilya Smith
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> Current implementation doesn't randomize address returned by mmap.
> All the entropy ends with choosing mmap_base_addr at the process
> creation. After that mmap build very predictable layout of address
> space. It allows to bypass ASLR in many cases. This patch make
> randomization of address on any mmap call.
Why should this be done in the kernel rather than libc? libc is perfectly
capable of specifying random numbers in the first argument of mmap.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 12:48 ` Matthew Wilcox
0 siblings, 0 replies; 185+ messages in thread
From: Matthew Wilcox @ 2018-03-23 12:48 UTC (permalink / raw)
To: Ilya Smith
Cc: kstewart, linux-mips, dalias, jack, linux-sh, benh, bhsharma,
heiko.carstens, jejb, linux-mm, mhocko, paulus, deepa.kernel,
hpa, sparclinux, linux-ia64, dan.j.williams, aarcange,
linux-s390, ysato, mpe, deller, x86, hughd, linux, nitin.m.gupta,
linux-alpha, mingo, jhogan, mattst88, linux-snps-arc, fenghua.yu,
riel, punit.agrawal, keescook, arnd, pombredanne, npiggin,
jglisse, ink
On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> Current implementation doesn't randomize address returned by mmap.
> All the entropy ends with choosing mmap_base_addr at the process
> creation. After that mmap build very predictable layout of address
> space. It allows to bypass ASLR in many cases. This patch make
> randomization of address on any mmap call.
Why should this be done in the kernel rather than libc? libc is perfectly
capable of specifying random numbers in the first argument of mmap.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 12:48 ` Matthew Wilcox
0 siblings, 0 replies; 185+ messages in thread
From: Matthew Wilcox @ 2018-03-23 12:48 UTC (permalink / raw)
To: Ilya Smith
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> Current implementation doesn't randomize address returned by mmap.
> All the entropy ends with choosing mmap_base_addr at the process
> creation. After that mmap build very predictable layout of address
> space. It allows to bypass ASLR in many cases. This patch make
> randomization of address on any mmap call.
Why should this be done in the kernel rather than libc? libc is perfectly
capable of specifying random numbers in the first argument of mmap.
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 12:48 ` Matthew Wilcox
0 siblings, 0 replies; 185+ messages in thread
From: Matthew Wilcox @ 2018-03-23 12:48 UTC (permalink / raw)
To: linux-snps-arc
On Thu, Mar 22, 2018@07:36:36PM +0300, Ilya Smith wrote:
> Current implementation doesn't randomize address returned by mmap.
> All the entropy ends with choosing mmap_base_addr at the process
> creation. After that mmap build very predictable layout of address
> space. It allows to bypass ASLR in many cases. This patch make
> randomization of address on any mmap call.
Why should this be done in the kernel rather than libc? libc is perfectly
capable of specifying random numbers in the first argument of mmap.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-22 20:57 ` Andrew Morton
` (3 preceding siblings ...)
(?)
@ 2018-03-23 17:25 ` Ilya Smith
-1 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:25 UTC (permalink / raw)
To: Andrew Morton
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
Hello, Andrew
Thanks for reading this patch.
> On 22 Mar 2018, at 23:57, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Thu, 22 Mar 2018 19:36:36 +0300 Ilya Smith <blackzert@gmail.com> wrote:
>
>> Current implementation doesn't randomize address returned by mmap.
>> All the entropy ends with choosing mmap_base_addr at the process
>> creation. After that mmap build very predictable layout of address
>> space. It allows to bypass ASLR in many cases.
>
> Perhaps some more effort on the problem description would help. *Are*
> people predicting layouts at present? What problems does this cause?
> How are they doing this and are there other approaches to solving the
> problem?
>
Sorry, I’ve lost it in first version. In short - memory layout could be easily
repaired by single leakage. Also any Out of Bounds error may easily be
exploited according to current implementation. All because mmap choose address
just before previously allocated segment. You can read more about it here:
http://www.openwall.com/lists/oss-security/2018/02/27/5
Some test are available here https://github.com/blackzert/aslur.
To solve the problem Kernel should randomize address on any mmap so
attacker could never easily gain needed addresses.
> Mainly: what value does this patchset have to our users? This reader
> is unable to determine that from the information which you have
> provided. Full details, please.
The value of this patch is to decrease successful rate of exploitation
vulnerable applications.These could be either remote or local vectors.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 17:25 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:25 UTC (permalink / raw)
To: Andrew Morton
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar
Hello, Andrew
Thanks for reading this patch.
> On 22 Mar 2018, at 23:57, Andrew Morton <akpm@linux-foundation.org> =
wrote:
>=20
> On Thu, 22 Mar 2018 19:36:36 +0300 Ilya Smith <blackzert@gmail.com> =
wrote:
>=20
>> Current implementation doesn't randomize address returned by mmap.
>> All the entropy ends with choosing mmap_base_addr at the process
>> creation. After that mmap build very predictable layout of address
>> space. It allows to bypass ASLR in many cases.
>=20
> Perhaps some more effort on the problem description would help. *Are*
> people predicting layouts at present? What problems does this cause?=20=
> How are they doing this and are there other approaches to solving the
> problem?
>=20
Sorry, I=E2=80=99ve lost it in first version. In short - memory layout =
could be easily=20
repaired by single leakage. Also any Out of Bounds error may easily be=20=
exploited according to current implementation. All because mmap choose =
address=20
just before previously allocated segment. You can read more about it =
here:=20
http://www.openwall.com/lists/oss-security/2018/02/27/5
Some test are available here https://github.com/blackzert/aslur.=20
To solve the problem Kernel should randomize address on any mmap so
attacker could never easily gain needed addresses.
> Mainly: what value does this patchset have to our users? This reader
> is unable to determine that from the information which you have
> provided. Full details, please.
The value of this patch is to decrease successful rate of exploitation
vulnerable applications.These could be either remote or local vectors.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 17:25 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:25 UTC (permalink / raw)
To: Andrew Morton
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
Hello, Andrew
Thanks for reading this patch.
> On 22 Mar 2018, at 23:57, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Thu, 22 Mar 2018 19:36:36 +0300 Ilya Smith <blackzert@gmail.com> wrote:
>
>> Current implementation doesn't randomize address returned by mmap.
>> All the entropy ends with choosing mmap_base_addr at the process
>> creation. After that mmap build very predictable layout of address
>> space. It allows to bypass ASLR in many cases.
>
> Perhaps some more effort on the problem description would help. *Are*
> people predicting layouts at present? What problems does this cause?
> How are they doing this and are there other approaches to solving the
> problem?
>
Sorry, I’ve lost it in first version. In short - memory layout could be easily
repaired by single leakage. Also any Out of Bounds error may easily be
exploited according to current implementation. All because mmap choose address
just before previously allocated segment. You can read more about it here:
http://www.openwall.com/lists/oss-security/2018/02/27/5
Some test are available here https://github.com/blackzert/aslur.
To solve the problem Kernel should randomize address on any mmap so
attacker could never easily gain needed addresses.
> Mainly: what value does this patchset have to our users? This reader
> is unable to determine that from the information which you have
> provided. Full details, please.
The value of this patch is to decrease successful rate of exploitation
vulnerable applications.These could be either remote or local vectors.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 17:25 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:25 UTC (permalink / raw)
To: Andrew Morton
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
Hello, Andrew
Thanks for reading this patch.
> On 22 Mar 2018, at 23:57, Andrew Morton <akpm@linux-foundation.org> =
wrote:
>=20
> On Thu, 22 Mar 2018 19:36:36 +0300 Ilya Smith <blackzert@gmail.com> =
wrote:
>=20
>> Current implementation doesn't randomize address returned by mmap.
>> All the entropy ends with choosing mmap_base_addr at the process
>> creation. After that mmap build very predictable layout of address
>> space. It allows to bypass ASLR in many cases.
>=20
> Perhaps some more effort on the problem description would help. *Are*
> people predicting layouts at present? What problems does this cause?=20=
> How are they doing this and are there other approaches to solving the
> problem?
>=20
Sorry, I=E2=80=99ve lost it in first version. In short - memory layout =
could be easily=20
repaired by single leakage. Also any Out of Bounds error may easily be=20=
exploited according to current implementation. All because mmap choose =
address=20
just before previously allocated segment. You can read more about it =
here:=20
http://www.openwall.com/lists/oss-security/2018/02/27/5
Some test are available here https://github.com/blackzert/aslur.=20
To solve the problem Kernel should randomize address on any mmap so
attacker could never easily gain needed addresses.
> Mainly: what value does this patchset have to our users? This reader
> is unable to determine that from the information which you have
> provided. Full details, please.
The value of this patch is to decrease successful rate of exploitation
vulnerable applications.These could be either remote or local vectors.
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 17:25 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:25 UTC (permalink / raw)
To: linux-snps-arc
Hello, Andrew
Thanks for reading this patch.
> On 22 Mar 2018,@23:57, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Thu, 22 Mar 2018 19:36:36 +0300 Ilya Smith <blackzert@gmail.com> wrote:
>
>> Current implementation doesn't randomize address returned by mmap.
>> All the entropy ends with choosing mmap_base_addr at the process
>> creation. After that mmap build very predictable layout of address
>> space. It allows to bypass ASLR in many cases.
>
> Perhaps some more effort on the problem description would help. *Are*
> people predicting layouts at present? What problems does this cause?
> How are they doing this and are there other approaches to solving the
> problem?
>
Sorry, I?ve lost it in first version. In short - memory layout could be easily
repaired by single leakage. Also any Out of Bounds error may easily be
exploited according to current implementation. All because mmap choose address
just before previously allocated segment. You can read more about it here:
http://www.openwall.com/lists/oss-security/2018/02/27/5
Some test are available here https://github.com/blackzert/aslur.
To solve the problem Kernel should randomize address on any mmap so
attacker could never easily gain needed addresses.
> Mainly: what value does this patchset have to our users? This reader
> is unable to determine that from the information which you have
> provided. Full details, please.
The value of this patch is to decrease successful rate of exploitation
vulnerable applications.These could be either remote or local vectors.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 17:25 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:25 UTC (permalink / raw)
To: Andrew Morton
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar
Hello, Andrew
Thanks for reading this patch.
> On 22 Mar 2018, at 23:57, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Thu, 22 Mar 2018 19:36:36 +0300 Ilya Smith <blackzert@gmail.com> wrote:
>
>> Current implementation doesn't randomize address returned by mmap.
>> All the entropy ends with choosing mmap_base_addr at the process
>> creation. After that mmap build very predictable layout of address
>> space. It allows to bypass ASLR in many cases.
>
> Perhaps some more effort on the problem description would help. *Are*
> people predicting layouts at present? What problems does this cause?
> How are they doing this and are there other approaches to solving the
> problem?
>
Sorry, I’ve lost it in first version. In short - memory layout could be easily
repaired by single leakage. Also any Out of Bounds error may easily be
exploited according to current implementation. All because mmap choose address
just before previously allocated segment. You can read more about it here:
http://www.openwall.com/lists/oss-security/2018/02/27/5
Some test are available here https://github.com/blackzert/aslur.
To solve the problem Kernel should randomize address on any mmap so
attacker could never easily gain needed addresses.
> Mainly: what value does this patchset have to our users? This reader
> is unable to determine that from the information which you have
> provided. Full details, please.
The value of this patch is to decrease successful rate of exploitation
vulnerable applications.These could be either remote or local vectors.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 1/2] Randomization of address chosen by mmap.
2018-03-22 20:53 ` Andrew Morton
` (3 preceding siblings ...)
(?)
@ 2018-03-23 17:43 ` Ilya Smith
-1 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:43 UTC (permalink / raw)
To: Andrew Morton
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, ralf,
jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, Hugh Dickins,
kstewart, pombredanne, steve.capper, punit.agrawal, aneesh.kumar,
npiggin, Kees Cook, bhsharma, riel, nitin.m.gupta,
Kirill A. Shutemov, Dan Williams, Jan Kara, ross.zwisler,
Jerome Glisse, Matthew Wilcox, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
> On 22 Mar 2018, at 23:53, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Thu, 22 Mar 2018 19:36:37 +0300 Ilya Smith <blackzert@gmail.com> wrote:
>
>> include/linux/mm.h | 16 ++++--
>> mm/mmap.c | 164 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> You'll be wanting to update the documentation.
> Documentation/sysctl/kernel.txt and
> Documentation/admin-guide/kernel-parameters.txt.
>
Sure, thanks for pointing there. I will add few lines there after discussion them
here.
>> ...
>>
>> @@ -2268,6 +2276,9 @@ extern unsigned long unmapped_area_topdown(struct vm_unmapped_area_info *info);
>> static inline unsigned long
>> vm_unmapped_area(struct vm_unmapped_area_info *info)
>> {
>> + /* How about 32 bit process?? */
>> + if ((current->flags & PF_RANDOMIZE) && randomize_va_space > 3)
>> + return unmapped_area_random(info);
>
> The handling of randomize_va_space is peculiar. Rather than being a
> bitfield which independently selects different modes, it is treated as
> a scalar: the larger the value, the more stuff we randomize.
>
> I can see the sense in that (and I wonder what randomize_va_space=5
> will do). But it is... odd.
>
> Why did you select randomize_va_space=4 for this? Is there a mode 3
> already and we forgot to document it? Or did you leave a gap for
> something? If the former, please feel free to fix the documentation
> (in a separate, preceding patch) while you're in there ;)
>
Yes, I was not sure about correct value so leaved some gap for future. Also
according to current implementation this value used like a scalar. But I’m
agree bitfield looks more flexible for the future. I think right now I can leave
3 as value for my patch and it could be fixed any time in the future. What
do you think about it?
>> if (info->flags & VM_UNMAPPED_AREA_TOPDOWN)
>> return unmapped_area_topdown(info);
>> else
>> @@ -2529,11 +2540,6 @@ int drop_caches_sysctl_handler(struct ctl_table *, int,
>> void drop_slab(void);
>> void drop_slab_node(int nid);
>>
>>
>> ...
>>
>> @@ -1780,6 +1781,169 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
>> return error;
>> }
>>
>> +unsigned long unmapped_area_random(struct vm_unmapped_area_info *info)
>> +{
>
> This function is just dead code if CONFIG_MMU=n, yes? Let's add the
> ifdefs to make it go away in that case.
>
Thanks, I missed that case. I will fix it.
>> + struct mm_struct *mm = current->mm;
>> + struct vm_area_struct *vma = NULL;
>> + struct vm_area_struct *visited_vma = NULL;
>> + unsigned long entropy[2];
>> + unsigned long length, low_limit, high_limit, gap_start, gap_end;
>> + unsigned long addr = 0;
>> +
>> + /* get entropy with prng */
>> + prandom_bytes(&entropy, sizeof(entropy));
>> + /* small hack to prevent EPERM result */
>> + info->low_limit = max(info->low_limit, mmap_min_addr);
>> +
>>
>> ...
>>
>> +found:
>> + /* We found a suitable gap. Clip it with the original high_limit. */
>> + if (gap_end > info->high_limit)
>> + gap_end = info->high_limit;
>> + gap_end -= info->length;
>> + gap_end -= (gap_end - info->align_offset) & info->align_mask;
>> + /* only one suitable page */
>> + if (gap_end == gap_start)
>> + return gap_start;
>> + addr = entropy[1] % (min((gap_end - gap_start) >> PAGE_SHIFT,
>> + 0x10000UL));
>
> What does the magic 10000 mean? Isn't a comment needed explaining this?
>
>> + addr = gap_end - (addr << PAGE_SHIFT);
>> + addr += (info->align_offset - addr) & info->align_mask;
>> + return addr;
>> +}
>>
>> ...
>>
>
This one what I fix by next patch. I was trying to make patches separate to make
it easier to understand them. This constant came from last version discussion
and honestly doesn’t means much. I replaced it with Architecture depended limit
that as I plan would be CONFIG value as well.
This value means maximum number of pages we can move away from the next
vma. The less value means less security but less memory fragmentation. Any way
on 64bit systems memory fragmentation is not such a big problem.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 1/2] Randomization of address chosen by mmap.
@ 2018-03-23 17:43 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:43 UTC (permalink / raw)
To: Andrew Morton
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, ralf,
jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, Hugh Dickins,
kstewart, pombredanne, steve.capper, punit.agrawal, aneesh.kumar,
npiggin
> On 22 Mar 2018, at 23:53, Andrew Morton <akpm@linux-foundation.org> =
wrote:
>=20
> On Thu, 22 Mar 2018 19:36:37 +0300 Ilya Smith <blackzert@gmail.com> =
wrote:
>=20
>> include/linux/mm.h | 16 ++++--
>> mm/mmap.c | 164 =
+++++++++++++++++++++++++++++++++++++++++++++++++++++
>=20
> You'll be wanting to update the documentation.=20
> Documentation/sysctl/kernel.txt and
> Documentation/admin-guide/kernel-parameters.txt.
>=20
Sure, thanks for pointing there. I will add few lines there after =
discussion them
here.
>> ...
>>=20
>> @@ -2268,6 +2276,9 @@ extern unsigned long =
unmapped_area_topdown(struct vm_unmapped_area_info *info);
>> static inline unsigned long
>> vm_unmapped_area(struct vm_unmapped_area_info *info)
>> {
>> + /* How about 32 bit process?? */
>> + if ((current->flags & PF_RANDOMIZE) && randomize_va_space > 3)
>> + return unmapped_area_random(info);
>=20
> The handling of randomize_va_space is peculiar. Rather than being a
> bitfield which independently selects different modes, it is treated as
> a scalar: the larger the value, the more stuff we randomize.
>=20
> I can see the sense in that (and I wonder what randomize_va_space=3D5
> will do). But it is... odd.
>=20
> Why did you select randomize_va_space=3D4 for this? Is there a mode 3
> already and we forgot to document it? Or did you leave a gap for
> something? If the former, please feel free to fix the documentation
> (in a separate, preceding patch) while you're in there ;)
>=20
Yes, I was not sure about correct value so leaved some gap for future. =
Also
according to current implementation this value used like a scalar. But =
I=E2=80=99m
agree bitfield looks more flexible for the future. I think right now I =
can leave
3 as value for my patch and it could be fixed any time in the future. =
What
do you think about it?
>> if (info->flags & VM_UNMAPPED_AREA_TOPDOWN)
>> return unmapped_area_topdown(info);
>> else
>> @@ -2529,11 +2540,6 @@ int drop_caches_sysctl_handler(struct =
ctl_table *, int,
>> void drop_slab(void);
>> void drop_slab_node(int nid);
>>=20
>>=20
>> ...
>>=20
>> @@ -1780,6 +1781,169 @@ unsigned long mmap_region(struct file *file, =
unsigned long addr,
>> return error;
>> }
>>=20
>> +unsigned long unmapped_area_random(struct vm_unmapped_area_info =
*info)
>> +{
>=20
> This function is just dead code if CONFIG_MMU=3Dn, yes? Let's add the
> ifdefs to make it go away in that case.
>=20
Thanks, I missed that case. I will fix it.
>> + struct mm_struct *mm =3D current->mm;
>> + struct vm_area_struct *vma =3D NULL;
>> + struct vm_area_struct *visited_vma =3D NULL;
>> + unsigned long entropy[2];
>> + unsigned long length, low_limit, high_limit, gap_start, gap_end;
>> + unsigned long addr =3D 0;
>> +
>> + /* get entropy with prng */
>> + prandom_bytes(&entropy, sizeof(entropy));
>> + /* small hack to prevent EPERM result */
>> + info->low_limit =3D max(info->low_limit, mmap_min_addr);
>> +
>>=20
>> ...
>>=20
>> +found:
>> + /* We found a suitable gap. Clip it with the original =
high_limit. */
>> + if (gap_end > info->high_limit)
>> + gap_end =3D info->high_limit;
>> + gap_end -=3D info->length;
>> + gap_end -=3D (gap_end - info->align_offset) & info->align_mask;
>> + /* only one suitable page */
>> + if (gap_end =3D=3D gap_start)
>> + return gap_start;
>> + addr =3D entropy[1] % (min((gap_end - gap_start) >> PAGE_SHIFT,
>> + 0x10000UL));
>=20
> What does the magic 10000 mean? Isn't a comment needed explaining =
this?
>=20
>> + addr =3D gap_end - (addr << PAGE_SHIFT);
>> + addr +=3D (info->align_offset - addr) & info->align_mask;
>> + return addr;
>> +}
>>=20
>> ...
>>=20
>=20
This one what I fix by next patch. I was trying to make patches separate =
to make
it easier to understand them. This constant came from last version =
discussion=20
and honestly doesn=E2=80=99t means much. I replaced it with Architecture =
depended limit
that as I plan would be CONFIG value as well.
This value means maximum number of pages we can move away from the next
vma. The less value means less security but less memory fragmentation. =
Any way
on 64bit systems memory fragmentation is not such a big problem.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 1/2] Randomization of address chosen by mmap.
@ 2018-03-23 17:43 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:43 UTC (permalink / raw)
To: Andrew Morton
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, ralf,
jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, Hugh Dickins,
kstewart, pombredanne, steve.capper, punit.agrawal, aneesh.kumar,
npiggin, Kees Cook, bhsharma, riel, nitin.m.gupta,
Kirill A. Shutemov, Dan Williams, Jan Kara, ross.zwisler,
Jerome Glisse, Matthew Wilcox, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
> On 22 Mar 2018, at 23:53, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Thu, 22 Mar 2018 19:36:37 +0300 Ilya Smith <blackzert@gmail.com> wrote:
>
>> include/linux/mm.h | 16 ++++--
>> mm/mmap.c | 164 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> You'll be wanting to update the documentation.
> Documentation/sysctl/kernel.txt and
> Documentation/admin-guide/kernel-parameters.txt.
>
Sure, thanks for pointing there. I will add few lines there after discussion them
here.
>> ...
>>
>> @@ -2268,6 +2276,9 @@ extern unsigned long unmapped_area_topdown(struct vm_unmapped_area_info *info);
>> static inline unsigned long
>> vm_unmapped_area(struct vm_unmapped_area_info *info)
>> {
>> + /* How about 32 bit process?? */
>> + if ((current->flags & PF_RANDOMIZE) && randomize_va_space > 3)
>> + return unmapped_area_random(info);
>
> The handling of randomize_va_space is peculiar. Rather than being a
> bitfield which independently selects different modes, it is treated as
> a scalar: the larger the value, the more stuff we randomize.
>
> I can see the sense in that (and I wonder what randomize_va_space=5
> will do). But it is... odd.
>
> Why did you select randomize_va_space=4 for this? Is there a mode 3
> already and we forgot to document it? Or did you leave a gap for
> something? If the former, please feel free to fix the documentation
> (in a separate, preceding patch) while you're in there ;)
>
Yes, I was not sure about correct value so leaved some gap for future. Also
according to current implementation this value used like a scalar. But I’m
agree bitfield looks more flexible for the future. I think right now I can leave
3 as value for my patch and it could be fixed any time in the future. What
do you think about it?
>> if (info->flags & VM_UNMAPPED_AREA_TOPDOWN)
>> return unmapped_area_topdown(info);
>> else
>> @@ -2529,11 +2540,6 @@ int drop_caches_sysctl_handler(struct ctl_table *, int,
>> void drop_slab(void);
>> void drop_slab_node(int nid);
>>
>>
>> ...
>>
>> @@ -1780,6 +1781,169 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
>> return error;
>> }
>>
>> +unsigned long unmapped_area_random(struct vm_unmapped_area_info *info)
>> +{
>
> This function is just dead code if CONFIG_MMU=n, yes? Let's add the
> ifdefs to make it go away in that case.
>
Thanks, I missed that case. I will fix it.
>> + struct mm_struct *mm = current->mm;
>> + struct vm_area_struct *vma = NULL;
>> + struct vm_area_struct *visited_vma = NULL;
>> + unsigned long entropy[2];
>> + unsigned long length, low_limit, high_limit, gap_start, gap_end;
>> + unsigned long addr = 0;
>> +
>> + /* get entropy with prng */
>> + prandom_bytes(&entropy, sizeof(entropy));
>> + /* small hack to prevent EPERM result */
>> + info->low_limit = max(info->low_limit, mmap_min_addr);
>> +
>>
>> ...
>>
>> +found:
>> + /* We found a suitable gap. Clip it with the original high_limit. */
>> + if (gap_end > info->high_limit)
>> + gap_end = info->high_limit;
>> + gap_end -= info->length;
>> + gap_end -= (gap_end - info->align_offset) & info->align_mask;
>> + /* only one suitable page */
>> + if (gap_end == gap_start)
>> + return gap_start;
>> + addr = entropy[1] % (min((gap_end - gap_start) >> PAGE_SHIFT,
>> + 0x10000UL));
>
> What does the magic 10000 mean? Isn't a comment needed explaining this?
>
>> + addr = gap_end - (addr << PAGE_SHIFT);
>> + addr += (info->align_offset - addr) & info->align_mask;
>> + return addr;
>> +}
>>
>> ...
>>
>
This one what I fix by next patch. I was trying to make patches separate to make
it easier to understand them. This constant came from last version discussion
and honestly doesn’t means much. I replaced it with Architecture depended limit
that as I plan would be CONFIG value as well.
This value means maximum number of pages we can move away from the next
vma. The less value means less security but less memory fragmentation. Any way
on 64bit systems memory fragmentation is not such a big problem.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 1/2] Randomization of address chosen by mmap.
@ 2018-03-23 17:43 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:43 UTC (permalink / raw)
To: Andrew Morton
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, ralf,
jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, Hugh Dickins,
kstewart, pombredanne, steve.capper, punit.agrawal, aneesh.kumar,
npiggin, Kees Cook, bhsharma, riel, nitin.m.gupta,
Kirill A. Shutemov, Dan Williams, Jan Kara, ross.zwisler,
Jerome Glisse, Matthew Wilcox, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
> On 22 Mar 2018, at 23:53, Andrew Morton <akpm@linux-foundation.org> =
wrote:
>=20
> On Thu, 22 Mar 2018 19:36:37 +0300 Ilya Smith <blackzert@gmail.com> =
wrote:
>=20
>> include/linux/mm.h | 16 ++++--
>> mm/mmap.c | 164 =
+++++++++++++++++++++++++++++++++++++++++++++++++++++
>=20
> You'll be wanting to update the documentation.=20
> Documentation/sysctl/kernel.txt and
> Documentation/admin-guide/kernel-parameters.txt.
>=20
Sure, thanks for pointing there. I will add few lines there after =
discussion them
here.
>> ...
>>=20
>> @@ -2268,6 +2276,9 @@ extern unsigned long =
unmapped_area_topdown(struct vm_unmapped_area_info *info);
>> static inline unsigned long
>> vm_unmapped_area(struct vm_unmapped_area_info *info)
>> {
>> + /* How about 32 bit process?? */
>> + if ((current->flags & PF_RANDOMIZE) && randomize_va_space > 3)
>> + return unmapped_area_random(info);
>=20
> The handling of randomize_va_space is peculiar. Rather than being a
> bitfield which independently selects different modes, it is treated as
> a scalar: the larger the value, the more stuff we randomize.
>=20
> I can see the sense in that (and I wonder what randomize_va_space=3D5
> will do). But it is... odd.
>=20
> Why did you select randomize_va_space=3D4 for this? Is there a mode 3
> already and we forgot to document it? Or did you leave a gap for
> something? If the former, please feel free to fix the documentation
> (in a separate, preceding patch) while you're in there ;)
>=20
Yes, I was not sure about correct value so leaved some gap for future. =
Also
according to current implementation this value used like a scalar. But =
I=E2=80=99m
agree bitfield looks more flexible for the future. I think right now I =
can leave
3 as value for my patch and it could be fixed any time in the future. =
What
do you think about it?
>> if (info->flags & VM_UNMAPPED_AREA_TOPDOWN)
>> return unmapped_area_topdown(info);
>> else
>> @@ -2529,11 +2540,6 @@ int drop_caches_sysctl_handler(struct =
ctl_table *, int,
>> void drop_slab(void);
>> void drop_slab_node(int nid);
>>=20
>>=20
>> ...
>>=20
>> @@ -1780,6 +1781,169 @@ unsigned long mmap_region(struct file *file, =
unsigned long addr,
>> return error;
>> }
>>=20
>> +unsigned long unmapped_area_random(struct vm_unmapped_area_info =
*info)
>> +{
>=20
> This function is just dead code if CONFIG_MMU=3Dn, yes? Let's add the
> ifdefs to make it go away in that case.
>=20
Thanks, I missed that case. I will fix it.
>> + struct mm_struct *mm =3D current->mm;
>> + struct vm_area_struct *vma =3D NULL;
>> + struct vm_area_struct *visited_vma =3D NULL;
>> + unsigned long entropy[2];
>> + unsigned long length, low_limit, high_limit, gap_start, gap_end;
>> + unsigned long addr =3D 0;
>> +
>> + /* get entropy with prng */
>> + prandom_bytes(&entropy, sizeof(entropy));
>> + /* small hack to prevent EPERM result */
>> + info->low_limit =3D max(info->low_limit, mmap_min_addr);
>> +
>>=20
>> ...
>>=20
>> +found:
>> + /* We found a suitable gap. Clip it with the original =
high_limit. */
>> + if (gap_end > info->high_limit)
>> + gap_end =3D info->high_limit;
>> + gap_end -=3D info->length;
>> + gap_end -=3D (gap_end - info->align_offset) & info->align_mask;
>> + /* only one suitable page */
>> + if (gap_end =3D=3D gap_start)
>> + return gap_start;
>> + addr =3D entropy[1] % (min((gap_end - gap_start) >> PAGE_SHIFT,
>> + 0x10000UL));
>=20
> What does the magic 10000 mean? Isn't a comment needed explaining =
this?
>=20
>> + addr =3D gap_end - (addr << PAGE_SHIFT);
>> + addr +=3D (info->align_offset - addr) & info->align_mask;
>> + return addr;
>> +}
>>=20
>> ...
>>=20
>=20
This one what I fix by next patch. I was trying to make patches separate =
to make
it easier to understand them. This constant came from last version =
discussion=20
and honestly doesn=E2=80=99t means much. I replaced it with Architecture =
depended limit
that as I plan would be CONFIG value as well.
This value means maximum number of pages we can move away from the next
vma. The less value means less security but less memory fragmentation. =
Any way
on 64bit systems memory fragmentation is not such a big problem.
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 1/2] Randomization of address chosen by mmap.
@ 2018-03-23 17:43 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:43 UTC (permalink / raw)
To: linux-snps-arc
> On 22 Mar 2018,@23:53, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Thu, 22 Mar 2018 19:36:37 +0300 Ilya Smith <blackzert@gmail.com> wrote:
>
>> include/linux/mm.h | 16 ++++--
>> mm/mmap.c | 164 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> You'll be wanting to update the documentation.
> Documentation/sysctl/kernel.txt and
> Documentation/admin-guide/kernel-parameters.txt.
>
Sure, thanks for pointing there. I will add few lines there after discussion them
here.
>> ...
>>
>> @@ -2268,6 +2276,9 @@ extern unsigned long unmapped_area_topdown(struct vm_unmapped_area_info *info);
>> static inline unsigned long
>> vm_unmapped_area(struct vm_unmapped_area_info *info)
>> {
>> + /* How about 32 bit process?? */
>> + if ((current->flags & PF_RANDOMIZE) && randomize_va_space > 3)
>> + return unmapped_area_random(info);
>
> The handling of randomize_va_space is peculiar. Rather than being a
> bitfield which independently selects different modes, it is treated as
> a scalar: the larger the value, the more stuff we randomize.
>
> I can see the sense in that (and I wonder what randomize_va_space=5
> will do). But it is... odd.
>
> Why did you select randomize_va_space=4 for this? Is there a mode 3
> already and we forgot to document it? Or did you leave a gap for
> something? If the former, please feel free to fix the documentation
> (in a separate, preceding patch) while you're in there ;)
>
Yes, I was not sure about correct value so leaved some gap for future. Also
according to current implementation this value used like a scalar. But I?m
agree bitfield looks more flexible for the future. I think right now I can leave
3 as value for my patch and it could be fixed any time in the future. What
do you think about it?
>> if (info->flags & VM_UNMAPPED_AREA_TOPDOWN)
>> return unmapped_area_topdown(info);
>> else
>> @@ -2529,11 +2540,6 @@ int drop_caches_sysctl_handler(struct ctl_table *, int,
>> void drop_slab(void);
>> void drop_slab_node(int nid);
>>
>>
>> ...
>>
>> @@ -1780,6 +1781,169 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
>> return error;
>> }
>>
>> +unsigned long unmapped_area_random(struct vm_unmapped_area_info *info)
>> +{
>
> This function is just dead code if CONFIG_MMU=n, yes? Let's add the
> ifdefs to make it go away in that case.
>
Thanks, I missed that case. I will fix it.
>> + struct mm_struct *mm = current->mm;
>> + struct vm_area_struct *vma = NULL;
>> + struct vm_area_struct *visited_vma = NULL;
>> + unsigned long entropy[2];
>> + unsigned long length, low_limit, high_limit, gap_start, gap_end;
>> + unsigned long addr = 0;
>> +
>> + /* get entropy with prng */
>> + prandom_bytes(&entropy, sizeof(entropy));
>> + /* small hack to prevent EPERM result */
>> + info->low_limit = max(info->low_limit, mmap_min_addr);
>> +
>>
>> ...
>>
>> +found:
>> + /* We found a suitable gap. Clip it with the original high_limit. */
>> + if (gap_end > info->high_limit)
>> + gap_end = info->high_limit;
>> + gap_end -= info->length;
>> + gap_end -= (gap_end - info->align_offset) & info->align_mask;
>> + /* only one suitable page */
>> + if (gap_end == gap_start)
>> + return gap_start;
>> + addr = entropy[1] % (min((gap_end - gap_start) >> PAGE_SHIFT,
>> + 0x10000UL));
>
> What does the magic 10000 mean? Isn't a comment needed explaining this?
>
>> + addr = gap_end - (addr << PAGE_SHIFT);
>> + addr += (info->align_offset - addr) & info->align_mask;
>> + return addr;
>> +}
>>
>> ...
>>
>
This one what I fix by next patch. I was trying to make patches separate to make
it easier to understand them. This constant came from last version discussion
and honestly doesn?t means much. I replaced it with Architecture depended limit
that as I plan would be CONFIG value as well.
This value means maximum number of pages we can move away from the next
vma. The less value means less security but less memory fragmentation. Any way
on 64bit systems memory fragmentation is not such a big problem.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 1/2] Randomization of address chosen by mmap.
@ 2018-03-23 17:43 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:43 UTC (permalink / raw)
To: Andrew Morton
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, ralf,
jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, Hugh Dickins,
kstewart, pombredanne, steve.capper, punit.agrawal, aneesh.kumar,
npiggin
> On 22 Mar 2018, at 23:53, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Thu, 22 Mar 2018 19:36:37 +0300 Ilya Smith <blackzert@gmail.com> wrote:
>
>> include/linux/mm.h | 16 ++++--
>> mm/mmap.c | 164 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> You'll be wanting to update the documentation.
> Documentation/sysctl/kernel.txt and
> Documentation/admin-guide/kernel-parameters.txt.
>
Sure, thanks for pointing there. I will add few lines there after discussion them
here.
>> ...
>>
>> @@ -2268,6 +2276,9 @@ extern unsigned long unmapped_area_topdown(struct vm_unmapped_area_info *info);
>> static inline unsigned long
>> vm_unmapped_area(struct vm_unmapped_area_info *info)
>> {
>> + /* How about 32 bit process?? */
>> + if ((current->flags & PF_RANDOMIZE) && randomize_va_space > 3)
>> + return unmapped_area_random(info);
>
> The handling of randomize_va_space is peculiar. Rather than being a
> bitfield which independently selects different modes, it is treated as
> a scalar: the larger the value, the more stuff we randomize.
>
> I can see the sense in that (and I wonder what randomize_va_space=5
> will do). But it is... odd.
>
> Why did you select randomize_va_space=4 for this? Is there a mode 3
> already and we forgot to document it? Or did you leave a gap for
> something? If the former, please feel free to fix the documentation
> (in a separate, preceding patch) while you're in there ;)
>
Yes, I was not sure about correct value so leaved some gap for future. Also
according to current implementation this value used like a scalar. But I’m
agree bitfield looks more flexible for the future. I think right now I can leave
3 as value for my patch and it could be fixed any time in the future. What
do you think about it?
>> if (info->flags & VM_UNMAPPED_AREA_TOPDOWN)
>> return unmapped_area_topdown(info);
>> else
>> @@ -2529,11 +2540,6 @@ int drop_caches_sysctl_handler(struct ctl_table *, int,
>> void drop_slab(void);
>> void drop_slab_node(int nid);
>>
>>
>> ...
>>
>> @@ -1780,6 +1781,169 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
>> return error;
>> }
>>
>> +unsigned long unmapped_area_random(struct vm_unmapped_area_info *info)
>> +{
>
> This function is just dead code if CONFIG_MMU=n, yes? Let's add the
> ifdefs to make it go away in that case.
>
Thanks, I missed that case. I will fix it.
>> + struct mm_struct *mm = current->mm;
>> + struct vm_area_struct *vma = NULL;
>> + struct vm_area_struct *visited_vma = NULL;
>> + unsigned long entropy[2];
>> + unsigned long length, low_limit, high_limit, gap_start, gap_end;
>> + unsigned long addr = 0;
>> +
>> + /* get entropy with prng */
>> + prandom_bytes(&entropy, sizeof(entropy));
>> + /* small hack to prevent EPERM result */
>> + info->low_limit = max(info->low_limit, mmap_min_addr);
>> +
>>
>> ...
>>
>> +found:
>> + /* We found a suitable gap. Clip it with the original high_limit. */
>> + if (gap_end > info->high_limit)
>> + gap_end = info->high_limit;
>> + gap_end -= info->length;
>> + gap_end -= (gap_end - info->align_offset) & info->align_mask;
>> + /* only one suitable page */
>> + if (gap_end == gap_start)
>> + return gap_start;
>> + addr = entropy[1] % (min((gap_end - gap_start) >> PAGE_SHIFT,
>> + 0x10000UL));
>
> What does the magic 10000 mean? Isn't a comment needed explaining this?
>
>> + addr = gap_end - (addr << PAGE_SHIFT);
>> + addr += (info->align_offset - addr) & info->align_mask;
>> + return addr;
>> +}
>>
>> ...
>>
>
This one what I fix by next patch. I was trying to make patches separate to make
it easier to understand them. This constant came from last version discussion
and honestly doesn’t means much. I replaced it with Architecture depended limit
that as I plan would be CONFIG value as well.
This value means maximum number of pages we can move away from the next
vma. The less value means less security but less memory fragmentation. Any way
on 64bit systems memory fragmentation is not such a big problem.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 2/2] Architecture defined limit on memory region random shift.
2018-03-22 20:54 ` Andrew Morton
@ 2018-03-23 17:48 ` Ilya Smith
-1 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:48 UTC (permalink / raw)
To: Andrew Morton
Cc: kstewart, linux-mips, dalias, Jan Kara, linux-sh, bhsharma,
heiko.carstens, jejb, Linux-MM, Michal Hocko, paulus,
deepa.kernel, hpa, sparclinux, linux-ia64, Dan Williams,
Andrea Arcangeli, linux-s390, ysato, Helge Deller, x86,
Hugh Dickins, linux, Matthew Wilcox, nitin.m.gupta, linux-alpha,
mingo, mattst88, linux-snps-arc, fenghua.yu, riel, punit.agrawal,
Kees Cook, arnd
[-- Attachment #1.1: Type: text/plain, Size: 727 bytes --]
> On 22 Mar 2018, at 23:54, Andrew Morton <akpm@linux-foundation.org> wrote:
>
>
> Please add changelogs. An explanation of what a "limit on memory
> region random shift" is would be nice ;) Why does it exist, why are we
> doing this, etc. Surely there's something to be said - at present this
> is just a lump of random code?
>
Sorry, my bad. The main idea of this limit is to decrease possible memory
fragmentation. This is not so big problem on 64bit process, but really big for
32 bit processes since may cause failure memory allocation. To control memory
fragmentation and protect 32 bit systems (or architectures) this limit was
introduce by this patch. It could be also moved to CONFIG_ as well.
[-- Attachment #1.2: Type: text/html, Size: 2884 bytes --]
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 2/2] Architecture defined limit on memory region random shift.
@ 2018-03-23 17:48 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:48 UTC (permalink / raw)
To: Andrew Morton
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, ralf,
jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, Hugh Dickins,
kstewart, pombredanne, steve.capper, punit.agrawal, aneesh.kumar,
npiggin, Kees Cook, bhsharma, riel, nitin.m.gupta,
Kirill A. Shutemov, Dan Williams, Jan Kara, ross.zwisler,
Jerome Glisse, Matthew Wilcox, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
[-- Attachment #1.1: Type: text/plain, Size: 727 bytes --]
> On 22 Mar 2018, at 23:54, Andrew Morton <akpm@linux-foundation.org> wrote:
>
>
> Please add changelogs. An explanation of what a "limit on memory
> region random shift" is would be nice ;) Why does it exist, why are we
> doing this, etc. Surely there's something to be said - at present this
> is just a lump of random code?
>
Sorry, my bad. The main idea of this limit is to decrease possible memory
fragmentation. This is not so big problem on 64bit process, but really big for
32 bit processes since may cause failure memory allocation. To control memory
fragmentation and protect 32 bit systems (or architectures) this limit was
introduce by this patch. It could be also moved to CONFIG_ as well.
[-- Attachment #1.2: Type: text/html, Size: 2884 bytes --]
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 2/2] Architecture defined limit on memory region random shift.
2018-03-22 20:54 ` Andrew Morton
` (3 preceding siblings ...)
(?)
@ 2018-03-23 17:49 ` Ilya Smith
-1 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:49 UTC (permalink / raw)
To: Andrew Morton
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
> On 22 Mar 2018, at 23:54, Andrew Morton <akpm@linux-foundation.org> wrote:
>
>
> Please add changelogs. An explanation of what a "limit on memory
> region random shift" is would be nice ;) Why does it exist, why are we
> doing this, etc. Surely there's something to be said - at present this
> is just a lump of random code?
>
>
>
Sorry, my bad. The main idea of this limit is to decrease possible memory
fragmentation. This is not so big problem on 64bit process, but really big for
32 bit processes since may cause failure memory allocation. To control memory
fragmentation and protect 32 bit systems (or architectures) this limit was
introduce by this patch. It could be also moved to CONFIG_ as well.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 2/2] Architecture defined limit on memory region random shift.
@ 2018-03-23 17:49 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:49 UTC (permalink / raw)
To: Andrew Morton
Cc: kstewart, linux-mips, dalias, jack, linux-sh, benh, bhsharma,
heiko.carstens, jejb, linux-mm, mhocko, paulus, deepa.kernel,
hpa, sparclinux, linux-ia64, dan.j.williams, aarcange,
linux-s390, ysato, mpe, deller, x86, hughd, linux, willy,
nitin.m.gupta, linux-alpha, mingo, jhogan, mattst88,
linux-snps-arc, fenghua.yu, riel, punit.agrawal, keescook, arnd,
pombredanne, npiggin, jglisse
> On 22 Mar 2018, at 23:54, Andrew Morton <akpm@linux-foundation.org> wrote:
>
>
> Please add changelogs. An explanation of what a "limit on memory
> region random shift" is would be nice ;) Why does it exist, why are we
> doing this, etc. Surely there's something to be said - at present this
> is just a lump of random code?
>
>
>
Sorry, my bad. The main idea of this limit is to decrease possible memory
fragmentation. This is not so big problem on 64bit process, but really big for
32 bit processes since may cause failure memory allocation. To control memory
fragmentation and protect 32 bit systems (or architectures) this limit was
introduce by this patch. It could be also moved to CONFIG_ as well.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 2/2] Architecture defined limit on memory region random shift.
@ 2018-03-23 17:49 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:49 UTC (permalink / raw)
To: Andrew Morton
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
> On 22 Mar 2018, at 23:54, Andrew Morton <akpm@linux-foundation.org> wrote:
>
>
> Please add changelogs. An explanation of what a "limit on memory
> region random shift" is would be nice ;) Why does it exist, why are we
> doing this, etc. Surely there's something to be said - at present this
> is just a lump of random code?
>
>
>
Sorry, my bad. The main idea of this limit is to decrease possible memory
fragmentation. This is not so big problem on 64bit process, but really big for
32 bit processes since may cause failure memory allocation. To control memory
fragmentation and protect 32 bit systems (or architectures) this limit was
introduce by this patch. It could be also moved to CONFIG_ as well.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 2/2] Architecture defined limit on memory region random shift.
@ 2018-03-23 17:49 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:49 UTC (permalink / raw)
To: Andrew Morton
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 12810 bytes --]
> On 22 Mar 2018, at 23:54, Andrew Morton <akpm@linux-foundation.org> wrote:
>
>
> Please add changelogs. An explanation of what a "limit on memory
> region random shift" is would be nice ;) Why does it exist, why are we
> doing this, etc. Surely there's something to be said - at present this
> is just a lump of random code?
>
>
>
Sorry, my bad. The main idea of this limit is to decrease possible memory
fragmentation. This is not so big problem on 64bit process, but really big for
32 bit processes since may cause failure memory allocation. To control memory
fragmentation and protect 32 bit systems (or architectures) this limit was
introduce by this patch. It could be also moved to CONFIG_ as well.
From blackzert@gmail.com Fri Mar 23 18:55:58 2018
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Mar 2018 18:56:04 +0100 (CET)
Received: from mail-lf0-x242.google.com ([IPv6:2a00:1450:4010:c07::242]:39888
"EHLO mail-lf0-x242.google.com" rhost-flags-OK-OK-OK-OK)
by eddie.linux-mips.org with ESMTP id S23990723AbeCWRz5Oe5wq convert rfc822-to-8bit
(ORCPT <rfc822;linux-mips@linux-mips.org>);
Fri, 23 Mar 2018 18:55:57 +0100
Received: by mail-lf0-x242.google.com with SMTP id p142-v6so19522202lfd.6;
Fri, 23 Mar 2018 10:55:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20161025;
h=mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=Nn/LegfdgCnPMfgxrP8ldElW5x41AbmrS9XnJZIcO0M=;
b=dmuwuz6Z424tcCQofiCkpe7cXUJw3+yS9d8dSuF6KIrQ3AS98qcM3znkAh+yQ8N861
DQUFRDwaQ8zsA9zfeG1lYzBYGpXJi8Q50XApUrKoNifIvTjyQXebt0GhEeFeh8udWnN1
SaV+sgwIzdJcB/Q+xKm4AeFiWecFUaKndxiCasm/VGFuPIpnt4oIuMGZ2lfUg8gMc7EF
TLbBhWhnBsA501jUsXGVCUu1Ta1OuIi+DgH6N9txRSK0LYwrDOwwO4wBeB3FY9sG34Ee
y4n5+NevXgWYxnIIpB+Zzgls02Nrk6ePhuN+gOhnMpVoienq2TVmDFk/zgtFS2MEb0+f
QLog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=Nn/LegfdgCnPMfgxrP8ldElW5x41AbmrS9XnJZIcO0M=;
b=laDkW/REk+yWaPTVY+xwYYLiXjC5617gcjtu9hlvqjYrWuiY6/2CWJeq60RJ0zfDcf
p1pm89/vYwJl4nQ+yw/p2xugnOuYN1oVjS3a8JrIC/snihpSETExvofuUQv+hR4wDbp6
0S81Iw/KuiGPLHTZohoNxQ/wjCX3nNaL12S/ePCKXlFqnyp7z0mV/2qYLVe22CFxzQwk
tIcrAuSID8w6m7+5nQNLllsZs/lgi/QYSrkwV+EDjxydCCM+iqAggB1EwPePApZoVw23
lBnmESc19NwHOdO91s1tye6bM7uzmfXmZZbt//9EwsxoCiOWlv95UnvgjWqHaDbYHPZY
kDkw==
X-Gm-Message-State: AElRT7FXL7+nRwZt86XOV+lihwpIqTwhVDgvuAUWOX67HKaU7Nc7DJDX
iSdRLoXARcdlt9CvSFKdABg=
X-Google-Smtp-Source: AG47ELvfGoHwG8ZFUTfHtGgnMEMhX5286YUod0rhOtxN+bKDVeOxka7156ZLffopag3GbBdCfb+X5Q==
X-Received: by 10.46.76.25 with SMTP id z25mr21154931lja.148.1521827752056;
Fri, 23 Mar 2018 10:55:52 -0700 (PDT)
Received: from [192.168.1.3] (broadband-188-255-70-164.moscow.rt.ru. [188.255.70.164])
by smtp.gmail.com with ESMTPSA id e8sm851332ljj.6.2018.03.23.10.55.49
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 23 Mar 2018 10:55:51 -0700 (PDT)
Content-Type: text/plain;
charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Subject: Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
From: Ilya Smith <blackzert@gmail.com>
In-Reply-To: <20180323124806.GA5624@bombadil.infradead.org>
Date: Fri, 23 Mar 2018 20:55:49 +0300
Cc: rth@twiddle.net, ink@jurassic.park.msu.ru, mattst88@gmail.com,
vgupta@synopsys.com, linux@armlinux.org.uk, tony.luck@intel.com,
fenghua.yu@intel.com, ralf@linux-mips.org, jejb@parisc-linux.org,
Helge Deller <deller@gmx.de>, benh@kernel.crashing.org,
paulus@samba.org, mpe@ellerman.id.au, schwidefsky@de.ibm.com,
heiko.carstens@de.ibm.com, ysato@users.sourceforge.jp,
dalias@libc.org, davem@davemloft.net, tglx@linutronix.de,
mingo@redhat.com, hpa@zytor.com, x86@kernel.org,
nyc@holomorphy.com, viro@zeniv.linux.org.uk, arnd@arndb.de,
gregkh@linuxfoundation.org, deepa.kernel@gmail.com,
Michal Hocko <mhocko@suse.com>,
Hugh Dickins <hughd@google.com>, kstewart@linuxfoundation.org,
pombredanne@nexb.com, Andrew Morton <akpm@linux-foundation.org>,
steve.capper@arm.com, punit.agrawal@arm.com,
aneesh.kumar@linux.vnet.ibm.com, npiggin@gmail.com,
Kees Cook <keescook@chromium.org>, bhsharma@redhat.com,
riel@redhat.com, nitin.m.gupta@oracle.com,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Dan Williams <dan.j.williams@intel.com>,
Jan Kara <jack@suse.cz>, ross.zwisler@linux.intel.com,
Jerome Glisse <jglisse@redhat.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Oleg Nesterov <oleg@redhat.com>, linux-alpha@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
linux-snps-arc@lists.infradead.org, linux-ia64@vger.kernel.org,
linux-metag@vger.kernel.org, linux-mips@linux-mips.org,
linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
sparclinux@vger.kernel.org, Linux-MM <linux-mm@kvack.org>
Content-Transfer-Encoding: 8BIT
Message-Id: <651E0DB6-4507-4DA1-AD46-9C26ED9792A8@gmail.com>
References: <1521736598-12812-1-git-send-email-blackzert@gmail.com>
<20180323124806.GA5624@bombadil.infradead.org>
To: Matthew Wilcox <willy@infradead.org>
X-Mailer: Apple Mail (2.3445.5.20)
Return-Path: <blackzert@gmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 63173
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: blackzert@gmail.com
Precedence: bulk
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
List-software: Ecartis version 1.0.0
List-Id: linux-mips <linux-mips.eddie.linux-mips.org>
X-List-ID: linux-mips <linux-mips.eddie.linux-mips.org>
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
X-list: linux-mips
Content-Length: 1135
Lines: 21
> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
>
> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>> Current implementation doesn't randomize address returned by mmap.
>> All the entropy ends with choosing mmap_base_addr at the process
>> creation. After that mmap build very predictable layout of address
>> space. It allows to bypass ASLR in many cases. This patch make
>> randomization of address on any mmap call.
>
> Why should this be done in the kernel rather than libc? libc is perfectly
> capable of specifying random numbers in the first argument of mmap.
Well, there is following reasons:
1. It should be done in any libc implementation, what is not possible IMO;
2. User mode is not that layer which should be responsible for choosing
random address or handling entropy;
3. Memory fragmentation is unpredictable in this case
Off course user mode could use random ‘hint’ address, but kernel may
discard this address if it is occupied for example and allocate just before
closest vma. So this solution doesn’t give that much security like
randomization address inside kernel.
From dalias@aerifal.cx Fri Mar 23 19:01:15 2018
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Mar 2018 19:01:21 +0100 (CET)
Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:48886 "EHLO
brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK)
by eddie.linux-mips.org with ESMTP id S23990498AbeCWSBPI4c3q (ORCPT
<rfc822;linux-mips@linux-mips.org>); Fri, 23 Mar 2018 19:01:15 +0100
Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2)
id 1ezQzI-0000XQ-00; Fri, 23 Mar 2018 18:00:24 +0000
Date: Fri, 23 Mar 2018 14:00:24 -0400
From: Rich Felker <dalias@libc.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Ilya Smith <blackzert@gmail.com>, rth@twiddle.net,
ink@jurassic.park.msu.ru, mattst88@gmail.com, vgupta@synopsys.com,
linux@armlinux.org.uk, tony.luck@intel.com, fenghua.yu@intel.com,
jhogan@kernel.org, ralf@linux-mips.org, jejb@parisc-linux.org,
deller@gmx.de, benh@kernel.crashing.org, paulus@samba.org,
mpe@ellerman.id.au, schwidefsky@de.ibm.com,
heiko.carstens@de.ibm.com, ysato@users.sourceforge.jp,
davem@davemloft.net, tglx@linutronix.de, mingo@redhat.com,
hpa@zytor.com, x86@kernel.org, nyc@holomorphy.com,
viro@zeniv.linux.org.uk, arnd@arndb.de, gregkh@linuxfoundation.org,
deepa.kernel@gmail.com, mhocko@suse.com, hughd@google.com,
kstewart@linuxfoundation.org, pombredanne@nexb.com,
akpm@linux-foundation.org, steve.capper@arm.com,
punit.agrawal@arm.com, paul.burton@mips.com,
aneesh.kumar@linux.vnet.ibm.com, npiggin@gmail.com,
keescook@chromium.org, bhsharma@redhat.com, riel@redhat.com,
nitin.m.gupta@oracle.com, kirill.shutemov@linux.intel.com,
dan.j.williams@intel.com, jack@suse.cz,
ross.zwisler@linux.intel.com, jglisse@redhat.com,
aarcange@redhat.com, oleg@redhat.com, linux-alpha@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-snps-arc@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org,
linux-metag@vger.kernel.org, linux-mips@linux-mips.org,
linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
sparclinux@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
Message-ID: <20180323180024.GB1436@brightrain.aerifal.cx>
References: <1521736598-12812-1-git-send-email-blackzert@gmail.com>
<20180323124806.GA5624@bombadil.infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180323124806.GA5624@bombadil.infradead.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Return-Path: <dalias@aerifal.cx>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 63174
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dalias@libc.org
Precedence: bulk
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
List-software: Ecartis version 1.0.0
List-Id: linux-mips <linux-mips.eddie.linux-mips.org>
X-List-ID: linux-mips <linux-mips.eddie.linux-mips.org>
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
X-list: linux-mips
Content-Length: 1289
Lines: 23
On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote:
> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> > Current implementation doesn't randomize address returned by mmap.
> > All the entropy ends with choosing mmap_base_addr at the process
> > creation. After that mmap build very predictable layout of address
> > space. It allows to bypass ASLR in many cases. This patch make
> > randomization of address on any mmap call.
>
> Why should this be done in the kernel rather than libc? libc is perfectly
> capable of specifying random numbers in the first argument of mmap.
Generally libc does not have a view of the current vm maps, and thus
in passing "random numbers", they would have to be uniform across the
whole vm space and thus non-uniform once the kernel rounds up to avoid
existing mappings. Also this would impose requirements that libc be
aware of the kernel's use of the virtual address space and what's
available to userspace -- for example, on 32-bit archs whether 2GB,
3GB, or full 4GB (for 32-bit-user-on-64-bit-kernel) is available, and
on 64-bit archs where fewer than the full 64 bits are actually valid
in addresses, what the actual usable pointer size is. There is
currently no clean way of conveying this information to userspace.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 2/2] Architecture defined limit on memory region random shift.
@ 2018-03-23 17:49 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:49 UTC (permalink / raw)
To: Andrew Morton
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
> On 22 Mar 2018, at 23:54, Andrew Morton <akpm@linux-foundation.org> =
wrote:
>=20
>=20
> Please add changelogs. An explanation of what a "limit on memory
> region random shift" is would be nice ;) Why does it exist, why are we
> doing this, etc. Surely there's something to be said - at present =
this
> is just a lump of random code?
>=20
>=20
>=20
Sorry, my bad. The main idea of this limit is to decrease possible =
memory=20
fragmentation. This is not so big problem on 64bit process, but really =
big for=20
32 bit processes since may cause failure memory allocation. To control =
memory=20
fragmentation and protect 32 bit systems (or architectures) this limit =
was=20
introduce by this patch. It could be also moved to CONFIG_ as well.=
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 2/2] Architecture defined limit on memory region random shift.
@ 2018-03-23 17:49 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:49 UTC (permalink / raw)
To: linux-snps-arc
> On 22 Mar 2018,@23:54, Andrew Morton <akpm@linux-foundation.org> wrote:
>
>
> Please add changelogs. An explanation of what a "limit on memory
> region random shift" is would be nice ;) Why does it exist, why are we
> doing this, etc. Surely there's something to be said - at present this
> is just a lump of random code?
>
>
>
Sorry, my bad. The main idea of this limit is to decrease possible memory
fragmentation. This is not so big problem on 64bit process, but really big for
32 bit processes since may cause failure memory allocation. To control memory
fragmentation and protect 32 bit systems (or architectures) this limit was
introduce by this patch. It could be also moved to CONFIG_ as well.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-23 12:48 ` Matthew Wilcox
` (3 preceding siblings ...)
(?)
@ 2018-03-23 17:55 ` Ilya Smith
-1 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:55 UTC (permalink / raw)
To: Matthew Wilcox
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, ralf,
jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
>
> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>> Current implementation doesn't randomize address returned by mmap.
>> All the entropy ends with choosing mmap_base_addr at the process
>> creation. After that mmap build very predictable layout of address
>> space. It allows to bypass ASLR in many cases. This patch make
>> randomization of address on any mmap call.
>
> Why should this be done in the kernel rather than libc? libc is perfectly
> capable of specifying random numbers in the first argument of mmap.
Well, there is following reasons:
1. It should be done in any libc implementation, what is not possible IMO;
2. User mode is not that layer which should be responsible for choosing
random address or handling entropy;
3. Memory fragmentation is unpredictable in this case
Off course user mode could use random ‘hint’ address, but kernel may
discard this address if it is occupied for example and allocate just before
closest vma. So this solution doesn’t give that much security like
randomization address inside kernel.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 17:55 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:55 UTC (permalink / raw)
To: Matthew Wilcox
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, ralf,
jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal
> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
>=20
> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>> Current implementation doesn't randomize address returned by mmap.
>> All the entropy ends with choosing mmap_base_addr at the process
>> creation. After that mmap build very predictable layout of address
>> space. It allows to bypass ASLR in many cases. This patch make
>> randomization of address on any mmap call.
>=20
> Why should this be done in the kernel rather than libc? libc is =
perfectly
> capable of specifying random numbers in the first argument of mmap.
Well, there is following reasons:
1. It should be done in any libc implementation, what is not possible =
IMO;
2. User mode is not that layer which should be responsible for choosing
random address or handling entropy;
3. Memory fragmentation is unpredictable in this case
Off course user mode could use random =E2=80=98hint=E2=80=99 address, =
but kernel may
discard this address if it is occupied for example and allocate just =
before
closest vma. So this solution doesn=E2=80=99t give that much security =
like=20
randomization address inside kernel.=
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 17:55 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:55 UTC (permalink / raw)
To: Matthew Wilcox
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, ralf,
jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
>
> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>> Current implementation doesn't randomize address returned by mmap.
>> All the entropy ends with choosing mmap_base_addr at the process
>> creation. After that mmap build very predictable layout of address
>> space. It allows to bypass ASLR in many cases. This patch make
>> randomization of address on any mmap call.
>
> Why should this be done in the kernel rather than libc? libc is perfectly
> capable of specifying random numbers in the first argument of mmap.
Well, there is following reasons:
1. It should be done in any libc implementation, what is not possible IMO;
2. User mode is not that layer which should be responsible for choosing
random address or handling entropy;
3. Memory fragmentation is unpredictable in this case
Off course user mode could use random ‘hint’ address, but kernel may
discard this address if it is occupied for example and allocate just before
closest vma. So this solution doesn’t give that much security like
randomization address inside kernel.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 17:55 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:55 UTC (permalink / raw)
To: Matthew Wilcox
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, ralf,
jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
>=20
> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>> Current implementation doesn't randomize address returned by mmap.
>> All the entropy ends with choosing mmap_base_addr at the process
>> creation. After that mmap build very predictable layout of address
>> space. It allows to bypass ASLR in many cases. This patch make
>> randomization of address on any mmap call.
>=20
> Why should this be done in the kernel rather than libc? libc is =
perfectly
> capable of specifying random numbers in the first argument of mmap.
Well, there is following reasons:
1. It should be done in any libc implementation, what is not possible =
IMO;
2. User mode is not that layer which should be responsible for choosing
random address or handling entropy;
3. Memory fragmentation is unpredictable in this case
Off course user mode could use random =E2=80=98hint=E2=80=99 address, =
but kernel may
discard this address if it is occupied for example and allocate just =
before
closest vma. So this solution doesn=E2=80=99t give that much security =
like=20
randomization address inside kernel.=
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 17:55 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:55 UTC (permalink / raw)
To: linux-snps-arc
> On 23 Mar 2018,@15:48, Matthew Wilcox <willy@infradead.org> wrote:
>
> On Thu, Mar 22, 2018@07:36:36PM +0300, Ilya Smith wrote:
>> Current implementation doesn't randomize address returned by mmap.
>> All the entropy ends with choosing mmap_base_addr at the process
>> creation. After that mmap build very predictable layout of address
>> space. It allows to bypass ASLR in many cases. This patch make
>> randomization of address on any mmap call.
>
> Why should this be done in the kernel rather than libc? libc is perfectly
> capable of specifying random numbers in the first argument of mmap.
Well, there is following reasons:
1. It should be done in any libc implementation, what is not possible IMO;
2. User mode is not that layer which should be responsible for choosing
random address or handling entropy;
3. Memory fragmentation is unpredictable in this case
Off course user mode could use random ?hint? address, but kernel may
discard this address if it is occupied for example and allocate just before
closest vma. So this solution doesn?t give that much security like
randomization address inside kernel.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 17:55 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-23 17:55 UTC (permalink / raw)
To: Matthew Wilcox
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, ralf,
jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal
> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
>
> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>> Current implementation doesn't randomize address returned by mmap.
>> All the entropy ends with choosing mmap_base_addr at the process
>> creation. After that mmap build very predictable layout of address
>> space. It allows to bypass ASLR in many cases. This patch make
>> randomization of address on any mmap call.
>
> Why should this be done in the kernel rather than libc? libc is perfectly
> capable of specifying random numbers in the first argument of mmap.
Well, there is following reasons:
1. It should be done in any libc implementation, what is not possible IMO;
2. User mode is not that layer which should be responsible for choosing
random address or handling entropy;
3. Memory fragmentation is unpredictable in this case
Off course user mode could use random ‘hint’ address, but kernel may
discard this address if it is occupied for example and allocate just before
closest vma. So this solution doesn’t give that much security like
randomization address inside kernel.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-23 12:48 ` Matthew Wilcox
` (2 preceding siblings ...)
(?)
@ 2018-03-23 18:00 ` Rich Felker
-1 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-23 18:00 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Ilya Smith, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, jhogan, ralf, jejb, deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, davem, tglx, mingo, hpa, x86,
nyc, viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote:
> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> > Current implementation doesn't randomize address returned by mmap.
> > All the entropy ends with choosing mmap_base_addr at the process
> > creation. After that mmap build very predictable layout of address
> > space. It allows to bypass ASLR in many cases. This patch make
> > randomization of address on any mmap call.
>
> Why should this be done in the kernel rather than libc? libc is perfectly
> capable of specifying random numbers in the first argument of mmap.
Generally libc does not have a view of the current vm maps, and thus
in passing "random numbers", they would have to be uniform across the
whole vm space and thus non-uniform once the kernel rounds up to avoid
existing mappings. Also this would impose requirements that libc be
aware of the kernel's use of the virtual address space and what's
available to userspace -- for example, on 32-bit archs whether 2GB,
3GB, or full 4GB (for 32-bit-user-on-64-bit-kernel) is available, and
on 64-bit archs where fewer than the full 64 bits are actually valid
in addresses, what the actual usable pointer size is. There is
currently no clean way of conveying this information to userspace.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 18:00 ` Rich Felker
0 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-23 18:00 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Ilya Smith, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, jhogan, ralf, jejb, deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, davem, tglx, mingo, hpa, x86,
nyc, viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton
On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote:
> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> > Current implementation doesn't randomize address returned by mmap.
> > All the entropy ends with choosing mmap_base_addr at the process
> > creation. After that mmap build very predictable layout of address
> > space. It allows to bypass ASLR in many cases. This patch make
> > randomization of address on any mmap call.
>
> Why should this be done in the kernel rather than libc? libc is perfectly
> capable of specifying random numbers in the first argument of mmap.
Generally libc does not have a view of the current vm maps, and thus
in passing "random numbers", they would have to be uniform across the
whole vm space and thus non-uniform once the kernel rounds up to avoid
existing mappings. Also this would impose requirements that libc be
aware of the kernel's use of the virtual address space and what's
available to userspace -- for example, on 32-bit archs whether 2GB,
3GB, or full 4GB (for 32-bit-user-on-64-bit-kernel) is available, and
on 64-bit archs where fewer than the full 64 bits are actually valid
in addresses, what the actual usable pointer size is. There is
currently no clean way of conveying this information to userspace.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 18:00 ` Rich Felker
0 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-23 18:00 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Ilya Smith, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, jhogan, ralf, jejb, deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, davem, tglx, mingo, hpa, x86,
nyc, viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote:
> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> > Current implementation doesn't randomize address returned by mmap.
> > All the entropy ends with choosing mmap_base_addr at the process
> > creation. After that mmap build very predictable layout of address
> > space. It allows to bypass ASLR in many cases. This patch make
> > randomization of address on any mmap call.
>
> Why should this be done in the kernel rather than libc? libc is perfectly
> capable of specifying random numbers in the first argument of mmap.
Generally libc does not have a view of the current vm maps, and thus
in passing "random numbers", they would have to be uniform across the
whole vm space and thus non-uniform once the kernel rounds up to avoid
existing mappings. Also this would impose requirements that libc be
aware of the kernel's use of the virtual address space and what's
available to userspace -- for example, on 32-bit archs whether 2GB,
3GB, or full 4GB (for 32-bit-user-on-64-bit-kernel) is available, and
on 64-bit archs where fewer than the full 64 bits are actually valid
in addresses, what the actual usable pointer size is. There is
currently no clean way of conveying this information to userspace.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 18:00 ` Rich Felker
0 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-23 18:00 UTC (permalink / raw)
To: linux-snps-arc
On Fri, Mar 23, 2018@05:48:06AM -0700, Matthew Wilcox wrote:
> On Thu, Mar 22, 2018@07:36:36PM +0300, Ilya Smith wrote:
> > Current implementation doesn't randomize address returned by mmap.
> > All the entropy ends with choosing mmap_base_addr at the process
> > creation. After that mmap build very predictable layout of address
> > space. It allows to bypass ASLR in many cases. This patch make
> > randomization of address on any mmap call.
>
> Why should this be done in the kernel rather than libc? libc is perfectly
> capable of specifying random numbers in the first argument of mmap.
Generally libc does not have a view of the current vm maps, and thus
in passing "random numbers", they would have to be uniform across the
whole vm space and thus non-uniform once the kernel rounds up to avoid
existing mappings. Also this would impose requirements that libc be
aware of the kernel's use of the virtual address space and what's
available to userspace -- for example, on 32-bit archs whether 2GB,
3GB, or full 4GB (for 32-bit-user-on-64-bit-kernel) is available, and
on 64-bit archs where fewer than the full 64 bits are actually valid
in addresses, what the actual usable pointer size is. There is
currently no clean way of conveying this information to userspace.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 18:00 ` Rich Felker
0 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-23 18:00 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Ilya Smith, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, jhogan, ralf, jejb, deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, davem, tglx, mingo, hpa, x86,
nyc, viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton
On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote:
> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> > Current implementation doesn't randomize address returned by mmap.
> > All the entropy ends with choosing mmap_base_addr at the process
> > creation. After that mmap build very predictable layout of address
> > space. It allows to bypass ASLR in many cases. This patch make
> > randomization of address on any mmap call.
>
> Why should this be done in the kernel rather than libc? libc is perfectly
> capable of specifying random numbers in the first argument of mmap.
Generally libc does not have a view of the current vm maps, and thus
in passing "random numbers", they would have to be uniform across the
whole vm space and thus non-uniform once the kernel rounds up to avoid
existing mappings. Also this would impose requirements that libc be
aware of the kernel's use of the virtual address space and what's
available to userspace -- for example, on 32-bit archs whether 2GB,
3GB, or full 4GB (for 32-bit-user-on-64-bit-kernel) is available, and
on 64-bit archs where fewer than the full 64 bits are actually valid
in addresses, what the actual usable pointer size is. There is
currently no clean way of conveying this information to userspace.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-23 18:00 ` Rich Felker
(?)
(?)
@ 2018-03-23 19:06 ` Matthew Wilcox
-1 siblings, 0 replies; 185+ messages in thread
From: Matthew Wilcox @ 2018-03-23 19:06 UTC (permalink / raw)
To: Rich Felker
Cc: Ilya Smith, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, jhogan, ralf, jejb, deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, davem, tglx, mingo, hpa, x86,
nyc, viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
On Fri, Mar 23, 2018 at 02:00:24PM -0400, Rich Felker wrote:
> On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote:
> > On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> > > Current implementation doesn't randomize address returned by mmap.
> > > All the entropy ends with choosing mmap_base_addr at the process
> > > creation. After that mmap build very predictable layout of address
> > > space. It allows to bypass ASLR in many cases. This patch make
> > > randomization of address on any mmap call.
> >
> > Why should this be done in the kernel rather than libc? libc is perfectly
> > capable of specifying random numbers in the first argument of mmap.
>
> Generally libc does not have a view of the current vm maps, and thus
> in passing "random numbers", they would have to be uniform across the
> whole vm space and thus non-uniform once the kernel rounds up to avoid
> existing mappings.
I'm aware that you're the musl author, but glibc somehow manages to
provide etext, edata and end, demonstrating that it does know where at
least some of the memory map lies. Virtually everything after that is
brought into the address space via mmap, which at least glibc intercepts,
so it's entirely possible for a security-conscious libc to know where
other things are in the memory map. Not to mention that what we're
primarily talking about here are libraries which are dynamically linked
and are loaded by ld.so before calling main(); not dlopen() or even
regular user mmaps.
> Also this would impose requirements that libc be
> aware of the kernel's use of the virtual address space and what's
> available to userspace -- for example, on 32-bit archs whether 2GB,
> 3GB, or full 4GB (for 32-bit-user-on-64-bit-kernel) is available, and
> on 64-bit archs where fewer than the full 64 bits are actually valid
> in addresses, what the actual usable pointer size is. There is
> currently no clean way of conveying this information to userspace.
Huh, I thought libc was aware of this. Also, I'd expect a libc-based
implementation to restrict itself to, eg, only loading libraries in
the bottom 1GB to avoid applications who want to map huge things from
running out of unfragmented address space.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 19:06 ` Matthew Wilcox
0 siblings, 0 replies; 185+ messages in thread
From: Matthew Wilcox @ 2018-03-23 19:06 UTC (permalink / raw)
To: Rich Felker
Cc: kstewart, linux-mips, mhocko, jack, linux-sh, Ilya Smith, benh,
bhsharma, heiko.carstens, jejb, linux-mm, paulus, deepa.kernel,
hpa, sparclinux, linux-ia64, dan.j.williams, aarcange,
linux-s390, ysato, mpe, deller, x86, hughd, linux, nitin.m.gupta,
linux-alpha, mingo, jhogan, mattst88, linux-snps-arc, fenghua.yu,
riel, punit.agrawal, keescook, arnd, pombredanne, npiggin,
jglisse, in
On Fri, Mar 23, 2018 at 02:00:24PM -0400, Rich Felker wrote:
> On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote:
> > On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> > > Current implementation doesn't randomize address returned by mmap.
> > > All the entropy ends with choosing mmap_base_addr at the process
> > > creation. After that mmap build very predictable layout of address
> > > space. It allows to bypass ASLR in many cases. This patch make
> > > randomization of address on any mmap call.
> >
> > Why should this be done in the kernel rather than libc? libc is perfectly
> > capable of specifying random numbers in the first argument of mmap.
>
> Generally libc does not have a view of the current vm maps, and thus
> in passing "random numbers", they would have to be uniform across the
> whole vm space and thus non-uniform once the kernel rounds up to avoid
> existing mappings.
I'm aware that you're the musl author, but glibc somehow manages to
provide etext, edata and end, demonstrating that it does know where at
least some of the memory map lies. Virtually everything after that is
brought into the address space via mmap, which at least glibc intercepts,
so it's entirely possible for a security-conscious libc to know where
other things are in the memory map. Not to mention that what we're
primarily talking about here are libraries which are dynamically linked
and are loaded by ld.so before calling main(); not dlopen() or even
regular user mmaps.
> Also this would impose requirements that libc be
> aware of the kernel's use of the virtual address space and what's
> available to userspace -- for example, on 32-bit archs whether 2GB,
> 3GB, or full 4GB (for 32-bit-user-on-64-bit-kernel) is available, and
> on 64-bit archs where fewer than the full 64 bits are actually valid
> in addresses, what the actual usable pointer size is. There is
> currently no clean way of conveying this information to userspace.
Huh, I thought libc was aware of this. Also, I'd expect a libc-based
implementation to restrict itself to, eg, only loading libraries in
the bottom 1GB to avoid applications who want to map huge things from
running out of unfragmented address space.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 19:06 ` Matthew Wilcox
0 siblings, 0 replies; 185+ messages in thread
From: Matthew Wilcox @ 2018-03-23 19:06 UTC (permalink / raw)
To: Rich Felker
Cc: Ilya Smith, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, jhogan, ralf, jejb, deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, davem, tglx, mingo, hpa, x86,
nyc, viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
On Fri, Mar 23, 2018 at 02:00:24PM -0400, Rich Felker wrote:
> On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote:
> > On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> > > Current implementation doesn't randomize address returned by mmap.
> > > All the entropy ends with choosing mmap_base_addr at the process
> > > creation. After that mmap build very predictable layout of address
> > > space. It allows to bypass ASLR in many cases. This patch make
> > > randomization of address on any mmap call.
> >
> > Why should this be done in the kernel rather than libc? libc is perfectly
> > capable of specifying random numbers in the first argument of mmap.
>
> Generally libc does not have a view of the current vm maps, and thus
> in passing "random numbers", they would have to be uniform across the
> whole vm space and thus non-uniform once the kernel rounds up to avoid
> existing mappings.
I'm aware that you're the musl author, but glibc somehow manages to
provide etext, edata and end, demonstrating that it does know where at
least some of the memory map lies. Virtually everything after that is
brought into the address space via mmap, which at least glibc intercepts,
so it's entirely possible for a security-conscious libc to know where
other things are in the memory map. Not to mention that what we're
primarily talking about here are libraries which are dynamically linked
and are loaded by ld.so before calling main(); not dlopen() or even
regular user mmaps.
> Also this would impose requirements that libc be
> aware of the kernel's use of the virtual address space and what's
> available to userspace -- for example, on 32-bit archs whether 2GB,
> 3GB, or full 4GB (for 32-bit-user-on-64-bit-kernel) is available, and
> on 64-bit archs where fewer than the full 64 bits are actually valid
> in addresses, what the actual usable pointer size is. There is
> currently no clean way of conveying this information to userspace.
Huh, I thought libc was aware of this. Also, I'd expect a libc-based
implementation to restrict itself to, eg, only loading libraries in
the bottom 1GB to avoid applications who want to map huge things from
running out of unfragmented address space.
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 19:06 ` Matthew Wilcox
0 siblings, 0 replies; 185+ messages in thread
From: Matthew Wilcox @ 2018-03-23 19:06 UTC (permalink / raw)
To: linux-snps-arc
On Fri, Mar 23, 2018@02:00:24PM -0400, Rich Felker wrote:
> On Fri, Mar 23, 2018@05:48:06AM -0700, Matthew Wilcox wrote:
> > On Thu, Mar 22, 2018@07:36:36PM +0300, Ilya Smith wrote:
> > > Current implementation doesn't randomize address returned by mmap.
> > > All the entropy ends with choosing mmap_base_addr at the process
> > > creation. After that mmap build very predictable layout of address
> > > space. It allows to bypass ASLR in many cases. This patch make
> > > randomization of address on any mmap call.
> >
> > Why should this be done in the kernel rather than libc? libc is perfectly
> > capable of specifying random numbers in the first argument of mmap.
>
> Generally libc does not have a view of the current vm maps, and thus
> in passing "random numbers", they would have to be uniform across the
> whole vm space and thus non-uniform once the kernel rounds up to avoid
> existing mappings.
I'm aware that you're the musl author, but glibc somehow manages to
provide etext, edata and end, demonstrating that it does know where at
least some of the memory map lies. Virtually everything after that is
brought into the address space via mmap, which at least glibc intercepts,
so it's entirely possible for a security-conscious libc to know where
other things are in the memory map. Not to mention that what we're
primarily talking about here are libraries which are dynamically linked
and are loaded by ld.so before calling main(); not dlopen() or even
regular user mmaps.
> Also this would impose requirements that libc be
> aware of the kernel's use of the virtual address space and what's
> available to userspace -- for example, on 32-bit archs whether 2GB,
> 3GB, or full 4GB (for 32-bit-user-on-64-bit-kernel) is available, and
> on 64-bit archs where fewer than the full 64 bits are actually valid
> in addresses, what the actual usable pointer size is. There is
> currently no clean way of conveying this information to userspace.
Huh, I thought libc was aware of this. Also, I'd expect a libc-based
implementation to restrict itself to, eg, only loading libraries in
the bottom 1GB to avoid applications who want to map huge things from
running out of unfragmented address space.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-23 19:06 ` Matthew Wilcox
` (2 preceding siblings ...)
(?)
@ 2018-03-23 19:16 ` Rich Felker
-1 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-23 19:16 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Ilya Smith, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, jhogan, ralf, jejb, deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, davem, tglx, mingo, hpa, x86,
nyc, viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
On Fri, Mar 23, 2018 at 12:06:18PM -0700, Matthew Wilcox wrote:
> On Fri, Mar 23, 2018 at 02:00:24PM -0400, Rich Felker wrote:
> > On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote:
> > > On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> > > > Current implementation doesn't randomize address returned by mmap.
> > > > All the entropy ends with choosing mmap_base_addr at the process
> > > > creation. After that mmap build very predictable layout of address
> > > > space. It allows to bypass ASLR in many cases. This patch make
> > > > randomization of address on any mmap call.
> > >
> > > Why should this be done in the kernel rather than libc? libc is perfectly
> > > capable of specifying random numbers in the first argument of mmap.
> >
> > Generally libc does not have a view of the current vm maps, and thus
> > in passing "random numbers", they would have to be uniform across the
> > whole vm space and thus non-uniform once the kernel rounds up to avoid
> > existing mappings.
>
> I'm aware that you're the musl author, but glibc somehow manages to
> provide etext, edata and end, demonstrating that it does know where at
> least some of the memory map lies.
Yes, but that's pretty minimal info.
> Virtually everything after that is
> brought into the address space via mmap, which at least glibc intercepts,
There's also vdso, the program interpreter (ldso), and theoretically
other things the kernel might add. I agree you _could_ track most of
this (and all if you want to open /proc/self/maps), but it seems
hackish and wrong (violating clean boundaries between userspace and
kernel responsibility).
> > Also this would impose requirements that libc be
> > aware of the kernel's use of the virtual address space and what's
> > available to userspace -- for example, on 32-bit archs whether 2GB,
> > 3GB, or full 4GB (for 32-bit-user-on-64-bit-kernel) is available, and
> > on 64-bit archs where fewer than the full 64 bits are actually valid
> > in addresses, what the actual usable pointer size is. There is
> > currently no clean way of conveying this information to userspace.
>
> Huh, I thought libc was aware of this. Also, I'd expect a libc-based
> implementation to restrict itself to, eg, only loading libraries in
> the bottom 1GB to avoid applications who want to map huge things from
> running out of unfragmented address space.
That seems like a rather arbitrary expectation and I'm not sure why
you'd expect it to result in less fragmentation rather than more. For
example if it started from 1GB and worked down, you'd immediately
reduce the contiguous free space from ~3GB to ~2GB, and if it started
from the bottom and worked up, brk would immediately become
unavailable, increasing mmap pressure elsewhere.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 19:16 ` Rich Felker
0 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-23 19:16 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Ilya Smith, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, jhogan, ralf, jejb, deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, davem, tglx, mingo, hpa, x86,
nyc, viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton
On Fri, Mar 23, 2018 at 12:06:18PM -0700, Matthew Wilcox wrote:
> On Fri, Mar 23, 2018 at 02:00:24PM -0400, Rich Felker wrote:
> > On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote:
> > > On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> > > > Current implementation doesn't randomize address returned by mmap.
> > > > All the entropy ends with choosing mmap_base_addr at the process
> > > > creation. After that mmap build very predictable layout of address
> > > > space. It allows to bypass ASLR in many cases. This patch make
> > > > randomization of address on any mmap call.
> > >
> > > Why should this be done in the kernel rather than libc? libc is perfectly
> > > capable of specifying random numbers in the first argument of mmap.
> >
> > Generally libc does not have a view of the current vm maps, and thus
> > in passing "random numbers", they would have to be uniform across the
> > whole vm space and thus non-uniform once the kernel rounds up to avoid
> > existing mappings.
>
> I'm aware that you're the musl author, but glibc somehow manages to
> provide etext, edata and end, demonstrating that it does know where at
> least some of the memory map lies.
Yes, but that's pretty minimal info.
> Virtually everything after that is
> brought into the address space via mmap, which at least glibc intercepts,
There's also vdso, the program interpreter (ldso), and theoretically
other things the kernel might add. I agree you _could_ track most of
this (and all if you want to open /proc/self/maps), but it seems
hackish and wrong (violating clean boundaries between userspace and
kernel responsibility).
> > Also this would impose requirements that libc be
> > aware of the kernel's use of the virtual address space and what's
> > available to userspace -- for example, on 32-bit archs whether 2GB,
> > 3GB, or full 4GB (for 32-bit-user-on-64-bit-kernel) is available, and
> > on 64-bit archs where fewer than the full 64 bits are actually valid
> > in addresses, what the actual usable pointer size is. There is
> > currently no clean way of conveying this information to userspace.
>
> Huh, I thought libc was aware of this. Also, I'd expect a libc-based
> implementation to restrict itself to, eg, only loading libraries in
> the bottom 1GB to avoid applications who want to map huge things from
> running out of unfragmented address space.
That seems like a rather arbitrary expectation and I'm not sure why
you'd expect it to result in less fragmentation rather than more. For
example if it started from 1GB and worked down, you'd immediately
reduce the contiguous free space from ~3GB to ~2GB, and if it started
from the bottom and worked up, brk would immediately become
unavailable, increasing mmap pressure elsewhere.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 19:16 ` Rich Felker
0 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-23 19:16 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Ilya Smith, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, jhogan, ralf, jejb, deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, davem, tglx, mingo, hpa, x86,
nyc, viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
On Fri, Mar 23, 2018 at 12:06:18PM -0700, Matthew Wilcox wrote:
> On Fri, Mar 23, 2018 at 02:00:24PM -0400, Rich Felker wrote:
> > On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote:
> > > On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> > > > Current implementation doesn't randomize address returned by mmap.
> > > > All the entropy ends with choosing mmap_base_addr at the process
> > > > creation. After that mmap build very predictable layout of address
> > > > space. It allows to bypass ASLR in many cases. This patch make
> > > > randomization of address on any mmap call.
> > >
> > > Why should this be done in the kernel rather than libc? libc is perfectly
> > > capable of specifying random numbers in the first argument of mmap.
> >
> > Generally libc does not have a view of the current vm maps, and thus
> > in passing "random numbers", they would have to be uniform across the
> > whole vm space and thus non-uniform once the kernel rounds up to avoid
> > existing mappings.
>
> I'm aware that you're the musl author, but glibc somehow manages to
> provide etext, edata and end, demonstrating that it does know where at
> least some of the memory map lies.
Yes, but that's pretty minimal info.
> Virtually everything after that is
> brought into the address space via mmap, which at least glibc intercepts,
There's also vdso, the program interpreter (ldso), and theoretically
other things the kernel might add. I agree you _could_ track most of
this (and all if you want to open /proc/self/maps), but it seems
hackish and wrong (violating clean boundaries between userspace and
kernel responsibility).
> > Also this would impose requirements that libc be
> > aware of the kernel's use of the virtual address space and what's
> > available to userspace -- for example, on 32-bit archs whether 2GB,
> > 3GB, or full 4GB (for 32-bit-user-on-64-bit-kernel) is available, and
> > on 64-bit archs where fewer than the full 64 bits are actually valid
> > in addresses, what the actual usable pointer size is. There is
> > currently no clean way of conveying this information to userspace.
>
> Huh, I thought libc was aware of this. Also, I'd expect a libc-based
> implementation to restrict itself to, eg, only loading libraries in
> the bottom 1GB to avoid applications who want to map huge things from
> running out of unfragmented address space.
That seems like a rather arbitrary expectation and I'm not sure why
you'd expect it to result in less fragmentation rather than more. For
example if it started from 1GB and worked down, you'd immediately
reduce the contiguous free space from ~3GB to ~2GB, and if it started
from the bottom and worked up, brk would immediately become
unavailable, increasing mmap pressure elsewhere.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 19:16 ` Rich Felker
0 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-23 19:16 UTC (permalink / raw)
To: linux-snps-arc
On Fri, Mar 23, 2018@12:06:18PM -0700, Matthew Wilcox wrote:
> On Fri, Mar 23, 2018@02:00:24PM -0400, Rich Felker wrote:
> > On Fri, Mar 23, 2018@05:48:06AM -0700, Matthew Wilcox wrote:
> > > On Thu, Mar 22, 2018@07:36:36PM +0300, Ilya Smith wrote:
> > > > Current implementation doesn't randomize address returned by mmap.
> > > > All the entropy ends with choosing mmap_base_addr at the process
> > > > creation. After that mmap build very predictable layout of address
> > > > space. It allows to bypass ASLR in many cases. This patch make
> > > > randomization of address on any mmap call.
> > >
> > > Why should this be done in the kernel rather than libc? libc is perfectly
> > > capable of specifying random numbers in the first argument of mmap.
> >
> > Generally libc does not have a view of the current vm maps, and thus
> > in passing "random numbers", they would have to be uniform across the
> > whole vm space and thus non-uniform once the kernel rounds up to avoid
> > existing mappings.
>
> I'm aware that you're the musl author, but glibc somehow manages to
> provide etext, edata and end, demonstrating that it does know where at
> least some of the memory map lies.
Yes, but that's pretty minimal info.
> Virtually everything after that is
> brought into the address space via mmap, which at least glibc intercepts,
There's also vdso, the program interpreter (ldso), and theoretically
other things the kernel might add. I agree you _could_ track most of
this (and all if you want to open /proc/self/maps), but it seems
hackish and wrong (violating clean boundaries between userspace and
kernel responsibility).
> > Also this would impose requirements that libc be
> > aware of the kernel's use of the virtual address space and what's
> > available to userspace -- for example, on 32-bit archs whether 2GB,
> > 3GB, or full 4GB (for 32-bit-user-on-64-bit-kernel) is available, and
> > on 64-bit archs where fewer than the full 64 bits are actually valid
> > in addresses, what the actual usable pointer size is. There is
> > currently no clean way of conveying this information to userspace.
>
> Huh, I thought libc was aware of this. Also, I'd expect a libc-based
> implementation to restrict itself to, eg, only loading libraries in
> the bottom 1GB to avoid applications who want to map huge things from
> running out of unfragmented address space.
That seems like a rather arbitrary expectation and I'm not sure why
you'd expect it to result in less fragmentation rather than more. For
example if it started from 1GB and worked down, you'd immediately
reduce the contiguous free space from ~3GB to ~2GB, and if it started
from the bottom and worked up, brk would immediately become
unavailable, increasing mmap pressure elsewhere.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 19:16 ` Rich Felker
0 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-23 19:16 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Ilya Smith, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, jhogan, ralf, jejb, deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, davem, tglx, mingo, hpa, x86,
nyc, viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton
On Fri, Mar 23, 2018 at 12:06:18PM -0700, Matthew Wilcox wrote:
> On Fri, Mar 23, 2018 at 02:00:24PM -0400, Rich Felker wrote:
> > On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote:
> > > On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> > > > Current implementation doesn't randomize address returned by mmap.
> > > > All the entropy ends with choosing mmap_base_addr at the process
> > > > creation. After that mmap build very predictable layout of address
> > > > space. It allows to bypass ASLR in many cases. This patch make
> > > > randomization of address on any mmap call.
> > >
> > > Why should this be done in the kernel rather than libc? libc is perfectly
> > > capable of specifying random numbers in the first argument of mmap.
> >
> > Generally libc does not have a view of the current vm maps, and thus
> > in passing "random numbers", they would have to be uniform across the
> > whole vm space and thus non-uniform once the kernel rounds up to avoid
> > existing mappings.
>
> I'm aware that you're the musl author, but glibc somehow manages to
> provide etext, edata and end, demonstrating that it does know where at
> least some of the memory map lies.
Yes, but that's pretty minimal info.
> Virtually everything after that is
> brought into the address space via mmap, which at least glibc intercepts,
There's also vdso, the program interpreter (ldso), and theoretically
other things the kernel might add. I agree you _could_ track most of
this (and all if you want to open /proc/self/maps), but it seems
hackish and wrong (violating clean boundaries between userspace and
kernel responsibility).
> > Also this would impose requirements that libc be
> > aware of the kernel's use of the virtual address space and what's
> > available to userspace -- for example, on 32-bit archs whether 2GB,
> > 3GB, or full 4GB (for 32-bit-user-on-64-bit-kernel) is available, and
> > on 64-bit archs where fewer than the full 64 bits are actually valid
> > in addresses, what the actual usable pointer size is. There is
> > currently no clean way of conveying this information to userspace.
>
> Huh, I thought libc was aware of this. Also, I'd expect a libc-based
> implementation to restrict itself to, eg, only loading libraries in
> the bottom 1GB to avoid applications who want to map huge things from
> running out of unfragmented address space.
That seems like a rather arbitrary expectation and I'm not sure why
you'd expect it to result in less fragmentation rather than more. For
example if it started from 1GB and worked down, you'd immediately
reduce the contiguous free space from ~3GB to ~2GB, and if it started
from the bottom and worked up, brk would immediately become
unavailable, increasing mmap pressure elsewhere.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-23 19:16 ` Rich Felker
(?)
(?)
@ 2018-03-23 19:29 ` Matthew Wilcox
-1 siblings, 0 replies; 185+ messages in thread
From: Matthew Wilcox @ 2018-03-23 19:29 UTC (permalink / raw)
To: Rich Felker
Cc: Ilya Smith, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, jhogan, ralf, jejb, deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, davem, tglx, mingo, hpa, x86,
nyc, viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
On Fri, Mar 23, 2018 at 03:16:21PM -0400, Rich Felker wrote:
> > Huh, I thought libc was aware of this. Also, I'd expect a libc-based
> > implementation to restrict itself to, eg, only loading libraries in
> > the bottom 1GB to avoid applications who want to map huge things from
> > running out of unfragmented address space.
>
> That seems like a rather arbitrary expectation and I'm not sure why
> you'd expect it to result in less fragmentation rather than more. For
> example if it started from 1GB and worked down, you'd immediately
> reduce the contiguous free space from ~3GB to ~2GB, and if it started
> from the bottom and worked up, brk would immediately become
> unavailable, increasing mmap pressure elsewhere.
By *not* limiting yourself to the bottom 1GB, you'll almost immediately
fragment the address space even worse. Just looking at 'ls' as a
hopefully-good example of a typical app, it maps:
linux-vdso.so.1 (0x00007ffef5eef000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fb3657f5000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb36543b000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fb3651c9000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb364fc5000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb365c3f000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb364da7000)
The VDSO wouldn't move, but look at the distribution of mapping 6 things
into a 3GB address space in random locations. What are the odds you have
a contiguous 1GB chunk of address space? If you restrict yourself to the
bottom 1GB before running out of room and falling back to a sequential
allocation, you'll prevent a lot of fragmentation.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 19:29 ` Matthew Wilcox
0 siblings, 0 replies; 185+ messages in thread
From: Matthew Wilcox @ 2018-03-23 19:29 UTC (permalink / raw)
To: Rich Felker
Cc: kstewart, linux-mips, mhocko, jack, linux-sh, Ilya Smith, benh,
bhsharma, heiko.carstens, jejb, linux-mm, paulus, deepa.kernel,
hpa, sparclinux, linux-ia64, dan.j.williams, aarcange,
linux-s390, ysato, mpe, deller, x86, hughd, linux, nitin.m.gupta,
linux-alpha, mingo, jhogan, mattst88, linux-snps-arc, fenghua.yu,
riel, punit.agrawal, keescook, arnd, pombredanne, npiggin,
jglisse, in
On Fri, Mar 23, 2018 at 03:16:21PM -0400, Rich Felker wrote:
> > Huh, I thought libc was aware of this. Also, I'd expect a libc-based
> > implementation to restrict itself to, eg, only loading libraries in
> > the bottom 1GB to avoid applications who want to map huge things from
> > running out of unfragmented address space.
>
> That seems like a rather arbitrary expectation and I'm not sure why
> you'd expect it to result in less fragmentation rather than more. For
> example if it started from 1GB and worked down, you'd immediately
> reduce the contiguous free space from ~3GB to ~2GB, and if it started
> from the bottom and worked up, brk would immediately become
> unavailable, increasing mmap pressure elsewhere.
By *not* limiting yourself to the bottom 1GB, you'll almost immediately
fragment the address space even worse. Just looking at 'ls' as a
hopefully-good example of a typical app, it maps:
linux-vdso.so.1 (0x00007ffef5eef000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fb3657f5000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb36543b000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fb3651c9000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb364fc5000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb365c3f000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb364da7000)
The VDSO wouldn't move, but look at the distribution of mapping 6 things
into a 3GB address space in random locations. What are the odds you have
a contiguous 1GB chunk of address space? If you restrict yourself to the
bottom 1GB before running out of room and falling back to a sequential
allocation, you'll prevent a lot of fragmentation.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 19:29 ` Matthew Wilcox
0 siblings, 0 replies; 185+ messages in thread
From: Matthew Wilcox @ 2018-03-23 19:29 UTC (permalink / raw)
To: Rich Felker
Cc: Ilya Smith, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, jhogan, ralf, jejb, deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, davem, tglx, mingo, hpa, x86,
nyc, viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
On Fri, Mar 23, 2018 at 03:16:21PM -0400, Rich Felker wrote:
> > Huh, I thought libc was aware of this. Also, I'd expect a libc-based
> > implementation to restrict itself to, eg, only loading libraries in
> > the bottom 1GB to avoid applications who want to map huge things from
> > running out of unfragmented address space.
>
> That seems like a rather arbitrary expectation and I'm not sure why
> you'd expect it to result in less fragmentation rather than more. For
> example if it started from 1GB and worked down, you'd immediately
> reduce the contiguous free space from ~3GB to ~2GB, and if it started
> from the bottom and worked up, brk would immediately become
> unavailable, increasing mmap pressure elsewhere.
By *not* limiting yourself to the bottom 1GB, you'll almost immediately
fragment the address space even worse. Just looking at 'ls' as a
hopefully-good example of a typical app, it maps:
linux-vdso.so.1 (0x00007ffef5eef000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fb3657f5000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb36543b000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fb3651c9000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb364fc5000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb365c3f000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb364da7000)
The VDSO wouldn't move, but look at the distribution of mapping 6 things
into a 3GB address space in random locations. What are the odds you have
a contiguous 1GB chunk of address space? If you restrict yourself to the
bottom 1GB before running out of room and falling back to a sequential
allocation, you'll prevent a lot of fragmentation.
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 19:29 ` Matthew Wilcox
0 siblings, 0 replies; 185+ messages in thread
From: Matthew Wilcox @ 2018-03-23 19:29 UTC (permalink / raw)
To: linux-snps-arc
On Fri, Mar 23, 2018@03:16:21PM -0400, Rich Felker wrote:
> > Huh, I thought libc was aware of this. Also, I'd expect a libc-based
> > implementation to restrict itself to, eg, only loading libraries in
> > the bottom 1GB to avoid applications who want to map huge things from
> > running out of unfragmented address space.
>
> That seems like a rather arbitrary expectation and I'm not sure why
> you'd expect it to result in less fragmentation rather than more. For
> example if it started from 1GB and worked down, you'd immediately
> reduce the contiguous free space from ~3GB to ~2GB, and if it started
> from the bottom and worked up, brk would immediately become
> unavailable, increasing mmap pressure elsewhere.
By *not* limiting yourself to the bottom 1GB, you'll almost immediately
fragment the address space even worse. Just looking at 'ls' as a
hopefully-good example of a typical app, it maps:
linux-vdso.so.1 (0x00007ffef5eef000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fb3657f5000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb36543b000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fb3651c9000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb364fc5000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb365c3f000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb364da7000)
The VDSO wouldn't move, but look at the distribution of mapping 6 things
into a 3GB address space in random locations. What are the odds you have
a contiguous 1GB chunk of address space? If you restrict yourself to the
bottom 1GB before running out of room and falling back to a sequential
allocation, you'll prevent a lot of fragmentation.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-23 19:29 ` Matthew Wilcox
` (2 preceding siblings ...)
(?)
@ 2018-03-23 19:35 ` Rich Felker
-1 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-23 19:35 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Ilya Smith, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, jhogan, ralf, jejb, deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, davem, tglx, mingo, hpa, x86,
nyc, viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
On Fri, Mar 23, 2018 at 12:29:52PM -0700, Matthew Wilcox wrote:
> On Fri, Mar 23, 2018 at 03:16:21PM -0400, Rich Felker wrote:
> > > Huh, I thought libc was aware of this. Also, I'd expect a libc-based
> > > implementation to restrict itself to, eg, only loading libraries in
> > > the bottom 1GB to avoid applications who want to map huge things from
> > > running out of unfragmented address space.
> >
> > That seems like a rather arbitrary expectation and I'm not sure why
> > you'd expect it to result in less fragmentation rather than more. For
> > example if it started from 1GB and worked down, you'd immediately
> > reduce the contiguous free space from ~3GB to ~2GB, and if it started
> > from the bottom and worked up, brk would immediately become
> > unavailable, increasing mmap pressure elsewhere.
>
> By *not* limiting yourself to the bottom 1GB, you'll almost immediately
> fragment the address space even worse. Just looking at 'ls' as a
> hopefully-good example of a typical app, it maps:
>
> linux-vdso.so.1 (0x00007ffef5eef000)
> libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fb3657f5000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb36543b000)
> libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fb3651c9000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb364fc5000)
> /lib64/ld-linux-x86-64.so.2 (0x00007fb365c3f000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb364da7000)
>
> The VDSO wouldn't move, but look at the distribution of mapping 6 things
> into a 3GB address space in random locations. What are the odds you have
> a contiguous 1GB chunk of address space? If you restrict yourself to the
> bottom 1GB before running out of room and falling back to a sequential
> allocation, you'll prevent a lot of fragmentation.
Oh, you're talking about "with random locations" case. Randomizing
each map just hopelessly fragments things no matter what you do on
32-bit. If you reduce the space over which you randomize to the point
where it's not fragmenting/killing your available vm space, there are
so few degrees of freedom left that it's trivial to brute-force. Maybe
"libs randomized in low 1GB, everything else near-sequential in high
addresses" works half decently, but I have a hard time believing you
can get any ASLR that's significantly better than snake oil in a
32-bit address space, and you certainly do pay a high price in total
available vm space.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 19:35 ` Rich Felker
0 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-23 19:35 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Ilya Smith, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, jhogan, ralf, jejb, deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, davem, tglx, mingo, hpa, x86,
nyc, viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton
On Fri, Mar 23, 2018 at 12:29:52PM -0700, Matthew Wilcox wrote:
> On Fri, Mar 23, 2018 at 03:16:21PM -0400, Rich Felker wrote:
> > > Huh, I thought libc was aware of this. Also, I'd expect a libc-based
> > > implementation to restrict itself to, eg, only loading libraries in
> > > the bottom 1GB to avoid applications who want to map huge things from
> > > running out of unfragmented address space.
> >
> > That seems like a rather arbitrary expectation and I'm not sure why
> > you'd expect it to result in less fragmentation rather than more. For
> > example if it started from 1GB and worked down, you'd immediately
> > reduce the contiguous free space from ~3GB to ~2GB, and if it started
> > from the bottom and worked up, brk would immediately become
> > unavailable, increasing mmap pressure elsewhere.
>
> By *not* limiting yourself to the bottom 1GB, you'll almost immediately
> fragment the address space even worse. Just looking at 'ls' as a
> hopefully-good example of a typical app, it maps:
>
> linux-vdso.so.1 (0x00007ffef5eef000)
> libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fb3657f5000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb36543b000)
> libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fb3651c9000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb364fc5000)
> /lib64/ld-linux-x86-64.so.2 (0x00007fb365c3f000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb364da7000)
>
> The VDSO wouldn't move, but look at the distribution of mapping 6 things
> into a 3GB address space in random locations. What are the odds you have
> a contiguous 1GB chunk of address space? If you restrict yourself to the
> bottom 1GB before running out of room and falling back to a sequential
> allocation, you'll prevent a lot of fragmentation.
Oh, you're talking about "with random locations" case. Randomizing
each map just hopelessly fragments things no matter what you do on
32-bit. If you reduce the space over which you randomize to the point
where it's not fragmenting/killing your available vm space, there are
so few degrees of freedom left that it's trivial to brute-force. Maybe
"libs randomized in low 1GB, everything else near-sequential in high
addresses" works half decently, but I have a hard time believing you
can get any ASLR that's significantly better than snake oil in a
32-bit address space, and you certainly do pay a high price in total
available vm space.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 19:35 ` Rich Felker
0 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-23 19:35 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Ilya Smith, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, jhogan, ralf, jejb, deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, davem, tglx, mingo, hpa, x86,
nyc, viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
On Fri, Mar 23, 2018 at 12:29:52PM -0700, Matthew Wilcox wrote:
> On Fri, Mar 23, 2018 at 03:16:21PM -0400, Rich Felker wrote:
> > > Huh, I thought libc was aware of this. Also, I'd expect a libc-based
> > > implementation to restrict itself to, eg, only loading libraries in
> > > the bottom 1GB to avoid applications who want to map huge things from
> > > running out of unfragmented address space.
> >
> > That seems like a rather arbitrary expectation and I'm not sure why
> > you'd expect it to result in less fragmentation rather than more. For
> > example if it started from 1GB and worked down, you'd immediately
> > reduce the contiguous free space from ~3GB to ~2GB, and if it started
> > from the bottom and worked up, brk would immediately become
> > unavailable, increasing mmap pressure elsewhere.
>
> By *not* limiting yourself to the bottom 1GB, you'll almost immediately
> fragment the address space even worse. Just looking at 'ls' as a
> hopefully-good example of a typical app, it maps:
>
> linux-vdso.so.1 (0x00007ffef5eef000)
> libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fb3657f5000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb36543b000)
> libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fb3651c9000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb364fc5000)
> /lib64/ld-linux-x86-64.so.2 (0x00007fb365c3f000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb364da7000)
>
> The VDSO wouldn't move, but look at the distribution of mapping 6 things
> into a 3GB address space in random locations. What are the odds you have
> a contiguous 1GB chunk of address space? If you restrict yourself to the
> bottom 1GB before running out of room and falling back to a sequential
> allocation, you'll prevent a lot of fragmentation.
Oh, you're talking about "with random locations" case. Randomizing
each map just hopelessly fragments things no matter what you do on
32-bit. If you reduce the space over which you randomize to the point
where it's not fragmenting/killing your available vm space, there are
so few degrees of freedom left that it's trivial to brute-force. Maybe
"libs randomized in low 1GB, everything else near-sequential in high
addresses" works half decently, but I have a hard time believing you
can get any ASLR that's significantly better than snake oil in a
32-bit address space, and you certainly do pay a high price in total
available vm space.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 19:35 ` Rich Felker
0 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-23 19:35 UTC (permalink / raw)
To: linux-snps-arc
On Fri, Mar 23, 2018@12:29:52PM -0700, Matthew Wilcox wrote:
> On Fri, Mar 23, 2018@03:16:21PM -0400, Rich Felker wrote:
> > > Huh, I thought libc was aware of this. Also, I'd expect a libc-based
> > > implementation to restrict itself to, eg, only loading libraries in
> > > the bottom 1GB to avoid applications who want to map huge things from
> > > running out of unfragmented address space.
> >
> > That seems like a rather arbitrary expectation and I'm not sure why
> > you'd expect it to result in less fragmentation rather than more. For
> > example if it started from 1GB and worked down, you'd immediately
> > reduce the contiguous free space from ~3GB to ~2GB, and if it started
> > from the bottom and worked up, brk would immediately become
> > unavailable, increasing mmap pressure elsewhere.
>
> By *not* limiting yourself to the bottom 1GB, you'll almost immediately
> fragment the address space even worse. Just looking at 'ls' as a
> hopefully-good example of a typical app, it maps:
>
> linux-vdso.so.1 (0x00007ffef5eef000)
> libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fb3657f5000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb36543b000)
> libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fb3651c9000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb364fc5000)
> /lib64/ld-linux-x86-64.so.2 (0x00007fb365c3f000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb364da7000)
>
> The VDSO wouldn't move, but look at the distribution of mapping 6 things
> into a 3GB address space in random locations. What are the odds you have
> a contiguous 1GB chunk of address space? If you restrict yourself to the
> bottom 1GB before running out of room and falling back to a sequential
> allocation, you'll prevent a lot of fragmentation.
Oh, you're talking about "with random locations" case. Randomizing
each map just hopelessly fragments things no matter what you do on
32-bit. If you reduce the space over which you randomize to the point
where it's not fragmenting/killing your available vm space, there are
so few degrees of freedom left that it's trivial to brute-force. Maybe
"libs randomized in low 1GB, everything else near-sequential in high
addresses" works half decently, but I have a hard time believing you
can get any ASLR that's significantly better than snake oil in a
32-bit address space, and you certainly do pay a high price in total
available vm space.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-23 19:35 ` Rich Felker
0 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-23 19:35 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Ilya Smith, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, jhogan, ralf, jejb, deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, davem, tglx, mingo, hpa, x86,
nyc, viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton
On Fri, Mar 23, 2018 at 12:29:52PM -0700, Matthew Wilcox wrote:
> On Fri, Mar 23, 2018 at 03:16:21PM -0400, Rich Felker wrote:
> > > Huh, I thought libc was aware of this. Also, I'd expect a libc-based
> > > implementation to restrict itself to, eg, only loading libraries in
> > > the bottom 1GB to avoid applications who want to map huge things from
> > > running out of unfragmented address space.
> >
> > That seems like a rather arbitrary expectation and I'm not sure why
> > you'd expect it to result in less fragmentation rather than more. For
> > example if it started from 1GB and worked down, you'd immediately
> > reduce the contiguous free space from ~3GB to ~2GB, and if it started
> > from the bottom and worked up, brk would immediately become
> > unavailable, increasing mmap pressure elsewhere.
>
> By *not* limiting yourself to the bottom 1GB, you'll almost immediately
> fragment the address space even worse. Just looking at 'ls' as a
> hopefully-good example of a typical app, it maps:
>
> linux-vdso.so.1 (0x00007ffef5eef000)
> libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fb3657f5000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb36543b000)
> libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fb3651c9000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb364fc5000)
> /lib64/ld-linux-x86-64.so.2 (0x00007fb365c3f000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb364da7000)
>
> The VDSO wouldn't move, but look at the distribution of mapping 6 things
> into a 3GB address space in random locations. What are the odds you have
> a contiguous 1GB chunk of address space? If you restrict yourself to the
> bottom 1GB before running out of room and falling back to a sequential
> allocation, you'll prevent a lot of fragmentation.
Oh, you're talking about "with random locations" case. Randomizing
each map just hopelessly fragments things no matter what you do on
32-bit. If you reduce the space over which you randomize to the point
where it's not fragmenting/killing your available vm space, there are
so few degrees of freedom left that it's trivial to brute-force. Maybe
"libs randomized in low 1GB, everything else near-sequential in high
addresses" works half decently, but I have a hard time believing you
can get any ASLR that's significantly better than snake oil in a
32-bit address space, and you certainly do pay a high price in total
available vm space.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-23 17:55 ` Ilya Smith
` (2 preceding siblings ...)
(?)
@ 2018-03-26 8:46 ` Michal Hocko
-1 siblings, 0 replies; 185+ messages in thread
From: Michal Hocko @ 2018-03-26 8:46 UTC (permalink / raw)
To: Ilya Smith
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>
> > On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> >> Current implementation doesn't randomize address returned by mmap.
> >> All the entropy ends with choosing mmap_base_addr at the process
> >> creation. After that mmap build very predictable layout of address
> >> space. It allows to bypass ASLR in many cases. This patch make
> >> randomization of address on any mmap call.
> >
> > Why should this be done in the kernel rather than libc? libc is perfectly
> > capable of specifying random numbers in the first argument of mmap.
> Well, there is following reasons:
> 1. It should be done in any libc implementation, what is not possible IMO;
Is this really so helpful?
> 2. User mode is not that layer which should be responsible for choosing
> random address or handling entropy;
Why?
> 3. Memory fragmentation is unpredictable in this case
>
> Off course user mode could use random ‘hint’ address, but kernel may
> discard this address if it is occupied for example and allocate just before
> closest vma. So this solution doesn’t give that much security like
> randomization address inside kernel.
The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
address range atomically and chose a different range on failure.
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-26 8:46 ` Michal Hocko
0 siblings, 0 replies; 185+ messages in thread
From: Michal Hocko @ 2018-03-26 8:46 UTC (permalink / raw)
To: Ilya Smith
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal
On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>
> > On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> >> Current implementation doesn't randomize address returned by mmap.
> >> All the entropy ends with choosing mmap_base_addr at the process
> >> creation. After that mmap build very predictable layout of address
> >> space. It allows to bypass ASLR in many cases. This patch make
> >> randomization of address on any mmap call.
> >
> > Why should this be done in the kernel rather than libc? libc is perfectly
> > capable of specifying random numbers in the first argument of mmap.
> Well, there is following reasons:
> 1. It should be done in any libc implementation, what is not possible IMO;
Is this really so helpful?
> 2. User mode is not that layer which should be responsible for choosing
> random address or handling entropy;
Why?
> 3. Memory fragmentation is unpredictable in this case
>
> Off course user mode could use random ‘hint’ address, but kernel may
> discard this address if it is occupied for example and allocate just before
> closest vma. So this solution doesn’t give that much security like
> randomization address inside kernel.
The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
address range atomically and chose a different range on failure.
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-26 8:46 ` Michal Hocko
0 siblings, 0 replies; 185+ messages in thread
From: Michal Hocko @ 2018-03-26 8:46 UTC (permalink / raw)
To: Ilya Smith
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>
> > On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> >> Current implementation doesn't randomize address returned by mmap.
> >> All the entropy ends with choosing mmap_base_addr at the process
> >> creation. After that mmap build very predictable layout of address
> >> space. It allows to bypass ASLR in many cases. This patch make
> >> randomization of address on any mmap call.
> >
> > Why should this be done in the kernel rather than libc? libc is perfectly
> > capable of specifying random numbers in the first argument of mmap.
> Well, there is following reasons:
> 1. It should be done in any libc implementation, what is not possible IMO;
Is this really so helpful?
> 2. User mode is not that layer which should be responsible for choosing
> random address or handling entropy;
Why?
> 3. Memory fragmentation is unpredictable in this case
>
> Off course user mode could use random ‘hint’ address, but kernel may
> discard this address if it is occupied for example and allocate just before
> closest vma. So this solution doesn’t give that much security like
> randomization address inside kernel.
The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
address range atomically and chose a different range on failure.
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-26 8:46 ` Michal Hocko
0 siblings, 0 replies; 185+ messages in thread
From: Michal Hocko @ 2018-03-26 8:46 UTC (permalink / raw)
To: Ilya Smith
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>
> > On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> >> Current implementation doesn't randomize address returned by mmap.
> >> All the entropy ends with choosing mmap_base_addr at the process
> >> creation. After that mmap build very predictable layout of address
> >> space. It allows to bypass ASLR in many cases. This patch make
> >> randomization of address on any mmap call.
> >
> > Why should this be done in the kernel rather than libc? libc is perfectly
> > capable of specifying random numbers in the first argument of mmap.
> Well, there is following reasons:
> 1. It should be done in any libc implementation, what is not possible IMO;
Is this really so helpful?
> 2. User mode is not that layer which should be responsible for choosing
> random address or handling entropy;
Why?
> 3. Memory fragmentation is unpredictable in this case
>
> Off course user mode could use random a??hinta?? address, but kernel may
> discard this address if it is occupied for example and allocate just before
> closest vma. So this solution doesna??t give that much security like
> randomization address inside kernel.
The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
address range atomically and chose a different range on failure.
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-26 8:46 ` Michal Hocko
0 siblings, 0 replies; 185+ messages in thread
From: Michal Hocko @ 2018-03-26 8:46 UTC (permalink / raw)
To: linux-snps-arc
On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>
> > On 23 Mar 2018,@15:48, Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Thu, Mar 22, 2018@07:36:36PM +0300, Ilya Smith wrote:
> >> Current implementation doesn't randomize address returned by mmap.
> >> All the entropy ends with choosing mmap_base_addr at the process
> >> creation. After that mmap build very predictable layout of address
> >> space. It allows to bypass ASLR in many cases. This patch make
> >> randomization of address on any mmap call.
> >
> > Why should this be done in the kernel rather than libc? libc is perfectly
> > capable of specifying random numbers in the first argument of mmap.
> Well, there is following reasons:
> 1. It should be done in any libc implementation, what is not possible IMO;
Is this really so helpful?
> 2. User mode is not that layer which should be responsible for choosing
> random address or handling entropy;
Why?
> 3. Memory fragmentation is unpredictable in this case
>
> Off course user mode could use random ?hint? address, but kernel may
> discard this address if it is occupied for example and allocate just before
> closest vma. So this solution doesn?t give that much security like
> randomization address inside kernel.
The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
address range atomically and chose a different range on failure.
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-26 8:46 ` Michal Hocko
` (3 preceding siblings ...)
(?)
@ 2018-03-26 19:45 ` Ilya Smith
-1 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-26 19:45 UTC (permalink / raw)
To: Michal Hocko
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
>
> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>
>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
>>>
>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>> Current implementation doesn't randomize address returned by mmap.
>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>> creation. After that mmap build very predictable layout of address
>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>> randomization of address on any mmap call.
>>>
>>> Why should this be done in the kernel rather than libc? libc is perfectly
>>> capable of specifying random numbers in the first argument of mmap.
>> Well, there is following reasons:
>> 1. It should be done in any libc implementation, what is not possible IMO;
>
> Is this really so helpful?
Yes, ASLR is one of very important mitigation techniques which are really used
to protect applications. If there is no ASLR, it is very easy to exploit
vulnerable application and compromise the system. We can’t just fix all the
vulnerabilities right now, thats why we have mitigations - techniques which are
makes exploitation more hard or impossible in some cases.
Thats why it is helpful.
>
>> 2. User mode is not that layer which should be responsible for choosing
>> random address or handling entropy;
>
> Why?
Because of the following reasons:
1. To get random address you should have entropy. These entropy shouldn’t be
exposed to attacker anyhow, the best case is to get it from kernel. So this is
a syscall.
2. You should have memory map of your process to prevent remapping or big
fragmentation. Kernel already has this map. You will got another one in libc.
And any non-libc user of mmap (via syscall, etc) will make hole in your map.
This one also decrease performance cause you any way call syscall_mmap
which will try to find some address for you in worst case, but after you already
did some computing on it.
3. The more memory you use in userland for these proposal, the easier for
attacker to leak it or use in exploitation techniques.
4. It is so easy to fix Kernel function and so hard to support memory
management from userspace.
>
>> 3. Memory fragmentation is unpredictable in this case
>>
>> Off course user mode could use random ‘hint’ address, but kernel may
>> discard this address if it is occupied for example and allocate just before
>> closest vma. So this solution doesn’t give that much security like
>> randomization address inside kernel.
>
> The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
> address range atomically and chose a different range on failure.
>
This algorithm should track current memory. If he doesn’t he may cause
infinite loop while trying to choose memory. And each iteration increase time
needed on allocation new memory, what is not preferred by any libc library
developer.
Thats why I did this patch.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-26 19:45 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-26 19:45 UTC (permalink / raw)
To: Michal Hocko
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal
> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
>=20
> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>=20
>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> =
wrote:
>>>=20
>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>> Current implementation doesn't randomize address returned by mmap.
>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>> creation. After that mmap build very predictable layout of address
>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>> randomization of address on any mmap call.
>>>=20
>>> Why should this be done in the kernel rather than libc? libc is =
perfectly
>>> capable of specifying random numbers in the first argument of mmap.
>> Well, there is following reasons:
>> 1. It should be done in any libc implementation, what is not possible =
IMO;
>=20
> Is this really so helpful?
Yes, ASLR is one of very important mitigation techniques which are =
really used=20
to protect applications. If there is no ASLR, it is very easy to exploit=20=
vulnerable application and compromise the system. We can=E2=80=99t just =
fix all the=20
vulnerabilities right now, thats why we have mitigations - techniques =
which are=20
makes exploitation more hard or impossible in some cases.
Thats why it is helpful.
>=20
>> 2. User mode is not that layer which should be responsible for =
choosing
>> random address or handling entropy;
>=20
> Why?
Because of the following reasons:
1. To get random address you should have entropy. These entropy =
shouldn=E2=80=99t be=20
exposed to attacker anyhow, the best case is to get it from kernel. So =
this is
a syscall.
2. You should have memory map of your process to prevent remapping or =
big
fragmentation. Kernel already has this map. You will got another one in =
libc.
And any non-libc user of mmap (via syscall, etc) will make hole in your =
map.
This one also decrease performance cause you any way call syscall_mmap=20=
which will try to find some address for you in worst case, but after you =
already
did some computing on it.
3. The more memory you use in userland for these proposal, the easier =
for
attacker to leak it or use in exploitation techniques.
4. It is so easy to fix Kernel function and so hard to support memory
management from userspace.
>=20
>> 3. Memory fragmentation is unpredictable in this case
>>=20
>> Off course user mode could use random =E2=80=98hint=E2=80=99 address, =
but kernel may
>> discard this address if it is occupied for example and allocate just =
before
>> closest vma. So this solution doesn=E2=80=99t give that much security =
like=20
>> randomization address inside kernel.
>=20
> The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
> address range atomically and chose a different range on failure.
>=20
This algorithm should track current memory. If he doesn=E2=80=99t he may =
cause
infinite loop while trying to choose memory. And each iteration increase =
time
needed on allocation new memory, what is not preferred by any libc =
library
developer.
Thats why I did this patch.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-26 19:45 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-26 19:45 UTC (permalink / raw)
To: Michal Hocko
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
>
> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>
>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
>>>
>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>> Current implementation doesn't randomize address returned by mmap.
>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>> creation. After that mmap build very predictable layout of address
>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>> randomization of address on any mmap call.
>>>
>>> Why should this be done in the kernel rather than libc? libc is perfectly
>>> capable of specifying random numbers in the first argument of mmap.
>> Well, there is following reasons:
>> 1. It should be done in any libc implementation, what is not possible IMO;
>
> Is this really so helpful?
Yes, ASLR is one of very important mitigation techniques which are really used
to protect applications. If there is no ASLR, it is very easy to exploit
vulnerable application and compromise the system. We can’t just fix all the
vulnerabilities right now, thats why we have mitigations - techniques which are
makes exploitation more hard or impossible in some cases.
Thats why it is helpful.
>
>> 2. User mode is not that layer which should be responsible for choosing
>> random address or handling entropy;
>
> Why?
Because of the following reasons:
1. To get random address you should have entropy. These entropy shouldn’t be
exposed to attacker anyhow, the best case is to get it from kernel. So this is
a syscall.
2. You should have memory map of your process to prevent remapping or big
fragmentation. Kernel already has this map. You will got another one in libc.
And any non-libc user of mmap (via syscall, etc) will make hole in your map.
This one also decrease performance cause you any way call syscall_mmap
which will try to find some address for you in worst case, but after you already
did some computing on it.
3. The more memory you use in userland for these proposal, the easier for
attacker to leak it or use in exploitation techniques.
4. It is so easy to fix Kernel function and so hard to support memory
management from userspace.
>
>> 3. Memory fragmentation is unpredictable in this case
>>
>> Off course user mode could use random ‘hint’ address, but kernel may
>> discard this address if it is occupied for example and allocate just before
>> closest vma. So this solution doesn’t give that much security like
>> randomization address inside kernel.
>
> The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
> address range atomically and chose a different range on failure.
>
This algorithm should track current memory. If he doesn’t he may cause
infinite loop while trying to choose memory. And each iteration increase time
needed on allocation new memory, what is not preferred by any libc library
developer.
Thats why I did this patch.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-26 19:45 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-26 19:45 UTC (permalink / raw)
To: Michal Hocko
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
>=20
> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>=20
>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> =
wrote:
>>>=20
>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>> Current implementation doesn't randomize address returned by mmap.
>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>> creation. After that mmap build very predictable layout of address
>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>> randomization of address on any mmap call.
>>>=20
>>> Why should this be done in the kernel rather than libc? libc is =
perfectly
>>> capable of specifying random numbers in the first argument of mmap.
>> Well, there is following reasons:
>> 1. It should be done in any libc implementation, what is not possible =
IMO;
>=20
> Is this really so helpful?
Yes, ASLR is one of very important mitigation techniques which are =
really used=20
to protect applications. If there is no ASLR, it is very easy to exploit=20=
vulnerable application and compromise the system. We can=E2=80=99t just =
fix all the=20
vulnerabilities right now, thats why we have mitigations - techniques =
which are=20
makes exploitation more hard or impossible in some cases.
Thats why it is helpful.
>=20
>> 2. User mode is not that layer which should be responsible for =
choosing
>> random address or handling entropy;
>=20
> Why?
Because of the following reasons:
1. To get random address you should have entropy. These entropy =
shouldn=E2=80=99t be=20
exposed to attacker anyhow, the best case is to get it from kernel. So =
this is
a syscall.
2. You should have memory map of your process to prevent remapping or =
big
fragmentation. Kernel already has this map. You will got another one in =
libc.
And any non-libc user of mmap (via syscall, etc) will make hole in your =
map.
This one also decrease performance cause you any way call syscall_mmap=20=
which will try to find some address for you in worst case, but after you =
already
did some computing on it.
3. The more memory you use in userland for these proposal, the easier =
for
attacker to leak it or use in exploitation techniques.
4. It is so easy to fix Kernel function and so hard to support memory
management from userspace.
>=20
>> 3. Memory fragmentation is unpredictable in this case
>>=20
>> Off course user mode could use random =E2=80=98hint=E2=80=99 address, =
but kernel may
>> discard this address if it is occupied for example and allocate just =
before
>> closest vma. So this solution doesn=E2=80=99t give that much security =
like=20
>> randomization address inside kernel.
>=20
> The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
> address range atomically and chose a different range on failure.
>=20
This algorithm should track current memory. If he doesn=E2=80=99t he may =
cause
infinite loop while trying to choose memory. And each iteration increase =
time
needed on allocation new memory, what is not preferred by any libc =
library
developer.
Thats why I did this patch.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-26 19:45 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-26 19:45 UTC (permalink / raw)
To: linux-snps-arc
> On 26 Mar 2018,@11:46, Michal Hocko <mhocko@kernel.org> wrote:
>
> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>
>>> On 23 Mar 2018,@15:48, Matthew Wilcox <willy@infradead.org> wrote:
>>>
>>> On Thu, Mar 22, 2018@07:36:36PM +0300, Ilya Smith wrote:
>>>> Current implementation doesn't randomize address returned by mmap.
>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>> creation. After that mmap build very predictable layout of address
>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>> randomization of address on any mmap call.
>>>
>>> Why should this be done in the kernel rather than libc? libc is perfectly
>>> capable of specifying random numbers in the first argument of mmap.
>> Well, there is following reasons:
>> 1. It should be done in any libc implementation, what is not possible IMO;
>
> Is this really so helpful?
Yes, ASLR is one of very important mitigation techniques which are really used
to protect applications. If there is no ASLR, it is very easy to exploit
vulnerable application and compromise the system. We can?t just fix all the
vulnerabilities right now, thats why we have mitigations - techniques which are
makes exploitation more hard or impossible in some cases.
Thats why it is helpful.
>
>> 2. User mode is not that layer which should be responsible for choosing
>> random address or handling entropy;
>
> Why?
Because of the following reasons:
1. To get random address you should have entropy. These entropy shouldn?t be
exposed to attacker anyhow, the best case is to get it from kernel. So this is
a syscall.
2. You should have memory map of your process to prevent remapping or big
fragmentation. Kernel already has this map. You will got another one in libc.
And any non-libc user of mmap (via syscall, etc) will make hole in your map.
This one also decrease performance cause you any way call syscall_mmap
which will try to find some address for you in worst case, but after you already
did some computing on it.
3. The more memory you use in userland for these proposal, the easier for
attacker to leak it or use in exploitation techniques.
4. It is so easy to fix Kernel function and so hard to support memory
management from userspace.
>
>> 3. Memory fragmentation is unpredictable in this case
>>
>> Off course user mode could use random ?hint? address, but kernel may
>> discard this address if it is occupied for example and allocate just before
>> closest vma. So this solution doesn?t give that much security like
>> randomization address inside kernel.
>
> The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
> address range atomically and chose a different range on failure.
>
This algorithm should track current memory. If he doesn?t he may cause
infinite loop while trying to choose memory. And each iteration increase time
needed on allocation new memory, what is not preferred by any libc library
developer.
Thats why I did this patch.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-26 19:45 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-26 19:45 UTC (permalink / raw)
To: Michal Hocko
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal
> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
>
> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>
>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
>>>
>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>> Current implementation doesn't randomize address returned by mmap.
>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>> creation. After that mmap build very predictable layout of address
>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>> randomization of address on any mmap call.
>>>
>>> Why should this be done in the kernel rather than libc? libc is perfectly
>>> capable of specifying random numbers in the first argument of mmap.
>> Well, there is following reasons:
>> 1. It should be done in any libc implementation, what is not possible IMO;
>
> Is this really so helpful?
Yes, ASLR is one of very important mitigation techniques which are really used
to protect applications. If there is no ASLR, it is very easy to exploit
vulnerable application and compromise the system. We can’t just fix all the
vulnerabilities right now, thats why we have mitigations - techniques which are
makes exploitation more hard or impossible in some cases.
Thats why it is helpful.
>
>> 2. User mode is not that layer which should be responsible for choosing
>> random address or handling entropy;
>
> Why?
Because of the following reasons:
1. To get random address you should have entropy. These entropy shouldn’t be
exposed to attacker anyhow, the best case is to get it from kernel. So this is
a syscall.
2. You should have memory map of your process to prevent remapping or big
fragmentation. Kernel already has this map. You will got another one in libc.
And any non-libc user of mmap (via syscall, etc) will make hole in your map.
This one also decrease performance cause you any way call syscall_mmap
which will try to find some address for you in worst case, but after you already
did some computing on it.
3. The more memory you use in userland for these proposal, the easier for
attacker to leak it or use in exploitation techniques.
4. It is so easy to fix Kernel function and so hard to support memory
management from userspace.
>
>> 3. Memory fragmentation is unpredictable in this case
>>
>> Off course user mode could use random ‘hint’ address, but kernel may
>> discard this address if it is occupied for example and allocate just before
>> closest vma. So this solution doesn’t give that much security like
>> randomization address inside kernel.
>
> The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
> address range atomically and chose a different range on failure.
>
This algorithm should track current memory. If he doesn’t he may cause
infinite loop while trying to choose memory. And each iteration increase time
needed on allocation new memory, what is not preferred by any libc library
developer.
Thats why I did this patch.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-26 19:45 ` Ilya Smith
` (2 preceding siblings ...)
(?)
@ 2018-03-27 7:24 ` Michal Hocko
-1 siblings, 0 replies; 185+ messages in thread
From: Michal Hocko @ 2018-03-27 7:24 UTC (permalink / raw)
To: Ilya Smith
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>
> > On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
> >
> > On Fri 23-03-18 20:55:49, Ilya Smith wrote:
> >>
> >>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
> >>>
> >>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> >>>> Current implementation doesn't randomize address returned by mmap.
> >>>> All the entropy ends with choosing mmap_base_addr at the process
> >>>> creation. After that mmap build very predictable layout of address
> >>>> space. It allows to bypass ASLR in many cases. This patch make
> >>>> randomization of address on any mmap call.
> >>>
> >>> Why should this be done in the kernel rather than libc? libc is perfectly
> >>> capable of specifying random numbers in the first argument of mmap.
> >> Well, there is following reasons:
> >> 1. It should be done in any libc implementation, what is not possible IMO;
> >
> > Is this really so helpful?
>
> Yes, ASLR is one of very important mitigation techniques which are really used
> to protect applications. If there is no ASLR, it is very easy to exploit
> vulnerable application and compromise the system. We can’t just fix all the
> vulnerabilities right now, thats why we have mitigations - techniques which are
> makes exploitation more hard or impossible in some cases.
>
> Thats why it is helpful.
I am not questioning ASLR in general. I am asking whether we really need
per mmap ASLR in general. I can imagine that some environments want to
pay the additional price and other side effects, but considering this
can be achieved by libc, why to add more code to the kernel?
> >
> >> 2. User mode is not that layer which should be responsible for choosing
> >> random address or handling entropy;
> >
> > Why?
>
> Because of the following reasons:
> 1. To get random address you should have entropy. These entropy shouldn’t be
> exposed to attacker anyhow, the best case is to get it from kernel. So this is
> a syscall.
/dev/[u]random is not sufficient?
> 2. You should have memory map of your process to prevent remapping or big
> fragmentation. Kernel already has this map.
/proc/self/maps?
> You will got another one in libc.
> And any non-libc user of mmap (via syscall, etc) will make hole in your map.
> This one also decrease performance cause you any way call syscall_mmap
> which will try to find some address for you in worst case, but after you already
> did some computing on it.
I do not understand. a) you should be prepared to pay an additional
price for an additional security measures and b) how would anybody punch
a hole into your mapping?
> 3. The more memory you use in userland for these proposal, the easier for
> attacker to leak it or use in exploitation techniques.
This is true in general, isn't it? I fail to see how kernel chosen and
user chosen ranges would make any difference.
> 4. It is so easy to fix Kernel function and so hard to support memory
> management from userspace.
Well, on the other hand the new layout mode will add a maintenance
burden on the kernel and will have to be maintained for ever because it
is a user visible ABI.
> >> 3. Memory fragmentation is unpredictable in this case
> >>
> >> Off course user mode could use random ‘hint’ address, but kernel may
> >> discard this address if it is occupied for example and allocate just before
> >> closest vma. So this solution doesn’t give that much security like
> >> randomization address inside kernel.
> >
> > The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
> > address range atomically and chose a different range on failure.
> >
>
> This algorithm should track current memory. If he doesn’t he may cause
> infinite loop while trying to choose memory. And each iteration increase time
> needed on allocation new memory, what is not preferred by any libc library
> developer.
Well, I am pretty sure userspace can implement proper free ranges
tracking...
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 7:24 ` Michal Hocko
0 siblings, 0 replies; 185+ messages in thread
From: Michal Hocko @ 2018-03-27 7:24 UTC (permalink / raw)
To: Ilya Smith
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal
On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>
> > On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
> >
> > On Fri 23-03-18 20:55:49, Ilya Smith wrote:
> >>
> >>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
> >>>
> >>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> >>>> Current implementation doesn't randomize address returned by mmap.
> >>>> All the entropy ends with choosing mmap_base_addr at the process
> >>>> creation. After that mmap build very predictable layout of address
> >>>> space. It allows to bypass ASLR in many cases. This patch make
> >>>> randomization of address on any mmap call.
> >>>
> >>> Why should this be done in the kernel rather than libc? libc is perfectly
> >>> capable of specifying random numbers in the first argument of mmap.
> >> Well, there is following reasons:
> >> 1. It should be done in any libc implementation, what is not possible IMO;
> >
> > Is this really so helpful?
>
> Yes, ASLR is one of very important mitigation techniques which are really used
> to protect applications. If there is no ASLR, it is very easy to exploit
> vulnerable application and compromise the system. We can’t just fix all the
> vulnerabilities right now, thats why we have mitigations - techniques which are
> makes exploitation more hard or impossible in some cases.
>
> Thats why it is helpful.
I am not questioning ASLR in general. I am asking whether we really need
per mmap ASLR in general. I can imagine that some environments want to
pay the additional price and other side effects, but considering this
can be achieved by libc, why to add more code to the kernel?
> >
> >> 2. User mode is not that layer which should be responsible for choosing
> >> random address or handling entropy;
> >
> > Why?
>
> Because of the following reasons:
> 1. To get random address you should have entropy. These entropy shouldn’t be
> exposed to attacker anyhow, the best case is to get it from kernel. So this is
> a syscall.
/dev/[u]random is not sufficient?
> 2. You should have memory map of your process to prevent remapping or big
> fragmentation. Kernel already has this map.
/proc/self/maps?
> You will got another one in libc.
> And any non-libc user of mmap (via syscall, etc) will make hole in your map.
> This one also decrease performance cause you any way call syscall_mmap
> which will try to find some address for you in worst case, but after you already
> did some computing on it.
I do not understand. a) you should be prepared to pay an additional
price for an additional security measures and b) how would anybody punch
a hole into your mapping?
> 3. The more memory you use in userland for these proposal, the easier for
> attacker to leak it or use in exploitation techniques.
This is true in general, isn't it? I fail to see how kernel chosen and
user chosen ranges would make any difference.
> 4. It is so easy to fix Kernel function and so hard to support memory
> management from userspace.
Well, on the other hand the new layout mode will add a maintenance
burden on the kernel and will have to be maintained for ever because it
is a user visible ABI.
> >> 3. Memory fragmentation is unpredictable in this case
> >>
> >> Off course user mode could use random ‘hint’ address, but kernel may
> >> discard this address if it is occupied for example and allocate just before
> >> closest vma. So this solution doesn’t give that much security like
> >> randomization address inside kernel.
> >
> > The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
> > address range atomically and chose a different range on failure.
> >
>
> This algorithm should track current memory. If he doesn’t he may cause
> infinite loop while trying to choose memory. And each iteration increase time
> needed on allocation new memory, what is not preferred by any libc library
> developer.
Well, I am pretty sure userspace can implement proper free ranges
tracking...
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 7:24 ` Michal Hocko
0 siblings, 0 replies; 185+ messages in thread
From: Michal Hocko @ 2018-03-27 7:24 UTC (permalink / raw)
To: Ilya Smith
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>
> > On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
> >
> > On Fri 23-03-18 20:55:49, Ilya Smith wrote:
> >>
> >>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
> >>>
> >>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> >>>> Current implementation doesn't randomize address returned by mmap.
> >>>> All the entropy ends with choosing mmap_base_addr at the process
> >>>> creation. After that mmap build very predictable layout of address
> >>>> space. It allows to bypass ASLR in many cases. This patch make
> >>>> randomization of address on any mmap call.
> >>>
> >>> Why should this be done in the kernel rather than libc? libc is perfectly
> >>> capable of specifying random numbers in the first argument of mmap.
> >> Well, there is following reasons:
> >> 1. It should be done in any libc implementation, what is not possible IMO;
> >
> > Is this really so helpful?
>
> Yes, ASLR is one of very important mitigation techniques which are really used
> to protect applications. If there is no ASLR, it is very easy to exploit
> vulnerable application and compromise the system. We can’t just fix all the
> vulnerabilities right now, thats why we have mitigations - techniques which are
> makes exploitation more hard or impossible in some cases.
>
> Thats why it is helpful.
I am not questioning ASLR in general. I am asking whether we really need
per mmap ASLR in general. I can imagine that some environments want to
pay the additional price and other side effects, but considering this
can be achieved by libc, why to add more code to the kernel?
> >
> >> 2. User mode is not that layer which should be responsible for choosing
> >> random address or handling entropy;
> >
> > Why?
>
> Because of the following reasons:
> 1. To get random address you should have entropy. These entropy shouldn’t be
> exposed to attacker anyhow, the best case is to get it from kernel. So this is
> a syscall.
/dev/[u]random is not sufficient?
> 2. You should have memory map of your process to prevent remapping or big
> fragmentation. Kernel already has this map.
/proc/self/maps?
> You will got another one in libc.
> And any non-libc user of mmap (via syscall, etc) will make hole in your map.
> This one also decrease performance cause you any way call syscall_mmap
> which will try to find some address for you in worst case, but after you already
> did some computing on it.
I do not understand. a) you should be prepared to pay an additional
price for an additional security measures and b) how would anybody punch
a hole into your mapping?
> 3. The more memory you use in userland for these proposal, the easier for
> attacker to leak it or use in exploitation techniques.
This is true in general, isn't it? I fail to see how kernel chosen and
user chosen ranges would make any difference.
> 4. It is so easy to fix Kernel function and so hard to support memory
> management from userspace.
Well, on the other hand the new layout mode will add a maintenance
burden on the kernel and will have to be maintained for ever because it
is a user visible ABI.
> >> 3. Memory fragmentation is unpredictable in this case
> >>
> >> Off course user mode could use random ‘hint’ address, but kernel may
> >> discard this address if it is occupied for example and allocate just before
> >> closest vma. So this solution doesn’t give that much security like
> >> randomization address inside kernel.
> >
> > The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
> > address range atomically and chose a different range on failure.
> >
>
> This algorithm should track current memory. If he doesn’t he may cause
> infinite loop while trying to choose memory. And each iteration increase time
> needed on allocation new memory, what is not preferred by any libc library
> developer.
Well, I am pretty sure userspace can implement proper free ranges
tracking...
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 7:24 ` Michal Hocko
0 siblings, 0 replies; 185+ messages in thread
From: Michal Hocko @ 2018-03-27 7:24 UTC (permalink / raw)
To: Ilya Smith
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>
> > On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
> >
> > On Fri 23-03-18 20:55:49, Ilya Smith wrote:
> >>
> >>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
> >>>
> >>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> >>>> Current implementation doesn't randomize address returned by mmap.
> >>>> All the entropy ends with choosing mmap_base_addr at the process
> >>>> creation. After that mmap build very predictable layout of address
> >>>> space. It allows to bypass ASLR in many cases. This patch make
> >>>> randomization of address on any mmap call.
> >>>
> >>> Why should this be done in the kernel rather than libc? libc is perfectly
> >>> capable of specifying random numbers in the first argument of mmap.
> >> Well, there is following reasons:
> >> 1. It should be done in any libc implementation, what is not possible IMO;
> >
> > Is this really so helpful?
>
> Yes, ASLR is one of very important mitigation techniques which are really used
> to protect applications. If there is no ASLR, it is very easy to exploit
> vulnerable application and compromise the system. We cana??t just fix all the
> vulnerabilities right now, thats why we have mitigations - techniques which are
> makes exploitation more hard or impossible in some cases.
>
> Thats why it is helpful.
I am not questioning ASLR in general. I am asking whether we really need
per mmap ASLR in general. I can imagine that some environments want to
pay the additional price and other side effects, but considering this
can be achieved by libc, why to add more code to the kernel?
> >
> >> 2. User mode is not that layer which should be responsible for choosing
> >> random address or handling entropy;
> >
> > Why?
>
> Because of the following reasons:
> 1. To get random address you should have entropy. These entropy shouldna??t be
> exposed to attacker anyhow, the best case is to get it from kernel. So this is
> a syscall.
/dev/[u]random is not sufficient?
> 2. You should have memory map of your process to prevent remapping or big
> fragmentation. Kernel already has this map.
/proc/self/maps?
> You will got another one in libc.
> And any non-libc user of mmap (via syscall, etc) will make hole in your map.
> This one also decrease performance cause you any way call syscall_mmap
> which will try to find some address for you in worst case, but after you already
> did some computing on it.
I do not understand. a) you should be prepared to pay an additional
price for an additional security measures and b) how would anybody punch
a hole into your mapping?
> 3. The more memory you use in userland for these proposal, the easier for
> attacker to leak it or use in exploitation techniques.
This is true in general, isn't it? I fail to see how kernel chosen and
user chosen ranges would make any difference.
> 4. It is so easy to fix Kernel function and so hard to support memory
> management from userspace.
Well, on the other hand the new layout mode will add a maintenance
burden on the kernel and will have to be maintained for ever because it
is a user visible ABI.
> >> 3. Memory fragmentation is unpredictable in this case
> >>
> >> Off course user mode could use random a??hinta?? address, but kernel may
> >> discard this address if it is occupied for example and allocate just before
> >> closest vma. So this solution doesna??t give that much security like
> >> randomization address inside kernel.
> >
> > The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
> > address range atomically and chose a different range on failure.
> >
>
> This algorithm should track current memory. If he doesna??t he may cause
> infinite loop while trying to choose memory. And each iteration increase time
> needed on allocation new memory, what is not preferred by any libc library
> developer.
Well, I am pretty sure userspace can implement proper free ranges
tracking...
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 7:24 ` Michal Hocko
0 siblings, 0 replies; 185+ messages in thread
From: Michal Hocko @ 2018-03-27 7:24 UTC (permalink / raw)
To: linux-snps-arc
On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>
> > On 26 Mar 2018,@11:46, Michal Hocko <mhocko@kernel.org> wrote:
> >
> > On Fri 23-03-18 20:55:49, Ilya Smith wrote:
> >>
> >>> On 23 Mar 2018,@15:48, Matthew Wilcox <willy@infradead.org> wrote:
> >>>
> >>> On Thu, Mar 22, 2018@07:36:36PM +0300, Ilya Smith wrote:
> >>>> Current implementation doesn't randomize address returned by mmap.
> >>>> All the entropy ends with choosing mmap_base_addr at the process
> >>>> creation. After that mmap build very predictable layout of address
> >>>> space. It allows to bypass ASLR in many cases. This patch make
> >>>> randomization of address on any mmap call.
> >>>
> >>> Why should this be done in the kernel rather than libc? libc is perfectly
> >>> capable of specifying random numbers in the first argument of mmap.
> >> Well, there is following reasons:
> >> 1. It should be done in any libc implementation, what is not possible IMO;
> >
> > Is this really so helpful?
>
> Yes, ASLR is one of very important mitigation techniques which are really used
> to protect applications. If there is no ASLR, it is very easy to exploit
> vulnerable application and compromise the system. We can?t just fix all the
> vulnerabilities right now, thats why we have mitigations - techniques which are
> makes exploitation more hard or impossible in some cases.
>
> Thats why it is helpful.
I am not questioning ASLR in general. I am asking whether we really need
per mmap ASLR in general. I can imagine that some environments want to
pay the additional price and other side effects, but considering this
can be achieved by libc, why to add more code to the kernel?
> >
> >> 2. User mode is not that layer which should be responsible for choosing
> >> random address or handling entropy;
> >
> > Why?
>
> Because of the following reasons:
> 1. To get random address you should have entropy. These entropy shouldn?t be
> exposed to attacker anyhow, the best case is to get it from kernel. So this is
> a syscall.
/dev/[u]random is not sufficient?
> 2. You should have memory map of your process to prevent remapping or big
> fragmentation. Kernel already has this map.
/proc/self/maps?
> You will got another one in libc.
> And any non-libc user of mmap (via syscall, etc) will make hole in your map.
> This one also decrease performance cause you any way call syscall_mmap
> which will try to find some address for you in worst case, but after you already
> did some computing on it.
I do not understand. a) you should be prepared to pay an additional
price for an additional security measures and b) how would anybody punch
a hole into your mapping?
> 3. The more memory you use in userland for these proposal, the easier for
> attacker to leak it or use in exploitation techniques.
This is true in general, isn't it? I fail to see how kernel chosen and
user chosen ranges would make any difference.
> 4. It is so easy to fix Kernel function and so hard to support memory
> management from userspace.
Well, on the other hand the new layout mode will add a maintenance
burden on the kernel and will have to be maintained for ever because it
is a user visible ABI.
> >> 3. Memory fragmentation is unpredictable in this case
> >>
> >> Off course user mode could use random ?hint? address, but kernel may
> >> discard this address if it is occupied for example and allocate just before
> >> closest vma. So this solution doesn?t give that much security like
> >> randomization address inside kernel.
> >
> > The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
> > address range atomically and chose a different range on failure.
> >
>
> This algorithm should track current memory. If he doesn?t he may cause
> infinite loop while trying to choose memory. And each iteration increase time
> needed on allocation new memory, what is not preferred by any libc library
> developer.
Well, I am pretty sure userspace can implement proper free ranges
tracking...
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-27 7:24 ` Michal Hocko
` (3 preceding siblings ...)
(?)
@ 2018-03-27 13:51 ` Ilya Smith
-1 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-27 13:51 UTC (permalink / raw)
To: Michal Hocko
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
> On 27 Mar 2018, at 10:24, Michal Hocko <mhocko@kernel.org> wrote:
>
> On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>>
>>> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
>>>
>>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>>>
>>>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
>>>>>
>>>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>>>> Current implementation doesn't randomize address returned by mmap.
>>>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>>>> creation. After that mmap build very predictable layout of address
>>>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>>>> randomization of address on any mmap call.
>>>>>
>>>>> Why should this be done in the kernel rather than libc? libc is perfectly
>>>>> capable of specifying random numbers in the first argument of mmap.
>>>> Well, there is following reasons:
>>>> 1. It should be done in any libc implementation, what is not possible IMO;
>>>
>>> Is this really so helpful?
>>
>> Yes, ASLR is one of very important mitigation techniques which are really used
>> to protect applications. If there is no ASLR, it is very easy to exploit
>> vulnerable application and compromise the system. We can’t just fix all the
>> vulnerabilities right now, thats why we have mitigations - techniques which are
>> makes exploitation more hard or impossible in some cases.
>>
>> Thats why it is helpful.
>
> I am not questioning ASLR in general. I am asking whether we really need
> per mmap ASLR in general. I can imagine that some environments want to
> pay the additional price and other side effects, but considering this
> can be achieved by libc, why to add more code to the kernel?
I believe this is the only one right place for it. Adding these 200+ lines of
code we give this feature for any user - on desktop, on server, on IoT device,
on SCADA, etc. But if only glibc will implement ‘user-mode-aslr’ IoT and SCADA
devices will never get it.
>>>
>>>> 2. User mode is not that layer which should be responsible for choosing
>>>> random address or handling entropy;
>>>
>>> Why?
>>
>> Because of the following reasons:
>> 1. To get random address you should have entropy. These entropy shouldn’t be
>> exposed to attacker anyhow, the best case is to get it from kernel. So this is
>> a syscall.
>
> /dev/[u]random is not sufficient?
Using /dev/[u]random makes 3 syscalls - open, read, close. This is a performance
issue.
>
>> 2. You should have memory map of your process to prevent remapping or big
>> fragmentation. Kernel already has this map.
>
> /proc/self/maps?
Not any system has /proc and parsing /proc/self/maps is robust so it is the
performance issue. libc will have to do it on any mmap. And there is a possible
race here - application may mmap/unmap memory with native syscall during other
thread reading maps.
>> You will got another one in libc.
>> And any non-libc user of mmap (via syscall, etc) will make hole in your map.
>> This one also decrease performance cause you any way call syscall_mmap
>> which will try to find some address for you in worst case, but after you already
>> did some computing on it.
>
> I do not understand. a) you should be prepared to pay an additional
> price for an additional security measures and b) how would anybody punch
> a hole into your mapping?
>
I was talking about any code that call mmap directly without libc wrapper.
>> 3. The more memory you use in userland for these proposal, the easier for
>> attacker to leak it or use in exploitation techniques.
>
> This is true in general, isn't it? I fail to see how kernel chosen and
> user chosen ranges would make any difference.
My point here was that libc will have to keep memory representation as a tree
and this tree increase attack surface. It could be hidden in kernel as it is right now.
>
>> 4. It is so easy to fix Kernel function and so hard to support memory
>> management from userspace.
>
> Well, on the other hand the new layout mode will add a maintenance
> burden on the kernel and will have to be maintained for ever because it
> is a user visible ABI.
Thats why I made this patch as RFC and would like to discuss this ABI here. I
made randomize_va_space parameter to allow disable randomisation per whole
system. PF_RANDOMIZE flag may disable randomization for concrete process (or
process groups?). For architecture I’ve made info.random_shift = 0 , so if your
arch has small address space you may disable shifting. I also would like to add
some sysctl to allow process/groups to change this value and allow some
processes to have shifts bigger then another. Lets discuss it, please.
>
>>>> 3. Memory fragmentation is unpredictable in this case
>>>>
>>>> Off course user mode could use random ‘hint’ address, but kernel may
>>>> discard this address if it is occupied for example and allocate just before
>>>> closest vma. So this solution doesn’t give that much security like
>>>> randomization address inside kernel.
>>>
>>> The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
>>> address range atomically and chose a different range on failure.
>>>
>>
>> This algorithm should track current memory. If he doesn’t he may cause
>> infinite loop while trying to choose memory. And each iteration increase time
>> needed on allocation new memory, what is not preferred by any libc library
>> developer.
>
> Well, I am pretty sure userspace can implement proper free ranges
> tracking…
I think we need to know what libc developers will say on implementing ASLR in
user-mode. I am pretty sure they will say ‘nether’ or ‘some-day’. And problem
of ASLR will stay forever.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 13:51 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-27 13:51 UTC (permalink / raw)
To: Michal Hocko
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal
> On 27 Mar 2018, at 10:24, Michal Hocko <mhocko@kernel.org> wrote:
>=20
> On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>>=20
>>> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
>>>=20
>>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>>>=20
>>>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> =
wrote:
>>>>>=20
>>>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>>>> Current implementation doesn't randomize address returned by =
mmap.
>>>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>>>> creation. After that mmap build very predictable layout of =
address
>>>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>>>> randomization of address on any mmap call.
>>>>>=20
>>>>> Why should this be done in the kernel rather than libc? libc is =
perfectly
>>>>> capable of specifying random numbers in the first argument of =
mmap.
>>>> Well, there is following reasons:
>>>> 1. It should be done in any libc implementation, what is not =
possible IMO;
>>>=20
>>> Is this really so helpful?
>>=20
>> Yes, ASLR is one of very important mitigation techniques which are =
really used=20
>> to protect applications. If there is no ASLR, it is very easy to =
exploit=20
>> vulnerable application and compromise the system. We can=E2=80=99t =
just fix all the=20
>> vulnerabilities right now, thats why we have mitigations - techniques =
which are=20
>> makes exploitation more hard or impossible in some cases.
>>=20
>> Thats why it is helpful.
>=20
> I am not questioning ASLR in general. I am asking whether we really =
need
> per mmap ASLR in general. I can imagine that some environments want to
> pay the additional price and other side effects, but considering this
> can be achieved by libc, why to add more code to the kernel?
I believe this is the only one right place for it. Adding these 200+ =
lines of=20
code we give this feature for any user - on desktop, on server, on IoT =
device,=20
on SCADA, etc. But if only glibc will implement =E2=80=98user-mode-aslr=E2=
=80=99 IoT and SCADA=20
devices will never get it.
>>>=20
>>>> 2. User mode is not that layer which should be responsible for =
choosing
>>>> random address or handling entropy;
>>>=20
>>> Why?
>>=20
>> Because of the following reasons:
>> 1. To get random address you should have entropy. These entropy =
shouldn=E2=80=99t be=20
>> exposed to attacker anyhow, the best case is to get it from kernel. =
So this is
>> a syscall.
>=20
> /dev/[u]random is not sufficient?
Using /dev/[u]random makes 3 syscalls - open, read, close. This is a =
performance
issue.
>=20
>> 2. You should have memory map of your process to prevent remapping or =
big
>> fragmentation. Kernel already has this map.
>=20
> /proc/self/maps?
Not any system has /proc and parsing /proc/self/maps is robust so it is =
the=20
performance issue. libc will have to do it on any mmap. And there is a =
possible=20
race here - application may mmap/unmap memory with native syscall during =
other=20
thread reading maps.
>> You will got another one in libc.
>> And any non-libc user of mmap (via syscall, etc) will make hole in =
your map.
>> This one also decrease performance cause you any way call =
syscall_mmap=20
>> which will try to find some address for you in worst case, but after =
you already
>> did some computing on it.
>=20
> I do not understand. a) you should be prepared to pay an additional
> price for an additional security measures and b) how would anybody =
punch
> a hole into your mapping?=20
>=20
I was talking about any code that call mmap directly without libc =
wrapper.
>> 3. The more memory you use in userland for these proposal, the easier =
for
>> attacker to leak it or use in exploitation techniques.
>=20
> This is true in general, isn't it? I fail to see how kernel chosen and
> user chosen ranges would make any difference.
My point here was that libc will have to keep memory representation as a =
tree=20
and this tree increase attack surface. It could be hidden in kernel as =
it is right now.
>=20
>> 4. It is so easy to fix Kernel function and so hard to support memory
>> management from userspace.
>=20
> Well, on the other hand the new layout mode will add a maintenance
> burden on the kernel and will have to be maintained for ever because =
it
> is a user visible ABI.
Thats why I made this patch as RFC and would like to discuss this ABI =
here. I=20
made randomize_va_space parameter to allow disable randomisation per =
whole=20
system. PF_RANDOMIZE flag may disable randomization for concrete process =
(or=20
process groups?). For architecture I=E2=80=99ve made info.random_shift =3D=
0 , so if your=20
arch has small address space you may disable shifting. I also would like =
to add=20
some sysctl to allow process/groups to change this value and allow some=20=
processes to have shifts bigger then another. Lets discuss it, please.
>=20
>>>> 3. Memory fragmentation is unpredictable in this case
>>>>=20
>>>> Off course user mode could use random =E2=80=98hint=E2=80=99 =
address, but kernel may
>>>> discard this address if it is occupied for example and allocate =
just before
>>>> closest vma. So this solution doesn=E2=80=99t give that much =
security like=20
>>>> randomization address inside kernel.
>>>=20
>>> The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
>>> address range atomically and chose a different range on failure.
>>>=20
>>=20
>> This algorithm should track current memory. If he doesn=E2=80=99t he =
may cause
>> infinite loop while trying to choose memory. And each iteration =
increase time
>> needed on allocation new memory, what is not preferred by any libc =
library
>> developer.
>=20
> Well, I am pretty sure userspace can implement proper free ranges
> tracking=E2=80=A6
I think we need to know what libc developers will say on implementing =
ASLR in=20
user-mode. I am pretty sure they will say =E2=80=98nether=E2=80=99 or =
=E2=80=98some-day=E2=80=99. And problem=20
of ASLR will stay forever.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 13:51 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-27 13:51 UTC (permalink / raw)
To: Michal Hocko
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
> On 27 Mar 2018, at 10:24, Michal Hocko <mhocko@kernel.org> wrote:
>
> On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>>
>>> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
>>>
>>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>>>
>>>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
>>>>>
>>>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>>>> Current implementation doesn't randomize address returned by mmap.
>>>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>>>> creation. After that mmap build very predictable layout of address
>>>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>>>> randomization of address on any mmap call.
>>>>>
>>>>> Why should this be done in the kernel rather than libc? libc is perfectly
>>>>> capable of specifying random numbers in the first argument of mmap.
>>>> Well, there is following reasons:
>>>> 1. It should be done in any libc implementation, what is not possible IMO;
>>>
>>> Is this really so helpful?
>>
>> Yes, ASLR is one of very important mitigation techniques which are really used
>> to protect applications. If there is no ASLR, it is very easy to exploit
>> vulnerable application and compromise the system. We can’t just fix all the
>> vulnerabilities right now, thats why we have mitigations - techniques which are
>> makes exploitation more hard or impossible in some cases.
>>
>> Thats why it is helpful.
>
> I am not questioning ASLR in general. I am asking whether we really need
> per mmap ASLR in general. I can imagine that some environments want to
> pay the additional price and other side effects, but considering this
> can be achieved by libc, why to add more code to the kernel?
I believe this is the only one right place for it. Adding these 200+ lines of
code we give this feature for any user - on desktop, on server, on IoT device,
on SCADA, etc. But if only glibc will implement ‘user-mode-aslr’ IoT and SCADA
devices will never get it.
>>>
>>>> 2. User mode is not that layer which should be responsible for choosing
>>>> random address or handling entropy;
>>>
>>> Why?
>>
>> Because of the following reasons:
>> 1. To get random address you should have entropy. These entropy shouldn’t be
>> exposed to attacker anyhow, the best case is to get it from kernel. So this is
>> a syscall.
>
> /dev/[u]random is not sufficient?
Using /dev/[u]random makes 3 syscalls - open, read, close. This is a performance
issue.
>
>> 2. You should have memory map of your process to prevent remapping or big
>> fragmentation. Kernel already has this map.
>
> /proc/self/maps?
Not any system has /proc and parsing /proc/self/maps is robust so it is the
performance issue. libc will have to do it on any mmap. And there is a possible
race here - application may mmap/unmap memory with native syscall during other
thread reading maps.
>> You will got another one in libc.
>> And any non-libc user of mmap (via syscall, etc) will make hole in your map.
>> This one also decrease performance cause you any way call syscall_mmap
>> which will try to find some address for you in worst case, but after you already
>> did some computing on it.
>
> I do not understand. a) you should be prepared to pay an additional
> price for an additional security measures and b) how would anybody punch
> a hole into your mapping?
>
I was talking about any code that call mmap directly without libc wrapper.
>> 3. The more memory you use in userland for these proposal, the easier for
>> attacker to leak it or use in exploitation techniques.
>
> This is true in general, isn't it? I fail to see how kernel chosen and
> user chosen ranges would make any difference.
My point here was that libc will have to keep memory representation as a tree
and this tree increase attack surface. It could be hidden in kernel as it is right now.
>
>> 4. It is so easy to fix Kernel function and so hard to support memory
>> management from userspace.
>
> Well, on the other hand the new layout mode will add a maintenance
> burden on the kernel and will have to be maintained for ever because it
> is a user visible ABI.
Thats why I made this patch as RFC and would like to discuss this ABI here. I
made randomize_va_space parameter to allow disable randomisation per whole
system. PF_RANDOMIZE flag may disable randomization for concrete process (or
process groups?). For architecture I’ve made info.random_shift = 0 , so if your
arch has small address space you may disable shifting. I also would like to add
some sysctl to allow process/groups to change this value and allow some
processes to have shifts bigger then another. Lets discuss it, please.
>
>>>> 3. Memory fragmentation is unpredictable in this case
>>>>
>>>> Off course user mode could use random ‘hint’ address, but kernel may
>>>> discard this address if it is occupied for example and allocate just before
>>>> closest vma. So this solution doesn’t give that much security like
>>>> randomization address inside kernel.
>>>
>>> The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
>>> address range atomically and chose a different range on failure.
>>>
>>
>> This algorithm should track current memory. If he doesn’t he may cause
>> infinite loop while trying to choose memory. And each iteration increase time
>> needed on allocation new memory, what is not preferred by any libc library
>> developer.
>
> Well, I am pretty sure userspace can implement proper free ranges
> tracking…
I think we need to know what libc developers will say on implementing ASLR in
user-mode. I am pretty sure they will say ‘nether’ or ‘some-day’. And problem
of ASLR will stay forever.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 13:51 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-27 13:51 UTC (permalink / raw)
To: Michal Hocko
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
> On 27 Mar 2018, at 10:24, Michal Hocko <mhocko@kernel.org> wrote:
>=20
> On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>>=20
>>> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
>>>=20
>>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>>>=20
>>>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> =
wrote:
>>>>>=20
>>>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>>>> Current implementation doesn't randomize address returned by =
mmap.
>>>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>>>> creation. After that mmap build very predictable layout of =
address
>>>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>>>> randomization of address on any mmap call.
>>>>>=20
>>>>> Why should this be done in the kernel rather than libc? libc is =
perfectly
>>>>> capable of specifying random numbers in the first argument of =
mmap.
>>>> Well, there is following reasons:
>>>> 1. It should be done in any libc implementation, what is not =
possible IMO;
>>>=20
>>> Is this really so helpful?
>>=20
>> Yes, ASLR is one of very important mitigation techniques which are =
really used=20
>> to protect applications. If there is no ASLR, it is very easy to =
exploit=20
>> vulnerable application and compromise the system. We can=E2=80=99t =
just fix all the=20
>> vulnerabilities right now, thats why we have mitigations - techniques =
which are=20
>> makes exploitation more hard or impossible in some cases.
>>=20
>> Thats why it is helpful.
>=20
> I am not questioning ASLR in general. I am asking whether we really =
need
> per mmap ASLR in general. I can imagine that some environments want to
> pay the additional price and other side effects, but considering this
> can be achieved by libc, why to add more code to the kernel?
I believe this is the only one right place for it. Adding these 200+ =
lines of=20
code we give this feature for any user - on desktop, on server, on IoT =
device,=20
on SCADA, etc. But if only glibc will implement =E2=80=98user-mode-aslr=E2=
=80=99 IoT and SCADA=20
devices will never get it.
>>>=20
>>>> 2. User mode is not that layer which should be responsible for =
choosing
>>>> random address or handling entropy;
>>>=20
>>> Why?
>>=20
>> Because of the following reasons:
>> 1. To get random address you should have entropy. These entropy =
shouldn=E2=80=99t be=20
>> exposed to attacker anyhow, the best case is to get it from kernel. =
So this is
>> a syscall.
>=20
> /dev/[u]random is not sufficient?
Using /dev/[u]random makes 3 syscalls - open, read, close. This is a =
performance
issue.
>=20
>> 2. You should have memory map of your process to prevent remapping or =
big
>> fragmentation. Kernel already has this map.
>=20
> /proc/self/maps?
Not any system has /proc and parsing /proc/self/maps is robust so it is =
the=20
performance issue. libc will have to do it on any mmap. And there is a =
possible=20
race here - application may mmap/unmap memory with native syscall during =
other=20
thread reading maps.
>> You will got another one in libc.
>> And any non-libc user of mmap (via syscall, etc) will make hole in =
your map.
>> This one also decrease performance cause you any way call =
syscall_mmap=20
>> which will try to find some address for you in worst case, but after =
you already
>> did some computing on it.
>=20
> I do not understand. a) you should be prepared to pay an additional
> price for an additional security measures and b) how would anybody =
punch
> a hole into your mapping?=20
>=20
I was talking about any code that call mmap directly without libc =
wrapper.
>> 3. The more memory you use in userland for these proposal, the easier =
for
>> attacker to leak it or use in exploitation techniques.
>=20
> This is true in general, isn't it? I fail to see how kernel chosen and
> user chosen ranges would make any difference.
My point here was that libc will have to keep memory representation as a =
tree=20
and this tree increase attack surface. It could be hidden in kernel as =
it is right now.
>=20
>> 4. It is so easy to fix Kernel function and so hard to support memory
>> management from userspace.
>=20
> Well, on the other hand the new layout mode will add a maintenance
> burden on the kernel and will have to be maintained for ever because =
it
> is a user visible ABI.
Thats why I made this patch as RFC and would like to discuss this ABI =
here. I=20
made randomize_va_space parameter to allow disable randomisation per =
whole=20
system. PF_RANDOMIZE flag may disable randomization for concrete process =
(or=20
process groups?). For architecture I=E2=80=99ve made info.random_shift =3D=
0 , so if your=20
arch has small address space you may disable shifting. I also would like =
to add=20
some sysctl to allow process/groups to change this value and allow some=20=
processes to have shifts bigger then another. Lets discuss it, please.
>=20
>>>> 3. Memory fragmentation is unpredictable in this case
>>>>=20
>>>> Off course user mode could use random =E2=80=98hint=E2=80=99 =
address, but kernel may
>>>> discard this address if it is occupied for example and allocate =
just before
>>>> closest vma. So this solution doesn=E2=80=99t give that much =
security like=20
>>>> randomization address inside kernel.
>>>=20
>>> The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
>>> address range atomically and chose a different range on failure.
>>>=20
>>=20
>> This algorithm should track current memory. If he doesn=E2=80=99t he =
may cause
>> infinite loop while trying to choose memory. And each iteration =
increase time
>> needed on allocation new memory, what is not preferred by any libc =
library
>> developer.
>=20
> Well, I am pretty sure userspace can implement proper free ranges
> tracking=E2=80=A6
I think we need to know what libc developers will say on implementing =
ASLR in=20
user-mode. I am pretty sure they will say =E2=80=98nether=E2=80=99 or =
=E2=80=98some-day=E2=80=99. And problem=20
of ASLR will stay forever.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 13:51 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-27 13:51 UTC (permalink / raw)
To: linux-snps-arc
> On 27 Mar 2018,@10:24, Michal Hocko <mhocko@kernel.org> wrote:
>
> On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>>
>>> On 26 Mar 2018,@11:46, Michal Hocko <mhocko@kernel.org> wrote:
>>>
>>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>>>
>>>>> On 23 Mar 2018,@15:48, Matthew Wilcox <willy@infradead.org> wrote:
>>>>>
>>>>> On Thu, Mar 22, 2018@07:36:36PM +0300, Ilya Smith wrote:
>>>>>> Current implementation doesn't randomize address returned by mmap.
>>>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>>>> creation. After that mmap build very predictable layout of address
>>>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>>>> randomization of address on any mmap call.
>>>>>
>>>>> Why should this be done in the kernel rather than libc? libc is perfectly
>>>>> capable of specifying random numbers in the first argument of mmap.
>>>> Well, there is following reasons:
>>>> 1. It should be done in any libc implementation, what is not possible IMO;
>>>
>>> Is this really so helpful?
>>
>> Yes, ASLR is one of very important mitigation techniques which are really used
>> to protect applications. If there is no ASLR, it is very easy to exploit
>> vulnerable application and compromise the system. We can?t just fix all the
>> vulnerabilities right now, thats why we have mitigations - techniques which are
>> makes exploitation more hard or impossible in some cases.
>>
>> Thats why it is helpful.
>
> I am not questioning ASLR in general. I am asking whether we really need
> per mmap ASLR in general. I can imagine that some environments want to
> pay the additional price and other side effects, but considering this
> can be achieved by libc, why to add more code to the kernel?
I believe this is the only one right place for it. Adding these 200+ lines of
code we give this feature for any user - on desktop, on server, on IoT device,
on SCADA, etc. But if only glibc will implement ?user-mode-aslr? IoT and SCADA
devices will never get it.
>>>
>>>> 2. User mode is not that layer which should be responsible for choosing
>>>> random address or handling entropy;
>>>
>>> Why?
>>
>> Because of the following reasons:
>> 1. To get random address you should have entropy. These entropy shouldn?t be
>> exposed to attacker anyhow, the best case is to get it from kernel. So this is
>> a syscall.
>
> /dev/[u]random is not sufficient?
Using /dev/[u]random makes 3 syscalls - open, read, close. This is a performance
issue.
>
>> 2. You should have memory map of your process to prevent remapping or big
>> fragmentation. Kernel already has this map.
>
> /proc/self/maps?
Not any system has /proc and parsing /proc/self/maps is robust so it is the
performance issue. libc will have to do it on any mmap. And there is a possible
race here - application may mmap/unmap memory with native syscall during other
thread reading maps.
>> You will got another one in libc.
>> And any non-libc user of mmap (via syscall, etc) will make hole in your map.
>> This one also decrease performance cause you any way call syscall_mmap
>> which will try to find some address for you in worst case, but after you already
>> did some computing on it.
>
> I do not understand. a) you should be prepared to pay an additional
> price for an additional security measures and b) how would anybody punch
> a hole into your mapping?
>
I was talking about any code that call mmap directly without libc wrapper.
>> 3. The more memory you use in userland for these proposal, the easier for
>> attacker to leak it or use in exploitation techniques.
>
> This is true in general, isn't it? I fail to see how kernel chosen and
> user chosen ranges would make any difference.
My point here was that libc will have to keep memory representation as a tree
and this tree increase attack surface. It could be hidden in kernel as it is right now.
>
>> 4. It is so easy to fix Kernel function and so hard to support memory
>> management from userspace.
>
> Well, on the other hand the new layout mode will add a maintenance
> burden on the kernel and will have to be maintained for ever because it
> is a user visible ABI.
Thats why I made this patch as RFC and would like to discuss this ABI here. I
made randomize_va_space parameter to allow disable randomisation per whole
system. PF_RANDOMIZE flag may disable randomization for concrete process (or
process groups?). For architecture I?ve made info.random_shift = 0 , so if your
arch has small address space you may disable shifting. I also would like to add
some sysctl to allow process/groups to change this value and allow some
processes to have shifts bigger then another. Lets discuss it, please.
>
>>>> 3. Memory fragmentation is unpredictable in this case
>>>>
>>>> Off course user mode could use random ?hint? address, but kernel may
>>>> discard this address if it is occupied for example and allocate just before
>>>> closest vma. So this solution doesn?t give that much security like
>>>> randomization address inside kernel.
>>>
>>> The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
>>> address range atomically and chose a different range on failure.
>>>
>>
>> This algorithm should track current memory. If he doesn?t he may cause
>> infinite loop while trying to choose memory. And each iteration increase time
>> needed on allocation new memory, what is not preferred by any libc library
>> developer.
>
> Well, I am pretty sure userspace can implement proper free ranges
> tracking?
I think we need to know what libc developers will say on implementing ASLR in
user-mode. I am pretty sure they will say ?nether? or ?some-day?. And problem
of ASLR will stay forever.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 13:51 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-27 13:51 UTC (permalink / raw)
To: Michal Hocko
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal
> On 27 Mar 2018, at 10:24, Michal Hocko <mhocko@kernel.org> wrote:
>
> On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>>
>>> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
>>>
>>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>>>
>>>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
>>>>>
>>>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>>>> Current implementation doesn't randomize address returned by mmap.
>>>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>>>> creation. After that mmap build very predictable layout of address
>>>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>>>> randomization of address on any mmap call.
>>>>>
>>>>> Why should this be done in the kernel rather than libc? libc is perfectly
>>>>> capable of specifying random numbers in the first argument of mmap.
>>>> Well, there is following reasons:
>>>> 1. It should be done in any libc implementation, what is not possible IMO;
>>>
>>> Is this really so helpful?
>>
>> Yes, ASLR is one of very important mitigation techniques which are really used
>> to protect applications. If there is no ASLR, it is very easy to exploit
>> vulnerable application and compromise the system. We can’t just fix all the
>> vulnerabilities right now, thats why we have mitigations - techniques which are
>> makes exploitation more hard or impossible in some cases.
>>
>> Thats why it is helpful.
>
> I am not questioning ASLR in general. I am asking whether we really need
> per mmap ASLR in general. I can imagine that some environments want to
> pay the additional price and other side effects, but considering this
> can be achieved by libc, why to add more code to the kernel?
I believe this is the only one right place for it. Adding these 200+ lines of
code we give this feature for any user - on desktop, on server, on IoT device,
on SCADA, etc. But if only glibc will implement ‘user-mode-aslr’ IoT and SCADA
devices will never get it.
>>>
>>>> 2. User mode is not that layer which should be responsible for choosing
>>>> random address or handling entropy;
>>>
>>> Why?
>>
>> Because of the following reasons:
>> 1. To get random address you should have entropy. These entropy shouldn’t be
>> exposed to attacker anyhow, the best case is to get it from kernel. So this is
>> a syscall.
>
> /dev/[u]random is not sufficient?
Using /dev/[u]random makes 3 syscalls - open, read, close. This is a performance
issue.
>
>> 2. You should have memory map of your process to prevent remapping or big
>> fragmentation. Kernel already has this map.
>
> /proc/self/maps?
Not any system has /proc and parsing /proc/self/maps is robust so it is the
performance issue. libc will have to do it on any mmap. And there is a possible
race here - application may mmap/unmap memory with native syscall during other
thread reading maps.
>> You will got another one in libc.
>> And any non-libc user of mmap (via syscall, etc) will make hole in your map.
>> This one also decrease performance cause you any way call syscall_mmap
>> which will try to find some address for you in worst case, but after you already
>> did some computing on it.
>
> I do not understand. a) you should be prepared to pay an additional
> price for an additional security measures and b) how would anybody punch
> a hole into your mapping?
>
I was talking about any code that call mmap directly without libc wrapper.
>> 3. The more memory you use in userland for these proposal, the easier for
>> attacker to leak it or use in exploitation techniques.
>
> This is true in general, isn't it? I fail to see how kernel chosen and
> user chosen ranges would make any difference.
My point here was that libc will have to keep memory representation as a tree
and this tree increase attack surface. It could be hidden in kernel as it is right now.
>
>> 4. It is so easy to fix Kernel function and so hard to support memory
>> management from userspace.
>
> Well, on the other hand the new layout mode will add a maintenance
> burden on the kernel and will have to be maintained for ever because it
> is a user visible ABI.
Thats why I made this patch as RFC and would like to discuss this ABI here. I
made randomize_va_space parameter to allow disable randomisation per whole
system. PF_RANDOMIZE flag may disable randomization for concrete process (or
process groups?). For architecture I’ve made info.random_shift = 0 , so if your
arch has small address space you may disable shifting. I also would like to add
some sysctl to allow process/groups to change this value and allow some
processes to have shifts bigger then another. Lets discuss it, please.
>
>>>> 3. Memory fragmentation is unpredictable in this case
>>>>
>>>> Off course user mode could use random ‘hint’ address, but kernel may
>>>> discard this address if it is occupied for example and allocate just before
>>>> closest vma. So this solution doesn’t give that much security like
>>>> randomization address inside kernel.
>>>
>>> The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
>>> address range atomically and chose a different range on failure.
>>>
>>
>> This algorithm should track current memory. If he doesn’t he may cause
>> infinite loop while trying to choose memory. And each iteration increase time
>> needed on allocation new memory, what is not preferred by any libc library
>> developer.
>
> Well, I am pretty sure userspace can implement proper free ranges
> tracking…
I think we need to know what libc developers will say on implementing ASLR in
user-mode. I am pretty sure they will say ‘nether’ or ‘some-day’. And problem
of ASLR will stay forever.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-27 13:51 ` Ilya Smith
` (2 preceding siblings ...)
(?)
@ 2018-03-27 14:38 ` Michal Hocko
-1 siblings, 0 replies; 185+ messages in thread
From: Michal Hocko @ 2018-03-27 14:38 UTC (permalink / raw)
To: Ilya Smith
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
On Tue 27-03-18 16:51:08, Ilya Smith wrote:
>
> > On 27 Mar 2018, at 10:24, Michal Hocko <mhocko@kernel.org> wrote:
> >
> > On Mon 26-03-18 22:45:31, Ilya Smith wrote:
> >>
> >>> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
> >>>
> >>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
> >>>>
> >>>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
> >>>>>
> >>>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> >>>>>> Current implementation doesn't randomize address returned by mmap.
> >>>>>> All the entropy ends with choosing mmap_base_addr at the process
> >>>>>> creation. After that mmap build very predictable layout of address
> >>>>>> space. It allows to bypass ASLR in many cases. This patch make
> >>>>>> randomization of address on any mmap call.
> >>>>>
> >>>>> Why should this be done in the kernel rather than libc? libc is perfectly
> >>>>> capable of specifying random numbers in the first argument of mmap.
> >>>> Well, there is following reasons:
> >>>> 1. It should be done in any libc implementation, what is not possible IMO;
> >>>
> >>> Is this really so helpful?
> >>
> >> Yes, ASLR is one of very important mitigation techniques which are really used
> >> to protect applications. If there is no ASLR, it is very easy to exploit
> >> vulnerable application and compromise the system. We can’t just fix all the
> >> vulnerabilities right now, thats why we have mitigations - techniques which are
> >> makes exploitation more hard or impossible in some cases.
> >>
> >> Thats why it is helpful.
> >
> > I am not questioning ASLR in general. I am asking whether we really need
> > per mmap ASLR in general. I can imagine that some environments want to
> > pay the additional price and other side effects, but considering this
> > can be achieved by libc, why to add more code to the kernel?
>
> I believe this is the only one right place for it. Adding these 200+ lines of
> code we give this feature for any user - on desktop, on server, on IoT device,
> on SCADA, etc. But if only glibc will implement ‘user-mode-aslr’ IoT and SCADA
> devices will never get it.
I guess it would really help if you could be more specific about the
class of security issues this would help to mitigate. My first
understanding was that we we need some randomization between program
executable segments to reduce the attack space when a single address
leaks and you know the segments layout (ordering). But why do we need
_all_ mmaps to be randomized. Because that complicates the
implementation consirably for different reasons you have mentioned
earlier.
Do you have any specific CVE that would be mitigated by this
randomization approach?
I am sorry, I am not a security expert to see all the cosequences but a
vague - the more randomization the better - sounds rather weak to me.
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 14:38 ` Michal Hocko
0 siblings, 0 replies; 185+ messages in thread
From: Michal Hocko @ 2018-03-27 14:38 UTC (permalink / raw)
To: Ilya Smith
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal
On Tue 27-03-18 16:51:08, Ilya Smith wrote:
>
> > On 27 Mar 2018, at 10:24, Michal Hocko <mhocko@kernel.org> wrote:
> >
> > On Mon 26-03-18 22:45:31, Ilya Smith wrote:
> >>
> >>> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
> >>>
> >>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
> >>>>
> >>>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
> >>>>>
> >>>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> >>>>>> Current implementation doesn't randomize address returned by mmap.
> >>>>>> All the entropy ends with choosing mmap_base_addr at the process
> >>>>>> creation. After that mmap build very predictable layout of address
> >>>>>> space. It allows to bypass ASLR in many cases. This patch make
> >>>>>> randomization of address on any mmap call.
> >>>>>
> >>>>> Why should this be done in the kernel rather than libc? libc is perfectly
> >>>>> capable of specifying random numbers in the first argument of mmap.
> >>>> Well, there is following reasons:
> >>>> 1. It should be done in any libc implementation, what is not possible IMO;
> >>>
> >>> Is this really so helpful?
> >>
> >> Yes, ASLR is one of very important mitigation techniques which are really used
> >> to protect applications. If there is no ASLR, it is very easy to exploit
> >> vulnerable application and compromise the system. We can’t just fix all the
> >> vulnerabilities right now, thats why we have mitigations - techniques which are
> >> makes exploitation more hard or impossible in some cases.
> >>
> >> Thats why it is helpful.
> >
> > I am not questioning ASLR in general. I am asking whether we really need
> > per mmap ASLR in general. I can imagine that some environments want to
> > pay the additional price and other side effects, but considering this
> > can be achieved by libc, why to add more code to the kernel?
>
> I believe this is the only one right place for it. Adding these 200+ lines of
> code we give this feature for any user - on desktop, on server, on IoT device,
> on SCADA, etc. But if only glibc will implement ‘user-mode-aslr’ IoT and SCADA
> devices will never get it.
I guess it would really help if you could be more specific about the
class of security issues this would help to mitigate. My first
understanding was that we we need some randomization between program
executable segments to reduce the attack space when a single address
leaks and you know the segments layout (ordering). But why do we need
_all_ mmaps to be randomized. Because that complicates the
implementation consirably for different reasons you have mentioned
earlier.
Do you have any specific CVE that would be mitigated by this
randomization approach?
I am sorry, I am not a security expert to see all the cosequences but a
vague - the more randomization the better - sounds rather weak to me.
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 14:38 ` Michal Hocko
0 siblings, 0 replies; 185+ messages in thread
From: Michal Hocko @ 2018-03-27 14:38 UTC (permalink / raw)
To: Ilya Smith
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
On Tue 27-03-18 16:51:08, Ilya Smith wrote:
>
> > On 27 Mar 2018, at 10:24, Michal Hocko <mhocko@kernel.org> wrote:
> >
> > On Mon 26-03-18 22:45:31, Ilya Smith wrote:
> >>
> >>> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
> >>>
> >>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
> >>>>
> >>>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
> >>>>>
> >>>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> >>>>>> Current implementation doesn't randomize address returned by mmap.
> >>>>>> All the entropy ends with choosing mmap_base_addr at the process
> >>>>>> creation. After that mmap build very predictable layout of address
> >>>>>> space. It allows to bypass ASLR in many cases. This patch make
> >>>>>> randomization of address on any mmap call.
> >>>>>
> >>>>> Why should this be done in the kernel rather than libc? libc is perfectly
> >>>>> capable of specifying random numbers in the first argument of mmap.
> >>>> Well, there is following reasons:
> >>>> 1. It should be done in any libc implementation, what is not possible IMO;
> >>>
> >>> Is this really so helpful?
> >>
> >> Yes, ASLR is one of very important mitigation techniques which are really used
> >> to protect applications. If there is no ASLR, it is very easy to exploit
> >> vulnerable application and compromise the system. We can’t just fix all the
> >> vulnerabilities right now, thats why we have mitigations - techniques which are
> >> makes exploitation more hard or impossible in some cases.
> >>
> >> Thats why it is helpful.
> >
> > I am not questioning ASLR in general. I am asking whether we really need
> > per mmap ASLR in general. I can imagine that some environments want to
> > pay the additional price and other side effects, but considering this
> > can be achieved by libc, why to add more code to the kernel?
>
> I believe this is the only one right place for it. Adding these 200+ lines of
> code we give this feature for any user - on desktop, on server, on IoT device,
> on SCADA, etc. But if only glibc will implement ‘user-mode-aslr’ IoT and SCADA
> devices will never get it.
I guess it would really help if you could be more specific about the
class of security issues this would help to mitigate. My first
understanding was that we we need some randomization between program
executable segments to reduce the attack space when a single address
leaks and you know the segments layout (ordering). But why do we need
_all_ mmaps to be randomized. Because that complicates the
implementation consirably for different reasons you have mentioned
earlier.
Do you have any specific CVE that would be mitigated by this
randomization approach?
I am sorry, I am not a security expert to see all the cosequences but a
vague - the more randomization the better - sounds rather weak to me.
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 14:38 ` Michal Hocko
0 siblings, 0 replies; 185+ messages in thread
From: Michal Hocko @ 2018-03-27 14:38 UTC (permalink / raw)
To: Ilya Smith
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
On Tue 27-03-18 16:51:08, Ilya Smith wrote:
>
> > On 27 Mar 2018, at 10:24, Michal Hocko <mhocko@kernel.org> wrote:
> >
> > On Mon 26-03-18 22:45:31, Ilya Smith wrote:
> >>
> >>> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
> >>>
> >>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
> >>>>
> >>>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
> >>>>>
> >>>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
> >>>>>> Current implementation doesn't randomize address returned by mmap.
> >>>>>> All the entropy ends with choosing mmap_base_addr at the process
> >>>>>> creation. After that mmap build very predictable layout of address
> >>>>>> space. It allows to bypass ASLR in many cases. This patch make
> >>>>>> randomization of address on any mmap call.
> >>>>>
> >>>>> Why should this be done in the kernel rather than libc? libc is perfectly
> >>>>> capable of specifying random numbers in the first argument of mmap.
> >>>> Well, there is following reasons:
> >>>> 1. It should be done in any libc implementation, what is not possible IMO;
> >>>
> >>> Is this really so helpful?
> >>
> >> Yes, ASLR is one of very important mitigation techniques which are really used
> >> to protect applications. If there is no ASLR, it is very easy to exploit
> >> vulnerable application and compromise the system. We cana??t just fix all the
> >> vulnerabilities right now, thats why we have mitigations - techniques which are
> >> makes exploitation more hard or impossible in some cases.
> >>
> >> Thats why it is helpful.
> >
> > I am not questioning ASLR in general. I am asking whether we really need
> > per mmap ASLR in general. I can imagine that some environments want to
> > pay the additional price and other side effects, but considering this
> > can be achieved by libc, why to add more code to the kernel?
>
> I believe this is the only one right place for it. Adding these 200+ lines of
> code we give this feature for any user - on desktop, on server, on IoT device,
> on SCADA, etc. But if only glibc will implement a??user-mode-aslra?? IoT and SCADA
> devices will never get it.
I guess it would really help if you could be more specific about the
class of security issues this would help to mitigate. My first
understanding was that we we need some randomization between program
executable segments to reduce the attack space when a single address
leaks and you know the segments layout (ordering). But why do we need
_all_ mmaps to be randomized. Because that complicates the
implementation consirably for different reasons you have mentioned
earlier.
Do you have any specific CVE that would be mitigated by this
randomization approach?
I am sorry, I am not a security expert to see all the cosequences but a
vague - the more randomization the better - sounds rather weak to me.
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 14:38 ` Michal Hocko
0 siblings, 0 replies; 185+ messages in thread
From: Michal Hocko @ 2018-03-27 14:38 UTC (permalink / raw)
To: linux-snps-arc
On Tue 27-03-18 16:51:08, Ilya Smith wrote:
>
> > On 27 Mar 2018,@10:24, Michal Hocko <mhocko@kernel.org> wrote:
> >
> > On Mon 26-03-18 22:45:31, Ilya Smith wrote:
> >>
> >>> On 26 Mar 2018,@11:46, Michal Hocko <mhocko@kernel.org> wrote:
> >>>
> >>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
> >>>>
> >>>>> On 23 Mar 2018,@15:48, Matthew Wilcox <willy@infradead.org> wrote:
> >>>>>
> >>>>> On Thu, Mar 22, 2018@07:36:36PM +0300, Ilya Smith wrote:
> >>>>>> Current implementation doesn't randomize address returned by mmap.
> >>>>>> All the entropy ends with choosing mmap_base_addr at the process
> >>>>>> creation. After that mmap build very predictable layout of address
> >>>>>> space. It allows to bypass ASLR in many cases. This patch make
> >>>>>> randomization of address on any mmap call.
> >>>>>
> >>>>> Why should this be done in the kernel rather than libc? libc is perfectly
> >>>>> capable of specifying random numbers in the first argument of mmap.
> >>>> Well, there is following reasons:
> >>>> 1. It should be done in any libc implementation, what is not possible IMO;
> >>>
> >>> Is this really so helpful?
> >>
> >> Yes, ASLR is one of very important mitigation techniques which are really used
> >> to protect applications. If there is no ASLR, it is very easy to exploit
> >> vulnerable application and compromise the system. We can?t just fix all the
> >> vulnerabilities right now, thats why we have mitigations - techniques which are
> >> makes exploitation more hard or impossible in some cases.
> >>
> >> Thats why it is helpful.
> >
> > I am not questioning ASLR in general. I am asking whether we really need
> > per mmap ASLR in general. I can imagine that some environments want to
> > pay the additional price and other side effects, but considering this
> > can be achieved by libc, why to add more code to the kernel?
>
> I believe this is the only one right place for it. Adding these 200+ lines of
> code we give this feature for any user - on desktop, on server, on IoT device,
> on SCADA, etc. But if only glibc will implement ?user-mode-aslr? IoT and SCADA
> devices will never get it.
I guess it would really help if you could be more specific about the
class of security issues this would help to mitigate. My first
understanding was that we we need some randomization between program
executable segments to reduce the attack space when a single address
leaks and you know the segments layout (ordering). But why do we need
_all_ mmaps to be randomized. Because that complicates the
implementation consirably for different reasons you have mentioned
earlier.
Do you have any specific CVE that would be mitigated by this
randomization approach?
I am sorry, I am not a security expert to see all the cosequences but a
vague - the more randomization the better - sounds rather weak to me.
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-27 13:51 ` Ilya Smith
` (2 preceding siblings ...)
(?)
@ 2018-03-27 22:16 ` Theodore Y. Ts'o
-1 siblings, 0 replies; 185+ messages in thread
From: Theodore Y. Ts'o @ 2018-03-27 22:16 UTC (permalink / raw)
To: Ilya Smith
Cc: Michal Hocko, Matthew Wilcox, rth, ink, mattst88, vgupta, linux,
tony.luck, fenghua.yu, ralf, jejb, Helge Deller, benh, paulus,
mpe, schwidefsky, heiko.carstens, ysato, dalias, davem, tglx,
mingo, hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel,
Hugh Dickins, kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
On Tue, Mar 27, 2018 at 04:51:08PM +0300, Ilya Smith wrote:
> > /dev/[u]random is not sufficient?
>
> Using /dev/[u]random makes 3 syscalls - open, read, close. This is a performance
> issue.
You may want to take a look at the getrandom(2) system call, which is
the recommended way getting secure random numbers from the kernel.
> > Well, I am pretty sure userspace can implement proper free ranges
> > tracking…
>
> I think we need to know what libc developers will say on implementing ASLR in
> user-mode. I am pretty sure they will say ‘nether’ or ‘some-day’. And problem
> of ASLR will stay forever.
Why can't you send patches to the libc developers?
Regards,
- Ted
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 22:16 ` Theodore Y. Ts'o
0 siblings, 0 replies; 185+ messages in thread
From: Theodore Y. Ts'o @ 2018-03-27 22:16 UTC (permalink / raw)
To: Ilya Smith
Cc: Michal Hocko, Matthew Wilcox, rth, ink, mattst88, vgupta, linux,
tony.luck, fenghua.yu, ralf, jejb, Helge Deller, benh, paulus,
mpe, schwidefsky, heiko.carstens, ysato, dalias, davem, tglx,
mingo, hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel,
Hugh Dickins, kstewart, pombredanne, Andrew Morton
On Tue, Mar 27, 2018 at 04:51:08PM +0300, Ilya Smith wrote:
> > /dev/[u]random is not sufficient?
>
> Using /dev/[u]random makes 3 syscalls - open, read, close. This is a performance
> issue.
You may want to take a look at the getrandom(2) system call, which is
the recommended way getting secure random numbers from the kernel.
> > Well, I am pretty sure userspace can implement proper free ranges
> > tracking…
>
> I think we need to know what libc developers will say on implementing ASLR in
> user-mode. I am pretty sure they will say ‘nether’ or ‘some-day’. And problem
> of ASLR will stay forever.
Why can't you send patches to the libc developers?
Regards,
- Ted
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 22:16 ` Theodore Y. Ts'o
0 siblings, 0 replies; 185+ messages in thread
From: Theodore Y. Ts'o @ 2018-03-27 22:16 UTC (permalink / raw)
To: Ilya Smith
Cc: Michal Hocko, Matthew Wilcox, rth, ink, mattst88, vgupta, linux,
tony.luck, fenghua.yu, ralf, jejb, Helge Deller, benh, paulus,
mpe, schwidefsky, heiko.carstens, ysato, dalias, davem, tglx,
mingo, hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel,
Hugh Dickins, kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
On Tue, Mar 27, 2018 at 04:51:08PM +0300, Ilya Smith wrote:
> > /dev/[u]random is not sufficient?
>
> Using /dev/[u]random makes 3 syscalls - open, read, close. This is a performance
> issue.
You may want to take a look at the getrandom(2) system call, which is
the recommended way getting secure random numbers from the kernel.
> > Well, I am pretty sure userspace can implement proper free ranges
> > tracking…
>
> I think we need to know what libc developers will say on implementing ASLR in
> user-mode. I am pretty sure they will say ‘nether’ or ‘some-day’. And problem
> of ASLR will stay forever.
Why can't you send patches to the libc developers?
Regards,
- Ted
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 22:16 ` Theodore Y. Ts'o
0 siblings, 0 replies; 185+ messages in thread
From: Theodore Y. Ts'o @ 2018-03-27 22:16 UTC (permalink / raw)
To: Ilya Smith
Cc: Michal Hocko, Matthew Wilcox, rth, ink, mattst88, vgupta, linux,
tony.luck, fenghua.yu, ralf, jejb, Helge Deller, benh, paulus,
mpe, schwidefsky, heiko.carstens, ysato, dalias, davem, tglx,
mingo, hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel,
Hugh Dickins, kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
On Tue, Mar 27, 2018 at 04:51:08PM +0300, Ilya Smith wrote:
> > /dev/[u]random is not sufficient?
>
> Using /dev/[u]random makes 3 syscalls - open, read, close. This is a performance
> issue.
You may want to take a look at the getrandom(2) system call, which is
the recommended way getting secure random numbers from the kernel.
> > Well, I am pretty sure userspace can implement proper free ranges
> > trackinga?|
>
> I think we need to know what libc developers will say on implementing ASLR in
> user-mode. I am pretty sure they will say a??nethera?? or a??some-daya??. And problem
> of ASLR will stay forever.
Why can't you send patches to the libc developers?
Regards,
- Ted
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 22:16 ` Theodore Y. Ts'o
0 siblings, 0 replies; 185+ messages in thread
From: Theodore Y. Ts'o @ 2018-03-27 22:16 UTC (permalink / raw)
To: Ilya Smith
Cc: Michal Hocko, Matthew Wilcox, rth, ink, mattst88, vgupta, linux,
tony.luck, fenghua.yu, ralf, jejb, Helge Deller, benh, paulus,
mpe, schwidefsky, heiko.carstens, ysato, dalias, davem, tglx,
mingo, hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel,
Hugh Dickins, kstewart, pombredanne, Andrew Morton
On Tue, Mar 27, 2018 at 04:51:08PM +0300, Ilya Smith wrote:
> > /dev/[u]random is not sufficient?
>
> Using /dev/[u]random makes 3 syscalls - open, read, close. This is a performance
> issue.
You may want to take a look at the getrandom(2) system call, which is
the recommended way getting secure random numbers from the kernel.
> > Well, I am pretty sure userspace can implement proper free ranges
> > tracking…
>
> I think we need to know what libc developers will say on implementing ASLR in
> user-mode. I am pretty sure they will say ‘nether’ or ‘some-day’. And problem
> of ASLR will stay forever.
Why can't you send patches to the libc developers?
Regards,
- Ted
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-27 13:51 ` Ilya Smith
` (2 preceding siblings ...)
(?)
@ 2018-03-27 22:53 ` Kees Cook
-1 siblings, 0 replies; 185+ messages in thread
From: Kees Cook @ 2018-03-27 22:53 UTC (permalink / raw)
To: Ilya Smith
Cc: Kate Stewart, Linux MIPS Mailing List, Rich Felker, Jan Kara,
linux-sh, Benjamin Herrenschmidt, Bhupesh Sharma, Heiko Carstens,
Michal Hocko, Linux-MM, Paul Mackerras, Deepa Dinamani,
H. Peter Anvin, sparclinux, linux-ia64, Dan Williams,
Andrea Arcangeli, linux-s390, Yoshinori Sato, Michael Ellerman,
Helge Deller, X86 ML, Hugh Dickins, Russell King
T24gVHVlLCBNYXIgMjcsIDIwMTggYXQgNjo1MSBBTSwgSWx5YSBTbWl0aCA8YmxhY2t6ZXJ0QGdt
YWlsLmNvbT4gd3JvdGU6Cj4KPj4gT24gMjcgTWFyIDIwMTgsIGF0IDEwOjI0LCBNaWNoYWwgSG9j
a28gPG1ob2Nrb0BrZXJuZWwub3JnPiB3cm90ZToKPj4KPj4gT24gTW9uIDI2LTAzLTE4IDIyOjQ1
OjMxLCBJbHlhIFNtaXRoIHdyb3RlOgo+Pj4KPj4+PiBPbiAyNiBNYXIgMjAxOCwgYXQgMTE6NDYs
IE1pY2hhbCBIb2NrbyA8bWhvY2tvQGtlcm5lbC5vcmc+IHdyb3RlOgo+Pj4+Cj4+Pj4gT24gRnJp
IDIzLTAzLTE4IDIwOjU1OjQ5LCBJbHlhIFNtaXRoIHdyb3RlOgo+Pj4+Pgo+Pj4+Pj4gT24gMjMg
TWFyIDIwMTgsIGF0IDE1OjQ4LCBNYXR0aGV3IFdpbGNveCA8d2lsbHlAaW5mcmFkZWFkLm9yZz4g
d3JvdGU6Cj4+Pj4+Pgo+Pj4+Pj4gT24gVGh1LCBNYXIgMjIsIDIwMTggYXQgMDc6MzY6MzZQTSAr
MDMwMCwgSWx5YSBTbWl0aCB3cm90ZToKPj4+Pj4+PiBDdXJyZW50IGltcGxlbWVudGF0aW9uIGRv
ZXNuJ3QgcmFuZG9taXplIGFkZHJlc3MgcmV0dXJuZWQgYnkgbW1hcC4KPj4+Pj4+PiBBbGwgdGhl
IGVudHJvcHkgZW5kcyB3aXRoIGNob29zaW5nIG1tYXBfYmFzZV9hZGRyIGF0IHRoZSBwcm9jZXNz
Cj4+Pj4+Pj4gY3JlYXRpb24uIEFmdGVyIHRoYXQgbW1hcCBidWlsZCB2ZXJ5IHByZWRpY3RhYmxl
IGxheW91dCBvZiBhZGRyZXNzCj4+Pj4+Pj4gc3BhY2UuIEl0IGFsbG93cyB0byBieXBhc3MgQVNM
UiBpbiBtYW55IGNhc2VzLiBUaGlzIHBhdGNoIG1ha2UKPj4+Pj4+PiByYW5kb21pemF0aW9uIG9m
IGFkZHJlc3Mgb24gYW55IG1tYXAgY2FsbC4KPj4+Pj4+Cj4+Pj4+PiBXaHkgc2hvdWxkIHRoaXMg
YmUgZG9uZSBpbiB0aGUga2VybmVsIHJhdGhlciB0aGFuIGxpYmM/ICBsaWJjIGlzIHBlcmZlY3Rs
eQo+Pj4+Pj4gY2FwYWJsZSBvZiBzcGVjaWZ5aW5nIHJhbmRvbSBudW1iZXJzIGluIHRoZSBmaXJz
dCBhcmd1bWVudCBvZiBtbWFwLgo+Pj4+PiBXZWxsLCB0aGVyZSBpcyBmb2xsb3dpbmcgcmVhc29u
czoKPj4+Pj4gMS4gSXQgc2hvdWxkIGJlIGRvbmUgaW4gYW55IGxpYmMgaW1wbGVtZW50YXRpb24s
IHdoYXQgaXMgbm90IHBvc3NpYmxlIElNTzsKPj4+Pgo+Pj4+IElzIHRoaXMgcmVhbGx5IHNvIGhl
bHBmdWw/Cj4+Pgo+Pj4gWWVzLCBBU0xSIGlzIG9uZSBvZiB2ZXJ5IGltcG9ydGFudCBtaXRpZ2F0
aW9uIHRlY2huaXF1ZXMgd2hpY2ggYXJlIHJlYWxseSB1c2VkCj4+PiB0byBwcm90ZWN0IGFwcGxp
Y2F0aW9ucy4gSWYgdGhlcmUgaXMgbm8gQVNMUiwgaXQgaXMgdmVyeSBlYXN5IHRvIGV4cGxvaXQK
Pj4+IHZ1bG5lcmFibGUgYXBwbGljYXRpb24gYW5kIGNvbXByb21pc2UgdGhlIHN5c3RlbS4gV2Ug
Y2Fu4oCZdCBqdXN0IGZpeCBhbGwgdGhlCj4+PiB2dWxuZXJhYmlsaXRpZXMgcmlnaHQgbm93LCB0
aGF0cyB3aHkgd2UgaGF2ZSBtaXRpZ2F0aW9ucyAtIHRlY2huaXF1ZXMgd2hpY2ggYXJlCj4+PiBt
YWtlcyBleHBsb2l0YXRpb24gbW9yZSBoYXJkIG9yIGltcG9zc2libGUgaW4gc29tZSBjYXNlcy4K
Pj4+Cj4+PiBUaGF0cyB3aHkgaXQgaXMgaGVscGZ1bC4KPj4KPj4gSSBhbSBub3QgcXVlc3Rpb25p
bmcgQVNMUiBpbiBnZW5lcmFsLiBJIGFtIGFza2luZyB3aGV0aGVyIHdlIHJlYWxseSBuZWVkCj4+
IHBlciBtbWFwIEFTTFIgaW4gZ2VuZXJhbC4gSSBjYW4gaW1hZ2luZSB0aGF0IHNvbWUgZW52aXJv
bm1lbnRzIHdhbnQgdG8KPj4gcGF5IHRoZSBhZGRpdGlvbmFsIHByaWNlIGFuZCBvdGhlciBzaWRl
IGVmZmVjdHMsIGJ1dCBjb25zaWRlcmluZyB0aGlzCj4+IGNhbiBiZSBhY2hpZXZlZCBieSBsaWJj
LCB3aHkgdG8gYWRkIG1vcmUgY29kZSB0byB0aGUga2VybmVsPwo+Cj4gSSBiZWxpZXZlIHRoaXMg
aXMgdGhlIG9ubHkgb25lIHJpZ2h0IHBsYWNlIGZvciBpdC4gQWRkaW5nIHRoZXNlIDIwMCsgbGlu
ZXMgb2YKPiBjb2RlIHdlIGdpdmUgdGhpcyBmZWF0dXJlIGZvciBhbnkgdXNlciAtIG9uIGRlc2t0
b3AsIG9uIHNlcnZlciwgb24gSW9UIGRldmljZSwKPiBvbiBTQ0FEQSwgZXRjLiBCdXQgaWYgb25s
eSBnbGliYyB3aWxsIGltcGxlbWVudCDigJh1c2VyLW1vZGUtYXNscuKAmSBJb1QgYW5kIFNDQURB
Cj4gZGV2aWNlcyB3aWxsIG5ldmVyIGdldCBpdC4KCkkgYWdyZWU6IHB1c2hpbmcgdGhpcyBvZmYg
dG8gbGliYyBsZWF2ZXMgYSBsb3Qgb2YgdGhpbmdzIHVucHJvdGVjdGVkLgpJIHRoaW5rIHRoaXMg
c2hvdWxkIGxpdmUgaW4gdGhlIGtlcm5lbC4gVGhlIHF1ZXN0aW9uIEkgaGF2ZSBpcyBhYm91dApt
YWtpbmcgaXQgbWFpbnRhaW5hYmxlL3JlYWRhYmxlL2V0Yy4KClRoZSBzdGF0ZS1vZi10aGUtYXJ0
IGZvciBBU0xSIGlzIG1vdmluZyB0byBmaW5lciBncmFudWxhcml0eSAob3ZlcgpqdXN0IGJhc2Ut
YWRkcmVzcyBvZmZzZXQpLCBzbyBJJ2QgcmVhbGx5IGxpa2UgdG8gc2VlIHRoaXMgc3VwcG9ydGVk
IGluCnRoZSBrZXJuZWwuIFdlJ2xsIGJlIGdldHRpbmcgdGhlcmUgZm9yIG90aGVyIHRoaW5ncyBp
biB0aGUgZnV0dXJlLCBhbmQKSSdkIGxpa2UgdG8gaGF2ZSBhIHdvcmtpbmcgcHJvZHVjdGlvbiBl
eGFtcGxlIGZvciByZXNlYXJjaGVycyB0bwpzdHVkeSwgZXRjLgoKLUtlZXMKCi0tIApLZWVzIENv
b2sKUGl4ZWwgU2VjdXJpdHkKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fCmxpbnV4LXNucHMtYXJjIG1haWxpbmcgbGlzdApsaW51eC1zbnBzLWFyY0BsaXN0
cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGlu
Zm8vbGludXgtc25wcy1hcmM=
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 22:53 ` Kees Cook
0 siblings, 0 replies; 185+ messages in thread
From: Kees Cook @ 2018-03-27 22:53 UTC (permalink / raw)
To: Ilya Smith
Cc: Michal Hocko, Matthew Wilcox, Richard Henderson, ink, mattst88,
Vineet Gupta, Russell King, Tony Luck, Fenghua Yu, Ralf Baechle,
James E.J. Bottomley, Helge Deller, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Martin Schwidefsky,
Heiko Carstens, Yoshinori Sato, Rich Felker, David S. Miller,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, X86 ML, nyc,
Al Viro, Arnd Bergmann, Greg KH, Deepa Dinamani, Hugh Dickins,
Kate Stewart, Philippe Ombredanne, Andrew Morton, Steve Capper,
Punit Agrawal, Aneesh Kumar K.V, Nick Piggin, Bhupesh Sharma,
Rik van Riel, nitin.m.gupta, Kirill A. Shutemov, Dan Williams,
Jan Kara, Ross Zwisler, Jerome Glisse, Andrea Arcangeli,
Oleg Nesterov, linux-alpha, LKML, linux-snps-arc, linux-ia64,
linux-metag, Linux MIPS Mailing List, linux-parisc, PowerPC,
linux-s390, linux-sh, sparclinux, Linux-MM
On Tue, Mar 27, 2018 at 6:51 AM, Ilya Smith <blackzert@gmail.com> wrote:
>
>> On 27 Mar 2018, at 10:24, Michal Hocko <mhocko@kernel.org> wrote:
>>
>> On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>>>
>>>> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
>>>>
>>>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>>>>
>>>>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
>>>>>>
>>>>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>>>>> Current implementation doesn't randomize address returned by mmap.
>>>>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>>>>> creation. After that mmap build very predictable layout of address
>>>>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>>>>> randomization of address on any mmap call.
>>>>>>
>>>>>> Why should this be done in the kernel rather than libc? libc is perfectly
>>>>>> capable of specifying random numbers in the first argument of mmap.
>>>>> Well, there is following reasons:
>>>>> 1. It should be done in any libc implementation, what is not possible IMO;
>>>>
>>>> Is this really so helpful?
>>>
>>> Yes, ASLR is one of very important mitigation techniques which are really used
>>> to protect applications. If there is no ASLR, it is very easy to exploit
>>> vulnerable application and compromise the system. We can’t just fix all the
>>> vulnerabilities right now, thats why we have mitigations - techniques which are
>>> makes exploitation more hard or impossible in some cases.
>>>
>>> Thats why it is helpful.
>>
>> I am not questioning ASLR in general. I am asking whether we really need
>> per mmap ASLR in general. I can imagine that some environments want to
>> pay the additional price and other side effects, but considering this
>> can be achieved by libc, why to add more code to the kernel?
>
> I believe this is the only one right place for it. Adding these 200+ lines of
> code we give this feature for any user - on desktop, on server, on IoT device,
> on SCADA, etc. But if only glibc will implement ‘user-mode-aslr’ IoT and SCADA
> devices will never get it.
I agree: pushing this off to libc leaves a lot of things unprotected.
I think this should live in the kernel. The question I have is about
making it maintainable/readable/etc.
The state-of-the-art for ASLR is moving to finer granularity (over
just base-address offset), so I'd really like to see this supported in
the kernel. We'll be getting there for other things in the future, and
I'd like to have a working production example for researchers to
study, etc.
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 22:53 ` Kees Cook
0 siblings, 0 replies; 185+ messages in thread
From: Kees Cook @ 2018-03-27 22:53 UTC (permalink / raw)
To: Ilya Smith
Cc: Michal Hocko, Matthew Wilcox, Richard Henderson, ink, mattst88,
Vineet Gupta, Russell King, Tony Luck, Fenghua Yu, Ralf Baechle,
James E.J. Bottomley, Helge Deller, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Martin Schwidefsky,
Heiko Carstens, Yoshinori Sato, Rich Felker, David S. Miller,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, X86 ML, nyc,
Al Viro, Arnd Bergmann, Greg KH, Deepa Dinamani, Hugh Dickins,
Kate Stewart, Philippe Ombredanne, Andrew Morton, Steve Capper,
Punit Agrawal, Aneesh Kumar K.V, Nick Piggin, Bhupesh Sharma,
Rik van Riel, nitin.m.gupta, Kirill A. Shutemov, Dan Williams,
Jan Kara, Ross Zwisler, Jerome Glisse, Andrea Arcangeli,
Oleg Nesterov, linux-alpha, LKML, linux-snps-arc, linux-ia64,
linux-metag, Linux MIPS Mailing List, linux-parisc, PowerPC,
linux-s390, linux-sh, sparclinux, Linux-MM
On Tue, Mar 27, 2018 at 6:51 AM, Ilya Smith <blackzert@gmail.com> wrote:
>
>> On 27 Mar 2018, at 10:24, Michal Hocko <mhocko@kernel.org> wrote:
>>
>> On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>>>
>>>> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
>>>>
>>>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>>>>
>>>>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote=
:
>>>>>>
>>>>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>>>>> Current implementation doesn't randomize address returned by mmap.
>>>>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>>>>> creation. After that mmap build very predictable layout of address
>>>>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>>>>> randomization of address on any mmap call.
>>>>>>
>>>>>> Why should this be done in the kernel rather than libc? libc is per=
fectly
>>>>>> capable of specifying random numbers in the first argument of mmap.
>>>>> Well, there is following reasons:
>>>>> 1. It should be done in any libc implementation, what is not possible=
IMO;
>>>>
>>>> Is this really so helpful?
>>>
>>> Yes, ASLR is one of very important mitigation techniques which are real=
ly used
>>> to protect applications. If there is no ASLR, it is very easy to exploi=
t
>>> vulnerable application and compromise the system. We can=E2=80=99t just=
fix all the
>>> vulnerabilities right now, thats why we have mitigations - techniques w=
hich are
>>> makes exploitation more hard or impossible in some cases.
>>>
>>> Thats why it is helpful.
>>
>> I am not questioning ASLR in general. I am asking whether we really need
>> per mmap ASLR in general. I can imagine that some environments want to
>> pay the additional price and other side effects, but considering this
>> can be achieved by libc, why to add more code to the kernel?
>
> I believe this is the only one right place for it. Adding these 200+ line=
s of
> code we give this feature for any user - on desktop, on server, on IoT de=
vice,
> on SCADA, etc. But if only glibc will implement =E2=80=98user-mode-aslr=
=E2=80=99 IoT and SCADA
> devices will never get it.
I agree: pushing this off to libc leaves a lot of things unprotected.
I think this should live in the kernel. The question I have is about
making it maintainable/readable/etc.
The state-of-the-art for ASLR is moving to finer granularity (over
just base-address offset), so I'd really like to see this supported in
the kernel. We'll be getting there for other things in the future, and
I'd like to have a working production example for researchers to
study, etc.
-Kees
--=20
Kees Cook
Pixel Security
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 22:53 ` Kees Cook
0 siblings, 0 replies; 185+ messages in thread
From: Kees Cook @ 2018-03-27 22:53 UTC (permalink / raw)
To: linux-snps-arc
On Tue, Mar 27, 2018@6:51 AM, Ilya Smith <blackzert@gmail.com> wrote:
>
>> On 27 Mar 2018,@10:24, Michal Hocko <mhocko@kernel.org> wrote:
>>
>> On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>>>
>>>> On 26 Mar 2018,@11:46, Michal Hocko <mhocko@kernel.org> wrote:
>>>>
>>>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>>>>
>>>>>> On 23 Mar 2018,@15:48, Matthew Wilcox <willy@infradead.org> wrote:
>>>>>>
>>>>>> On Thu, Mar 22, 2018@07:36:36PM +0300, Ilya Smith wrote:
>>>>>>> Current implementation doesn't randomize address returned by mmap.
>>>>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>>>>> creation. After that mmap build very predictable layout of address
>>>>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>>>>> randomization of address on any mmap call.
>>>>>>
>>>>>> Why should this be done in the kernel rather than libc? libc is perfectly
>>>>>> capable of specifying random numbers in the first argument of mmap.
>>>>> Well, there is following reasons:
>>>>> 1. It should be done in any libc implementation, what is not possible IMO;
>>>>
>>>> Is this really so helpful?
>>>
>>> Yes, ASLR is one of very important mitigation techniques which are really used
>>> to protect applications. If there is no ASLR, it is very easy to exploit
>>> vulnerable application and compromise the system. We can?t just fix all the
>>> vulnerabilities right now, thats why we have mitigations - techniques which are
>>> makes exploitation more hard or impossible in some cases.
>>>
>>> Thats why it is helpful.
>>
>> I am not questioning ASLR in general. I am asking whether we really need
>> per mmap ASLR in general. I can imagine that some environments want to
>> pay the additional price and other side effects, but considering this
>> can be achieved by libc, why to add more code to the kernel?
>
> I believe this is the only one right place for it. Adding these 200+ lines of
> code we give this feature for any user - on desktop, on server, on IoT device,
> on SCADA, etc. But if only glibc will implement ?user-mode-aslr? IoT and SCADA
> devices will never get it.
I agree: pushing this off to libc leaves a lot of things unprotected.
I think this should live in the kernel. The question I have is about
making it maintainable/readable/etc.
The state-of-the-art for ASLR is moving to finer granularity (over
just base-address offset), so I'd really like to see this supported in
the kernel. We'll be getting there for other things in the future, and
I'd like to have a working production example for researchers to
study, etc.
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 22:53 ` Kees Cook
0 siblings, 0 replies; 185+ messages in thread
From: Kees Cook @ 2018-03-27 22:53 UTC (permalink / raw)
To: Ilya Smith
Cc: Kate Stewart, Linux MIPS Mailing List, Rich Felker, Jan Kara,
linux-sh, Benjamin Herrenschmidt, Bhupesh Sharma, Heiko Carstens,
Michal Hocko, Linux-MM, Paul Mackerras, Deepa Dinamani,
H. Peter Anvin, sparclinux, linux-ia64, Dan Williams,
Andrea Arcangeli, linux-s390, Yoshinori Sato, Michael Ellerman,
Helge Deller, X86 ML, Hugh Dickins, Russell King
On Tue, Mar 27, 2018 at 6:51 AM, Ilya Smith <blackzert@gmail.com> wrote:
>
>> On 27 Mar 2018, at 10:24, Michal Hocko <mhocko@kernel.org> wrote:
>>
>> On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>>>
>>>> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
>>>>
>>>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>>>>
>>>>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
>>>>>>
>>>>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>>>>> Current implementation doesn't randomize address returned by mmap.
>>>>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>>>>> creation. After that mmap build very predictable layout of address
>>>>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>>>>> randomization of address on any mmap call.
>>>>>>
>>>>>> Why should this be done in the kernel rather than libc? libc is perfectly
>>>>>> capable of specifying random numbers in the first argument of mmap.
>>>>> Well, there is following reasons:
>>>>> 1. It should be done in any libc implementation, what is not possible IMO;
>>>>
>>>> Is this really so helpful?
>>>
>>> Yes, ASLR is one of very important mitigation techniques which are really used
>>> to protect applications. If there is no ASLR, it is very easy to exploit
>>> vulnerable application and compromise the system. We can’t just fix all the
>>> vulnerabilities right now, thats why we have mitigations - techniques which are
>>> makes exploitation more hard or impossible in some cases.
>>>
>>> Thats why it is helpful.
>>
>> I am not questioning ASLR in general. I am asking whether we really need
>> per mmap ASLR in general. I can imagine that some environments want to
>> pay the additional price and other side effects, but considering this
>> can be achieved by libc, why to add more code to the kernel?
>
> I believe this is the only one right place for it. Adding these 200+ lines of
> code we give this feature for any user - on desktop, on server, on IoT device,
> on SCADA, etc. But if only glibc will implement ‘user-mode-aslr’ IoT and SCADA
> devices will never get it.
I agree: pushing this off to libc leaves a lot of things unprotected.
I think this should live in the kernel. The question I have is about
making it maintainable/readable/etc.
The state-of-the-art for ASLR is moving to finer granularity (over
just base-address offset), so I'd really like to see this supported in
the kernel. We'll be getting there for other things in the future, and
I'd like to have a working production example for researchers to
study, etc.
-Kees
--
Kees Cook
Pixel Security
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-27 22:53 ` Kees Cook
(?)
(?)
@ 2018-03-27 23:49 ` Matthew Wilcox
-1 siblings, 0 replies; 185+ messages in thread
From: Matthew Wilcox @ 2018-03-27 23:49 UTC (permalink / raw)
To: Kees Cook
Cc: Kate Stewart, Linux MIPS Mailing List, Rich Felker, Jan Kara,
linux-sh, Ilya Smith, Benjamin Herrenschmidt, Bhupesh Sharma,
Heiko Carstens, Michal Hocko, Linux-MM, Paul Mackerras,
Deepa Dinamani, H. Peter Anvin, sparclinux, linux-ia64,
Dan Williams, Andrea Arcangeli, linux-s390, Yoshinori Sato,
Michael Ellerman, Helge Deller, X86 ML, Hugh Dickins
On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote:
> I agree: pushing this off to libc leaves a lot of things unprotected.
> I think this should live in the kernel. The question I have is about
> making it maintainable/readable/etc.
>
> The state-of-the-art for ASLR is moving to finer granularity (over
> just base-address offset), so I'd really like to see this supported in
> the kernel. We'll be getting there for other things in the future, and
> I'd like to have a working production example for researchers to
> study, etc.
One thing we need is to limit the fragmentation of this approach.
Even on 64-bit systems, we can easily get into a situation where there isn't
space to map a contiguous terabyte.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 23:49 ` Matthew Wilcox
0 siblings, 0 replies; 185+ messages in thread
From: Matthew Wilcox @ 2018-03-27 23:49 UTC (permalink / raw)
To: Kees Cook
Cc: Ilya Smith, Michal Hocko, Richard Henderson, ink, mattst88,
Vineet Gupta, Russell King, Tony Luck, Fenghua Yu, Ralf Baechle,
James E.J. Bottomley, Helge Deller, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Martin Schwidefsky,
Heiko Carstens, Yoshinori Sato, Rich Felker, David S. Miller,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, X86 ML, nyc,
Al Viro, Arnd Bergmann, Greg KH, Deepa Dinamani, Hugh Dickins,
Kate Stewart, Philippe Ombredanne, Andrew Morton, Steve Capper,
Punit Agrawal, Aneesh Kumar K.V, Nick Piggin, Bhupesh Sharma,
Rik van Riel, nitin.m.gupta, Kirill A. Shutemov, Dan Williams,
Jan Kara, Ross Zwisler, Jerome Glisse, Andrea Arcangeli,
Oleg Nesterov, linux-alpha, LKML, linux-snps-arc, linux-ia64,
linux-metag, Linux MIPS Mailing List, linux-parisc, PowerPC,
linux-s390, linux-sh, sparclinux, Linux-MM
On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote:
> I agree: pushing this off to libc leaves a lot of things unprotected.
> I think this should live in the kernel. The question I have is about
> making it maintainable/readable/etc.
>
> The state-of-the-art for ASLR is moving to finer granularity (over
> just base-address offset), so I'd really like to see this supported in
> the kernel. We'll be getting there for other things in the future, and
> I'd like to have a working production example for researchers to
> study, etc.
One thing we need is to limit the fragmentation of this approach.
Even on 64-bit systems, we can easily get into a situation where there isn't
space to map a contiguous terabyte.
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 23:49 ` Matthew Wilcox
0 siblings, 0 replies; 185+ messages in thread
From: Matthew Wilcox @ 2018-03-27 23:49 UTC (permalink / raw)
To: linux-snps-arc
On Tue, Mar 27, 2018@03:53:53PM -0700, Kees Cook wrote:
> I agree: pushing this off to libc leaves a lot of things unprotected.
> I think this should live in the kernel. The question I have is about
> making it maintainable/readable/etc.
>
> The state-of-the-art for ASLR is moving to finer granularity (over
> just base-address offset), so I'd really like to see this supported in
> the kernel. We'll be getting there for other things in the future, and
> I'd like to have a working production example for researchers to
> study, etc.
One thing we need is to limit the fragmentation of this approach.
Even on 64-bit systems, we can easily get into a situation where there isn't
space to map a contiguous terabyte.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 23:49 ` Matthew Wilcox
0 siblings, 0 replies; 185+ messages in thread
From: Matthew Wilcox @ 2018-03-27 23:49 UTC (permalink / raw)
To: Kees Cook
Cc: Kate Stewart, Linux MIPS Mailing List, Rich Felker, Jan Kara,
linux-sh, Ilya Smith, Benjamin Herrenschmidt, Bhupesh Sharma,
Heiko Carstens, Michal Hocko, Linux-MM, Paul Mackerras,
Deepa Dinamani, H. Peter Anvin, sparclinux, linux-ia64,
Dan Williams, Andrea Arcangeli, linux-s390, Yoshinori Sato,
Michael Ellerman, Helge Deller, X86 ML, Hugh Dickins
On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote:
> I agree: pushing this off to libc leaves a lot of things unprotected.
> I think this should live in the kernel. The question I have is about
> making it maintainable/readable/etc.
>
> The state-of-the-art for ASLR is moving to finer granularity (over
> just base-address offset), so I'd really like to see this supported in
> the kernel. We'll be getting there for other things in the future, and
> I'd like to have a working production example for researchers to
> study, etc.
One thing we need is to limit the fragmentation of this approach.
Even on 64-bit systems, we can easily get into a situation where there isn't
space to map a contiguous terabyte.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-27 23:49 ` Matthew Wilcox
(?)
(?)
@ 2018-03-27 23:57 ` Kees Cook
-1 siblings, 0 replies; 185+ messages in thread
From: Kees Cook @ 2018-03-27 23:57 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Kate Stewart, Linux MIPS Mailing List, Rich Felker, Jan Kara,
linux-sh, Ilya Smith, Benjamin Herrenschmidt, Bhupesh Sharma,
Heiko Carstens, Michal Hocko, Linux-MM, Paul Mackerras,
Deepa Dinamani, H. Peter Anvin, sparclinux, linux-ia64,
Dan Williams, Andrea Arcangeli, linux-s390, Yoshinori Sato,
Michael Ellerman, Helge Deller, X86 ML, Hugh Dickins
On Tue, Mar 27, 2018 at 4:49 PM, Matthew Wilcox <willy@infradead.org> wrote:
> On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote:
>> I agree: pushing this off to libc leaves a lot of things unprotected.
>> I think this should live in the kernel. The question I have is about
>> making it maintainable/readable/etc.
>>
>> The state-of-the-art for ASLR is moving to finer granularity (over
>> just base-address offset), so I'd really like to see this supported in
>> the kernel. We'll be getting there for other things in the future, and
>> I'd like to have a working production example for researchers to
>> study, etc.
>
> One thing we need is to limit the fragmentation of this approach.
> Even on 64-bit systems, we can easily get into a situation where there isn't
> space to map a contiguous terabyte.
FWIW, I wouldn't expect normal systems to use this. I am curious about
fragmentation vs entropy though. Are workloads with a mis of lots of
tiny allocations and TB-allocations? AIUI, glibc uses larger mmap()
regions for handling tiny mallocs().
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 23:57 ` Kees Cook
0 siblings, 0 replies; 185+ messages in thread
From: Kees Cook @ 2018-03-27 23:57 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Ilya Smith, Michal Hocko, Richard Henderson, ink, mattst88,
Vineet Gupta, Russell King, Tony Luck, Fenghua Yu, Ralf Baechle,
James E.J. Bottomley, Helge Deller, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Martin Schwidefsky,
Heiko Carstens, Yoshinori Sato, Rich Felker, David S. Miller,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, X86 ML, nyc,
Al Viro, Arnd Bergmann, Greg KH, Deepa Dinamani, Hugh Dickins,
Kate Stewart, Philippe Ombredanne, Andrew Morton, Steve Capper,
Punit Agrawal, Aneesh Kumar K.V, Nick Piggin, Bhupesh Sharma,
Rik van Riel, nitin.m.gupta, Kirill A. Shutemov, Dan Williams,
Jan Kara, Ross Zwisler, Jerome Glisse, Andrea Arcangeli,
Oleg Nesterov, linux-alpha, LKML, linux-snps-arc, linux-ia64,
linux-metag, Linux MIPS Mailing List, linux-parisc, PowerPC,
linux-s390, linux-sh, sparclinux, Linux-MM
On Tue, Mar 27, 2018 at 4:49 PM, Matthew Wilcox <willy@infradead.org> wrote:
> On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote:
>> I agree: pushing this off to libc leaves a lot of things unprotected.
>> I think this should live in the kernel. The question I have is about
>> making it maintainable/readable/etc.
>>
>> The state-of-the-art for ASLR is moving to finer granularity (over
>> just base-address offset), so I'd really like to see this supported in
>> the kernel. We'll be getting there for other things in the future, and
>> I'd like to have a working production example for researchers to
>> study, etc.
>
> One thing we need is to limit the fragmentation of this approach.
> Even on 64-bit systems, we can easily get into a situation where there isn't
> space to map a contiguous terabyte.
FWIW, I wouldn't expect normal systems to use this. I am curious about
fragmentation vs entropy though. Are workloads with a mis of lots of
tiny allocations and TB-allocations? AIUI, glibc uses larger mmap()
regions for handling tiny mallocs().
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 23:57 ` Kees Cook
0 siblings, 0 replies; 185+ messages in thread
From: Kees Cook @ 2018-03-27 23:57 UTC (permalink / raw)
To: linux-snps-arc
On Tue, Mar 27, 2018@4:49 PM, Matthew Wilcox <willy@infradead.org> wrote:
> On Tue, Mar 27, 2018@03:53:53PM -0700, Kees Cook wrote:
>> I agree: pushing this off to libc leaves a lot of things unprotected.
>> I think this should live in the kernel. The question I have is about
>> making it maintainable/readable/etc.
>>
>> The state-of-the-art for ASLR is moving to finer granularity (over
>> just base-address offset), so I'd really like to see this supported in
>> the kernel. We'll be getting there for other things in the future, and
>> I'd like to have a working production example for researchers to
>> study, etc.
>
> One thing we need is to limit the fragmentation of this approach.
> Even on 64-bit systems, we can easily get into a situation where there isn't
> space to map a contiguous terabyte.
FWIW, I wouldn't expect normal systems to use this. I am curious about
fragmentation vs entropy though. Are workloads with a mis of lots of
tiny allocations and TB-allocations? AIUI, glibc uses larger mmap()
regions for handling tiny mallocs().
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 23:57 ` Kees Cook
0 siblings, 0 replies; 185+ messages in thread
From: Kees Cook @ 2018-03-27 23:57 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Kate Stewart, Linux MIPS Mailing List, Rich Felker, Jan Kara,
linux-sh, Ilya Smith, Benjamin Herrenschmidt, Bhupesh Sharma,
Heiko Carstens, Michal Hocko, Linux-MM, Paul Mackerras,
Deepa Dinamani, H. Peter Anvin, sparclinux, linux-ia64,
Dan Williams, Andrea Arcangeli, linux-s390, Yoshinori Sato,
Michael Ellerman, Helge Deller, X86 ML, Hugh Dickins
On Tue, Mar 27, 2018 at 4:49 PM, Matthew Wilcox <willy@infradead.org> wrote:
> On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote:
>> I agree: pushing this off to libc leaves a lot of things unprotected.
>> I think this should live in the kernel. The question I have is about
>> making it maintainable/readable/etc.
>>
>> The state-of-the-art for ASLR is moving to finer granularity (over
>> just base-address offset), so I'd really like to see this supported in
>> the kernel. We'll be getting there for other things in the future, and
>> I'd like to have a working production example for researchers to
>> study, etc.
>
> One thing we need is to limit the fragmentation of this approach.
> Even on 64-bit systems, we can easily get into a situation where there isn't
> space to map a contiguous terabyte.
FWIW, I wouldn't expect normal systems to use this. I am curious about
fragmentation vs entropy though. Are workloads with a mis of lots of
tiny allocations and TB-allocations? AIUI, glibc uses larger mmap()
regions for handling tiny mallocs().
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-27 22:16 ` Theodore Y. Ts'o
(?)
(?)
@ 2018-03-27 23:58 ` Rich Felker
-1 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-27 23:58 UTC (permalink / raw)
To: Theodore Y. Ts'o, Ilya Smith, Michal Hocko, Matthew Wilcox,
rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, ralf,
jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, davem, tglx, mingo, hpa, x86, nyc, viro,
arnd, gregkh, deepa.kernel, Hugh Dickins, kstewart, pombredanne,
Andrew Morton, steve.capper, punit.agrawal, aneesh.kumar,
npiggin, Kees Cook, bhsharma, riel, nitin.m.gupta,
Kirill A. Shutemov, Dan Williams, Jan Kara, ross.zwisler,
Jerome Glisse, Andrea Arcangeli, Oleg Nesterov, linux-alpha,
LKML, linux-snps-arc, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
Linux-MM
On Tue, Mar 27, 2018 at 06:16:35PM -0400, Theodore Y. Ts'o wrote:
> On Tue, Mar 27, 2018 at 04:51:08PM +0300, Ilya Smith wrote:
> > > /dev/[u]random is not sufficient?
> >
> > Using /dev/[u]random makes 3 syscalls - open, read, close. This is a performance
> > issue.
>
> You may want to take a look at the getrandom(2) system call, which is
> the recommended way getting secure random numbers from the kernel.
Yes, while opening /dev/urandom is not acceptable due to needing an
fd, getrandom and existing fallbacks for it have this covered if
needed.
> > > Well, I am pretty sure userspace can implement proper free ranges
> > > tracking…
> >
> > I think we need to know what libc developers will say on implementing ASLR in
> > user-mode. I am pretty sure they will say ‘nether’ or ‘some-day’. And problem
> > of ASLR will stay forever.
>
> Why can't you send patches to the libc developers?
I can tell you right now that any patch submitted for musl that
depended on trying to duplicate knowledge of the entire virtual
address space layout in userspace as part of mmap would be rejected,
and I would recommend glibc do the same.
Not only does it vastly increase complexity; it also has all sorts of
failure modes (fd exhastion, etc.) which would either introduce new
and unwanted ways for mmap to fail, or would force fallback to the
normal (no extra randomization) strategy under conditions an attacker
could potentially control, defeating the whole purpose. It would also
potentially make it easier for an attacker to examine the vm layout
for attacks, since it would be recorded in userspace.
There's also the issue of preserving AS-safety of mmap. POSIX does not
actually require mmap to be AS-safe, and on musl munmap is not fully
AS-safe anyway because of some obscure issues it compensates for, but
we may be able to make it AS-safe (this is a low-priority open issue).
If mmap were manipulating data structures representing the vm space in
userspace, though, the only way to make it anywhere near AS-safe would
be to block all signals and take a lock every time mmap or munmap is
called. This would significantly increase the cost of each call,
especially now that meltdown/spectre mitigations have greatly
increased the overhead of each syscall.
Overall, asking userspace to take a lead role in management of process
vm space is a radical change in the split of what user and kernel are
responsible for, and it really does not make sense as part of a
dubious hardening measure. Something this big would need to be really
well-motivated.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 23:58 ` Rich Felker
0 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-27 23:58 UTC (permalink / raw)
To: Theodore Y. Ts'o, Ilya Smith, Michal Hocko, Matthew Wilcox,
rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, ralf,
jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, davem, tglx, mingo, hpa, x86, nyc, viro,
arnd, gregkh, deepa.kernel, Hugh Dickins, kstewart, pombredanne,
Andrew Morton, steve.capper, punit.agrawal, aneesh.kumar,
npiggin, Kees Cook, bhsharma, riel, nitin.m.gupta,
Kirill A. Shutemov, Dan Williams, Jan Kara, ross.zwisler,
Jerome Glisse, Andrea Arcangeli, Oleg Nesterov, linux-alpha,
LKML, linux-snps-arc, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
Linux-MM
On Tue, Mar 27, 2018 at 06:16:35PM -0400, Theodore Y. Ts'o wrote:
> On Tue, Mar 27, 2018 at 04:51:08PM +0300, Ilya Smith wrote:
> > > /dev/[u]random is not sufficient?
> >
> > Using /dev/[u]random makes 3 syscalls - open, read, close. This is a performance
> > issue.
>
> You may want to take a look at the getrandom(2) system call, which is
> the recommended way getting secure random numbers from the kernel.
Yes, while opening /dev/urandom is not acceptable due to needing an
fd, getrandom and existing fallbacks for it have this covered if
needed.
> > > Well, I am pretty sure userspace can implement proper free ranges
> > > tracking…
> >
> > I think we need to know what libc developers will say on implementing ASLR in
> > user-mode. I am pretty sure they will say ‘nether’ or ‘some-day’. And problem
> > of ASLR will stay forever.
>
> Why can't you send patches to the libc developers?
I can tell you right now that any patch submitted for musl that
depended on trying to duplicate knowledge of the entire virtual
address space layout in userspace as part of mmap would be rejected,
and I would recommend glibc do the same.
Not only does it vastly increase complexity; it also has all sorts of
failure modes (fd exhastion, etc.) which would either introduce new
and unwanted ways for mmap to fail, or would force fallback to the
normal (no extra randomization) strategy under conditions an attacker
could potentially control, defeating the whole purpose. It would also
potentially make it easier for an attacker to examine the vm layout
for attacks, since it would be recorded in userspace.
There's also the issue of preserving AS-safety of mmap. POSIX does not
actually require mmap to be AS-safe, and on musl munmap is not fully
AS-safe anyway because of some obscure issues it compensates for, but
we may be able to make it AS-safe (this is a low-priority open issue).
If mmap were manipulating data structures representing the vm space in
userspace, though, the only way to make it anywhere near AS-safe would
be to block all signals and take a lock every time mmap or munmap is
called. This would significantly increase the cost of each call,
especially now that meltdown/spectre mitigations have greatly
increased the overhead of each syscall.
Overall, asking userspace to take a lead role in management of process
vm space is a radical change in the split of what user and kernel are
responsible for, and it really does not make sense as part of a
dubious hardening measure. Something this big would need to be really
well-motivated.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 23:58 ` Rich Felker
0 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-27 23:58 UTC (permalink / raw)
To: Theodore Y. Ts'o, Ilya Smith, Michal Hocko, Matthew Wilcox,
rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, ralf,
jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, davem, tglx, mingo, hpa, x86, nyc, viro,
arnd, gregkh, deepa.kernel, Hugh Dickins, kstewart, pombredanne,
Andrew Morton, steve.capper, punit.agrawal, aneesh.kumar,
npiggin, Kees Cook, bhsharma, riel, nitin.m.gupta,
Kirill A. Shutemov, Dan Williams, Jan Kara, ross.zwisler,
Jerome Glisse, Andrea Arcangeli, Oleg Nesterov, linux-alpha,
LKML, linux-snps-arc, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
Linux-MM
On Tue, Mar 27, 2018 at 06:16:35PM -0400, Theodore Y. Ts'o wrote:
> On Tue, Mar 27, 2018 at 04:51:08PM +0300, Ilya Smith wrote:
> > > /dev/[u]random is not sufficient?
> >
> > Using /dev/[u]random makes 3 syscalls - open, read, close. This is a performance
> > issue.
>
> You may want to take a look at the getrandom(2) system call, which is
> the recommended way getting secure random numbers from the kernel.
Yes, while opening /dev/urandom is not acceptable due to needing an
fd, getrandom and existing fallbacks for it have this covered if
needed.
> > > Well, I am pretty sure userspace can implement proper free ranges
> > > trackinga?|
> >
> > I think we need to know what libc developers will say on implementing ASLR in
> > user-mode. I am pretty sure they will say a??nethera?? or a??some-daya??. And problem
> > of ASLR will stay forever.
>
> Why can't you send patches to the libc developers?
I can tell you right now that any patch submitted for musl that
depended on trying to duplicate knowledge of the entire virtual
address space layout in userspace as part of mmap would be rejected,
and I would recommend glibc do the same.
Not only does it vastly increase complexity; it also has all sorts of
failure modes (fd exhastion, etc.) which would either introduce new
and unwanted ways for mmap to fail, or would force fallback to the
normal (no extra randomization) strategy under conditions an attacker
could potentially control, defeating the whole purpose. It would also
potentially make it easier for an attacker to examine the vm layout
for attacks, since it would be recorded in userspace.
There's also the issue of preserving AS-safety of mmap. POSIX does not
actually require mmap to be AS-safe, and on musl munmap is not fully
AS-safe anyway because of some obscure issues it compensates for, but
we may be able to make it AS-safe (this is a low-priority open issue).
If mmap were manipulating data structures representing the vm space in
userspace, though, the only way to make it anywhere near AS-safe would
be to block all signals and take a lock every time mmap or munmap is
called. This would significantly increase the cost of each call,
especially now that meltdown/spectre mitigations have greatly
increased the overhead of each syscall.
Overall, asking userspace to take a lead role in management of process
vm space is a radical change in the split of what user and kernel are
responsible for, and it really does not make sense as part of a
dubious hardening measure. Something this big would need to be really
well-motivated.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-27 23:58 ` Rich Felker
0 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-27 23:58 UTC (permalink / raw)
To: linux-snps-arc
On Tue, Mar 27, 2018@06:16:35PM -0400, Theodore Y. Ts'o wrote:
> On Tue, Mar 27, 2018@04:51:08PM +0300, Ilya Smith wrote:
> > > /dev/[u]random is not sufficient?
> >
> > Using /dev/[u]random makes 3 syscalls - open, read, close. This is a performance
> > issue.
>
> You may want to take a look at the getrandom(2) system call, which is
> the recommended way getting secure random numbers from the kernel.
Yes, while opening /dev/urandom is not acceptable due to needing an
fd, getrandom and existing fallbacks for it have this covered if
needed.
> > > Well, I am pretty sure userspace can implement proper free ranges
> > > tracking?
> >
> > I think we need to know what libc developers will say on implementing ASLR in
> > user-mode. I am pretty sure they will say ?nether? or ?some-day?. And problem
> > of ASLR will stay forever.
>
> Why can't you send patches to the libc developers?
I can tell you right now that any patch submitted for musl that
depended on trying to duplicate knowledge of the entire virtual
address space layout in userspace as part of mmap would be rejected,
and I would recommend glibc do the same.
Not only does it vastly increase complexity; it also has all sorts of
failure modes (fd exhastion, etc.) which would either introduce new
and unwanted ways for mmap to fail, or would force fallback to the
normal (no extra randomization) strategy under conditions an attacker
could potentially control, defeating the whole purpose. It would also
potentially make it easier for an attacker to examine the vm layout
for attacks, since it would be recorded in userspace.
There's also the issue of preserving AS-safety of mmap. POSIX does not
actually require mmap to be AS-safe, and on musl munmap is not fully
AS-safe anyway because of some obscure issues it compensates for, but
we may be able to make it AS-safe (this is a low-priority open issue).
If mmap were manipulating data structures representing the vm space in
userspace, though, the only way to make it anywhere near AS-safe would
be to block all signals and take a lock every time mmap or munmap is
called. This would significantly increase the cost of each call,
especially now that meltdown/spectre mitigations have greatly
increased the overhead of each syscall.
Overall, asking userspace to take a lead role in management of process
vm space is a radical change in the split of what user and kernel are
responsible for, and it really does not make sense as part of a
dubious hardening measure. Something this big would need to be really
well-motivated.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-27 23:49 ` Matthew Wilcox
(?)
(?)
@ 2018-03-28 0:00 ` Rich Felker
-1 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-28 0:00 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Kate Stewart, Linux MIPS Mailing List, Jan Kara, linux-sh,
Ilya Smith, Benjamin Herrenschmidt, Bhupesh Sharma,
Heiko Carstens, Michal Hocko, Linux-MM, Paul Mackerras,
Deepa Dinamani, H. Peter Anvin, sparclinux, linux-ia64,
Dan Williams, Andrea Arcangeli, linux-s390, Yoshinori Sato,
Michael Ellerman, Helge Deller, X86 ML, Hugh Dickins,
Russell King
On Tue, Mar 27, 2018 at 04:49:04PM -0700, Matthew Wilcox wrote:
> On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote:
> > I agree: pushing this off to libc leaves a lot of things unprotected.
> > I think this should live in the kernel. The question I have is about
> > making it maintainable/readable/etc.
> >
> > The state-of-the-art for ASLR is moving to finer granularity (over
> > just base-address offset), so I'd really like to see this supported in
> > the kernel. We'll be getting there for other things in the future, and
> > I'd like to have a working production example for researchers to
> > study, etc.
>
> One thing we need is to limit the fragmentation of this approach.
> Even on 64-bit systems, we can easily get into a situation where there isn't
> space to map a contiguous terabyte.
The default limit of only 65536 VMAs will also quickly come into play
if consecutive anon mmaps don't get merged. Of course this can be
raised, but it has significant resource and performance (fork) costs.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 0:00 ` Rich Felker
0 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-28 0:00 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Kees Cook, Ilya Smith, Michal Hocko, Richard Henderson, ink,
mattst88, Vineet Gupta, Russell King, Tony Luck, Fenghua Yu,
Ralf Baechle, James E.J. Bottomley, Helge Deller,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Martin Schwidefsky, Heiko Carstens, Yoshinori Sato,
David S. Miller, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
X86 ML, nyc, Al Viro, Arnd Bergmann, Greg KH, Deepa Dinamani,
Hugh Dickins, Kate Stewart, Philippe Ombredanne, Andrew Morton,
Steve Capper, Punit Agrawal, Aneesh Kumar K.V, Nick Piggin,
Bhupesh Sharma, Rik van Riel, nitin.m.gupta, Kirill A. Shutemov,
Dan Williams, Jan Kara, Ross Zwisler, Jerome Glisse,
Andrea Arcangeli, Oleg Nesterov, linux-alpha, LKML,
linux-snps-arc, linux-ia64, linux-metag, Linux MIPS Mailing List,
linux-parisc, PowerPC, linux-s390, linux-sh, sparclinux,
Linux-MM
On Tue, Mar 27, 2018 at 04:49:04PM -0700, Matthew Wilcox wrote:
> On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote:
> > I agree: pushing this off to libc leaves a lot of things unprotected.
> > I think this should live in the kernel. The question I have is about
> > making it maintainable/readable/etc.
> >
> > The state-of-the-art for ASLR is moving to finer granularity (over
> > just base-address offset), so I'd really like to see this supported in
> > the kernel. We'll be getting there for other things in the future, and
> > I'd like to have a working production example for researchers to
> > study, etc.
>
> One thing we need is to limit the fragmentation of this approach.
> Even on 64-bit systems, we can easily get into a situation where there isn't
> space to map a contiguous terabyte.
The default limit of only 65536 VMAs will also quickly come into play
if consecutive anon mmaps don't get merged. Of course this can be
raised, but it has significant resource and performance (fork) costs.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 0:00 ` Rich Felker
0 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-28 0:00 UTC (permalink / raw)
To: linux-snps-arc
On Tue, Mar 27, 2018@04:49:04PM -0700, Matthew Wilcox wrote:
> On Tue, Mar 27, 2018@03:53:53PM -0700, Kees Cook wrote:
> > I agree: pushing this off to libc leaves a lot of things unprotected.
> > I think this should live in the kernel. The question I have is about
> > making it maintainable/readable/etc.
> >
> > The state-of-the-art for ASLR is moving to finer granularity (over
> > just base-address offset), so I'd really like to see this supported in
> > the kernel. We'll be getting there for other things in the future, and
> > I'd like to have a working production example for researchers to
> > study, etc.
>
> One thing we need is to limit the fragmentation of this approach.
> Even on 64-bit systems, we can easily get into a situation where there isn't
> space to map a contiguous terabyte.
The default limit of only 65536 VMAs will also quickly come into play
if consecutive anon mmaps don't get merged. Of course this can be
raised, but it has significant resource and performance (fork) costs.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 0:00 ` Rich Felker
0 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-28 0:00 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Kate Stewart, Linux MIPS Mailing List, Jan Kara, linux-sh,
Ilya Smith, Benjamin Herrenschmidt, Bhupesh Sharma,
Heiko Carstens, Michal Hocko, Linux-MM, Paul Mackerras,
Deepa Dinamani, H. Peter Anvin, sparclinux, linux-ia64,
Dan Williams, Andrea Arcangeli, linux-s390, Yoshinori Sato,
Michael Ellerman, Helge Deller, X86 ML, Hugh Dickins,
Russell King
On Tue, Mar 27, 2018 at 04:49:04PM -0700, Matthew Wilcox wrote:
> On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote:
> > I agree: pushing this off to libc leaves a lot of things unprotected.
> > I think this should live in the kernel. The question I have is about
> > making it maintainable/readable/etc.
> >
> > The state-of-the-art for ASLR is moving to finer granularity (over
> > just base-address offset), so I'd really like to see this supported in
> > the kernel. We'll be getting there for other things in the future, and
> > I'd like to have a working production example for researchers to
> > study, etc.
>
> One thing we need is to limit the fragmentation of this approach.
> Even on 64-bit systems, we can easily get into a situation where there isn't
> space to map a contiguous terabyte.
The default limit of only 65536 VMAs will also quickly come into play
if consecutive anon mmaps don't get merged. Of course this can be
raised, but it has significant resource and performance (fork) costs.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-23 19:06 ` Matthew Wilcox
` (2 preceding siblings ...)
(?)
@ 2018-03-28 4:50 ` Rob Landley
-1 siblings, 0 replies; 185+ messages in thread
From: Rob Landley @ 2018-03-28 4:50 UTC (permalink / raw)
To: Matthew Wilcox, Rich Felker
Cc: Ilya Smith, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, jhogan, ralf, jejb, deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, davem, tglx, mingo, hpa, x86,
nyc, viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
On 03/23/2018 02:06 PM, Matthew Wilcox wrote:
> On Fri, Mar 23, 2018 at 02:00:24PM -0400, Rich Felker wrote:
>> On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote:
>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>> Current implementation doesn't randomize address returned by mmap.
>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>> creation. After that mmap build very predictable layout of address
>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>> randomization of address on any mmap call.
>>>
>>> Why should this be done in the kernel rather than libc? libc is perfectly
>>> capable of specifying random numbers in the first argument of mmap.
>>
>> Generally libc does not have a view of the current vm maps, and thus
>> in passing "random numbers", they would have to be uniform across the
>> whole vm space and thus non-uniform once the kernel rounds up to avoid
>> existing mappings.
>
> I'm aware that you're the musl author, but glibc somehow manages to
> provide etext, edata and end, demonstrating that it does know where at
> least some of the memory map lies.
You can parse /proc/self/maps, but it's really expensive and disgusting.
Rob
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 4:50 ` Rob Landley
0 siblings, 0 replies; 185+ messages in thread
From: Rob Landley @ 2018-03-28 4:50 UTC (permalink / raw)
To: Matthew Wilcox, Rich Felker
Cc: Ilya Smith, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, jhogan, ralf, jejb, deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, davem, tglx, mingo, hpa, x86,
nyc, viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton
On 03/23/2018 02:06 PM, Matthew Wilcox wrote:
> On Fri, Mar 23, 2018 at 02:00:24PM -0400, Rich Felker wrote:
>> On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote:
>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>> Current implementation doesn't randomize address returned by mmap.
>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>> creation. After that mmap build very predictable layout of address
>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>> randomization of address on any mmap call.
>>>
>>> Why should this be done in the kernel rather than libc? libc is perfectly
>>> capable of specifying random numbers in the first argument of mmap.
>>
>> Generally libc does not have a view of the current vm maps, and thus
>> in passing "random numbers", they would have to be uniform across the
>> whole vm space and thus non-uniform once the kernel rounds up to avoid
>> existing mappings.
>
> I'm aware that you're the musl author, but glibc somehow manages to
> provide etext, edata and end, demonstrating that it does know where at
> least some of the memory map lies.
You can parse /proc/self/maps, but it's really expensive and disgusting.
Rob
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 4:50 ` Rob Landley
0 siblings, 0 replies; 185+ messages in thread
From: Rob Landley @ 2018-03-28 4:50 UTC (permalink / raw)
To: Matthew Wilcox, Rich Felker
Cc: Ilya Smith, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, jhogan, ralf, jejb, deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, davem, tglx, mingo, hpa, x86,
nyc, viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
On 03/23/2018 02:06 PM, Matthew Wilcox wrote:
> On Fri, Mar 23, 2018 at 02:00:24PM -0400, Rich Felker wrote:
>> On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote:
>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>> Current implementation doesn't randomize address returned by mmap.
>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>> creation. After that mmap build very predictable layout of address
>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>> randomization of address on any mmap call.
>>>
>>> Why should this be done in the kernel rather than libc? libc is perfectly
>>> capable of specifying random numbers in the first argument of mmap.
>>
>> Generally libc does not have a view of the current vm maps, and thus
>> in passing "random numbers", they would have to be uniform across the
>> whole vm space and thus non-uniform once the kernel rounds up to avoid
>> existing mappings.
>
> I'm aware that you're the musl author, but glibc somehow manages to
> provide etext, edata and end, demonstrating that it does know where at
> least some of the memory map lies.
You can parse /proc/self/maps, but it's really expensive and disgusting.
Rob
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 4:50 ` Rob Landley
0 siblings, 0 replies; 185+ messages in thread
From: Rob Landley @ 2018-03-28 4:50 UTC (permalink / raw)
To: linux-snps-arc
On 03/23/2018 02:06 PM, Matthew Wilcox wrote:
> On Fri, Mar 23, 2018@02:00:24PM -0400, Rich Felker wrote:
>> On Fri, Mar 23, 2018@05:48:06AM -0700, Matthew Wilcox wrote:
>>> On Thu, Mar 22, 2018@07:36:36PM +0300, Ilya Smith wrote:
>>>> Current implementation doesn't randomize address returned by mmap.
>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>> creation. After that mmap build very predictable layout of address
>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>> randomization of address on any mmap call.
>>>
>>> Why should this be done in the kernel rather than libc? libc is perfectly
>>> capable of specifying random numbers in the first argument of mmap.
>>
>> Generally libc does not have a view of the current vm maps, and thus
>> in passing "random numbers", they would have to be uniform across the
>> whole vm space and thus non-uniform once the kernel rounds up to avoid
>> existing mappings.
>
> I'm aware that you're the musl author, but glibc somehow manages to
> provide etext, edata and end, demonstrating that it does know where at
> least some of the memory map lies.
You can parse /proc/self/maps, but it's really expensive and disgusting.
Rob
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 4:50 ` Rob Landley
0 siblings, 0 replies; 185+ messages in thread
From: Rob Landley @ 2018-03-28 4:50 UTC (permalink / raw)
To: Matthew Wilcox, Rich Felker
Cc: Ilya Smith, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, jhogan, ralf, jejb, deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, davem, tglx, mingo, hpa, x86,
nyc, viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton
On 03/23/2018 02:06 PM, Matthew Wilcox wrote:
> On Fri, Mar 23, 2018 at 02:00:24PM -0400, Rich Felker wrote:
>> On Fri, Mar 23, 2018 at 05:48:06AM -0700, Matthew Wilcox wrote:
>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>> Current implementation doesn't randomize address returned by mmap.
>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>> creation. After that mmap build very predictable layout of address
>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>> randomization of address on any mmap call.
>>>
>>> Why should this be done in the kernel rather than libc? libc is perfectly
>>> capable of specifying random numbers in the first argument of mmap.
>>
>> Generally libc does not have a view of the current vm maps, and thus
>> in passing "random numbers", they would have to be uniform across the
>> whole vm space and thus non-uniform once the kernel rounds up to avoid
>> existing mappings.
>
> I'm aware that you're the musl author, but glibc somehow manages to
> provide etext, edata and end, demonstrating that it does know where at
> least some of the memory map lies.
You can parse /proc/self/maps, but it's really expensive and disgusting.
Rob
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-27 14:38 ` Michal Hocko
` (3 preceding siblings ...)
(?)
@ 2018-03-28 18:47 ` Ilya Smith
-1 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-28 18:47 UTC (permalink / raw)
To: Michal Hocko
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
> On 27 Mar 2018, at 17:38, Michal Hocko <mhocko@kernel.org> wrote:
>
> On Tue 27-03-18 16:51:08, Ilya Smith wrote:
>>
>>> On 27 Mar 2018, at 10:24, Michal Hocko <mhocko@kernel.org> wrote:
>>>
>>> On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>>>>
>>>>> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
>>>>>
>>>>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>>>>>
>>>>>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
>>>>>>>
>>>>>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>>>>>> Current implementation doesn't randomize address returned by mmap.
>>>>>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>>>>>> creation. After that mmap build very predictable layout of address
>>>>>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>>>>>> randomization of address on any mmap call.
>>>>>>>
>>>>>>> Why should this be done in the kernel rather than libc? libc is perfectly
>>>>>>> capable of specifying random numbers in the first argument of mmap.
>>>>>> Well, there is following reasons:
>>>>>> 1. It should be done in any libc implementation, what is not possible IMO;
>>>>>
>>>>> Is this really so helpful?
>>>>
>>>> Yes, ASLR is one of very important mitigation techniques which are really used
>>>> to protect applications. If there is no ASLR, it is very easy to exploit
>>>> vulnerable application and compromise the system. We can’t just fix all the
>>>> vulnerabilities right now, thats why we have mitigations - techniques which are
>>>> makes exploitation more hard or impossible in some cases.
>>>>
>>>> Thats why it is helpful.
>>>
>>> I am not questioning ASLR in general. I am asking whether we really need
>>> per mmap ASLR in general. I can imagine that some environments want to
>>> pay the additional price and other side effects, but considering this
>>> can be achieved by libc, why to add more code to the kernel?
>>
>> I believe this is the only one right place for it. Adding these 200+ lines of
>> code we give this feature for any user - on desktop, on server, on IoT device,
>> on SCADA, etc. But if only glibc will implement ‘user-mode-aslr’ IoT and SCADA
>> devices will never get it.
>
> I guess it would really help if you could be more specific about the
> class of security issues this would help to mitigate. My first
> understanding was that we we need some randomization between program
> executable segments to reduce the attack space when a single address
> leaks and you know the segments layout (ordering). But why do we need
> _all_ mmaps to be randomized. Because that complicates the
> implementation consirably for different reasons you have mentioned
> earlier.
>
There are following reasons:
1) To protect layout if one region was leaked (as you said).
2) To protect against exploitation of Out-of-bounds vulnerabilities in some
cases (CWE-125 , CWE-787)
3) To protect against exploitation of Buffer Overflows in some cases (CWE-120)
4) To protect application in cases when attacker need to guess the address
(paper ASLR-NG by Hector Marco-Gisbert and Ismael Ripoll-Ripoll)
And may be more cases.
> Do you have any specific CVE that would be mitigated by this
> randomization approach?
> I am sorry, I am not a security expert to see all the cosequences but a
> vague - the more randomization the better - sounds rather weak to me.
It is hard to name concrete CVE number, sorry. Mitigations are made to prevent
exploitation but not to fix vulnerabilities. It means good mitigation will make
vulnerable application crash but not been compromised in most cases. This means
the better randomization, the less successful exploitation rate.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 18:47 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-28 18:47 UTC (permalink / raw)
To: Michal Hocko
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal
> On 27 Mar 2018, at 17:38, Michal Hocko <mhocko@kernel.org> wrote:
>=20
> On Tue 27-03-18 16:51:08, Ilya Smith wrote:
>>=20
>>> On 27 Mar 2018, at 10:24, Michal Hocko <mhocko@kernel.org> wrote:
>>>=20
>>> On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>>>>=20
>>>>> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
>>>>>=20
>>>>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>>>>>=20
>>>>>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> =
wrote:
>>>>>>>=20
>>>>>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>>>>>> Current implementation doesn't randomize address returned by =
mmap.
>>>>>>>> All the entropy ends with choosing mmap_base_addr at the =
process
>>>>>>>> creation. After that mmap build very predictable layout of =
address
>>>>>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>>>>>> randomization of address on any mmap call.
>>>>>>>=20
>>>>>>> Why should this be done in the kernel rather than libc? libc is =
perfectly
>>>>>>> capable of specifying random numbers in the first argument of =
mmap.
>>>>>> Well, there is following reasons:
>>>>>> 1. It should be done in any libc implementation, what is not =
possible IMO;
>>>>>=20
>>>>> Is this really so helpful?
>>>>=20
>>>> Yes, ASLR is one of very important mitigation techniques which are =
really used=20
>>>> to protect applications. If there is no ASLR, it is very easy to =
exploit=20
>>>> vulnerable application and compromise the system. We can=E2=80=99t =
just fix all the=20
>>>> vulnerabilities right now, thats why we have mitigations - =
techniques which are=20
>>>> makes exploitation more hard or impossible in some cases.
>>>>=20
>>>> Thats why it is helpful.
>>>=20
>>> I am not questioning ASLR in general. I am asking whether we really =
need
>>> per mmap ASLR in general. I can imagine that some environments want =
to
>>> pay the additional price and other side effects, but considering =
this
>>> can be achieved by libc, why to add more code to the kernel?
>>=20
>> I believe this is the only one right place for it. Adding these 200+ =
lines of=20
>> code we give this feature for any user - on desktop, on server, on =
IoT device,=20
>> on SCADA, etc. But if only glibc will implement =E2=80=98user-mode-aslr=
=E2=80=99 IoT and SCADA=20
>> devices will never get it.
>=20
> I guess it would really help if you could be more specific about the
> class of security issues this would help to mitigate. My first
> understanding was that we we need some randomization between program
> executable segments to reduce the attack space when a single address
> leaks and you know the segments layout (ordering). But why do we need
> _all_ mmaps to be randomized. Because that complicates the
> implementation consirably for different reasons you have mentioned
> earlier.
>=20
There are following reasons:
1) To protect layout if one region was leaked (as you said).=20
2) To protect against exploitation of Out-of-bounds vulnerabilities in =
some=20
cases (CWE-125 , CWE-787)
3) To protect against exploitation of Buffer Overflows in some cases =
(CWE-120)
4) To protect application in cases when attacker need to guess the =
address=20
(paper ASLR-NG by Hector Marco-Gisbert and Ismael Ripoll-Ripoll)
And may be more cases.
> Do you have any specific CVE that would be mitigated by this
> randomization approach?
> I am sorry, I am not a security expert to see all the cosequences but =
a
> vague - the more randomization the better - sounds rather weak to me.
It is hard to name concrete CVE number, sorry. Mitigations are made to =
prevent=20
exploitation but not to fix vulnerabilities. It means good mitigation =
will make=20
vulnerable application crash but not been compromised in most cases. =
This means=20
the better randomization, the less successful exploitation rate.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 18:47 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-28 18:47 UTC (permalink / raw)
To: Michal Hocko
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
> On 27 Mar 2018, at 17:38, Michal Hocko <mhocko@kernel.org> wrote:
>
> On Tue 27-03-18 16:51:08, Ilya Smith wrote:
>>
>>> On 27 Mar 2018, at 10:24, Michal Hocko <mhocko@kernel.org> wrote:
>>>
>>> On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>>>>
>>>>> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
>>>>>
>>>>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>>>>>
>>>>>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
>>>>>>>
>>>>>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>>>>>> Current implementation doesn't randomize address returned by mmap.
>>>>>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>>>>>> creation. After that mmap build very predictable layout of address
>>>>>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>>>>>> randomization of address on any mmap call.
>>>>>>>
>>>>>>> Why should this be done in the kernel rather than libc? libc is perfectly
>>>>>>> capable of specifying random numbers in the first argument of mmap.
>>>>>> Well, there is following reasons:
>>>>>> 1. It should be done in any libc implementation, what is not possible IMO;
>>>>>
>>>>> Is this really so helpful?
>>>>
>>>> Yes, ASLR is one of very important mitigation techniques which are really used
>>>> to protect applications. If there is no ASLR, it is very easy to exploit
>>>> vulnerable application and compromise the system. We can’t just fix all the
>>>> vulnerabilities right now, thats why we have mitigations - techniques which are
>>>> makes exploitation more hard or impossible in some cases.
>>>>
>>>> Thats why it is helpful.
>>>
>>> I am not questioning ASLR in general. I am asking whether we really need
>>> per mmap ASLR in general. I can imagine that some environments want to
>>> pay the additional price and other side effects, but considering this
>>> can be achieved by libc, why to add more code to the kernel?
>>
>> I believe this is the only one right place for it. Adding these 200+ lines of
>> code we give this feature for any user - on desktop, on server, on IoT device,
>> on SCADA, etc. But if only glibc will implement ‘user-mode-aslr’ IoT and SCADA
>> devices will never get it.
>
> I guess it would really help if you could be more specific about the
> class of security issues this would help to mitigate. My first
> understanding was that we we need some randomization between program
> executable segments to reduce the attack space when a single address
> leaks and you know the segments layout (ordering). But why do we need
> _all_ mmaps to be randomized. Because that complicates the
> implementation consirably for different reasons you have mentioned
> earlier.
>
There are following reasons:
1) To protect layout if one region was leaked (as you said).
2) To protect against exploitation of Out-of-bounds vulnerabilities in some
cases (CWE-125 , CWE-787)
3) To protect against exploitation of Buffer Overflows in some cases (CWE-120)
4) To protect application in cases when attacker need to guess the address
(paper ASLR-NG by Hector Marco-Gisbert and Ismael Ripoll-Ripoll)
And may be more cases.
> Do you have any specific CVE that would be mitigated by this
> randomization approach?
> I am sorry, I am not a security expert to see all the cosequences but a
> vague - the more randomization the better - sounds rather weak to me.
It is hard to name concrete CVE number, sorry. Mitigations are made to prevent
exploitation but not to fix vulnerabilities. It means good mitigation will make
vulnerable application crash but not been compromised in most cases. This means
the better randomization, the less successful exploitation rate.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 18:47 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-28 18:47 UTC (permalink / raw)
To: Michal Hocko
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
> On 27 Mar 2018, at 17:38, Michal Hocko <mhocko@kernel.org> wrote:
>=20
> On Tue 27-03-18 16:51:08, Ilya Smith wrote:
>>=20
>>> On 27 Mar 2018, at 10:24, Michal Hocko <mhocko@kernel.org> wrote:
>>>=20
>>> On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>>>>=20
>>>>> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
>>>>>=20
>>>>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>>>>>=20
>>>>>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> =
wrote:
>>>>>>>=20
>>>>>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>>>>>> Current implementation doesn't randomize address returned by =
mmap.
>>>>>>>> All the entropy ends with choosing mmap_base_addr at the =
process
>>>>>>>> creation. After that mmap build very predictable layout of =
address
>>>>>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>>>>>> randomization of address on any mmap call.
>>>>>>>=20
>>>>>>> Why should this be done in the kernel rather than libc? libc is =
perfectly
>>>>>>> capable of specifying random numbers in the first argument of =
mmap.
>>>>>> Well, there is following reasons:
>>>>>> 1. It should be done in any libc implementation, what is not =
possible IMO;
>>>>>=20
>>>>> Is this really so helpful?
>>>>=20
>>>> Yes, ASLR is one of very important mitigation techniques which are =
really used=20
>>>> to protect applications. If there is no ASLR, it is very easy to =
exploit=20
>>>> vulnerable application and compromise the system. We can=E2=80=99t =
just fix all the=20
>>>> vulnerabilities right now, thats why we have mitigations - =
techniques which are=20
>>>> makes exploitation more hard or impossible in some cases.
>>>>=20
>>>> Thats why it is helpful.
>>>=20
>>> I am not questioning ASLR in general. I am asking whether we really =
need
>>> per mmap ASLR in general. I can imagine that some environments want =
to
>>> pay the additional price and other side effects, but considering =
this
>>> can be achieved by libc, why to add more code to the kernel?
>>=20
>> I believe this is the only one right place for it. Adding these 200+ =
lines of=20
>> code we give this feature for any user - on desktop, on server, on =
IoT device,=20
>> on SCADA, etc. But if only glibc will implement =E2=80=98user-mode-aslr=
=E2=80=99 IoT and SCADA=20
>> devices will never get it.
>=20
> I guess it would really help if you could be more specific about the
> class of security issues this would help to mitigate. My first
> understanding was that we we need some randomization between program
> executable segments to reduce the attack space when a single address
> leaks and you know the segments layout (ordering). But why do we need
> _all_ mmaps to be randomized. Because that complicates the
> implementation consirably for different reasons you have mentioned
> earlier.
>=20
There are following reasons:
1) To protect layout if one region was leaked (as you said).=20
2) To protect against exploitation of Out-of-bounds vulnerabilities in =
some=20
cases (CWE-125 , CWE-787)
3) To protect against exploitation of Buffer Overflows in some cases =
(CWE-120)
4) To protect application in cases when attacker need to guess the =
address=20
(paper ASLR-NG by Hector Marco-Gisbert and Ismael Ripoll-Ripoll)
And may be more cases.
> Do you have any specific CVE that would be mitigated by this
> randomization approach?
> I am sorry, I am not a security expert to see all the cosequences but =
a
> vague - the more randomization the better - sounds rather weak to me.
It is hard to name concrete CVE number, sorry. Mitigations are made to =
prevent=20
exploitation but not to fix vulnerabilities. It means good mitigation =
will make=20
vulnerable application crash but not been compromised in most cases. =
This means=20
the better randomization, the less successful exploitation rate.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 18:47 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-28 18:47 UTC (permalink / raw)
To: linux-snps-arc
> On 27 Mar 2018,@17:38, Michal Hocko <mhocko@kernel.org> wrote:
>
> On Tue 27-03-18 16:51:08, Ilya Smith wrote:
>>
>>> On 27 Mar 2018,@10:24, Michal Hocko <mhocko@kernel.org> wrote:
>>>
>>> On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>>>>
>>>>> On 26 Mar 2018,@11:46, Michal Hocko <mhocko@kernel.org> wrote:
>>>>>
>>>>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>>>>>
>>>>>>> On 23 Mar 2018,@15:48, Matthew Wilcox <willy@infradead.org> wrote:
>>>>>>>
>>>>>>> On Thu, Mar 22, 2018@07:36:36PM +0300, Ilya Smith wrote:
>>>>>>>> Current implementation doesn't randomize address returned by mmap.
>>>>>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>>>>>> creation. After that mmap build very predictable layout of address
>>>>>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>>>>>> randomization of address on any mmap call.
>>>>>>>
>>>>>>> Why should this be done in the kernel rather than libc? libc is perfectly
>>>>>>> capable of specifying random numbers in the first argument of mmap.
>>>>>> Well, there is following reasons:
>>>>>> 1. It should be done in any libc implementation, what is not possible IMO;
>>>>>
>>>>> Is this really so helpful?
>>>>
>>>> Yes, ASLR is one of very important mitigation techniques which are really used
>>>> to protect applications. If there is no ASLR, it is very easy to exploit
>>>> vulnerable application and compromise the system. We can?t just fix all the
>>>> vulnerabilities right now, thats why we have mitigations - techniques which are
>>>> makes exploitation more hard or impossible in some cases.
>>>>
>>>> Thats why it is helpful.
>>>
>>> I am not questioning ASLR in general. I am asking whether we really need
>>> per mmap ASLR in general. I can imagine that some environments want to
>>> pay the additional price and other side effects, but considering this
>>> can be achieved by libc, why to add more code to the kernel?
>>
>> I believe this is the only one right place for it. Adding these 200+ lines of
>> code we give this feature for any user - on desktop, on server, on IoT device,
>> on SCADA, etc. But if only glibc will implement ?user-mode-aslr? IoT and SCADA
>> devices will never get it.
>
> I guess it would really help if you could be more specific about the
> class of security issues this would help to mitigate. My first
> understanding was that we we need some randomization between program
> executable segments to reduce the attack space when a single address
> leaks and you know the segments layout (ordering). But why do we need
> _all_ mmaps to be randomized. Because that complicates the
> implementation consirably for different reasons you have mentioned
> earlier.
>
There are following reasons:
1) To protect layout if one region was leaked (as you said).
2) To protect against exploitation of Out-of-bounds vulnerabilities in some
cases (CWE-125 , CWE-787)
3) To protect against exploitation of Buffer Overflows in some cases (CWE-120)
4) To protect application in cases when attacker need to guess the address
(paper ASLR-NG by Hector Marco-Gisbert and Ismael Ripoll-Ripoll)
And may be more cases.
> Do you have any specific CVE that would be mitigated by this
> randomization approach?
> I am sorry, I am not a security expert to see all the cosequences but a
> vague - the more randomization the better - sounds rather weak to me.
It is hard to name concrete CVE number, sorry. Mitigations are made to prevent
exploitation but not to fix vulnerabilities. It means good mitigation will make
vulnerable application crash but not been compromised in most cases. This means
the better randomization, the less successful exploitation rate.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 18:47 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-28 18:47 UTC (permalink / raw)
To: Michal Hocko
Cc: Matthew Wilcox, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, ralf, jejb, Helge Deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, dalias, davem, tglx, mingo,
hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel, Hugh Dickins,
kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal
> On 27 Mar 2018, at 17:38, Michal Hocko <mhocko@kernel.org> wrote:
>
> On Tue 27-03-18 16:51:08, Ilya Smith wrote:
>>
>>> On 27 Mar 2018, at 10:24, Michal Hocko <mhocko@kernel.org> wrote:
>>>
>>> On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>>>>
>>>>> On 26 Mar 2018, at 11:46, Michal Hocko <mhocko@kernel.org> wrote:
>>>>>
>>>>> On Fri 23-03-18 20:55:49, Ilya Smith wrote:
>>>>>>
>>>>>>> On 23 Mar 2018, at 15:48, Matthew Wilcox <willy@infradead.org> wrote:
>>>>>>>
>>>>>>> On Thu, Mar 22, 2018 at 07:36:36PM +0300, Ilya Smith wrote:
>>>>>>>> Current implementation doesn't randomize address returned by mmap.
>>>>>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>>>>>> creation. After that mmap build very predictable layout of address
>>>>>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>>>>>> randomization of address on any mmap call.
>>>>>>>
>>>>>>> Why should this be done in the kernel rather than libc? libc is perfectly
>>>>>>> capable of specifying random numbers in the first argument of mmap.
>>>>>> Well, there is following reasons:
>>>>>> 1. It should be done in any libc implementation, what is not possible IMO;
>>>>>
>>>>> Is this really so helpful?
>>>>
>>>> Yes, ASLR is one of very important mitigation techniques which are really used
>>>> to protect applications. If there is no ASLR, it is very easy to exploit
>>>> vulnerable application and compromise the system. We can’t just fix all the
>>>> vulnerabilities right now, thats why we have mitigations - techniques which are
>>>> makes exploitation more hard or impossible in some cases.
>>>>
>>>> Thats why it is helpful.
>>>
>>> I am not questioning ASLR in general. I am asking whether we really need
>>> per mmap ASLR in general. I can imagine that some environments want to
>>> pay the additional price and other side effects, but considering this
>>> can be achieved by libc, why to add more code to the kernel?
>>
>> I believe this is the only one right place for it. Adding these 200+ lines of
>> code we give this feature for any user - on desktop, on server, on IoT device,
>> on SCADA, etc. But if only glibc will implement ‘user-mode-aslr’ IoT and SCADA
>> devices will never get it.
>
> I guess it would really help if you could be more specific about the
> class of security issues this would help to mitigate. My first
> understanding was that we we need some randomization between program
> executable segments to reduce the attack space when a single address
> leaks and you know the segments layout (ordering). But why do we need
> _all_ mmaps to be randomized. Because that complicates the
> implementation consirably for different reasons you have mentioned
> earlier.
>
There are following reasons:
1) To protect layout if one region was leaked (as you said).
2) To protect against exploitation of Out-of-bounds vulnerabilities in some
cases (CWE-125 , CWE-787)
3) To protect against exploitation of Buffer Overflows in some cases (CWE-120)
4) To protect application in cases when attacker need to guess the address
(paper ASLR-NG by Hector Marco-Gisbert and Ismael Ripoll-Ripoll)
And may be more cases.
> Do you have any specific CVE that would be mitigated by this
> randomization approach?
> I am sorry, I am not a security expert to see all the cosequences but a
> vague - the more randomization the better - sounds rather weak to me.
It is hard to name concrete CVE number, sorry. Mitigations are made to prevent
exploitation but not to fix vulnerabilities. It means good mitigation will make
vulnerable application crash but not been compromised in most cases. This means
the better randomization, the less successful exploitation rate.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-27 22:16 ` Theodore Y. Ts'o
` (3 preceding siblings ...)
(?)
@ 2018-03-28 18:48 ` Ilya Smith
-1 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-28 18:48 UTC (permalink / raw)
To: Theodore Y. Ts'o
Cc: Michal Hocko, Matthew Wilcox, rth, ink, mattst88, vgupta, linux,
tony.luck, fenghua.yu, ralf, jejb, Helge Deller, benh, paulus,
mpe, schwidefsky, heiko.carstens, ysato, dalias, davem, tglx,
mingo, hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel,
Hugh Dickins, kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
> On 28 Mar 2018, at 01:16, Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> On Tue, Mar 27, 2018 at 04:51:08PM +0300, Ilya Smith wrote:
>>> /dev/[u]random is not sufficient?
>>
>> Using /dev/[u]random makes 3 syscalls - open, read, close. This is a performance
>> issue.
>
> You may want to take a look at the getrandom(2) system call, which is
> the recommended way getting secure random numbers from the kernel.
>
>>> Well, I am pretty sure userspace can implement proper free ranges
>>> tracking…
>>
>> I think we need to know what libc developers will say on implementing ASLR in
>> user-mode. I am pretty sure they will say ‘nether’ or ‘some-day’. And problem
>> of ASLR will stay forever.
>
> Why can't you send patches to the libc developers?
>
> Regards,
>
> - Ted
I still believe the issue is on kernel side, not in library.
Best regards,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 18:48 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-28 18:48 UTC (permalink / raw)
To: Theodore Y. Ts'o
Cc: Michal Hocko, Matthew Wilcox, rth, ink, mattst88, vgupta, linux,
tony.luck, fenghua.yu, ralf, jejb, Helge Deller, benh, paulus,
mpe, schwidefsky, heiko.carstens, ysato, dalias, davem, tglx,
mingo, hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel,
Hugh Dickins, kstewart, pombredanne, Andrew Morton
> On 28 Mar 2018, at 01:16, Theodore Y. Ts'o <tytso@mit.edu> wrote:
>=20
> On Tue, Mar 27, 2018 at 04:51:08PM +0300, Ilya Smith wrote:
>>> /dev/[u]random is not sufficient?
>>=20
>> Using /dev/[u]random makes 3 syscalls - open, read, close. This is a =
performance
>> issue.
>=20
> You may want to take a look at the getrandom(2) system call, which is
> the recommended way getting secure random numbers from the kernel.
>=20
>>> Well, I am pretty sure userspace can implement proper free ranges
>>> tracking=E2=80=A6
>>=20
>> I think we need to know what libc developers will say on implementing =
ASLR in=20
>> user-mode. I am pretty sure they will say =E2=80=98nether=E2=80=99 or =
=E2=80=98some-day=E2=80=99. And problem=20
>> of ASLR will stay forever.
>=20
> Why can't you send patches to the libc developers?
>=20
> Regards,
>=20
> - Ted
I still believe the issue is on kernel side, not in library.
Best regards,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 18:48 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-28 18:48 UTC (permalink / raw)
To: Theodore Y. Ts'o
Cc: Michal Hocko, Matthew Wilcox, rth, ink, mattst88, vgupta, linux,
tony.luck, fenghua.yu, ralf, jejb, Helge Deller, benh, paulus,
mpe, schwidefsky, heiko.carstens, ysato, dalias, davem, tglx,
mingo, hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel,
Hugh Dickins, kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
> On 28 Mar 2018, at 01:16, Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> On Tue, Mar 27, 2018 at 04:51:08PM +0300, Ilya Smith wrote:
>>> /dev/[u]random is not sufficient?
>>
>> Using /dev/[u]random makes 3 syscalls - open, read, close. This is a performance
>> issue.
>
> You may want to take a look at the getrandom(2) system call, which is
> the recommended way getting secure random numbers from the kernel.
>
>>> Well, I am pretty sure userspace can implement proper free ranges
>>> tracking…
>>
>> I think we need to know what libc developers will say on implementing ASLR in
>> user-mode. I am pretty sure they will say ‘nether’ or ‘some-day’. And problem
>> of ASLR will stay forever.
>
> Why can't you send patches to the libc developers?
>
> Regards,
>
> - Ted
I still believe the issue is on kernel side, not in library.
Best regards,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 18:48 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-28 18:48 UTC (permalink / raw)
To: Theodore Y. Ts'o
Cc: Michal Hocko, Matthew Wilcox, rth, ink, mattst88, vgupta, linux,
tony.luck, fenghua.yu, ralf, jejb, Helge Deller, benh, paulus,
mpe, schwidefsky, heiko.carstens, ysato, dalias, davem, tglx,
mingo, hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel,
Hugh Dickins, kstewart, pombredanne, Andrew Morton, steve.capper,
punit.agrawal, aneesh.kumar, npiggin, Kees Cook, bhsharma, riel,
nitin.m.gupta, Kirill A. Shutemov, Dan Williams, Jan Kara,
ross.zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, Linux-MM
> On 28 Mar 2018, at 01:16, Theodore Y. Ts'o <tytso@mit.edu> wrote:
>=20
> On Tue, Mar 27, 2018 at 04:51:08PM +0300, Ilya Smith wrote:
>>> /dev/[u]random is not sufficient?
>>=20
>> Using /dev/[u]random makes 3 syscalls - open, read, close. This is a =
performance
>> issue.
>=20
> You may want to take a look at the getrandom(2) system call, which is
> the recommended way getting secure random numbers from the kernel.
>=20
>>> Well, I am pretty sure userspace can implement proper free ranges
>>> tracking=E2=80=A6
>>=20
>> I think we need to know what libc developers will say on implementing =
ASLR in=20
>> user-mode. I am pretty sure they will say =E2=80=98nether=E2=80=99 or =
=E2=80=98some-day=E2=80=99. And problem=20
>> of ASLR will stay forever.
>=20
> Why can't you send patches to the libc developers?
>=20
> Regards,
>=20
> - Ted
I still believe the issue is on kernel side, not in library.
Best regards,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 18:48 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-28 18:48 UTC (permalink / raw)
To: linux-snps-arc
> On 28 Mar 2018,@01:16, Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> On Tue, Mar 27, 2018@04:51:08PM +0300, Ilya Smith wrote:
>>> /dev/[u]random is not sufficient?
>>
>> Using /dev/[u]random makes 3 syscalls - open, read, close. This is a performance
>> issue.
>
> You may want to take a look at the getrandom(2) system call, which is
> the recommended way getting secure random numbers from the kernel.
>
>>> Well, I am pretty sure userspace can implement proper free ranges
>>> tracking?
>>
>> I think we need to know what libc developers will say on implementing ASLR in
>> user-mode. I am pretty sure they will say ?nether? or ?some-day?. And problem
>> of ASLR will stay forever.
>
> Why can't you send patches to the libc developers?
>
> Regards,
>
> - Ted
I still believe the issue is on kernel side, not in library.
Best regards,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 18:48 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-28 18:48 UTC (permalink / raw)
To: Theodore Y. Ts'o
Cc: Michal Hocko, Matthew Wilcox, rth, ink, mattst88, vgupta, linux,
tony.luck, fenghua.yu, ralf, jejb, Helge Deller, benh, paulus,
mpe, schwidefsky, heiko.carstens, ysato, dalias, davem, tglx,
mingo, hpa, x86, nyc, viro, arnd, gregkh, deepa.kernel,
Hugh Dickins, kstewart, pombredanne, Andrew Morton
> On 28 Mar 2018, at 01:16, Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> On Tue, Mar 27, 2018 at 04:51:08PM +0300, Ilya Smith wrote:
>>> /dev/[u]random is not sufficient?
>>
>> Using /dev/[u]random makes 3 syscalls - open, read, close. This is a performance
>> issue.
>
> You may want to take a look at the getrandom(2) system call, which is
> the recommended way getting secure random numbers from the kernel.
>
>>> Well, I am pretty sure userspace can implement proper free ranges
>>> tracking…
>>
>> I think we need to know what libc developers will say on implementing ASLR in
>> user-mode. I am pretty sure they will say ‘nether’ or ‘some-day’. And problem
>> of ASLR will stay forever.
>
> Why can't you send patches to the libc developers?
>
> Regards,
>
> - Ted
I still believe the issue is on kernel side, not in library.
Best regards,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-28 0:00 ` Rich Felker
` (2 preceding siblings ...)
(?)
@ 2018-03-28 21:07 ` Luck, Tony
-1 siblings, 0 replies; 185+ messages in thread
From: Luck, Tony @ 2018-03-28 21:07 UTC (permalink / raw)
To: Rich Felker, Matthew Wilcox
Cc: Kate Stewart, Linux MIPS Mailing List, Jan Kara, linux-sh,
Ilya Smith, Bhupesh Sharma, Heiko Carstens, Michal Hocko,
Linux-MM, Paul Mackerras, Deepa Dinamani, H. Peter Anvin,
sparclinux, linux-ia64, Williams, Dan J, Andrea Arcangeli,
linux-s390, Yoshinori Sato, Helge Deller, X86 ML, Hugh Dickins,
Russell King, nitin.m.gupta@oracle.com
> The default limit of only 65536 VMAs will also quickly come into play
> if consecutive anon mmaps don't get merged. Of course this can be
> raised, but it has significant resource and performance (fork) costs.
Could the random mmap address chooser look for how many existing
VMAs have space before/after and the right attributes to merge with the
new one you want to create? If this is above some threshold (100?) then
pick one of them randomly and allocate the new address so that it will
merge from below/above with an existing one.
That should still give you a very high degree of randomness, but prevent
out of control numbers of VMAs from being created.
-Tony
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 21:07 ` Luck, Tony
0 siblings, 0 replies; 185+ messages in thread
From: Luck, Tony @ 2018-03-28 21:07 UTC (permalink / raw)
To: Rich Felker, Matthew Wilcox
Cc: Kees Cook, Ilya Smith, Michal Hocko, Richard Henderson, ink,
mattst88, Vineet Gupta, Russell King, Yu, Fenghua, Ralf Baechle,
James E.J. Bottomley, Helge Deller, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Martin Schwidefsky,
Heiko Carstens, Yoshinori Sato, David S. Miller, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, X86 ML, nyc, Al Viro, Arnd Bergmann,
Greg KH, Deepa Dinamani, Hugh Dickins, Kate Stewart,
Philippe Ombredanne, Andrew Morton, Steve Capper, Punit Agrawal,
Aneesh Kumar K.V, Nick Piggin, Bhupesh Sharma, Rik van Riel,
nitin.m.gupta, Kirill A. Shutemov, Williams, Dan J, Jan Kara,
Ross Zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
Linux MIPS Mailing List, linux-parisc, PowerPC, linux-s390,
linux-sh, sparclinux, Linux-MM
> The default limit of only 65536 VMAs will also quickly come into play
> if consecutive anon mmaps don't get merged. Of course this can be
> raised, but it has significant resource and performance (fork) costs.
Could the random mmap address chooser look for how many existing
VMAs have space before/after and the right attributes to merge with the
new one you want to create? If this is above some threshold (100?) then
pick one of them randomly and allocate the new address so that it will
merge from below/above with an existing one.
That should still give you a very high degree of randomness, but prevent
out of control numbers of VMAs from being created.
-Tony
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 21:07 ` Luck, Tony
0 siblings, 0 replies; 185+ messages in thread
From: Luck, Tony @ 2018-03-28 21:07 UTC (permalink / raw)
To: Rich Felker, Matthew Wilcox
Cc: Kees Cook, Ilya Smith, Michal Hocko, Richard Henderson, ink,
mattst88, Vineet Gupta, Russell King, Yu, Fenghua, Ralf Baechle,
James E.J. Bottomley, Helge Deller, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Martin Schwidefsky,
Heiko Carstens, Yoshinori Sato, David S. Miller, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, X86 ML, nyc, Al Viro, Arnd Bergmann,
Greg KH, Deepa Dinamani, Hugh Dickins, Kate Stewart,
Philippe Ombredanne, Andrew Morton, Steve Capper, Punit Agrawal,
Aneesh Kumar K.V, Nick Piggin, Bhupesh Sharma, Rik van Riel,
nitin.m.gupta, Kirill A. Shutemov, Williams, Dan J, Jan Kara,
Ross Zwisler, Jerome Glisse, Andrea Arcangeli, Oleg Nesterov,
linux-alpha, LKML, linux-snps-arc, linux-ia64, linux-metag,
Linux MIPS Mailing List, linux-parisc, PowerPC, linux-s390,
linux-sh, sparclinux, Linux-MM
> The default limit of only 65536 VMAs will also quickly come into play
> if consecutive anon mmaps don't get merged. Of course this can be
> raised, but it has significant resource and performance (fork) costs.
Could the random mmap address chooser look for how many existing
VMAs have space before/after and the right attributes to merge with the
new one you want to create? If this is above some threshold (100?) then
pick one of them randomly and allocate the new address so that it will
merge from below/above with an existing one.
That should still give you a very high degree of randomness, but prevent
out of control numbers of VMAs from being created.
-Tony
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 21:07 ` Luck, Tony
0 siblings, 0 replies; 185+ messages in thread
From: Luck, Tony @ 2018-03-28 21:07 UTC (permalink / raw)
To: linux-snps-arc
> The default limit of only 65536 VMAs will also quickly come into play
> if consecutive anon mmaps don't get merged. Of course this can be
> raised, but it has significant resource and performance (fork) costs.
Could the random mmap address chooser look for how many existing
VMAs have space before/after and the right attributes to merge with the
new one you want to create? If this is above some threshold (100?) then
pick one of them randomly and allocate the new address so that it will
merge from below/above with an existing one.
That should still give you a very high degree of randomness, but prevent
out of control numbers of VMAs from being created.
-Tony
^ permalink raw reply [flat|nested] 185+ messages in thread
* RE: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 21:07 ` Luck, Tony
0 siblings, 0 replies; 185+ messages in thread
From: Luck, Tony @ 2018-03-28 21:07 UTC (permalink / raw)
To: Rich Felker, Matthew Wilcox
Cc: Kate Stewart, Linux MIPS Mailing List, Jan Kara, linux-sh,
Ilya Smith, Bhupesh Sharma, Heiko Carstens, Michal Hocko,
Linux-MM, Paul Mackerras, Deepa Dinamani, H. Peter Anvin,
sparclinux, linux-ia64, Williams, Dan J, Andrea Arcangeli,
linux-s390, Yoshinori Sato, Helge Deller, X86 ML, Hugh Dickins,
Russell King, nitin.m.gupta@oracle.com
> The default limit of only 65536 VMAs will also quickly come into play
> if consecutive anon mmaps don't get merged. Of course this can be
> raised, but it has significant resource and performance (fork) costs.
Could the random mmap address chooser look for how many existing
VMAs have space before/after and the right attributes to merge with the
new one you want to create? If this is above some threshold (100?) then
pick one of them randomly and allocate the new address so that it will
merge from below/above with an existing one.
That should still give you a very high degree of randomness, but prevent
out of control numbers of VMAs from being created.
-Tony
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-27 23:49 ` Matthew Wilcox
` (2 preceding siblings ...)
(?)
@ 2018-03-28 21:07 ` Ilya Smith
-1 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-28 21:07 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Kate Stewart, Linux MIPS Mailing List, Rich Felker, Jan Kara,
linux-sh, Benjamin Herrenschmidt, Bhupesh Sharma, Heiko Carstens,
Michal Hocko, Linux-MM, Paul Mackerras, Deepa Dinamani,
H. Peter Anvin, sparclinux, linux-ia64, Dan Williams,
Andrea Arcangeli, linux-s390, Yoshinori Sato, Michael Ellerman,
Helge Deller, X86 ML, Hugh Dickins, Russell King
Cj4gT24gMjggTWFyIDIwMTgsIGF0IDAyOjQ5LCBNYXR0aGV3IFdpbGNveCA8d2lsbHlAaW5mcmFk
ZWFkLm9yZz4gd3JvdGU6Cj4gCj4gT24gVHVlLCBNYXIgMjcsIDIwMTggYXQgMDM6NTM6NTNQTSAt
MDcwMCwgS2VlcyBDb29rIHdyb3RlOgo+PiBJIGFncmVlOiBwdXNoaW5nIHRoaXMgb2ZmIHRvIGxp
YmMgbGVhdmVzIGEgbG90IG9mIHRoaW5ncyB1bnByb3RlY3RlZC4KPj4gSSB0aGluayB0aGlzIHNo
b3VsZCBsaXZlIGluIHRoZSBrZXJuZWwuIFRoZSBxdWVzdGlvbiBJIGhhdmUgaXMgYWJvdXQKPj4g
bWFraW5nIGl0IG1haW50YWluYWJsZS9yZWFkYWJsZS9ldGMuCj4+IAo+PiBUaGUgc3RhdGUtb2Yt
dGhlLWFydCBmb3IgQVNMUiBpcyBtb3ZpbmcgdG8gZmluZXIgZ3JhbnVsYXJpdHkgKG92ZXIKPj4g
anVzdCBiYXNlLWFkZHJlc3Mgb2Zmc2V0KSwgc28gSSdkIHJlYWxseSBsaWtlIHRvIHNlZSB0aGlz
IHN1cHBvcnRlZCBpbgo+PiB0aGUga2VybmVsLiBXZSdsbCBiZSBnZXR0aW5nIHRoZXJlIGZvciBv
dGhlciB0aGluZ3MgaW4gdGhlIGZ1dHVyZSwgYW5kCj4+IEknZCBsaWtlIHRvIGhhdmUgYSB3b3Jr
aW5nIHByb2R1Y3Rpb24gZXhhbXBsZSBmb3IgcmVzZWFyY2hlcnMgdG8KPj4gc3R1ZHksIGV0Yy4K
PiAKPiBPbmUgdGhpbmcgd2UgbmVlZCBpcyB0byBsaW1pdCB0aGUgZnJhZ21lbnRhdGlvbiBvZiB0
aGlzIGFwcHJvYWNoLgo+IEV2ZW4gb24gNjQtYml0IHN5c3RlbXMsIHdlIGNhbiBlYXNpbHkgZ2V0
IGludG8gYSBzaXR1YXRpb24gd2hlcmUgdGhlcmUgaXNuJ3QKPiBzcGFjZSB0byBtYXAgYSBjb250
aWd1b3VzIHRlcmFieXRlLgoKQXMgSSB3cm90ZSBiZWZvcmUsIHNoaWZ0X3JhbmRvbSBpcyBpbnRy
b2R1Y2VkIHRvIGJlIGZyYWdtZW50YXRpb24gbGltaXQuIEV2ZW4gCndpdGhvdXQgaXQsIHRoZSBt
YWluIHF1ZXN0aW9uIGhlcmUgaXMg4oCYaWYgd2UgY2Fu4oCZdCBhbGxvY2F0ZSBtZW1vcnkgd2l0
aCBOIHNpemUgCmJ5dGVzLCBob3cgbWFueSBieXRlcyB3ZSBhbHJlYWR5IGFsbG9jYXRlZD/igJku
IEZyb20gdGhlc2UgcG9pbnQgb2YgdmlldyBJIAphbHJlYWR5IHNob3dlZCBpbiBwcmV2aW91cyB2
ZXJzaW9uIG9mIHBhdGNoIHRoYXQgaWYgYXBwbGljYXRpb24gdXNlcyBub3Qgc28gYmlnIAptZW1v
cnkgYWxsb2NhdGlvbnMsIGl0IHdpbGwgaGF2ZSBlbm91Z2ggbWVtb3J5IHRvIHVzZS4gSWYgaXQg
dXNlcyBYWCBHaWdhYnl0ZXMgCm9yIFRlcmFieXRlcyBtZW1vcnksIHRoaXMgYXBwbGljYXRpb24g
aGFzIGFsbCBjaGFuY2VzIHRvIGJlIGV4cGxvaXRlZCB3aXRoIApmdWxseSByYW5kb21pemF0aW9u
IG9yIHdpdGhvdXQuIFNpbmNlIGl0IGlzIG11Y2ggZWFzaWVyIHRvIGZpbmQob3IgZ3Vlc3MpIGFu
eSAKdXNhYmxlIHBvaW50ZXIsIGV0Yy4gRm9yIHRoZSBpbnN0YW5jZSB5b3UgaGF2ZSBvbmx5IDEy
OCB0ZXJhYnl0ZXMgb2YgbWVtb3J5IGZvciAKdXNlciBzcGFjZSwgc28gcHJvYmFiaWxpdHkgdG8g
ZXhwbG9pdCB0aGlzIGFwcGxpY2F0aW9uIGlzIDEvMTI4IHdoYXQgaXMgbm90IApzZWN1cmUgYXQg
YWxsLiBUaGlzIGlzIHZlcnkgcm91Z2ggZXN0aW1hdGUgYnV0IEkgdHJ5IHRvIG1ha2UgdGhpbmdz
IGVhc2llciB0byAKdW5kZXJzdGFuZC4KCkJlc3QgcmVnYXJkcywKSWx5YQoKCgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1zbnBzLWFyYyBtYWls
aW5nIGxpc3QKbGludXgtc25wcy1hcmNAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMu
aW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LXNucHMtYXJj
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 21:07 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-28 21:07 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Kees Cook, Michal Hocko, Richard Henderson, ink, mattst88,
Vineet Gupta, Russell King, Tony Luck, Fenghua Yu, Ralf Baechle,
James E.J. Bottomley, Helge Deller, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Martin Schwidefsky,
Heiko Carstens, Yoshinori Sato, Rich Felker, David S. Miller,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, X86 ML, nyc,
Al Viro, Arnd Bergmann, Greg KH, Deepa Dinamani, Hugh Dickins,
Kate Stewart, Philippe Ombredanne, Andrew Morton, Steve Capper,
Punit Agrawal, Aneesh Kumar K.V, Nick Piggin, Bhupesh Sharma,
Rik van Riel, nitin.m.gupta, Kirill A. Shutemov, Dan Williams,
Jan Kara, Ross Zwisler, Jerome Glisse, Andrea Arcangeli,
Oleg Nesterov, linux-alpha, LKML, linux-snps-arc, linux-ia64,
linux-metag, Linux MIPS Mailing List, linux-parisc, PowerPC,
linux-s390, linux-sh, sparclinux, Linux-MM
> On 28 Mar 2018, at 02:49, Matthew Wilcox <willy@infradead.org> wrote:
>
> On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote:
>> I agree: pushing this off to libc leaves a lot of things unprotected.
>> I think this should live in the kernel. The question I have is about
>> making it maintainable/readable/etc.
>>
>> The state-of-the-art for ASLR is moving to finer granularity (over
>> just base-address offset), so I'd really like to see this supported in
>> the kernel. We'll be getting there for other things in the future, and
>> I'd like to have a working production example for researchers to
>> study, etc.
>
> One thing we need is to limit the fragmentation of this approach.
> Even on 64-bit systems, we can easily get into a situation where there isn't
> space to map a contiguous terabyte.
As I wrote before, shift_random is introduced to be fragmentation limit. Even
without it, the main question here is ‘if we can’t allocate memory with N size
bytes, how many bytes we already allocated?’. From these point of view I
already showed in previous version of patch that if application uses not so big
memory allocations, it will have enough memory to use. If it uses XX Gigabytes
or Terabytes memory, this application has all chances to be exploited with
fully randomization or without. Since it is much easier to find(or guess) any
usable pointer, etc. For the instance you have only 128 terabytes of memory for
user space, so probability to exploit this application is 1/128 what is not
secure at all. This is very rough estimate but I try to make things easier to
understand.
Best regards,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 21:07 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-28 21:07 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Kees Cook, Michal Hocko, Richard Henderson, ink, mattst88,
Vineet Gupta, Russell King, Tony Luck, Fenghua Yu, Ralf Baechle,
James E.J. Bottomley, Helge Deller, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Martin Schwidefsky,
Heiko Carstens, Yoshinori Sato, Rich Felker, David S. Miller,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, X86 ML, nyc,
Al Viro, Arnd Bergmann, Greg KH, Deepa Dinamani, Hugh Dickins,
Kate Stewart, Philippe Ombredanne, Andrew Morton, Steve Capper,
Punit Agrawal, Aneesh Kumar K.V, Nick Piggin, Bhupesh Sharma,
Rik van Riel, nitin.m.gupta, Kirill A. Shutemov, Dan Williams,
Jan Kara, Ross Zwisler, Jerome Glisse, Andrea Arcangeli,
Oleg Nesterov, linux-alpha, LKML, linux-snps-arc, linux-ia64,
linux-metag, Linux MIPS Mailing List, linux-parisc, PowerPC,
linux-s390, linux-sh, sparclinux, Linux-MM
> On 28 Mar 2018, at 02:49, Matthew Wilcox <willy@infradead.org> wrote:
>=20
> On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote:
>> I agree: pushing this off to libc leaves a lot of things unprotected.
>> I think this should live in the kernel. The question I have is about
>> making it maintainable/readable/etc.
>>=20
>> The state-of-the-art for ASLR is moving to finer granularity (over
>> just base-address offset), so I'd really like to see this supported =
in
>> the kernel. We'll be getting there for other things in the future, =
and
>> I'd like to have a working production example for researchers to
>> study, etc.
>=20
> One thing we need is to limit the fragmentation of this approach.
> Even on 64-bit systems, we can easily get into a situation where there =
isn't
> space to map a contiguous terabyte.
As I wrote before, shift_random is introduced to be fragmentation limit. =
Even=20
without it, the main question here is =E2=80=98if we can=E2=80=99t =
allocate memory with N size=20
bytes, how many bytes we already allocated?=E2=80=99. =46rom these point =
of view I=20
already showed in previous version of patch that if application uses not =
so big=20
memory allocations, it will have enough memory to use. If it uses XX =
Gigabytes=20
or Terabytes memory, this application has all chances to be exploited =
with=20
fully randomization or without. Since it is much easier to find(or =
guess) any=20
usable pointer, etc. For the instance you have only 128 terabytes of =
memory for=20
user space, so probability to exploit this application is 1/128 what is =
not=20
secure at all. This is very rough estimate but I try to make things =
easier to=20
understand.
Best regards,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 21:07 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-28 21:07 UTC (permalink / raw)
To: linux-snps-arc
> On 28 Mar 2018,@02:49, Matthew Wilcox <willy@infradead.org> wrote:
>
> On Tue, Mar 27, 2018@03:53:53PM -0700, Kees Cook wrote:
>> I agree: pushing this off to libc leaves a lot of things unprotected.
>> I think this should live in the kernel. The question I have is about
>> making it maintainable/readable/etc.
>>
>> The state-of-the-art for ASLR is moving to finer granularity (over
>> just base-address offset), so I'd really like to see this supported in
>> the kernel. We'll be getting there for other things in the future, and
>> I'd like to have a working production example for researchers to
>> study, etc.
>
> One thing we need is to limit the fragmentation of this approach.
> Even on 64-bit systems, we can easily get into a situation where there isn't
> space to map a contiguous terabyte.
As I wrote before, shift_random is introduced to be fragmentation limit. Even
without it, the main question here is ?if we can?t allocate memory with N size
bytes, how many bytes we already allocated??. From these point of view I
already showed in previous version of patch that if application uses not so big
memory allocations, it will have enough memory to use. If it uses XX Gigabytes
or Terabytes memory, this application has all chances to be exploited with
fully randomization or without. Since it is much easier to find(or guess) any
usable pointer, etc. For the instance you have only 128 terabytes of memory for
user space, so probability to exploit this application is 1/128 what is not
secure at all. This is very rough estimate but I try to make things easier to
understand.
Best regards,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-28 21:07 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-28 21:07 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Kate Stewart, Linux MIPS Mailing List, Rich Felker, Jan Kara,
linux-sh, Benjamin Herrenschmidt, Bhupesh Sharma, Heiko Carstens,
Michal Hocko, Linux-MM, Paul Mackerras, Deepa Dinamani,
H. Peter Anvin, sparclinux, linux-ia64, Dan Williams,
Andrea Arcangeli, linux-s390, Yoshinori Sato, Michael Ellerman,
Helge Deller, X86 ML, Hugh Dickins, Russell King
> On 28 Mar 2018, at 02:49, Matthew Wilcox <willy@infradead.org> wrote:
>
> On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote:
>> I agree: pushing this off to libc leaves a lot of things unprotected.
>> I think this should live in the kernel. The question I have is about
>> making it maintainable/readable/etc.
>>
>> The state-of-the-art for ASLR is moving to finer granularity (over
>> just base-address offset), so I'd really like to see this supported in
>> the kernel. We'll be getting there for other things in the future, and
>> I'd like to have a working production example for researchers to
>> study, etc.
>
> One thing we need is to limit the fragmentation of this approach.
> Even on 64-bit systems, we can easily get into a situation where there isn't
> space to map a contiguous terabyte.
As I wrote before, shift_random is introduced to be fragmentation limit. Even
without it, the main question here is ‘if we can’t allocate memory with N size
bytes, how many bytes we already allocated?’. From these point of view I
already showed in previous version of patch that if application uses not so big
memory allocations, it will have enough memory to use. If it uses XX Gigabytes
or Terabytes memory, this application has all chances to be exploited with
fully randomization or without. Since it is much easier to find(or guess) any
usable pointer, etc. For the instance you have only 128 terabytes of memory for
user space, so probability to exploit this application is 1/128 what is not
secure at all. This is very rough estimate but I try to make things easier to
understand.
Best regards,
Ilya
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-22 16:36 ` Ilya Smith
(?)
(?)
@ 2018-03-30 7:55 ` Pavel Machek
-1 siblings, 0 replies; 185+ messages in thread
From: Pavel Machek @ 2018-03-30 7:55 UTC (permalink / raw)
To: Ilya Smith
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
[-- Attachment #1: Type: text/plain, Size: 657 bytes --]
Hi!
> Current implementation doesn't randomize address returned by mmap.
> All the entropy ends with choosing mmap_base_addr at the process
> creation. After that mmap build very predictable layout of address
> space. It allows to bypass ASLR in many cases. This patch make
> randomization of address on any mmap call.
How will this interact with people debugging their application, and
getting different behaviours based on memory layout?
strace, strace again, get different results?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-30 7:55 ` Pavel Machek
0 siblings, 0 replies; 185+ messages in thread
From: Pavel Machek @ 2018-03-30 7:55 UTC (permalink / raw)
To: Ilya Smith
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar
[-- Attachment #1: Type: text/plain, Size: 657 bytes --]
Hi!
> Current implementation doesn't randomize address returned by mmap.
> All the entropy ends with choosing mmap_base_addr at the process
> creation. After that mmap build very predictable layout of address
> space. It allows to bypass ASLR in many cases. This patch make
> randomization of address on any mmap call.
How will this interact with people debugging their application, and
getting different behaviours based on memory layout?
strace, strace again, get different results?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-30 7:55 ` Pavel Machek
0 siblings, 0 replies; 185+ messages in thread
From: Pavel Machek @ 2018-03-30 7:55 UTC (permalink / raw)
To: Ilya Smith
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
[-- Attachment #1: Type: text/plain, Size: 657 bytes --]
Hi!
> Current implementation doesn't randomize address returned by mmap.
> All the entropy ends with choosing mmap_base_addr at the process
> creation. After that mmap build very predictable layout of address
> space. It allows to bypass ASLR in many cases. This patch make
> randomization of address on any mmap call.
How will this interact with people debugging their application, and
getting different behaviours based on memory layout?
strace, strace again, get different results?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-30 7:55 ` Pavel Machek
0 siblings, 0 replies; 185+ messages in thread
From: Pavel Machek @ 2018-03-30 7:55 UTC (permalink / raw)
To: linux-snps-arc
Hi!
> Current implementation doesn't randomize address returned by mmap.
> All the entropy ends with choosing mmap_base_addr at the process
> creation. After that mmap build very predictable layout of address
> space. It allows to bypass ASLR in many cases. This patch make
> randomization of address on any mmap call.
How will this interact with people debugging their application, and
getting different behaviours based on memory layout?
strace, strace again, get different results?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-snps-arc/attachments/20180330/ad6e292b/attachment.sig>
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-30 7:55 ` Pavel Machek
` (3 preceding siblings ...)
(?)
@ 2018-03-30 9:07 ` Ilya Smith
-1 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-30 9:07 UTC (permalink / raw)
To: Pavel Machek
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
Hi
> On 30 Mar 2018, at 10:55, Pavel Machek <pavel@ucw.cz> wrote:
>
> Hi!
>
>> Current implementation doesn't randomize address returned by mmap.
>> All the entropy ends with choosing mmap_base_addr at the process
>> creation. After that mmap build very predictable layout of address
>> space. It allows to bypass ASLR in many cases. This patch make
>> randomization of address on any mmap call.
>
> How will this interact with people debugging their application, and
> getting different behaviours based on memory layout?
>
> strace, strace again, get different results?
>
Honestly I’m confused about your question. If the only one way for debugging
application is to use predictable mmap behaviour, then something went wrong in
this live and we should stop using computers at all.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-30 9:07 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-30 9:07 UTC (permalink / raw)
To: Pavel Machek
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton
Hi
> On 30 Mar 2018, at 10:55, Pavel Machek <pavel@ucw.cz> wrote:
>=20
> Hi!
>=20
>> Current implementation doesn't randomize address returned by mmap.
>> All the entropy ends with choosing mmap_base_addr at the process
>> creation. After that mmap build very predictable layout of address
>> space. It allows to bypass ASLR in many cases. This patch make
>> randomization of address on any mmap call.
>=20
> How will this interact with people debugging their application, and
> getting different behaviours based on memory layout?
>=20
> strace, strace again, get different results?
>=20
Honestly I=E2=80=99m confused about your question. If the only one way =
for debugging=20
application is to use predictable mmap behaviour, then something went =
wrong in=20
this live and we should stop using computers at all.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-30 9:07 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-30 9:07 UTC (permalink / raw)
To: Pavel Machek
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
Hi
> On 30 Mar 2018, at 10:55, Pavel Machek <pavel@ucw.cz> wrote:
>
> Hi!
>
>> Current implementation doesn't randomize address returned by mmap.
>> All the entropy ends with choosing mmap_base_addr at the process
>> creation. After that mmap build very predictable layout of address
>> space. It allows to bypass ASLR in many cases. This patch make
>> randomization of address on any mmap call.
>
> How will this interact with people debugging their application, and
> getting different behaviours based on memory layout?
>
> strace, strace again, get different results?
>
Honestly I’m confused about your question. If the only one way for debugging
application is to use predictable mmap behaviour, then something went wrong in
this live and we should stop using computers at all.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-30 9:07 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-30 9:07 UTC (permalink / raw)
To: Pavel Machek
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
Hi
> On 30 Mar 2018, at 10:55, Pavel Machek <pavel@ucw.cz> wrote:
>=20
> Hi!
>=20
>> Current implementation doesn't randomize address returned by mmap.
>> All the entropy ends with choosing mmap_base_addr at the process
>> creation. After that mmap build very predictable layout of address
>> space. It allows to bypass ASLR in many cases. This patch make
>> randomization of address on any mmap call.
>=20
> How will this interact with people debugging their application, and
> getting different behaviours based on memory layout?
>=20
> strace, strace again, get different results?
>=20
Honestly I=E2=80=99m confused about your question. If the only one way =
for debugging=20
application is to use predictable mmap behaviour, then something went =
wrong in=20
this live and we should stop using computers at all.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-30 9:07 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-30 9:07 UTC (permalink / raw)
To: linux-snps-arc
Hi
> On 30 Mar 2018,@10:55, Pavel Machek <pavel@ucw.cz> wrote:
>
> Hi!
>
>> Current implementation doesn't randomize address returned by mmap.
>> All the entropy ends with choosing mmap_base_addr at the process
>> creation. After that mmap build very predictable layout of address
>> space. It allows to bypass ASLR in many cases. This patch make
>> randomization of address on any mmap call.
>
> How will this interact with people debugging their application, and
> getting different behaviours based on memory layout?
>
> strace, strace again, get different results?
>
Honestly I?m confused about your question. If the only one way for debugging
application is to use predictable mmap behaviour, then something went wrong in
this live and we should stop using computers at all.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-30 9:07 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-30 9:07 UTC (permalink / raw)
To: Pavel Machek
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton
Hi
> On 30 Mar 2018, at 10:55, Pavel Machek <pavel@ucw.cz> wrote:
>
> Hi!
>
>> Current implementation doesn't randomize address returned by mmap.
>> All the entropy ends with choosing mmap_base_addr at the process
>> creation. After that mmap build very predictable layout of address
>> space. It allows to bypass ASLR in many cases. This patch make
>> randomization of address on any mmap call.
>
> How will this interact with people debugging their application, and
> getting different behaviours based on memory layout?
>
> strace, strace again, get different results?
>
Honestly I’m confused about your question. If the only one way for debugging
application is to use predictable mmap behaviour, then something went wrong in
this live and we should stop using computers at all.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-30 9:07 ` Ilya Smith
(?)
(?)
@ 2018-03-30 9:57 ` Pavel Machek
-1 siblings, 0 replies; 185+ messages in thread
From: Pavel Machek @ 2018-03-30 9:57 UTC (permalink / raw)
To: Ilya Smith
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]
On Fri 2018-03-30 12:07:58, Ilya Smith wrote:
> Hi
>
> > On 30 Mar 2018, at 10:55, Pavel Machek <pavel@ucw.cz> wrote:
> >
> > Hi!
> >
> >> Current implementation doesn't randomize address returned by mmap.
> >> All the entropy ends with choosing mmap_base_addr at the process
> >> creation. After that mmap build very predictable layout of address
> >> space. It allows to bypass ASLR in many cases. This patch make
> >> randomization of address on any mmap call.
> >
> > How will this interact with people debugging their application, and
> > getting different behaviours based on memory layout?
> >
> > strace, strace again, get different results?
> >
>
> Honestly I’m confused about your question. If the only one way for debugging
> application is to use predictable mmap behaviour, then something went wrong in
> this live and we should stop using computers at all.
I'm not saying "only way". I'm saying one way, and you are breaking
that. There's advanced stuff like debuggers going "back in time".
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-30 9:57 ` Pavel Machek
0 siblings, 0 replies; 185+ messages in thread
From: Pavel Machek @ 2018-03-30 9:57 UTC (permalink / raw)
To: Ilya Smith
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton
[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]
On Fri 2018-03-30 12:07:58, Ilya Smith wrote:
> Hi
>
> > On 30 Mar 2018, at 10:55, Pavel Machek <pavel@ucw.cz> wrote:
> >
> > Hi!
> >
> >> Current implementation doesn't randomize address returned by mmap.
> >> All the entropy ends with choosing mmap_base_addr at the process
> >> creation. After that mmap build very predictable layout of address
> >> space. It allows to bypass ASLR in many cases. This patch make
> >> randomization of address on any mmap call.
> >
> > How will this interact with people debugging their application, and
> > getting different behaviours based on memory layout?
> >
> > strace, strace again, get different results?
> >
>
> Honestly I’m confused about your question. If the only one way for debugging
> application is to use predictable mmap behaviour, then something went wrong in
> this live and we should stop using computers at all.
I'm not saying "only way". I'm saying one way, and you are breaking
that. There's advanced stuff like debuggers going "back in time".
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-30 9:57 ` Pavel Machek
0 siblings, 0 replies; 185+ messages in thread
From: Pavel Machek @ 2018-03-30 9:57 UTC (permalink / raw)
To: Ilya Smith
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]
On Fri 2018-03-30 12:07:58, Ilya Smith wrote:
> Hi
>
> > On 30 Mar 2018, at 10:55, Pavel Machek <pavel@ucw.cz> wrote:
> >
> > Hi!
> >
> >> Current implementation doesn't randomize address returned by mmap.
> >> All the entropy ends with choosing mmap_base_addr at the process
> >> creation. After that mmap build very predictable layout of address
> >> space. It allows to bypass ASLR in many cases. This patch make
> >> randomization of address on any mmap call.
> >
> > How will this interact with people debugging their application, and
> > getting different behaviours based on memory layout?
> >
> > strace, strace again, get different results?
> >
>
> Honestly I’m confused about your question. If the only one way for debugging
> application is to use predictable mmap behaviour, then something went wrong in
> this live and we should stop using computers at all.
I'm not saying "only way". I'm saying one way, and you are breaking
that. There's advanced stuff like debuggers going "back in time".
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-30 9:57 ` Pavel Machek
0 siblings, 0 replies; 185+ messages in thread
From: Pavel Machek @ 2018-03-30 9:57 UTC (permalink / raw)
To: linux-snps-arc
On Fri 2018-03-30 12:07:58, Ilya Smith wrote:
> Hi
>
> > On 30 Mar 2018,@10:55, Pavel Machek <pavel@ucw.cz> wrote:
> >
> > Hi!
> >
> >> Current implementation doesn't randomize address returned by mmap.
> >> All the entropy ends with choosing mmap_base_addr at the process
> >> creation. After that mmap build very predictable layout of address
> >> space. It allows to bypass ASLR in many cases. This patch make
> >> randomization of address on any mmap call.
> >
> > How will this interact with people debugging their application, and
> > getting different behaviours based on memory layout?
> >
> > strace, strace again, get different results?
> >
>
> Honestly I?m confused about your question. If the only one way for debugging
> application is to use predictable mmap behaviour, then something went wrong in
> this live and we should stop using computers at all.
I'm not saying "only way". I'm saying one way, and you are breaking
that. There's advanced stuff like debuggers going "back in time".
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-snps-arc/attachments/20180330/2476295d/attachment.sig>
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-30 9:57 ` Pavel Machek
` (3 preceding siblings ...)
(?)
@ 2018-03-30 11:10 ` Ilya Smith
-1 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-30 11:10 UTC (permalink / raw)
To: Pavel Machek
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
> On 30 Mar 2018, at 12:57, Pavel Machek <pavel@ucw.cz> wrote:
>
> On Fri 2018-03-30 12:07:58, Ilya Smith wrote:
>> Hi
>>
>>> On 30 Mar 2018, at 10:55, Pavel Machek <pavel@ucw.cz> wrote:
>>>
>>> Hi!
>>>
>>>> Current implementation doesn't randomize address returned by mmap.
>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>> creation. After that mmap build very predictable layout of address
>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>> randomization of address on any mmap call.
>>>
>>> How will this interact with people debugging their application, and
>>> getting different behaviours based on memory layout?
>>>
>>> strace, strace again, get different results?
>>>
>>
>> Honestly I’m confused about your question. If the only one way for debugging
>> application is to use predictable mmap behaviour, then something went wrong in
>> this live and we should stop using computers at all.
>
> I'm not saying "only way". I'm saying one way, and you are breaking
> that. There's advanced stuff like debuggers going "back in time".
>
Correct me if I wrong, when you run gdb for instance and try to debug some
application, gdb will disable randomization. This behaviour works with gdb
command: set disable-randomization on. As I know, gdb remove flag PF_RANDOMIZE
from current personality thats how it disables ASLR for debugging process.
According to my patch, flag PF_RANDOMIZE is checked before calling
unmapped_area_random. So I don’t breaking debugging. If you talking about the
case, when your application crashes under customer environment and you want to
debug it; in this case layout of memory is what you don’t control at all and
you have to understand what is where. So for debugging memory process layout is
not what you should care of.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-30 11:10 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-30 11:10 UTC (permalink / raw)
To: Pavel Machek
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton
> On 30 Mar 2018, at 12:57, Pavel Machek <pavel@ucw.cz> wrote:
>=20
> On Fri 2018-03-30 12:07:58, Ilya Smith wrote:
>> Hi
>>=20
>>> On 30 Mar 2018, at 10:55, Pavel Machek <pavel@ucw.cz> wrote:
>>>=20
>>> Hi!
>>>=20
>>>> Current implementation doesn't randomize address returned by mmap.
>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>> creation. After that mmap build very predictable layout of address
>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>> randomization of address on any mmap call.
>>>=20
>>> How will this interact with people debugging their application, and
>>> getting different behaviours based on memory layout?
>>>=20
>>> strace, strace again, get different results?
>>>=20
>>=20
>> Honestly I=E2=80=99m confused about your question. If the only one =
way for debugging=20
>> application is to use predictable mmap behaviour, then something went =
wrong in=20
>> this live and we should stop using computers at all.
>=20
> I'm not saying "only way". I'm saying one way, and you are breaking
> that. There's advanced stuff like debuggers going "back in time".
>=20
Correct me if I wrong, when you run gdb for instance and try to debug =
some=20
application, gdb will disable randomization. This behaviour works with =
gdb=20
command: set disable-randomization on. As I know, gdb remove flag =
PF_RANDOMIZE=20
from current personality thats how it disables ASLR for debugging =
process.=20
According to my patch, flag PF_RANDOMIZE is checked before calling=20
unmapped_area_random. So I don=E2=80=99t breaking debugging. If you =
talking about the=20
case, when your application crashes under customer environment and you =
want to
debug it; in this case layout of memory is what you don=E2=80=99t =
control at all and=20
you have to understand what is where. So for debugging memory process =
layout is
not what you should care of.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-30 11:10 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-30 11:10 UTC (permalink / raw)
To: Pavel Machek
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
> On 30 Mar 2018, at 12:57, Pavel Machek <pavel@ucw.cz> wrote:
>
> On Fri 2018-03-30 12:07:58, Ilya Smith wrote:
>> Hi
>>
>>> On 30 Mar 2018, at 10:55, Pavel Machek <pavel@ucw.cz> wrote:
>>>
>>> Hi!
>>>
>>>> Current implementation doesn't randomize address returned by mmap.
>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>> creation. After that mmap build very predictable layout of address
>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>> randomization of address on any mmap call.
>>>
>>> How will this interact with people debugging their application, and
>>> getting different behaviours based on memory layout?
>>>
>>> strace, strace again, get different results?
>>>
>>
>> Honestly I’m confused about your question. If the only one way for debugging
>> application is to use predictable mmap behaviour, then something went wrong in
>> this live and we should stop using computers at all.
>
> I'm not saying "only way". I'm saying one way, and you are breaking
> that. There's advanced stuff like debuggers going "back in time".
>
Correct me if I wrong, when you run gdb for instance and try to debug some
application, gdb will disable randomization. This behaviour works with gdb
command: set disable-randomization on. As I know, gdb remove flag PF_RANDOMIZE
from current personality thats how it disables ASLR for debugging process.
According to my patch, flag PF_RANDOMIZE is checked before calling
unmapped_area_random. So I don’t breaking debugging. If you talking about the
case, when your application crashes under customer environment and you want to
debug it; in this case layout of memory is what you don’t control at all and
you have to understand what is where. So for debugging memory process layout is
not what you should care of.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-30 11:10 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-30 11:10 UTC (permalink / raw)
To: Pavel Machek
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
> On 30 Mar 2018, at 12:57, Pavel Machek <pavel@ucw.cz> wrote:
>=20
> On Fri 2018-03-30 12:07:58, Ilya Smith wrote:
>> Hi
>>=20
>>> On 30 Mar 2018, at 10:55, Pavel Machek <pavel@ucw.cz> wrote:
>>>=20
>>> Hi!
>>>=20
>>>> Current implementation doesn't randomize address returned by mmap.
>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>> creation. After that mmap build very predictable layout of address
>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>> randomization of address on any mmap call.
>>>=20
>>> How will this interact with people debugging their application, and
>>> getting different behaviours based on memory layout?
>>>=20
>>> strace, strace again, get different results?
>>>=20
>>=20
>> Honestly I=E2=80=99m confused about your question. If the only one =
way for debugging=20
>> application is to use predictable mmap behaviour, then something went =
wrong in=20
>> this live and we should stop using computers at all.
>=20
> I'm not saying "only way". I'm saying one way, and you are breaking
> that. There's advanced stuff like debuggers going "back in time".
>=20
Correct me if I wrong, when you run gdb for instance and try to debug =
some=20
application, gdb will disable randomization. This behaviour works with =
gdb=20
command: set disable-randomization on. As I know, gdb remove flag =
PF_RANDOMIZE=20
from current personality thats how it disables ASLR for debugging =
process.=20
According to my patch, flag PF_RANDOMIZE is checked before calling=20
unmapped_area_random. So I don=E2=80=99t breaking debugging. If you =
talking about the=20
case, when your application crashes under customer environment and you =
want to
debug it; in this case layout of memory is what you don=E2=80=99t =
control at all and=20
you have to understand what is where. So for debugging memory process =
layout is
not what you should care of.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-30 11:10 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-30 11:10 UTC (permalink / raw)
To: linux-snps-arc
> On 30 Mar 2018,@12:57, Pavel Machek <pavel@ucw.cz> wrote:
>
> On Fri 2018-03-30 12:07:58, Ilya Smith wrote:
>> Hi
>>
>>> On 30 Mar 2018,@10:55, Pavel Machek <pavel@ucw.cz> wrote:
>>>
>>> Hi!
>>>
>>>> Current implementation doesn't randomize address returned by mmap.
>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>> creation. After that mmap build very predictable layout of address
>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>> randomization of address on any mmap call.
>>>
>>> How will this interact with people debugging their application, and
>>> getting different behaviours based on memory layout?
>>>
>>> strace, strace again, get different results?
>>>
>>
>> Honestly I?m confused about your question. If the only one way for debugging
>> application is to use predictable mmap behaviour, then something went wrong in
>> this live and we should stop using computers at all.
>
> I'm not saying "only way". I'm saying one way, and you are breaking
> that. There's advanced stuff like debuggers going "back in time".
>
Correct me if I wrong, when you run gdb for instance and try to debug some
application, gdb will disable randomization. This behaviour works with gdb
command: set disable-randomization on. As I know, gdb remove flag PF_RANDOMIZE
from current personality thats how it disables ASLR for debugging process.
According to my patch, flag PF_RANDOMIZE is checked before calling
unmapped_area_random. So I don?t breaking debugging. If you talking about the
case, when your application crashes under customer environment and you want to
debug it; in this case layout of memory is what you don?t control at all and
you have to understand what is where. So for debugging memory process layout is
not what you should care of.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-30 11:10 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-03-30 11:10 UTC (permalink / raw)
To: Pavel Machek
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton
> On 30 Mar 2018, at 12:57, Pavel Machek <pavel@ucw.cz> wrote:
>
> On Fri 2018-03-30 12:07:58, Ilya Smith wrote:
>> Hi
>>
>>> On 30 Mar 2018, at 10:55, Pavel Machek <pavel@ucw.cz> wrote:
>>>
>>> Hi!
>>>
>>>> Current implementation doesn't randomize address returned by mmap.
>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>> creation. After that mmap build very predictable layout of address
>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>> randomization of address on any mmap call.
>>>
>>> How will this interact with people debugging their application, and
>>> getting different behaviours based on memory layout?
>>>
>>> strace, strace again, get different results?
>>>
>>
>> Honestly I’m confused about your question. If the only one way for debugging
>> application is to use predictable mmap behaviour, then something went wrong in
>> this live and we should stop using computers at all.
>
> I'm not saying "only way". I'm saying one way, and you are breaking
> that. There's advanced stuff like debuggers going "back in time".
>
Correct me if I wrong, when you run gdb for instance and try to debug some
application, gdb will disable randomization. This behaviour works with gdb
command: set disable-randomization on. As I know, gdb remove flag PF_RANDOMIZE
from current personality thats how it disables ASLR for debugging process.
According to my patch, flag PF_RANDOMIZE is checked before calling
unmapped_area_random. So I don’t breaking debugging. If you talking about the
case, when your application crashes under customer environment and you want to
debug it; in this case layout of memory is what you don’t control at all and
you have to understand what is where. So for debugging memory process layout is
not what you should care of.
Thanks,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-30 7:55 ` Pavel Machek
` (2 preceding siblings ...)
(?)
@ 2018-03-30 13:33 ` Rich Felker
-1 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-30 13:33 UTC (permalink / raw)
To: Pavel Machek
Cc: Ilya Smith, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, jhogan, ralf, jejb, deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, davem, tglx, mingo, hpa, x86,
nyc, viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
On Fri, Mar 30, 2018 at 09:55:08AM +0200, Pavel Machek wrote:
> Hi!
>
> > Current implementation doesn't randomize address returned by mmap.
> > All the entropy ends with choosing mmap_base_addr at the process
> > creation. After that mmap build very predictable layout of address
> > space. It allows to bypass ASLR in many cases. This patch make
> > randomization of address on any mmap call.
>
> How will this interact with people debugging their application, and
> getting different behaviours based on memory layout?
>
> strace, strace again, get different results?
Normally gdb disables ASLR for the process when invoking a program to
debug. I don't see why that would be terribly useful with strace but
you can do the same if you want.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-30 13:33 ` Rich Felker
0 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-30 13:33 UTC (permalink / raw)
To: Pavel Machek
Cc: Ilya Smith, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, jhogan, ralf, jejb, deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, davem, tglx, mingo, hpa, x86,
nyc, viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton
On Fri, Mar 30, 2018 at 09:55:08AM +0200, Pavel Machek wrote:
> Hi!
>
> > Current implementation doesn't randomize address returned by mmap.
> > All the entropy ends with choosing mmap_base_addr at the process
> > creation. After that mmap build very predictable layout of address
> > space. It allows to bypass ASLR in many cases. This patch make
> > randomization of address on any mmap call.
>
> How will this interact with people debugging their application, and
> getting different behaviours based on memory layout?
>
> strace, strace again, get different results?
Normally gdb disables ASLR for the process when invoking a program to
debug. I don't see why that would be terribly useful with strace but
you can do the same if you want.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-30 13:33 ` Rich Felker
0 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-30 13:33 UTC (permalink / raw)
To: Pavel Machek
Cc: Ilya Smith, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, jhogan, ralf, jejb, deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, davem, tglx, mingo, hpa, x86,
nyc, viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
On Fri, Mar 30, 2018 at 09:55:08AM +0200, Pavel Machek wrote:
> Hi!
>
> > Current implementation doesn't randomize address returned by mmap.
> > All the entropy ends with choosing mmap_base_addr at the process
> > creation. After that mmap build very predictable layout of address
> > space. It allows to bypass ASLR in many cases. This patch make
> > randomization of address on any mmap call.
>
> How will this interact with people debugging their application, and
> getting different behaviours based on memory layout?
>
> strace, strace again, get different results?
Normally gdb disables ASLR for the process when invoking a program to
debug. I don't see why that would be terribly useful with strace but
you can do the same if you want.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-30 13:33 ` Rich Felker
0 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-30 13:33 UTC (permalink / raw)
To: linux-snps-arc
On Fri, Mar 30, 2018@09:55:08AM +0200, Pavel Machek wrote:
> Hi!
>
> > Current implementation doesn't randomize address returned by mmap.
> > All the entropy ends with choosing mmap_base_addr at the process
> > creation. After that mmap build very predictable layout of address
> > space. It allows to bypass ASLR in many cases. This patch make
> > randomization of address on any mmap call.
>
> How will this interact with people debugging their application, and
> getting different behaviours based on memory layout?
>
> strace, strace again, get different results?
Normally gdb disables ASLR for the process when invoking a program to
debug. I don't see why that would be terribly useful with strace but
you can do the same if you want.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-03-30 13:33 ` Rich Felker
0 siblings, 0 replies; 185+ messages in thread
From: Rich Felker @ 2018-03-30 13:33 UTC (permalink / raw)
To: Pavel Machek
Cc: Ilya Smith, rth, ink, mattst88, vgupta, linux, tony.luck,
fenghua.yu, jhogan, ralf, jejb, deller, benh, paulus, mpe,
schwidefsky, heiko.carstens, ysato, davem, tglx, mingo, hpa, x86,
nyc, viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton
On Fri, Mar 30, 2018 at 09:55:08AM +0200, Pavel Machek wrote:
> Hi!
>
> > Current implementation doesn't randomize address returned by mmap.
> > All the entropy ends with choosing mmap_base_addr at the process
> > creation. After that mmap build very predictable layout of address
> > space. It allows to bypass ASLR in many cases. This patch make
> > randomization of address on any mmap call.
>
> How will this interact with people debugging their application, and
> getting different behaviours based on memory layout?
>
> strace, strace again, get different results?
Normally gdb disables ASLR for the process when invoking a program to
debug. I don't see why that would be terribly useful with strace but
you can do the same if you want.
Rich
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
2018-03-28 21:07 ` Luck, Tony
` (3 preceding siblings ...)
(?)
@ 2018-04-03 0:11 ` Ilya Smith
-1 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-04-03 0:11 UTC (permalink / raw)
To: Luck, Tony
Cc: Kate Stewart, Linux MIPS Mailing List, Rich Felker, Jan Kara,
linux-sh, Benjamin Herrenschmidt, Bhupesh Sharma, Heiko Carstens,
Michal Hocko, Linux-MM, Paul Mackerras, Deepa Dinamani,
H. Peter Anvin, sparclinux, linux-ia64, Williams, Dan J,
Andrea Arcangeli, linux-s390, Yoshinori Sato, Michael Ellerman,
Helge Deller, X86 ML, Hugh Dickins
PiBPbiAyOSBNYXIgMjAxOCwgYXQgMDA6MDcsIEx1Y2ssIFRvbnkgPHRvbnkubHVja0BpbnRlbC5j
b20+IHdyb3RlOgo+IAo+PiBUaGUgZGVmYXVsdCBsaW1pdCBvZiBvbmx5IDY1NTM2IFZNQXMgd2ls
bCBhbHNvIHF1aWNrbHkgY29tZSBpbnRvIHBsYXkKPj4gaWYgY29uc2VjdXRpdmUgYW5vbiBtbWFw
cyBkb24ndCBnZXQgbWVyZ2VkLiBPZiBjb3Vyc2UgdGhpcyBjYW4gYmUKPj4gcmFpc2VkLCBidXQg
aXQgaGFzIHNpZ25pZmljYW50IHJlc291cmNlIGFuZCBwZXJmb3JtYW5jZSAoZm9yaykgY29zdHMu
Cj4gCj4gQ291bGQgdGhlIHJhbmRvbSBtbWFwIGFkZHJlc3MgY2hvb3NlciBsb29rIGZvciBob3cg
bWFueSBleGlzdGluZwo+IFZNQXMgaGF2ZSBzcGFjZSBiZWZvcmUvYWZ0ZXIgYW5kIHRoZSByaWdo
dCBhdHRyaWJ1dGVzIHRvIG1lcmdlIHdpdGggdGhlCj4gbmV3IG9uZSB5b3Ugd2FudCB0byBjcmVh
dGU/IElmIHRoaXMgaXMgYWJvdmUgc29tZSB0aHJlc2hvbGQgKDEwMD8pIHRoZW4KPiBwaWNrIG9u
ZSBvZiB0aGVtIHJhbmRvbWx5IGFuZCBhbGxvY2F0ZSB0aGUgbmV3IGFkZHJlc3Mgc28gdGhhdCBp
dCB3aWxsCj4gbWVyZ2UgZnJvbSBiZWxvdy9hYm92ZSB3aXRoIGFuIGV4aXN0aW5nIG9uZS4KPiAK
PiBUaGF0IHNob3VsZCBzdGlsbCBnaXZlIHlvdSBhIHZlcnkgaGlnaCBkZWdyZWUgb2YgcmFuZG9t
bmVzcywgYnV0IHByZXZlbnQKPiBvdXQgb2YgY29udHJvbCBudW1iZXJzIG9mIFZNQXMgZnJvbSBi
ZWluZyBjcmVhdGVkLgoKSSB0aGluayB0aGlzIHdvdWxkbuKAmXQgd29yay4gRm9yIGV4YW1wbGUg
dGhlc2UgMTAwIGFsbG9jYXRpb24gbWF5IGhhcHBlbmVkIG9uIApwcm9jZXNzIGluaXRpYWxpemF0
aW9uLiBCdXQgd2hlbiBhdHRhY2tlciBjb21lIHRvIHRoZSBzZXJ2ZXIgYWxsIGhpcyAKYWxsb2Nh
dGlvbnMgd291bGQgYmUgbWFkZSBvbiB0aGUgcHJlZGljdGFibGUgb2Zmc2V0cyBmcm9tIGVhY2gg
b3RoZXIuIFNvIGluIApyZXN1bHQgd2UgZGlkIG5vdGhpbmcganVzdCBkZWNyZWFzZSBwZXJmb3Jt
YW5jZSBvZiBmaXJzdCAxMDAgYWxsb2NhdGlvbnMuIEkgCnRoaW5rIEkgY2FuIG1ha2UgaW9jdGwg
dG8gdHVybiBvZmYgdGhpcyByYW5kb21pemF0aW9uIHBlciBwcm9jZXNzIGFuZCBpdCBjb3VsZCAK
YmUgdXNlZCBpZiBuZWVkZWQuIEZvciBleGFtcGxlIGlmIGFwcGxpY2F0aW9uIGdvaW5nIHRvIGFs
bG9jYXRlIGJpZyBjaHVuayBvciAKbWFrZSBiaWcgbWVtb3J5IHByZXNzdXJlLCBldGMuCgpCZXN0
IHJlZ2FyZHMsCklseWEKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fCmxpbnV4LXNucHMtYXJjIG1haWxpbmcgbGlzdApsaW51eC1zbnBzLWFyY0BsaXN0cy5p
bmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8v
bGludXgtc25wcy1hcmM=
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-04-03 0:11 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-04-03 0:11 UTC (permalink / raw)
To: Luck, Tony
Cc: Rich Felker, Matthew Wilcox, Kees Cook, Michal Hocko,
Richard Henderson, ink, mattst88, Vineet Gupta, Russell King, Yu,
Fenghua, Ralf Baechle, James E.J. Bottomley, Helge Deller,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Martin Schwidefsky, Heiko Carstens, Yoshinori Sato,
David S. Miller, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
X86 ML, nyc, Al Viro, Arnd Bergmann, Greg KH, Deepa Dinamani,
Hugh Dickins, Kate Stewart, Philippe Ombredanne, Andrew Morton,
Steve Capper, Punit Agrawal, Aneesh Kumar K.V, Nick Piggin,
Bhupesh Sharma, Rik van Riel, nitin.m.gupta, Kirill A. Shutemov,
Williams, Dan J, Jan Kara, Ross Zwisler, Jerome Glisse,
Andrea Arcangeli, Oleg Nesterov, linux-alpha, LKML,
linux-snps-arc, linux-ia64, linux-metag, Linux MIPS Mailing List,
linux-parisc, PowerPC, linux-s390, linux-sh, sparclinux,
Linux-MM
> On 29 Mar 2018, at 00:07, Luck, Tony <tony.luck@intel.com> wrote:
>
>> The default limit of only 65536 VMAs will also quickly come into play
>> if consecutive anon mmaps don't get merged. Of course this can be
>> raised, but it has significant resource and performance (fork) costs.
>
> Could the random mmap address chooser look for how many existing
> VMAs have space before/after and the right attributes to merge with the
> new one you want to create? If this is above some threshold (100?) then
> pick one of them randomly and allocate the new address so that it will
> merge from below/above with an existing one.
>
> That should still give you a very high degree of randomness, but prevent
> out of control numbers of VMAs from being created.
I think this wouldn’t work. For example these 100 allocation may happened on
process initialization. But when attacker come to the server all his
allocations would be made on the predictable offsets from each other. So in
result we did nothing just decrease performance of first 100 allocations. I
think I can make ioctl to turn off this randomization per process and it could
be used if needed. For example if application going to allocate big chunk or
make big memory pressure, etc.
Best regards,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-04-03 0:11 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-04-03 0:11 UTC (permalink / raw)
To: Luck, Tony
Cc: Rich Felker, Matthew Wilcox, Kees Cook, Michal Hocko,
Richard Henderson, ink, mattst88, Vineet Gupta, Russell King, Yu,
Fenghua, Ralf Baechle, James E.J. Bottomley, Helge Deller,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Martin Schwidefsky, Heiko Carstens, Yoshinori Sato,
David S. Miller, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
X86 ML, nyc, Al Viro, Arnd Bergmann, Greg KH, Deepa Dinamani,
Hugh Dickins, Kate Stewart, Philippe Ombredanne, Andrew Morton,
Steve Capper, Punit Agrawal, Aneesh Kumar K.V, Nick Piggin,
Bhupesh Sharma, Rik van Riel, nitin.m.gupta, Kirill A. Shutemov,
Williams, Dan J, Jan Kara, Ross Zwisler, Jerome Glisse,
Andrea Arcangeli, Oleg Nesterov, linux-alpha, LKML,
linux-snps-arc, linux-ia64, linux-metag, Linux MIPS Mailing List,
linux-parisc, PowerPC, linux-s390, linux-sh, sparclinux,
Linux-MM
> On 29 Mar 2018, at 00:07, Luck, Tony <tony.luck@intel.com> wrote:
>
>> The default limit of only 65536 VMAs will also quickly come into play
>> if consecutive anon mmaps don't get merged. Of course this can be
>> raised, but it has significant resource and performance (fork) costs.
>
> Could the random mmap address chooser look for how many existing
> VMAs have space before/after and the right attributes to merge with the
> new one you want to create? If this is above some threshold (100?) then
> pick one of them randomly and allocate the new address so that it will
> merge from below/above with an existing one.
>
> That should still give you a very high degree of randomness, but prevent
> out of control numbers of VMAs from being created.
I think this wouldn’t work. For example these 100 allocation may happened on
process initialization. But when attacker come to the server all his
allocations would be made on the predictable offsets from each other. So in
result we did nothing just decrease performance of first 100 allocations. I
think I can make ioctl to turn off this randomization per process and it could
be used if needed. For example if application going to allocate big chunk or
make big memory pressure, etc.
Best regards,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-04-03 0:11 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-04-03 0:11 UTC (permalink / raw)
To: Luck, Tony
Cc: Rich Felker, Matthew Wilcox, Kees Cook, Michal Hocko,
Richard Henderson, ink, mattst88, Vineet Gupta, Russell King, Yu,
Fenghua, Ralf Baechle, James E.J. Bottomley, Helge Deller,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Martin Schwidefsky, Heiko Carstens, Yoshinori Sato,
David S. Miller, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
X86 ML, nyc, Al Viro, Arnd Bergmann, Greg KH, Deepa Dinamani,
Hugh Dickins, Kate Stewart, Philippe Ombredanne, Andrew Morton,
Steve Capper, Punit Agrawal, Aneesh Kumar K.V, Nick Piggin,
Bhupesh Sharma, Rik van Riel, nitin.m.gupta, Kirill A. Shutemov,
Williams, Dan J, Jan Kara, Ross Zwisler, Jerome Glisse,
Andrea Arcangeli, Oleg Nesterov, linux-alpha, LKML,
linux-snps-arc, linux-ia64, linux-metag, Linux MIPS Mailing List,
linux-parisc, PowerPC, linux-s390, linux-sh, sparclinux,
Linux-MM
> On 29 Mar 2018, at 00:07, Luck, Tony <tony.luck@intel.com> wrote:
>=20
>> The default limit of only 65536 VMAs will also quickly come into play
>> if consecutive anon mmaps don't get merged. Of course this can be
>> raised, but it has significant resource and performance (fork) costs.
>=20
> Could the random mmap address chooser look for how many existing
> VMAs have space before/after and the right attributes to merge with =
the
> new one you want to create? If this is above some threshold (100?) =
then
> pick one of them randomly and allocate the new address so that it will
> merge from below/above with an existing one.
>=20
> That should still give you a very high degree of randomness, but =
prevent
> out of control numbers of VMAs from being created.
I think this wouldn=E2=80=99t work. For example these 100 allocation may =
happened on=20
process initialization. But when attacker come to the server all his=20
allocations would be made on the predictable offsets from each other. So =
in=20
result we did nothing just decrease performance of first 100 =
allocations. I=20
think I can make ioctl to turn off this randomization per process and it =
could=20
be used if needed. For example if application going to allocate big =
chunk or=20
make big memory pressure, etc.
Best regards,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-04-03 0:11 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-04-03 0:11 UTC (permalink / raw)
To: linux-snps-arc
> On 29 Mar 2018,@00:07, Luck, Tony <tony.luck@intel.com> wrote:
>
>> The default limit of only 65536 VMAs will also quickly come into play
>> if consecutive anon mmaps don't get merged. Of course this can be
>> raised, but it has significant resource and performance (fork) costs.
>
> Could the random mmap address chooser look for how many existing
> VMAs have space before/after and the right attributes to merge with the
> new one you want to create? If this is above some threshold (100?) then
> pick one of them randomly and allocate the new address so that it will
> merge from below/above with an existing one.
>
> That should still give you a very high degree of randomness, but prevent
> out of control numbers of VMAs from being created.
I think this wouldn?t work. For example these 100 allocation may happened on
process initialization. But when attacker come to the server all his
allocations would be made on the predictable offsets from each other. So in
result we did nothing just decrease performance of first 100 allocations. I
think I can make ioctl to turn off this randomization per process and it could
be used if needed. For example if application going to allocate big chunk or
make big memory pressure, etc.
Best regards,
Ilya
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
@ 2018-04-03 0:11 ` Ilya Smith
0 siblings, 0 replies; 185+ messages in thread
From: Ilya Smith @ 2018-04-03 0:11 UTC (permalink / raw)
To: Luck, Tony
Cc: Kate Stewart, Linux MIPS Mailing List, Rich Felker, Jan Kara,
linux-sh, Benjamin Herrenschmidt, Bhupesh Sharma, Heiko Carstens,
Michal Hocko, Linux-MM, Paul Mackerras, Deepa Dinamani,
H. Peter Anvin, sparclinux, linux-ia64, Williams, Dan J,
Andrea Arcangeli, linux-s390, Yoshinori Sato, Michael Ellerman,
Helge Deller, X86 ML, Hugh Dickins
> On 29 Mar 2018, at 00:07, Luck, Tony <tony.luck@intel.com> wrote:
>
>> The default limit of only 65536 VMAs will also quickly come into play
>> if consecutive anon mmaps don't get merged. Of course this can be
>> raised, but it has significant resource and performance (fork) costs.
>
> Could the random mmap address chooser look for how many existing
> VMAs have space before/after and the right attributes to merge with the
> new one you want to create? If this is above some threshold (100?) then
> pick one of them randomly and allocate the new address so that it will
> merge from below/above with an existing one.
>
> That should still give you a very high degree of randomness, but prevent
> out of control numbers of VMAs from being created.
I think this wouldn’t work. For example these 100 allocation may happened on
process initialization. But when attacker come to the server all his
allocations would be made on the predictable offsets from each other. So in
result we did nothing just decrease performance of first 100 allocations. I
think I can make ioctl to turn off this randomization per process and it could
be used if needed. For example if application going to allocate big chunk or
make big memory pressure, etc.
Best regards,
Ilya
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 185+ messages in thread
end of thread, other threads:[~2018-04-03 0:13 UTC | newest]
Thread overview: 185+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-22 16:36 [RFC PATCH v2 0/2] Randomization of address chosen by mmap Ilya Smith
2018-03-22 16:36 ` Ilya Smith
2018-03-22 16:36 ` Ilya Smith
2018-03-22 16:36 ` [RFC PATCH v2 1/2] " Ilya Smith
2018-03-22 16:36 ` Ilya Smith
2018-03-22 16:36 ` Ilya Smith
2018-03-22 20:53 ` Andrew Morton
2018-03-22 20:53 ` Andrew Morton
2018-03-22 20:53 ` Andrew Morton
2018-03-22 20:53 ` Andrew Morton
2018-03-23 17:43 ` Ilya Smith
2018-03-23 17:43 ` Ilya Smith
2018-03-23 17:43 ` Ilya Smith
2018-03-23 17:43 ` Ilya Smith
2018-03-23 17:43 ` Ilya Smith
2018-03-23 17:43 ` Ilya Smith
2018-03-22 16:36 ` [RFC PATCH v2 2/2] Architecture defined limit on memory region random shift Ilya Smith
2018-03-22 16:36 ` Ilya Smith
2018-03-22 16:36 ` Ilya Smith
2018-03-22 20:54 ` Andrew Morton
2018-03-22 20:54 ` Andrew Morton
2018-03-22 20:54 ` Andrew Morton
2018-03-22 20:54 ` Andrew Morton
2018-03-23 17:48 ` Ilya Smith
2018-03-23 17:48 ` Ilya Smith
2018-03-23 17:49 ` Ilya Smith
2018-03-23 17:49 ` Ilya Smith
2018-03-23 17:49 ` Ilya Smith
2018-03-23 17:49 ` Ilya Smith
2018-03-23 17:49 ` Ilya Smith
2018-03-23 17:49 ` Ilya Smith
2018-03-22 20:57 ` [RFC PATCH v2 0/2] Randomization of address chosen by mmap Andrew Morton
2018-03-22 20:57 ` Andrew Morton
2018-03-22 20:57 ` Andrew Morton
2018-03-22 20:57 ` Andrew Morton
2018-03-23 17:25 ` Ilya Smith
2018-03-23 17:25 ` Ilya Smith
2018-03-23 17:25 ` Ilya Smith
2018-03-23 17:25 ` Ilya Smith
2018-03-23 17:25 ` Ilya Smith
2018-03-23 17:25 ` Ilya Smith
2018-03-23 12:48 ` Matthew Wilcox
2018-03-23 12:48 ` Matthew Wilcox
2018-03-23 12:48 ` Matthew Wilcox
2018-03-23 12:48 ` Matthew Wilcox
2018-03-23 17:55 ` Ilya Smith
2018-03-23 17:55 ` Ilya Smith
2018-03-23 17:55 ` Ilya Smith
2018-03-23 17:55 ` Ilya Smith
2018-03-23 17:55 ` Ilya Smith
2018-03-23 17:55 ` Ilya Smith
2018-03-26 8:46 ` Michal Hocko
2018-03-26 8:46 ` Michal Hocko
2018-03-26 8:46 ` Michal Hocko
2018-03-26 8:46 ` Michal Hocko
2018-03-26 8:46 ` Michal Hocko
2018-03-26 19:45 ` Ilya Smith
2018-03-26 19:45 ` Ilya Smith
2018-03-26 19:45 ` Ilya Smith
2018-03-26 19:45 ` Ilya Smith
2018-03-26 19:45 ` Ilya Smith
2018-03-26 19:45 ` Ilya Smith
2018-03-27 7:24 ` Michal Hocko
2018-03-27 7:24 ` Michal Hocko
2018-03-27 7:24 ` Michal Hocko
2018-03-27 7:24 ` Michal Hocko
2018-03-27 7:24 ` Michal Hocko
2018-03-27 13:51 ` Ilya Smith
2018-03-27 13:51 ` Ilya Smith
2018-03-27 13:51 ` Ilya Smith
2018-03-27 13:51 ` Ilya Smith
2018-03-27 13:51 ` Ilya Smith
2018-03-27 13:51 ` Ilya Smith
2018-03-27 14:38 ` Michal Hocko
2018-03-27 14:38 ` Michal Hocko
2018-03-27 14:38 ` Michal Hocko
2018-03-27 14:38 ` Michal Hocko
2018-03-27 14:38 ` Michal Hocko
2018-03-28 18:47 ` Ilya Smith
2018-03-28 18:47 ` Ilya Smith
2018-03-28 18:47 ` Ilya Smith
2018-03-28 18:47 ` Ilya Smith
2018-03-28 18:47 ` Ilya Smith
2018-03-28 18:47 ` Ilya Smith
2018-03-27 22:16 ` Theodore Y. Ts'o
2018-03-27 22:16 ` Theodore Y. Ts'o
2018-03-27 22:16 ` Theodore Y. Ts'o
2018-03-27 22:16 ` Theodore Y. Ts'o
2018-03-27 22:16 ` Theodore Y. Ts'o
2018-03-27 23:58 ` Rich Felker
2018-03-27 23:58 ` Rich Felker
2018-03-27 23:58 ` Rich Felker
2018-03-27 23:58 ` Rich Felker
2018-03-28 18:48 ` Ilya Smith
2018-03-28 18:48 ` Ilya Smith
2018-03-28 18:48 ` Ilya Smith
2018-03-28 18:48 ` Ilya Smith
2018-03-28 18:48 ` Ilya Smith
2018-03-28 18:48 ` Ilya Smith
2018-03-27 22:53 ` Kees Cook
2018-03-27 22:53 ` Kees Cook
2018-03-27 22:53 ` Kees Cook
2018-03-27 22:53 ` Kees Cook
2018-03-27 22:53 ` Kees Cook
2018-03-27 23:49 ` Matthew Wilcox
2018-03-27 23:49 ` Matthew Wilcox
2018-03-27 23:49 ` Matthew Wilcox
2018-03-27 23:49 ` Matthew Wilcox
2018-03-27 23:57 ` Kees Cook
2018-03-27 23:57 ` Kees Cook
2018-03-27 23:57 ` Kees Cook
2018-03-27 23:57 ` Kees Cook
2018-03-28 0:00 ` Rich Felker
2018-03-28 0:00 ` Rich Felker
2018-03-28 0:00 ` Rich Felker
2018-03-28 0:00 ` Rich Felker
2018-03-28 21:07 ` Luck, Tony
2018-03-28 21:07 ` Luck, Tony
2018-03-28 21:07 ` Luck, Tony
2018-03-28 21:07 ` Luck, Tony
2018-03-28 21:07 ` Luck, Tony
2018-04-03 0:11 ` Ilya Smith
2018-04-03 0:11 ` Ilya Smith
2018-04-03 0:11 ` Ilya Smith
2018-04-03 0:11 ` Ilya Smith
2018-04-03 0:11 ` Ilya Smith
2018-04-03 0:11 ` Ilya Smith
2018-03-28 21:07 ` Ilya Smith
2018-03-28 21:07 ` Ilya Smith
2018-03-28 21:07 ` Ilya Smith
2018-03-28 21:07 ` Ilya Smith
2018-03-28 21:07 ` Ilya Smith
2018-03-23 18:00 ` Rich Felker
2018-03-23 18:00 ` Rich Felker
2018-03-23 18:00 ` Rich Felker
2018-03-23 18:00 ` Rich Felker
2018-03-23 18:00 ` Rich Felker
2018-03-23 19:06 ` Matthew Wilcox
2018-03-23 19:06 ` Matthew Wilcox
2018-03-23 19:06 ` Matthew Wilcox
2018-03-23 19:06 ` Matthew Wilcox
2018-03-23 19:16 ` Rich Felker
2018-03-23 19:16 ` Rich Felker
2018-03-23 19:16 ` Rich Felker
2018-03-23 19:16 ` Rich Felker
2018-03-23 19:16 ` Rich Felker
2018-03-23 19:29 ` Matthew Wilcox
2018-03-23 19:29 ` Matthew Wilcox
2018-03-23 19:29 ` Matthew Wilcox
2018-03-23 19:29 ` Matthew Wilcox
2018-03-23 19:35 ` Rich Felker
2018-03-23 19:35 ` Rich Felker
2018-03-23 19:35 ` Rich Felker
2018-03-23 19:35 ` Rich Felker
2018-03-23 19:35 ` Rich Felker
2018-03-28 4:50 ` Rob Landley
2018-03-28 4:50 ` Rob Landley
2018-03-28 4:50 ` Rob Landley
2018-03-28 4:50 ` Rob Landley
2018-03-28 4:50 ` Rob Landley
2018-03-30 7:55 ` Pavel Machek
2018-03-30 7:55 ` Pavel Machek
2018-03-30 7:55 ` Pavel Machek
2018-03-30 7:55 ` Pavel Machek
2018-03-30 9:07 ` Ilya Smith
2018-03-30 9:07 ` Ilya Smith
2018-03-30 9:07 ` Ilya Smith
2018-03-30 9:07 ` Ilya Smith
2018-03-30 9:07 ` Ilya Smith
2018-03-30 9:07 ` Ilya Smith
2018-03-30 9:57 ` Pavel Machek
2018-03-30 9:57 ` Pavel Machek
2018-03-30 9:57 ` Pavel Machek
2018-03-30 9:57 ` Pavel Machek
2018-03-30 11:10 ` Ilya Smith
2018-03-30 11:10 ` Ilya Smith
2018-03-30 11:10 ` Ilya Smith
2018-03-30 11:10 ` Ilya Smith
2018-03-30 11:10 ` Ilya Smith
2018-03-30 11:10 ` Ilya Smith
2018-03-30 13:33 ` Rich Felker
2018-03-30 13:33 ` Rich Felker
2018-03-30 13:33 ` Rich Felker
2018-03-30 13:33 ` Rich Felker
2018-03-30 13:33 ` Rich Felker
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.