Extend user-space ASLR range
Subsystems (15)
cover Extend user-space ASLR range
This is a backport of changes in 4.5 to extend the range of Address Space Layout Randomisation for user-space processes. When enabled, this should make some user-space vulnerabilities harder to exploit, but it can also cause some applications to fail if they currently use a large proportion of the virtual address space.
The default ASLR range remains the same, but it can be changed through kernel config (CONFIG_ARCH_MMAP_RND_BITS) or at run-time through sysctl (vm.mmap_rnd_bits). (For 32-bit compat tasks, the range is controlled through CONFIG_ARCH_MMAP_RND_COMPAT_BITS and vm.mmap_rnd_compat_bits.)
This includes support for arm, arm64 and x86 (32- and 64-bit). (arm64 is not currently supported by CIP, but it was easier to include it in the backport than to leave it out.)
For this and other backports, I'm looking for feedback like:
- Did I miss a follow-up fix or an earlier dependency?
- Does this cause a regression (other than as explained above)?
- Are you likely to use it?
- Are there related features you want in 4.4?
Ben.
Daniel Cashman (6):
mm: mmap: add new /proc tunable for mmap_base ASLR
arm: mm: support ARCH_MMAP_RND_BITS
arm64: mm: support ARCH_MMAP_RND_BITS
x86: mm: support ARCH_MMAP_RND_BITS
drivers: char: random: add get_random_long()
mm: ASLR: use get_random_long()
Documentation/sysctl/vm.txt | 29 +++++++++++++++++ arch/Kconfig | 68 ++++++++++++++++++++++++++++++++++++++++ arch/arm/Kconfig | 9 ++++++ arch/arm/mm/mmap.c | 3 +- arch/arm64/Kconfig | 29 +++++++++++++++++ arch/arm64/mm/mmap.c | 8 +++-- arch/mips/mm/mmap.c | 4 +-- arch/powerpc/kernel/process.c | 4 +-- arch/powerpc/mm/mmap.c | 4 +-- arch/sparc/kernel/sys_sparc_64.c | 2 +- arch/x86/Kconfig | 16 ++++++++++ arch/x86/mm/mmap.c | 12 +++---- drivers/char/random.c | 22 +++++++++++++ fs/binfmt_elf.c | 2 +- include/linux/mm.h | 11 +++++++ include/linux/random.h | 1 + kernel/sysctl.c | 22 +++++++++++++ mm/mmap.c | 12 +++++++ 18 files changed, 240 insertions(+), 18 deletions(-)
Signature · 6 lines
2.10.2 -- Ben Hutchings Software Developer, Codethink Ltd.
PATCH 1/6 mm: mmap: add new /proc tunable for mmap_base ASLR
From: Daniel Cashman <[email protected]>
commit d07e22597d1d355829b7b18ac19afa912cf758d1 upstream.
Address Space Layout Randomization (ASLR) provides a barrier to exploitation of user-space processes in the presence of security vulnerabilities by making it more difficult to find desired code/data which could help an attack. This is done by adding a random offset to the location of regions in the process address space, with a greater range of potential offset values corresponding to better protection/a larger search-space for brute force, but also to greater potential for fragmentation.
The offset added to the mmap_base address, which provides the basis for the majority of the mappings for a process, is set once on process exec in arch_pick_mmap_layout() and is done via hard-coded per-arch values, which reflect, hopefully, the best compromise for all systems. The trade-off between increased entropy in the offset value generation and the corresponding increased variability in address space fragmentation is not absolute, however, and some platforms may tolerate higher amounts of entropy. This patch introduces both new Kconfig values and a sysctl interface which may be used to change the amount of entropy used for offset generation on a system.
The direct motivation for this change was in response to the libstagefright vulnerabilities that affected Android, specifically to information provided by Google's project zero at:
http://googleprojectzero.blogspot.com/2015/09/stagefrightened.html
The attack presented therein, by Google's project zero, specifically targeted the limited randomness used to generate the offset added to the mmap_base address in order to craft a brute-force-based attack. Concretely, the attack was against the mediaserver process, which was limited to respawning every 5 seconds, on an arm device. The hard-coded 8 bits used resulted in an average expected success rate of defeating the mmap ASLR after just over 10 minutes (128 tries at 5 seconds a piece). With this patch, and an accompanying increase in the entropy value to 16 bits, the same attack would take an average expected time of over 45 hours (32768 tries), which makes it both less feasible and more likely to be noticed.
The introduced Kconfig and sysctl options are limited by per-arch minimum and maximum values, the minimum of which was chosen to match the current hard-coded value and the maximum of which was chosen so as to give the greatest flexibility without generating an invalid mmap_base address, generally a 3-4 bits less than the number of bits in the user-space accessible virtual address space.
When decided whether or not to change the default value, a system developer should consider that mmap_base address could be placed anywhere up to 2^(value) bits away from the non-randomized location, which would introduce variable-sized areas above and below the mmap_base address such that the maximum vm_area_struct size may be reduced, preventing very large allocations.
This patch (of 4):
ASLR only uses as few as 8 bits to generate the random offset for the mmap base address on 32 bit architectures. This value was chosen to prevent a poorly chosen value from dividing the address space in such a way as to prevent large allocations. This may not be an issue on all platforms. Allow the specification of a minimum number of bits so that platforms desiring greater ASLR protection may determine where to place the trade-off.
--- Documentation/sysctl/vm.txt | 29 +++++++++++++++++++ arch/Kconfig | 68 +++++++++++++++++++++++++++++++++++++++++++++ include/linux/mm.h | 11 ++++++++ kernel/sysctl.c | 22 +++++++++++++++ mm/mmap.c | 12 ++++++++ 5 files changed, 142 insertions(+)
Documentation/sysctl/vm.txt +29 -0
@@ -42,6 +42,8 @@ Currently, these files are in /proc/sys/vm: - min_slab_ratio - min_unmapped_ratio - mmap_min_addr +- mmap_rnd_bits +- mmap_rnd_compat_bits - nr_hugepages - nr_overcommit_hugepages - nr_trim_pages (only if CONFIG_MMU=n)
@@ -485,6 +487,33 @@ against future potential kernel bugs. ============================================================== +mmap_rnd_bits: + +This value can be used to select the number of bits to use to +determine the random offset to the base address of vma regions +resulting from mmap allocations on architectures which support +tuning address space randomization. This value will be bounded +by the architecture's minimum and maximum supported values. + +This value can be changed after boot using the +/proc/sys/vm/mmap_rnd_bits tunable + +============================================================== + +mmap_rnd_compat_bits: + +This value can be used to select the number of bits to use to +determine the random offset to the base address of vma regions +resulting from mmap allocations for applications run in +compatibility mode on architectures which support tuning address +space randomization. This value will be bounded by the +architecture's minimum and maximum supported values. + +This value can be changed after boot using the +/proc/sys/vm/mmap_rnd_compat_bits tunable + +============================================================== + nr_hugepages Change the minimum size of the hugepage pool.
arch/Kconfig +68 -0
74 lines not on this page · raw message
include/linux/mm.h +11 -0
@@ -51,6 +51,17 @@ extern int sysctl_legacy_va_layout;#define sysctl_legacy_va_layout 0#endif +#ifdef CONFIG_HAVE_ARCH_MMAP_RND_BITS +extern const int mmap_rnd_bits_min; +extern const int mmap_rnd_bits_max; +extern int mmap_rnd_bits__read_mostly ; +#endif +#ifdef CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS +extern const int mmap_rnd_compat_bits_min; +extern const int mmap_rnd_compat_bits_max; +extern int mmap_rnd_compat_bits__read_mostly ; +#endif +#include <asm/page.h> #include <asm/pgtable.h> #include <asm/processor.h>
kernel/sysctl.c +22 -0
@@ -1568,6 +1568,28 @@ static struct ctl_table vm_table[] = { .mode = 0644, .proc_handler = proc_doulongvec_minmax, }, +#ifdef CONFIG_HAVE_ARCH_MMAP_RND_BITS + { + .procname = "mmap_rnd_bits", + .data = &mmap_rnd_bits, + .maxlen = sizeof(mmap_rnd_bits), + .mode = 0600, + .proc_handler = proc_dointvec_minmax, + .extra1 = (void *)&mmap_rnd_bits_min, + .extra2 = (void *)&mmap_rnd_bits_max, + }, +#endif +#ifdef CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS + { + .procname = "mmap_rnd_compat_bits", + .data = &mmap_rnd_compat_bits, + .maxlen = sizeof(mmap_rnd_compat_bits), + .mode = 0600, + .proc_handler = proc_dointvec_minmax, + .extra1 = (void *)&mmap_rnd_compat_bits_min, + .extra2 = (void *)&mmap_rnd_compat_bits_max, + }, +#endif { } };
mm/mmap.c +12 -0
@@ -58,6 +58,18 @@#define arch_rebalance_pgtables (addr, len) (addr)#endif +#ifdef CONFIG_HAVE_ARCH_MMAP_RND_BITS +const int mmap_rnd_bits_min =CONFIG_ARCH_MMAP_RND_BITS_MIN ; +const int mmap_rnd_bits_max =CONFIG_ARCH_MMAP_RND_BITS_MAX ; +int mmap_rnd_bits__read_mostly =CONFIG_ARCH_MMAP_RND_BITS ; +#endif +#ifdef CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS +const int mmap_rnd_compat_bits_min =CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN ; +const int mmap_rnd_compat_bits_max =CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX ; +int mmap_rnd_compat_bits__read_mostly =CONFIG_ARCH_MMAP_RND_COMPAT_BITS ; +#endif + +static void unmap_region (struct mm_struct *mm,struct vm_area_struct *vma,struct vm_area_struct *prev,unsigned long start,unsigned long end);
Signature · 7 lines
2.10.2 -- Ben Hutchings Software Developer, Codethink Ltd.
PATCH 2/6 arm: mm: support ARCH_MMAP_RND_BITS
In reply to Ben HutchingsFrom: Daniel Cashman <[email protected]>
commit e0c25d958f78acfd5c97df5776eeba3e0684101b upstream.
arm: arch_mmap_rnd() uses a hard-code value of 8 to generate the random offset for the mmap base address. This value represents a compromise between increased ASLR effectiveness and avoiding address-space fragmentation. Replace it with a Kconfig option, which is sensibly bounded, so that platform developers may choose where to place this compromise. Keep 8 as the minimum acceptable value.
--- arch/arm/Kconfig | 9 +++++++++ arch/arm/mm/mmap.c | 3 +-- 2 files changed, 10 insertions(+), 2 deletions(-)
arch/arm/Kconfig +9 -0
@@ -35,6 +35,7 @@ config ARM select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6 select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 + select HAVE_ARCH_MMAP_RND_BITS if MMU select HAVE_ARCH_SECCOMP_FILTER if (AEABI && !OABI_COMPAT) select HAVE_ARCH_TRACEHOOK select HAVE_BPF_JIT
@@ -308,6 +309,14 @@ config MMU Select if you want MMU-based virtualised addressing space support by paged memory management. If unsure, say 'Y'. +config ARCH_MMAP_RND_BITS_MIN + default 8 + +config ARCH_MMAP_RND_BITS_MAX + default 14 if PAGE_OFFSET=0x40000000 + default 15 if PAGE_OFFSET=0x80000000 + default 16 + # # The "ARM system type" choice list is ordered alphabetically by option # text. Please add new entries in the option alphabetic order.
arch/arm/mm/mmap.c +1 -2
@@ -173,8 +173,7 @@ unsigned long arch_mmap_rnd(void) {unsigned long rnd; -/* 8 bits of randomness in 20 address space bits */ - rnd = (unsigned long )get_random_int () % (1 <<8 ); + rnd = (unsigned long )get_random_int () & ((1 << mmap_rnd_bits) -1 );return rnd <<PAGE_SHIFT ; }
Signature · 7 lines
2.10.2 -- Ben Hutchings Software Developer, Codethink Ltd.
PATCH 3/6 arm64: mm: support ARCH_MMAP_RND_BITS
In reply to Ben HutchingsFrom: Daniel Cashman <[email protected]>
commit 8f0d3aa9de57662fe35d8bacfbd9d7ef85ffe98f upstream.
arm64: arch_mmap_rnd() uses STACK_RND_MASK to generate the random offset for the mmap base address. This value represents a compromise between increased ASLR effectiveness and avoiding address-space fragmentation. Replace it with a Kconfig option, which is sensibly bounded, so that platform developers may choose where to place this compromise. Keep default values as new minimums.
--- arch/arm64/Kconfig | 29 +++++++++++++++++++++++++++++ arch/arm64/mm/mmap.c | 8 ++++++-- 2 files changed, 35 insertions(+), 2 deletions(-)
arch/arm64/Kconfig +29 -0
@@ -51,6 +51,8 @@ config ARM64 select HAVE_ARCH_JUMP_LABEL select HAVE_ARCH_KASAN if SPARSEMEM_VMEMMAP && !(ARM64_16K_PAGES && ARM64_VA_BITS_48) select HAVE_ARCH_KGDB + select HAVE_ARCH_MMAP_RND_BITS + select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT select HAVE_ARCH_SECCOMP_FILTER select HAVE_ARCH_TRACEHOOK select HAVE_BPF_JIT
@@ -104,6 +106,33 @@ config ARCH_PHYS_ADDR_T_64BIT config MMU def_bool y +config ARCH_MMAP_RND_BITS_MIN + default 14 if ARM64_64K_PAGES + default 16 if ARM64_16K_PAGES + default 18 + +# max bits determined by the following formula: +# VA_BITS - PAGE_SHIFT - 3 +config ARCH_MMAP_RND_BITS_MAX + default 19 if ARM64_VA_BITS=36 + default 24 if ARM64_VA_BITS=39 + default 27 if ARM64_VA_BITS=42 + default 30 if ARM64_VA_BITS=47 + default 29 if ARM64_VA_BITS=48 && ARM64_64K_PAGES + default 31 if ARM64_VA_BITS=48 && ARM64_16K_PAGES + default 33 if ARM64_VA_BITS=48 + default 14 if ARM64_64K_PAGES + default 16 if ARM64_16K_PAGES + default 18 + +config ARCH_MMAP_RND_COMPAT_BITS_MIN + default 7 if ARM64_64K_PAGES + default 9 if ARM64_16K_PAGES + default 11 + +config ARCH_MMAP_RND_COMPAT_BITS_MAX + default 16 + config NO_IOPORT_MAP def_bool y if !PCI
arch/arm64/mm/mmap.c +6 -2
@@ -51,8 +51,12 @@ unsigned long arch_mmap_rnd(void) {unsigned long rnd; - rnd = (unsigned long )get_random_int () &STACK_RND_MASK ; - +#ifdef CONFIG_COMPAT +if (test_thread_flag (TIF_32BIT )) + rnd = (unsigned long )get_random_int () & ((1 << mmap_rnd_compat_bits) -1 ); + else +#endif + rnd = (unsigned long )get_random_int () & ((1 << mmap_rnd_bits) -1 );return rnd <<PAGE_SHIFT ; }
Signature · 7 lines
2.10.2 -- Ben Hutchings Software Developer, Codethink Ltd.
PATCH 4/6 x86: mm: support ARCH_MMAP_RND_BITS
In reply to Ben HutchingsFrom: Daniel Cashman <[email protected]>
commit 9e08f57d684ac2f40685f55f659564bfd91a971e upstream.
x86: arch_mmap_rnd() uses hard-coded values, 8 for 32-bit and 28 for 64-bit, to generate the random offset for the mmap base address. This value represents a compromise between increased ASLR effectiveness and avoiding address-space fragmentation. Replace it with a Kconfig option, which is sensibly bounded, so that platform developers may choose where to place this compromise. Keep default values as new minimums.
--- arch/x86/Kconfig | 16 ++++++++++++++++ arch/x86/mm/mmap.c | 12 ++++++------ 2 files changed, 22 insertions(+), 6 deletions(-)
arch/x86/Kconfig +16 -0
@@ -82,6 +82,8 @@ config X86 select HAVE_ARCH_KASAN if X86_64 && SPARSEMEM_VMEMMAP select HAVE_ARCH_KGDB select HAVE_ARCH_KMEMCHECK + select HAVE_ARCH_MMAP_RND_BITS if MMU + select HAVE_ARCH_MMAP_RND_COMPAT_BITS if MMU && COMPAT select HAVE_ARCH_SECCOMP_FILTER select HAVE_ARCH_SOFT_DIRTY if X86_64 select HAVE_ARCH_TRACEHOOK
@@ -183,6 +185,20 @@ config HAVE_LATENCYTOP_SUPPORT config MMU def_bool y +config ARCH_MMAP_RND_BITS_MIN + default 28 if 64BIT + default 8 + +config ARCH_MMAP_RND_BITS_MAX + default 32 if 64BIT + default 16 + +config ARCH_MMAP_RND_COMPAT_BITS_MIN + default 8 + +config ARCH_MMAP_RND_COMPAT_BITS_MAX + default 16 + config SBUS bool
arch/x86/mm/mmap.c +6 -6
@@ -69,14 +69,14 @@ unsigned long arch_mmap_rnd(void) {unsigned long rnd; -/* -* 8 bits of randomness in 32bit mmaps, 20 address space bits -* 28 bits of randomness in 64bit mmaps, 40 address space bits -*/ if (mmap_is_ia32()) - rnd = (unsigned long )get_random_int () % (1 <<8 ); +#ifdef CONFIG_COMPAT + rnd = (unsigned long )get_random_int () & ((1 << mmap_rnd_compat_bits) -1 ); +#else + rnd = (unsigned long )get_random_int () & ((1 << mmap_rnd_bits) -1 ); +#endif else - rnd = (unsigned long )get_random_int () % (1 <<28 ); + rnd = (unsigned long )get_random_int () & ((1 << mmap_rnd_bits) -1 );return rnd <<PAGE_SHIFT ; }
Signature · 7 lines
2.10.2 -- Ben Hutchings Software Developer, Codethink Ltd.
PATCH 5/6 drivers: char: random: add get_random_long()
In reply to Ben HutchingsDaniel Cashman <[email protected]>
commit ec9ee4acd97c0039a61c0ae4f12705767ae62153 upstream.
Commit d07e22597d1d ("mm: mmap: add new /proc tunable for mmap_base ASLR") added the ability to choose from a range of values to use for entropy count in generating the random offset to the mmap_base address.
The maximum value on this range was set to 32 bits for 64-bit x86 systems, but this value could be increased further, requiring more than the 32 bits of randomness provided by get_random_int(), as is already possible for arm64. Add a new function: get_random_long() which more naturally fits with the mmap usage of get_random_int() but operates exactly the same as get_random_int().
Also, fix the shifting constant in mmap_rnd() to be an unsigned long so that values greater than 31 bits generate an appropriate mask without overflow. This is especially important on x86, as its shift instruction uses a 5-bit mask for the shift operand, which meant that any value for mmap_rnd_bits over 31 acts as a no-op and effectively disables mmap_base randomization.
Finally, replace calls to get_random_int() with get_random_long() where appropriate.
This patch (of 2):
Add get_random_long().
--- drivers/char/random.c | 22 ++++++++++++++++++++++ include/linux/random.h | 1 + 2 files changed, 23 insertions(+)
drivers/char/random.c +22 -0
@@ -1825,6 +1825,28 @@ unsigned int get_random_int(void)EXPORT_SYMBOL (get_random_int);/* +* Same as get_random_int(), but returns unsigned long. +*/ +unsigned long get_random_long (void ) +{ +__u32 *hash; +unsigned long ret; + +if (arch_get_random_long (&ret)) +return ret; + + hash =get_cpu_var (get_random_int_hash); + + hash[0 ] += current->pid + jiffies +random_get_entropy (); +md5_transform (hash, random_int_secret); + ret = *(unsigned long *)hash; +put_cpu_var (get_random_int_hash); + +return ret; +} +EXPORT_SYMBOL (get_random_long); + +/* * randomize_range() returns a start address such that * * [...... <range> .....]
include/linux/random.h +1 -0
@@ -34,6 +34,7 @@ extern const struct file_operations random_fops, urandom_fops;#endif unsigned int get_random_int (void ); +unsigned long get_random_long (void );unsigned long randomize_range (unsigned long start,unsigned long end,unsigned long len);u32 prandom_u32 (void );
Signature · 7 lines
2.10.2 -- Ben Hutchings Software Developer, Codethink Ltd.
PATCH 6/6 mm: ASLR: use get_random_long()
In reply to Ben HutchingsFrom: Daniel Cashman <[email protected]>
commit 5ef11c35ce86b94bfb878b684de4cdaf96f54b2f upstream.
Replace calls to get_random_int() followed by a cast to (unsigned long) with calls to get_random_long(). Also address shifting bug which, in case of x86 removed entropy mask for mmap_rnd_bits values > 31 bits.
--- arch/arm/mm/mmap.c | 2 +- arch/arm64/mm/mmap.c | 4 ++-- arch/mips/mm/mmap.c | 4 ++-- arch/powerpc/kernel/process.c | 4 ++-- arch/powerpc/mm/mmap.c | 4 ++-- arch/sparc/kernel/sys_sparc_64.c | 2 +- arch/x86/mm/mmap.c | 6 +++--- fs/binfmt_elf.c | 2 +- 8 files changed, 14 insertions(+), 14 deletions(-)
arch/arm/mm/mmap.c +1 -1
@@ -173,7 +173,7 @@ unsigned long arch_mmap_rnd(void) {unsigned long rnd; - rnd = (unsigned long )get_random_int () & ((1 << mmap_rnd_bits) -1 ); + rnd =get_random_long () & ((1UL << mmap_rnd_bits) -1 );return rnd <<PAGE_SHIFT ; }
arch/arm64/mm/mmap.c +2 -2
@@ -53,10 +53,10 @@ unsigned long arch_mmap_rnd(void)#ifdef CONFIG_COMPAT if (test_thread_flag (TIF_32BIT )) - rnd = (unsigned long )get_random_int () & ((1 << mmap_rnd_compat_bits) -1 ); + rnd =get_random_long () & ((1UL << mmap_rnd_compat_bits) -1 ); else#endif - rnd = (unsigned long )get_random_int () & ((1 << mmap_rnd_bits) -1 ); + rnd =get_random_long () & ((1UL << mmap_rnd_bits) -1 );return rnd <<PAGE_SHIFT ; }
arch/mips/mm/mmap.c +2 -2
@@ -146,7 +146,7 @@ unsigned long arch_mmap_rnd(void) {unsigned long rnd; - rnd = (unsigned long )get_random_int (); + rnd =get_random_long (); rnd <<=PAGE_SHIFT ;if (TASK_IS_32BIT_ADDR ) rnd &=0xfffffful ;
@@ -174,7 +174,7 @@ void arch_pick_mmap_layout(struct mm_struct *mm)static inline unsigned long brk_rnd (void ) { -unsigned long rnd =get_random_int (); +unsigned long rnd =get_random_long (); rnd = rnd <<PAGE_SHIFT ;/* 8MB for 32bit, 256MB for 64bit */
arch/powerpc/kernel/process.c +2 -2
@@ -1651,9 +1651,9 @@ static inline unsigned long brk_rnd(void)/* 8MB for 32bit, 1GB for 64bit */ if (is_32bit_task ()) - rnd = (long )(get_random_int () % (1 <<(23 -PAGE_SHIFT ))); + rnd = (get_random_long () % (1UL <<(23 -PAGE_SHIFT )));else - rnd = (long )(get_random_int () % (1 <<(30 -PAGE_SHIFT ))); + rnd = (get_random_long () % (1UL <<(30 -PAGE_SHIFT )));return rnd <<PAGE_SHIFT ; }
arch/powerpc/mm/mmap.c +2 -2
@@ -59,9 +59,9 @@ unsigned long arch_mmap_rnd(void)/* 8MB for 32bit, 1GB for 64bit */ if (is_32bit_task ()) - rnd = (unsigned long )get_random_int () % (1 <<(23 -PAGE_SHIFT )); + rnd =get_random_long () % (1 <<(23 -PAGE_SHIFT ));else - rnd = (unsigned long )get_random_int () % (1 <<(30 -PAGE_SHIFT )); + rnd =get_random_long () % (1UL <<(30 -PAGE_SHIFT ));return rnd <<PAGE_SHIFT ; }
arch/sparc/kernel/sys_sparc_64.c +1 -1
@@ -264,7 +264,7 @@ static unsigned long mmap_rnd(void)unsigned long rnd =0UL ;if (current->flags &PF_RANDOMIZE ) { -unsigned long val =get_random_int (); +unsigned long val =get_random_long ();if (test_thread_flag (TIF_32BIT )) rnd = (val % (1UL << (23UL -PAGE_SHIFT )));else
arch/x86/mm/mmap.c +3 -3
@@ -71,12 +71,12 @@ unsigned long arch_mmap_rnd(void) if (mmap_is_ia32())#ifdef CONFIG_COMPAT - rnd = (unsigned long )get_random_int () & ((1 << mmap_rnd_compat_bits) -1 ); + rnd =get_random_long () & ((1UL << mmap_rnd_compat_bits) -1 );#else - rnd = (unsigned long )get_random_int () & ((1 << mmap_rnd_bits) -1 ); + rnd =get_random_long () & ((1UL << mmap_rnd_bits) -1 );#endif else - rnd = (unsigned long )get_random_int () & ((1 << mmap_rnd_bits) -1 ); + rnd =get_random_long () & ((1UL << mmap_rnd_bits) -1 );return rnd <<PAGE_SHIFT ; }
fs/binfmt_elf.c +1 -1
@@ -651,7 +651,7 @@ static unsigned long randomize_stack_top(unsigned long stack_top)if ((current->flags &PF_RANDOMIZE ) && !(current->personality &ADDR_NO_RANDOMIZE )) { - random_variable = (unsigned long )get_random_int (); + random_variable =get_random_long (); random_variable &=STACK_RND_MASK ; random_variable <<=PAGE_SHIFT ; }
Signature · 6 lines
2.10.2 -- Ben Hutchings Software Developer, Codethink Ltd.
cover Extend user-space ASLR range
In reply to Ben HutchingsQuoted 42 lines · Ben Hutchings
This is a backport of changes in 4.5 to extend the range of Address Space Layout Randomisation for user-space processes. When enabled, this should make some user-space vulnerabilities harder to exploit, but it can also cause some applications to fail if they currently use a large proportion of the virtual address space.
The default ASLR range remains the same, but it can be changed through kernel config (
CONFIG_ARCH_MMAP_RND_BITS) or at run-time through sysctl (vm.mmap_rnd_bits). (For 32-bit compat tasks, the range is controlled throughCONFIG_ARCH_MMAP_RND_COMPAT_BITSand vm.mmap_rnd_compat_bits.)This includes support for arm, arm64 and x86 (32- and 64-bit). (arm64 is not currently supported by CIP, but it was easier to include it in the backport than to leave it out.)
For this and other backports, I'm looking for feedback like:
- Did I miss a follow-up fix or an earlier dependency?
- Does this cause a regression (other than as explained above)?
- Are you likely to use it?
- Are there related features you want in 4.4?Ben.
Daniel Cashman (6):
mm: mmap: add new /proc tunable formmap_baseASLR
arm: mm: supportARCH_MMAP_RND_BITS
arm64: mm: supportARCH_MMAP_RND_BITS
x86: mm: supportARCH_MMAP_RND_BITS
drivers: char: random: addget_random_long()
mm: ASLR: useget_random_long()Documentation/sysctl/vm.txt | 29 +++++++++++++++++ arch/Kconfig | 68 ++++++++++++++++++++++++++++++++++++++++ arch/arm/Kconfig | 9 ++++++ arch/arm/mm/mmap.c | 3 +- arch/arm64/Kconfig | 29 +++++++++++++++++ arch/arm64/mm/mmap.c | 8 +++-- arch/mips/mm/mmap.c | 4 +-- arch/powerpc/kernel/process.c | 4 +-- arch/powerpc/mm/mmap.c | 4 +-- arch/sparc/kernel/sys_sparc_64.c | 2 +- arch/x86/Kconfig | 16 ++++++++++
Quoted 9 lines
arch/x86/mm/mmap.c | 12 +++---- drivers/char/random.c | 22 +++++++++++++ fs/binfmt_elf.c | 2 +- include/linux/mm.h | 11 +++++++ include/linux/random.h | 1 + kernel/sysctl.c | 22 +++++++++++++ mm/mmap.c | 12 +++++++ 18 files changed, 240 insertions(+), 18 deletions(-)
Did you try to discuss the back-port topic with the KSPP folks or other key persons involved in these patches? In the ideal case, the authors can be CC'ed, do not get annoyed by "these crazy people doing legacy stuff", and may even do some reviews.
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux
cover Extend user-space ASLR range
Quoted 53 lines · Jan Kiszka
Quoted 42 lines · Ben Hutchings
This is a backport of changes in 4.5 to extend the range of Address Space Layout Randomisation for user-space processes. When enabled, this should make some user-space vulnerabilities harder to exploit, but it can also cause some applications to fail if they currently use a large proportion of the virtual address space.
The default ASLR range remains the same, but it can be changed through kernel config (
CONFIG_ARCH_MMAP_RND_BITS) or at run-time through sysctl (vm.mmap_rnd_bits). (For 32-bit compat tasks, the range is controlled throughCONFIG_ARCH_MMAP_RND_COMPAT_BITSand vm.mmap_rnd_compat_bits.)This includes support for arm, arm64 and x86 (32- and 64-bit). (arm64 is not currently supported by CIP, but it was easier to include it in the backport than to leave it out.)
For this and other backports, I'm looking for feedback like:
- Did I miss a follow-up fix or an earlier dependency?
- Does this cause a regression (other than as explained above)?
- Are you likely to use it?
- Are there related features you want in 4.4?Ben.
Daniel Cashman (6):
mm: mmap: add new /proc tunable formmap_baseASLR
arm: mm: supportARCH_MMAP_RND_BITS
arm64: mm: supportARCH_MMAP_RND_BITS
x86: mm: supportARCH_MMAP_RND_BITS
drivers: char: random: addget_random_long()
mm: ASLR: useget_random_long()Documentation/sysctl/vm.txt | 29 +++++++++++++++++ arch/Kconfig | 68 ++++++++++++++++++++++++++++++++++++++++ arch/arm/Kconfig | 9 ++++++ arch/arm/mm/mmap.c | 3 +- arch/arm64/Kconfig | 29 +++++++++++++++++ arch/arm64/mm/mmap.c | 8 +++-- arch/mips/mm/mmap.c | 4 +-- arch/powerpc/kernel/process.c | 4 +-- arch/powerpc/mm/mmap.c | 4 +-- arch/sparc/kernel/sys_sparc_64.c | 2 +- arch/x86/Kconfig | 16 ++++++++++Quoted 9 lines
arch/x86/mm/mmap.c | 12 +++---- drivers/char/random.c | 22 +++++++++++++ fs/binfmt_elf.c | 2 +- include/linux/mm.h | 11 +++++++ include/linux/random.h | 1 + kernel/sysctl.c | 22 +++++++++++++ mm/mmap.c | 12 +++++++ 18 files changed, 240 insertions(+), 18 deletions(-)
Quoted 5 lines
Did you try to discuss the back-port topic with the KSPP folks or other key persons involved in these patches? In the ideal case, the authors can be CC'ed, do not get annoyed by "these crazy people doing legacy stuff", and may even do some reviews.
I've chatted with Elena over this last week, and she talked to Kees who pointed out that the Android people are also doing KSPP backports to 4.4 (thanks, folks!). I didn't check any details, just a heads-up to avoid duplicate work.
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux
cover Extend user-space ASLR range
Quoted 60 lines · Jan Kiszka
Quoted 53 lines · Jan Kiszka
Quoted 42 lines · Ben Hutchings
This is a backport of changes in 4.5 to extend the range of Address Space Layout Randomisation for user-space processes. When enabled, this should make some user-space vulnerabilities harder to exploit, but it can also cause some applications to fail if they currently use a large proportion of the virtual address space.
The default ASLR range remains the same, but it can be changed through kernel config (
CONFIG_ARCH_MMAP_RND_BITS) or at run-time through sysctl (vm.mmap_rnd_bits). (For 32-bit compat tasks, the range is controlled throughCONFIG_ARCH_MMAP_RND_COMPAT_BITSand vm.mmap_rnd_compat_bits.)This includes support for arm, arm64 and x86 (32- and 64-bit). (arm64 is not currently supported by CIP, but it was easier to include it in the backport than to leave it out.)
For this and other backports, I'm looking for feedback like:
- Did I miss a follow-up fix or an earlier dependency?
- Does this cause a regression (other than as explained above)?
- Are you likely to use it?
- Are there related features you want in 4.4?Ben.
Daniel Cashman (6):
mm: mmap: add new /proc tunable formmap_baseASLR
arm: mm: supportARCH_MMAP_RND_BITS
arm64: mm: supportARCH_MMAP_RND_BITS
x86: mm: supportARCH_MMAP_RND_BITS
drivers: char: random: addget_random_long()
mm: ASLR: useget_random_long()Documentation/sysctl/vm.txt | 29 +++++++++++++++++ arch/Kconfig | 68 ++++++++++++++++++++++++++++++++++++++++ arch/arm/Kconfig | 9 ++++++ arch/arm/mm/mmap.c | 3 +- arch/arm64/Kconfig | 29 +++++++++++++++++ arch/arm64/mm/mmap.c | 8 +++-- arch/mips/mm/mmap.c | 4 +-- arch/powerpc/kernel/process.c | 4 +-- arch/powerpc/mm/mmap.c | 4 +-- arch/sparc/kernel/sys_sparc_64.c | 2 +- arch/x86/Kconfig | 16 ++++++++++Quoted 9 lines
arch/x86/mm/mmap.c | 12 +++---- drivers/char/random.c | 22 +++++++++++++ fs/binfmt_elf.c | 2 +- include/linux/mm.h | 11 +++++++ include/linux/random.h | 1 + kernel/sysctl.c | 22 +++++++++++++ mm/mmap.c | 12 +++++++ 18 files changed, 240 insertions(+), 18 deletions(-)Quoted 5 lines
Did you try to discuss the back-port topic with the KSPP folks or other key persons involved in these patches? In the ideal case, the authors can be CC'ed, do not get annoyed by "these crazy people doing legacy stuff", and may even do some reviews.
Quoted 4 lines
I've chatted with Elena over this last week, and she talked to Kees who pointed out that the Android people are also doing KSPP backports to 4.4 (thanks, folks!). I didn't check any details, just a heads-up to avoid duplicate work.
Hi!
The Android common kernel tree is visible here:
https://android.googlesource.com/kernel/common/
In the android-4.4 branch, the backport are these:
b471fcd FROMLIST: mm: ASLR: use get_random_long()
9a3fe39 FROMLIST: drivers: char: random: add get_random_long() d51891f FROMLIST: x86: mm: support ARCH_MMAP_RND_BITS. e2240a1 FROMLIST: arm64: mm: support ARCH_MMAP_RND_BITS. 25106ff FROMLIST: arm: mm: support ARCH_MMAP_RND_BITS. d49d887 FROMLIST: mm: mmap: Add new /proc tunable for mmap_base ASLR.
Hopefully that helps!
-Kees
Quoted 6 lines
Jan
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux
Signature · 2 lines
Kees Cook Nexus Security
cover Extend user-space ASLR range
Hi,
Quoted 74 lines · Kees Cook
Quoted 60 lines · Jan Kiszka
Quoted 53 lines · Jan Kiszka
Quoted 42 lines · Ben Hutchings
This is a backport of changes in 4.5 to extend the range of Address Space Layout Randomisation for user-space processes. When enabled, this should make some user-space vulnerabilities harder to exploit, but it can also cause some applications to fail if they currently use a large proportion of the virtual address space.
The default ASLR range remains the same, but it can be changed through kernel config (
CONFIG_ARCH_MMAP_RND_BITS) or at run-time through sysctl (vm.mmap_rnd_bits). (For 32-bit compat tasks, the range is controlled throughCONFIG_ARCH_MMAP_RND_COMPAT_BITSand vm.mmap_rnd_compat_bits.)This includes support for arm, arm64 and x86 (32- and 64-bit). (arm64 is not currently supported by CIP, but it was easier to include it in the backport than to leave it out.)
For this and other backports, I'm looking for feedback like:
- Did I miss a follow-up fix or an earlier dependency?
- Does this cause a regression (other than as explained above)?
- Are you likely to use it?
- Are there related features you want in 4.4?Ben.
Daniel Cashman (6):
mm: mmap: add new /proc tunable formmap_baseASLR
arm: mm: supportARCH_MMAP_RND_BITS
arm64: mm: supportARCH_MMAP_RND_BITS
x86: mm: supportARCH_MMAP_RND_BITS
drivers: char: random: addget_random_long()
mm: ASLR: useget_random_long()Documentation/sysctl/vm.txt | 29 +++++++++++++++++ arch/Kconfig | 68 ++++++++++++++++++++++++++++++++++++++++ arch/arm/Kconfig | 9 ++++++ arch/arm/mm/mmap.c | 3 +- arch/arm64/Kconfig | 29 +++++++++++++++++ arch/arm64/mm/mmap.c | 8 +++-- arch/mips/mm/mmap.c | 4 +-- arch/powerpc/kernel/process.c | 4 +-- arch/powerpc/mm/mmap.c | 4 +-- arch/sparc/kernel/sys_sparc_64.c | 2 +- arch/x86/Kconfig | 16 ++++++++++Quoted 9 lines
arch/x86/mm/mmap.c | 12 +++---- drivers/char/random.c | 22 +++++++++++++ fs/binfmt_elf.c | 2 +- include/linux/mm.h | 11 +++++++ include/linux/random.h | 1 + kernel/sysctl.c | 22 +++++++++++++ mm/mmap.c | 12 +++++++ 18 files changed, 240 insertions(+), 18 deletions(-)Quoted 5 lines
Did you try to discuss the back-port topic with the KSPP folks or other key persons involved in these patches? In the ideal case, the authors can be CC'ed, do not get annoyed by "these crazy people doing legacy stuff", and may even do some reviews.
Quoted 4 lines
I've chatted with Elena over this last week, and she talked to Kees who pointed out that the Android people are also doing KSPP backports to 4.4 (thanks, folks!). I didn't check any details, just a heads-up to avoid duplicate work.
Hi!
The Android common kernel tree is visible here:
https://android.googlesource.com/kernel/common/
In the android-4.4 branch, the backport are these:
Quoted 8 lines
b471fcd FROMLIST: mm: ASLR: use
get_random_long()
9a3fe39 FROMLIST: drivers: char: random: addget_random_long()d51891f FROMLIST: x86: mm: supportARCH_MMAP_RND_BITS. e2240a1 FROMLIST: arm64: mm: supportARCH_MMAP_RND_BITS. 25106ff FROMLIST: arm: mm: supportARCH_MMAP_RND_BITS. d49d887 FROMLIST: mm: mmap: Add new /proc tunable formmap_baseASLR.Hopefully that helps!
It does, thanks. I sent Dmitry Shmidt a mail this morning asking for this. Thanks.
Quoted 12 lines
-Kees
Quoted 6 lines
Jan
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux
Signature · 3 lines
Agustin Benito Bethencourt Principal Consultant - FOSS at Codethink agustin.benito at codethink.co.uk
cover Extend user-space ASLR range
In reply to Kees CookQuoted 2 lines · Kees Cook
Quoted 1 line · Jan Kiszka
On 2016-12-09 13:20, Jan Kiszka wrote:
[...]
Quoted 19 lines
Quoted 10 lines
Quoted 5 lines
Did you try to discuss the back-port topic with the KSPP folks or other key persons involved in these patches? In the ideal case, the authors can be CC'ed, do not get annoyed by "these crazy people doing legacy stuff", and may even do some reviews.
I've chatted with Elena over this last week, and she talked to Kees who pointed out that the Android people are also doing KSPP backports to 4.4 (thanks, folks!). I didn't check any details, just a heads-up to avoid duplicate work.
Hi!
The Android common kernel tree is visible here:
https://android.googlesource.com/kernel/common/
In the android-4.4 branch, the backport are these:
Quoted 8 lines
b471fcd FROMLIST: mm: ASLR: use
get_random_long()
9a3fe39 FROMLIST: drivers: char: random: addget_random_long()d51891f FROMLIST: x86: mm: supportARCH_MMAP_RND_BITS. e2240a1 FROMLIST: arm64: mm: supportARCH_MMAP_RND_BITS. 25106ff FROMLIST: arm: mm: supportARCH_MMAP_RND_BITS. d49d887 FROMLIST: mm: mmap: Add new /proc tunable formmap_baseASLR.Hopefully that helps!
Thanks. My backports are identical aside from the placement of some changes in Kconfig files, which shouldn't make a functional difference.
Ben.
Signature · 2 lines
Ben Hutchings Software Developer, Codethink Ltd.
cover Extend user-space ASLR range
In reply to Jan Kiszka[Sorry for the delay; I haven't been feeling well.]
Quoted 4 lines · Jan Kiszka
Did you try to discuss the back-port topic with the KSPP folks or other key persons involved in these patches? In the ideal case, the authors can be CC'ed, do not get annoyed by "these crazy people doing legacy stuff", and may even do some reviews.
I would normally cc the upstream developers, but I was hesitant to do so for CIP because this is not related to an official stable branch. Perhaps I should ask on the KSPP list whether a cc for such feature backports would be appreciated?
Quoted 6 lines · Jan Kiszka
I've chatted with Elena over this last week, and she talked to Kees who
pointed out that the Android people are also doing KSPP backports to 4.4
(thanks, folks!). I didn't check any details, just a heads-up to avoid duplicate work.
Thanks for letting me know.
Ben.
Signature · 2 lines
Ben Hutchings Software Developer, Codethink Ltd.
cover Extend user-space ASLR range
Hi,
Quoted 8 lines · Ben Hutchings
[Sorry for the delay; I haven't been feeling well.]
Quoted 4 lines · Jan Kiszka
Did you try to discuss the back-port topic with the KSPP folks or other key persons involved in these patches? In the ideal case, the authors can be CC'ed, do not get annoyed by "these crazy people doing legacy stuff", and may even do some reviews.
Quoted 4 lines
I would normally cc the upstream developers, but I was hesitant to do so for CIP because this is not related to an official stable branch. Perhaps I should ask on the KSPP list whether a cc for such feature backports would be appreciated?
Please do so.
Quoted 13 lines · Jan Kiszka
Quoted 6 lines
I've chatted with Elena over this last week, and she talked to Kees who
pointed out that the Android people are also doing KSPP backports to 4.4
(thanks, folks!). I didn't check any details, just a heads-up to avoid duplicate work.Thanks for letting me know.
Ben.
Signature · 3 lines
Agustin Benito Bethencourt Principal Consultant - FOSS at Codethink agustin.benito at codethink.co.uk
cover Extend user-space ASLR range
In reply to Ben HutchingsHi,
Quoted 15 lines · Ben Hutchings
This is a backport of changes in 4.5 to extend the range of Address Space Layout Randomisation for user-space processes. When enabled, this should make some user-space vulnerabilities harder to exploit, but it can also cause some applications to fail if they currently use a large proportion of the virtual address space.
The default ASLR range remains the same, but it can be changed through kernel config (
CONFIG_ARCH_MMAP_RND_BITS) or at run-time through sysctl (vm.mmap_rnd_bits). (For 32-bit compat tasks, the range is controlled throughCONFIG_ARCH_MMAP_RND_COMPAT_BITSand vm.mmap_rnd_compat_bits.)This includes support for arm, arm64 and x86 (32- and 64-bit). (arm64 is not currently supported by CIP, but it was easier to include it in the backport than to leave it out.)
Quoted 5 lines
For this and other backports, I'm looking for feedback like:
- Did I miss a follow-up fix or an earlier dependency?
- Does this cause a regression (other than as explained above)?
- Are you likely to use it?
- Are there related features you want in 4.4?
since there is no further feedback, I assume you me merge the patches, isn't is?
Hopefully in a couple or three more weeks we can start testing it with kernelci tooling.
Quoted 31 lines
Ben.
Daniel Cashman (6):
mm: mmap: add new /proc tunable formmap_baseASLR
arm: mm: supportARCH_MMAP_RND_BITS
arm64: mm: supportARCH_MMAP_RND_BITS
x86: mm: supportARCH_MMAP_RND_BITS
drivers: char: random: addget_random_long()
mm: ASLR: useget_random_long()Documentation/sysctl/vm.txt | 29 +++++++++++++++++ arch/Kconfig | 68 ++++++++++++++++++++++++++++++++++++++++ arch/arm/Kconfig | 9 ++++++ arch/arm/mm/mmap.c | 3 +- arch/arm64/Kconfig | 29 +++++++++++++++++ arch/arm64/mm/mmap.c | 8 +++-- arch/mips/mm/mmap.c | 4 +-- arch/powerpc/kernel/process.c | 4 +-- arch/powerpc/mm/mmap.c | 4 +-- arch/sparc/kernel/sys_sparc_64.c | 2 +- arch/x86/Kconfig | 16 ++++++++++ arch/x86/mm/mmap.c | 12 +++---- drivers/char/random.c | 22 +++++++++++++ fs/binfmt_elf.c | 2 +- include/linux/mm.h | 11 +++++++ include/linux/random.h | 1 + kernel/sysctl.c | 22 +++++++++++++ mm/mmap.c | 12 +++++++ 18 files changed, 240 insertions(+), 18 deletions(-)
Signature · 3 lines
Agustin Benito Bethencourt Principal Consultant - FOSS at Codethink agustin.benito at codethink.co.uk
cover Extend user-space ASLR range
Hi,
Quoted 18 lines · Agustin Benito Bethencourt
Hi,
Quoted 15 lines · Ben Hutchings
This is a backport of changes in 4.5 to extend the range of Address Space Layout Randomisation for user-space processes. When enabled, this should make some user-space vulnerabilities harder to exploit, but it can also cause some applications to fail if they currently use a large proportion of the virtual address space.
The default ASLR range remains the same, but it can be changed through kernel config (
CONFIG_ARCH_MMAP_RND_BITS) or at run-time through sysctl (vm.mmap_rnd_bits). (For 32-bit compat tasks, the range is controlled throughCONFIG_ARCH_MMAP_RND_COMPAT_BITSand vm.mmap_rnd_compat_bits.)This includes support for arm, arm64 and x86 (32- and 64-bit). (arm64 is not currently supported by CIP, but it was easier to include it in the backport than to leave it out.)
Quoted 8 lines
Quoted 5 lines
For this and other backports, I'm looking for feedback like:
- Did I miss a follow-up fix or an earlier dependency?
- Does this cause a regression (other than as explained above)?
- Are you likely to use it?
- Are there related features you want in 4.4?since there is no further feedback, I assume you me merge the patches, isn't is?
since there is no further feedback, I assume you will merge the patches, isn't is?
Quoted 37 lines
Hopefully in a couple or three more weeks we can start testing it with kernelci tooling.
Quoted 32 lines
Ben.
Daniel Cashman (6):
mm: mmap: add new /proc tunable formmap_baseASLR
arm: mm: supportARCH_MMAP_RND_BITS
arm64: mm: supportARCH_MMAP_RND_BITS
x86: mm: supportARCH_MMAP_RND_BITS
drivers: char: random: addget_random_long()
mm: ASLR: useget_random_long()Documentation/sysctl/vm.txt | 29 +++++++++++++++++ arch/Kconfig | 68 ++++++++++++++++++++++++++++++++++++++++ arch/arm/Kconfig | 9 ++++++ arch/arm/mm/mmap.c | 3 +- arch/arm64/Kconfig | 29 +++++++++++++++++ arch/arm64/mm/mmap.c | 8 +++-- arch/mips/mm/mmap.c | 4 +-- arch/powerpc/kernel/process.c | 4 +-- arch/powerpc/mm/mmap.c | 4 +-- arch/sparc/kernel/sys_sparc_64.c | 2 +- arch/x86/Kconfig | 16 ++++++++++ arch/x86/mm/mmap.c | 12 +++---- drivers/char/random.c | 22 +++++++++++++ fs/binfmt_elf.c | 2 +- include/linux/mm.h | 11 +++++++ include/linux/random.h | 1 + kernel/sysctl.c | 22 +++++++++++++ mm/mmap.c | 12 +++++++ 18 files changed, 240 insertions(+), 18 deletions(-)
Signature · 3 lines
Agustin Benito Bethencourt Principal Consultant - FOSS at Codethink agustin.benito at codethink.co.uk