|
[PATCH 4.4-cip 4/6] x86: mm: support ARCH_MMAP_RND_BITS
Ben Hutchings <ben.hutchings@...>
From: Daniel Cashman <dcashman@google.com>
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. Signed-off-by: Daniel Cashman <dcashman@google.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Kees Cook <keescook@chromium.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Don Zickus <dzickus@redhat.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: David Rientjes <rientjes@google.com> Cc: Mark Salyzyn <salyzyn@android.com> Cc: Jeff Vander Stoep <jeffv@google.com> Cc: Nick Kralevich <nnk@google.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Hector Marco-Gisbert <hecmargi@upv.es> Cc: Borislav Petkov <bp@suse.de> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk> --- arch/x86/Kconfig | 16 ++++++++++++++++ arch/x86/mm/mmap.c | 12 ++++++------ 2 files changed, 22 insertions(+), 6 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 436639a31624..ffbfa85271a3 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -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 diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c index 307f60ecfc6d..389939f74dd5 100644 --- a/arch/x86/mm/mmap.c +++ b/arch/x86/mm/mmap.c @@ -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; } -- 2.10.2 -- Ben Hutchings Software Developer, Codethink Ltd.
|
|
|
|
[PATCH 4.4-cip 3/6] arm64: mm: support ARCH_MMAP_RND_BITS
Ben Hutchings <ben.hutchings@...>
From: Daniel Cashman <dcashman@google.com>
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. Signed-off-by: Daniel Cashman <dcashman@google.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Kees Cook <keescook@chromium.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Don Zickus <dzickus@redhat.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: David Rientjes <rientjes@google.com> Cc: Mark Salyzyn <salyzyn@android.com> Cc: Jeff Vander Stoep <jeffv@google.com> Cc: Nick Kralevich <nnk@google.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Hector Marco-Gisbert <hecmargi@upv.es> Cc: Borislav Petkov <bp@suse.de> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk> --- arch/arm64/Kconfig | 29 +++++++++++++++++++++++++++++ arch/arm64/mm/mmap.c | 8 ++++++-- 2 files changed, 35 insertions(+), 2 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 14cdc6dea493..edf62be35adc 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -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 diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c index ed177475dd8c..4c893b5189dd 100644 --- a/arch/arm64/mm/mmap.c +++ b/arch/arm64/mm/mmap.c @@ -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; } -- 2.10.2 -- Ben Hutchings Software Developer, Codethink Ltd.
|
|
|
|
[PATCH 4.4-cip 2/6] arm: mm: support ARCH_MMAP_RND_BITS
Ben Hutchings <ben.hutchings@...>
From: Daniel Cashman <dcashman@google.com>
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. [arnd@arndb.de: ARM: avoid ARCH_MMAP_RND_BITS for NOMMU] Signed-off-by: Daniel Cashman <dcashman@google.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Kees Cook <keescook@chromium.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Don Zickus <dzickus@redhat.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: David Rientjes <rientjes@google.com> Cc: Mark Salyzyn <salyzyn@android.com> Cc: Jeff Vander Stoep <jeffv@google.com> Cc: Nick Kralevich <nnk@google.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Hector Marco-Gisbert <hecmargi@upv.es> Cc: Borislav Petkov <bp@suse.de> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> [bwh: Backported to 4.4: adjust context] Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk> --- arch/arm/Kconfig | 9 +++++++++ arch/arm/mm/mmap.c | 3 +-- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 34e1569a11ee..a1b8ca129a8a 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -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. diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c index 407dc786583a..4b4058db0781 100644 --- a/arch/arm/mm/mmap.c +++ b/arch/arm/mm/mmap.c @@ -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; } -- 2.10.2 -- Ben Hutchings Software Developer, Codethink Ltd.
|
|
|
|
[PATCH 4.4-cip 1/6] mm: mmap: add new /proc tunable for mmap_base ASLR
Ben Hutchings <ben.hutchings@...>
From: Daniel Cashman <dcashman@google.com>
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. Signed-off-by: Daniel Cashman <dcashman@google.com> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Kees Cook <keescook@chromium.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Don Zickus <dzickus@redhat.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: David Rientjes <rientjes@google.com> Cc: Mark Salyzyn <salyzyn@android.com> Cc: Jeff Vander Stoep <jeffv@google.com> Cc: Nick Kralevich <nnk@google.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Hector Marco-Gisbert <hecmargi@upv.es> Cc: Borislav Petkov <bp@suse.de> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk> --- 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(+) diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index f72370b440b1..ee763f3d3b52 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -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. diff --git a/arch/Kconfig b/arch/Kconfig index 4e949e58b192..ba1b626bca00 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -511,6 +511,74 @@ config ARCH_HAS_ELF_RANDOMIZE - arch_mmap_rnd() - arch_randomize_brk() +config HAVE_ARCH_MMAP_RND_BITS + bool + help + An arch should select this symbol if it supports setting a variable + number of bits for use in establishing the base address for mmap + allocations, has MMU enabled and provides values for both: + - ARCH_MMAP_RND_BITS_MIN + - ARCH_MMAP_RND_BITS_MAX + +config ARCH_MMAP_RND_BITS_MIN + int + +config ARCH_MMAP_RND_BITS_MAX + int + +config ARCH_MMAP_RND_BITS_DEFAULT + int + +config ARCH_MMAP_RND_BITS + int "Number of bits to use for ASLR of mmap base address" if EXPERT + range ARCH_MMAP_RND_BITS_MIN ARCH_MMAP_RND_BITS_MAX + default ARCH_MMAP_RND_BITS_DEFAULT if ARCH_MMAP_RND_BITS_DEFAULT + default ARCH_MMAP_RND_BITS_MIN + depends on HAVE_ARCH_MMAP_RND_BITS + help + 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. 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 + +config HAVE_ARCH_MMAP_RND_COMPAT_BITS + bool + help + An arch should select this symbol if it supports running applications + in compatibility mode, supports setting a variable number of bits for + use in establishing the base address for mmap allocations, has MMU + enabled and provides values for both: + - ARCH_MMAP_RND_COMPAT_BITS_MIN + - ARCH_MMAP_RND_COMPAT_BITS_MAX + +config ARCH_MMAP_RND_COMPAT_BITS_MIN + int + +config ARCH_MMAP_RND_COMPAT_BITS_MAX + int + +config ARCH_MMAP_RND_COMPAT_BITS_DEFAULT + int + +config ARCH_MMAP_RND_COMPAT_BITS + int "Number of bits to use for ASLR of mmap base address for compatible applications" if EXPERT + range ARCH_MMAP_RND_COMPAT_BITS_MIN ARCH_MMAP_RND_COMPAT_BITS_MAX + default ARCH_MMAP_RND_COMPAT_BITS_DEFAULT if ARCH_MMAP_RND_COMPAT_BITS_DEFAULT + default ARCH_MMAP_RND_COMPAT_BITS_MIN + depends on HAVE_ARCH_MMAP_RND_COMPAT_BITS + help + 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 compatible applications 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 + config HAVE_COPY_THREAD_TLS bool help diff --git a/include/linux/mm.h b/include/linux/mm.h index f0ffa01c90d9..ee18791531e4 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -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> diff --git a/kernel/sysctl.c b/kernel/sysctl.c index 999e025bf68e..9bc9f56b8b3d 100644 --- a/kernel/sysctl.c +++ b/kernel/sysctl.c @@ -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 { } }; diff --git a/mm/mmap.c b/mm/mmap.c index 455772a05e54..d99cef70ad18 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -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); -- 2.10.2 -- Ben Hutchings Software Developer, Codethink Ltd.
|
|
|
|
[PATCH 4.4-cip 0/6] Extend user-space ASLR range
Ben Hutchings <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 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(-) -- 2.10.2 -- Ben Hutchings Software Developer, Codethink Ltd.
|
|
|
|
The Problem with build.log
Don Brown <don.brown@...>
Hi Robert, --
Don Brown Codethink, Ltd. Software Engineering Consultant Indianapolis, IN USA Email: don.brown@... Mobile: +1 317-560-0513
|
|
|
|
Re: Features backports
Yoshitake Kobayashi
Hi,
toggle quoted messageShow quoted text
Since the Intel Apollo Lake has already released, we started to check the patches for that. I think the basic functionality has already upstreamed and it might be enough for expected use cases. http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-4.4/log/?h=standard/intel/bxt-rebase I continue to clarify more details. Best regards, Yoshi
On 2016/11/18 21:26, Agustin Benito Bethencourt wrote:
Hi,
|
|
|
|
Re: Open Source OPC UA
Jan Kiszka
On 2016-11-30 11:41, Wolfgang Mauerer wrote:
Am 29/11/2016 um 20:36 schrieb Jan Kiszka:If you have a link (and the project has a proper license), maybe send adoes anyone already have some experience with OSS OPC UAthere's another tiny implementation from some of the Ostwestfalen-Lippe PR to the open62541.org to extend their list. If we only had higher languages, that would be a major limitation. It's not so much about their size, more about their amount of dependencies and their suitability for embedded processors (just having "fun" with Go on Intel Quark...). But also having bindings for Java, C#, python, JavaScript, Go, you-name-them, would be valuable. So I would recommend to start with a common core - thus a native one - and add those bindings to them. Later on, if there is added value, we could also consider alternative core implementations. Regards, Jan
|
|
|
|
Re: Open Source OPC UA
Wolfgang Mauerer <wm@...>
Am 29/11/2016 um 20:36 schrieb Jan Kiszka:
does anyone already have some experience with OSS OPC UAthere's another tiny implementation from some of the Ostwestfalen-Lippe (OWL) group of people in Germany, but since it targets devices with only 10s of KiB of RAM and ROM, I don't think it's suitable for our purposes. As for language and main drivers: Do we have an agreement or an idea in the group what suitable languages are, and what characteristics main drivers should have? Considering the size of systems we're targeting, I personally would not see C (and possibly C++) as the only admissible language. Best regards, Wolfgang
|
|
|
|
Open Source OPC UA
Jan Kiszka
Hi all,
does anyone already have some experience with OSS OPC UA implementations, specifically for resource constrained devices? We stumbled over http://open62541.org which seems like being on the right path. There are more https://github.com/open62541/open62541/wiki/List-of-Open-Source-OPC-UA-Implementations but not all look that attractive for embedded devices, due to language, license or main drivers. I think, eventually, CIP should look into the topic free and standard-conforming OPC UA as well because it is gaining a lot of traction as THE protocol for data exchange in automation industry. Regards, Jan
|
|
|
|
Re: Features backports
Agustin Benito Bethencourt <agustin.benito@...>
Hi,
On 29/11/16 03:57, 小口琢夫 / KOGUCHI，TAKUO wrote: Hi,I think we have a good chance once they see we are testing Beaglebone Black in the open. That would be a good opportunity we might add value to them. Definitely I would talk to them before. If they are not pushing the patches upstream, it would be a good question why. -- Agustin Benito Bethencourt Principal Consultant - FOSS at Codethink agustin.benito@codethink.co.uk
|
|
|
|
Re: [Fuego] Update week 47
Bird, Timothy <Tim.Bird@...>
toggle quoted messageShow quoted text
-----Original Message-----This sounds really great. I would really like to see how the two systems (kernelci and fuego) could be integrated, so I am interested in this work. I see kernelci and fuego as complementary. That's why I'm focusing on the runtime aspects of Fuego, and not on the build/boot tests, at the moment. If we extend kernel-ci to support other types of tests, it would be nice if there were some ability to reuse aspects of fuego test definitions there. I got together with Fenguang Wu (the author of the 0day test project) at plumbers, and found that 0day and Fuego has some very similar concepts, and we might be able to share some materials. 0day is missing visualization tools for results, and doesn't support the notion of cross-compilation yet. But they have similar test phases (download, build, deploy, test, gather logs, parse results). For an initial attempt at writing a standard test API, I was hoping I could find enough common ground between 0day and Fuego to support the same test collateral between the two systems. From what I have seen so far, the test API for LAVA (which kernelci is based on) also has some similar concepts, but they haven't gotten around to formalizing the API in a way that could be used as the common shared API with multiple systems. Regards, -- Tim
|
|
|
|
Re: Update week 47
Daniel Sangorrin <daniel.sangorrin@...>
Hi,
toggle quoted messageShow quoted text
(Cc'ed to Fuego and LTSI mailing lists).
-----Original Message-----... ++ TestingI am planning to add support for kernel-ci on Fuego (Jenkins + a bunch of tests) using "https://ci.linaro.org/view/kernel-ci/" as a reference. That is, Fuego will git-trigger and perform kernel builds, and then send the results to a kernel-ci server (e.g. a local vagrant server or https://kernelci.org) using its REST API. My short-term vision is: [Fuego@toshiba] .... ----build results--------> [Kernel-ci@server] [Fuego@<company X>] Fuego can also be used for visualizing the local build results (maybe not as pretty as kernel-ci's dashboard) but as far as I know it doesn't have the kind of back-end API that kernel-ci has. For that reason, although for local testing Fuego is enough, we need a way to publish the results (mostly so that maintainers can see them). However, my long-term vision would be: [Fuego@toshiba] .... ----build/boot/LTP/Cyclictest/other_tests results--------> [Fuego OR modified kernel-ci@server] [Fuego@<company X>] In other words, Build and Boot tests are good but not enough. There are many other tests that we want to run (e.g. tests in Fuego for both the kernel and the root filesystem). I can see at least two options for implementing that: Option 1: Extend kernel-ci to support other type of tests. Option 2: Add a backend REST API to Fuego similar to the one kernel-ci has. Any feedback would be welcome. Best regards, Daniel [1] http://bird.org/ffiles/Introduction-to-Fuego-LCJ-2016.pdf
|
|
|
|
Re: Features backports
Takuo Koguchi
Hi,
toggle quoted messageShow quoted text
Regarding to Altera Socfpga Cyclone V, we might want to backport from 4.9; - L2cache ECC(./arch/arm/mm/cache-l2x0.c) - QSPI Flash controller(drivers/mtd/spi-nor/cadence-quadspi.c) 4.9 is still missing the followings which exist in the verdor tree(linux-socfpga); - HPS2FPGA(drivers/fpga/altera-hps2fpga.c) - NAND Flash controller(drivers/mtd/nand/denali_dt.c) I hope we can encourage Altera to push these features upstream or do it ourselves. Takuo
-----Original Message-----
|
|
|
|
Re: Features backports
Agustin Benito Bethencourt <agustin.benito@...>
Hi,
On 28/11/16 14:47, Jan Kiszka wrote: On 2016-11-18 13:26, Agustin Benito Bethencourt wrote:This is good. It allows us to dig a little and provide some light.Hi,To add two features areas from our requirement list: -- Agustin Benito Bethencourt Principal Consultant - FOSS at Codethink agustin.benito@codethink.co.uk
|
|
|
|
Re: Features backports
Jan Kiszka
On 2016-11-18 13:26, Agustin Benito Bethencourt wrote:
Hi,To add two features areas from our requirement list: - Distributed Switch Architecture, basically the level of 4.8 would be sufficient. However, there might be too many dependencies on networking core changes. If we pick 4.9 as next SLTS, then this becomes obsolete. - Graphic support for AM57xx from more recent kernels, but things may even still depend on TI's vendor kernel (in which case it would be too early). Both are a bit vague yet, but I'm trying to clarify more details. Comments are already welcome, of course. Jan
|
|
|
|
Re: Proposal: send gitlab notifications to this list
Yoshitake Kobayashi
Hi Agustin,
What do you think?Thanks for the suggestion. I think it is a nice idea. Best regards, Yoshi On 2016/11/28 18:47, Agustin Benito Bethencourt wrote: Hi,
|
|
|
|
Re: Proposal: send gitlab notifications to this list
Wolfgang Mauerer <wm@...>
Hi Agustin,
Am 28/11/2016 um 10:47 schrieb Agustin Benito Bethencourt: I think it would be positive to activate the mail notifications fromThat's a good idea, albeit we could also think about doing development completely kernel-style, with a review of patches on the mailing list (the fact that a patch has been merged or a bug has been opened is IMHO not as interesting as what should go into the repo). Best regards, Wolfgang
|
|
|
|
Proposal: send gitlab notifications to this list
Agustin Benito Bethencourt <agustin.benito@...>
Hi,
I think it would be positive to activate the mail notifications from gitlab and send them to this list. By activating them, you will be able to follow what is happening in our repos through mail. Using filters in your e-mail client you can manage the notification mails, so you "keep clean of notifications" this list if you need to. I believe the traffic will not be much for now so the traffic will be affordable in a single list. We can move notifications to a new list when the activity grows. What do you think? Best Regards -- Agustin Benito Bethencourt Principal Consultant - FOSS at Codethink agustin.benito@codethink.co.uk
|
|
|
|
Update week 47
Agustin Benito Bethencourt <agustin.benito@...>
Hi,
++ Meetings * This week the team at Codethink working on CIP has met f2f for the first time in Manchester, since three of us work remotely from home. ** Agreed on basic management processes we will follow. ** We have worked on the roadmap for the coming weeks. ** Moved forward the work on testing. ** You can find us in IRC channel #cip in freenode. ++ Kernel maintenance * There is a consolidation effort of the policies that has been discussed in this mailing list in our public wiki[1]. Ben H. and myself will look into them the following days to polish them. ++ Testing * The testing project has been created in Gitlab. A couple of colleagues at Codethink has picked up the initial effort done by Siemens and move it forward, in order to create a virtual machine with kernelci[2]. **The goal of the first milestone is that any developer with a board at her desk can test a kernel and see the results of those tests in her own machine. ** A tutorial will be published for those of you not familiar with the tools involved. If you are interested in using kernelci in your company, please join our effort. Collaboration is working. ++ Other topics * The CIP whitepaper keeps moving forward. * As reported, CIP Members took as strategic decision to use the tools that for each software component, each upstream community uses. I order to consolidate our work upstream in one place, we will use Gitlab[3]. ** The Gitlab instance is up and running. Feel free to join. Best Regards [1] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance [2] https://gitlab.com/cip-project/testing/tree/master [3] https://gitlab.com/cip-project -- Agustin Benito Bethencourt Principal Consultant - FOSS at Codethink agustin.benito@codethink.co.uk
|
|
|