Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761421AbYBFD0V (ORCPT ); Tue, 5 Feb 2008 22:26:21 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757157AbYBFD0J (ORCPT ); Tue, 5 Feb 2008 22:26:09 -0500 Received: from agminet01.oracle.com ([141.146.126.228]:58244 "EHLO agminet01.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756574AbYBFD0H (ORCPT ); Tue, 5 Feb 2008 22:26:07 -0500 Date: Tue, 5 Feb 2008 19:24:46 -0800 From: Randy Dunlap To: Jiri Kosina Cc: Arjan van de Ven , Ingo Molnar , Pavel Machek , Hugh Dickins , kernel list , Abel Bernabeu Subject: Re: brk randomization breaks columns Message-Id: <20080205192446.1ba1a1ca.randy.dunlap@oracle.com> In-Reply-To: References: <20080204122837.GA1647@elf.ucw.cz> <20080205070001.7bc8058f@laptopd505.fenrus.org> <20080205154648.GA24331@elf.ucw.cz> <20080205085841.51713a5d@laptopd505.fenrus.org> Organization: Oracle Linux Eng. X-Mailer: Sylpheed 2.4.7 (GTK+ 2.8.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5230 Lines: 154 On Tue, 5 Feb 2008 23:35:27 +0100 (CET) Jiri Kosina wrote: > On Tue, 5 Feb 2008, Arjan van de Ven wrote: > > > the combo of a config option + sysctl sounds the right way forward then > > ;( > > OK, so I propose the one below (unested yet, but should be trivial). Does > anyone have any objections? > > > > From: Jiri Kosina > > ASLR: add possibility for more fine-grained tweaking > > Some prehistoric binaries don't like when start of brk area is located > anywhere else than just after code+bss. > > This patch adds possibility to configure the default behavior of address > space randomization. In addition to that, randomize_va_space now can have > value of '2', which means full randomization including brk space. > > Also, documentation of randomize_va_space is added. Thanks. > Signed-off-by: Jiri Kosina > > diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt > index 8984a53..0373bbe 100644 > --- a/Documentation/sysctl/kernel.txt > +++ b/Documentation/sysctl/kernel.txt > @@ -41,6 +41,7 @@ show up in /proc/sys/kernel: > - pid_max > - powersave-nap [ PPC only ] > - printk > +- randomize_va_space > - real-root-dev ==> Documentation/initrd.txt > - reboot-cmd [ SPARC only ] > - rtsig-max > @@ -280,6 +281,37 @@ send before ratelimiting kicks in. > > ============================================================== > > +randomize-va-space: > + > +This option can be used to select the type of process address > +space randomization is used in the system, for architectures s/is used/that is used/ > +that support this feature. > + > +One of the following numeric values is possible: > + > +0 - [none] > + Turn the process address space randomization off by default. > + > +1 - [conservative] > + Conservative address space randomization makes the addresses of > + mmap base and VDSO page randomized. This, among other things, > + implies that shared libraries will be loaded to random addresses. > + Also for PIE binaries, the location of code start is randomized. > + > +2 - [full] > + > + This includes all the features that Conservative randomization > + provides. In addition to that, also start of the brk area is > + randomized. > + There a few legacy applications out there (such as some ancient > + versions of libc.so.5 from 1996), that assume that brk area starts Drop comma ^ that the brk area > + just after the end of the code+bss. These applications break when > + start of the brk area is randomized. There are however no known > + non-legacy applications that would be broken this way, so for most > + systems it is safe to chose Full randomization. choose > + > +============================================================== > + > reboot-cmd: (Sparc only) > > ??? This seems to be a way to give an argument to the Sparc > diff --git a/init/Kconfig b/init/Kconfig > index 87f50df..804a3a6 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -662,6 +662,46 @@ config SLOB > > endchoice > > +choice > + prompt "Address space randomization type" > + default RANDOMIZATION_CONSERVATIVE > + help > + This option allows to select the type of process address space > + randomization that will be used by default (for those architectures > + that support address space randomization). This option can be > + overriden in runtime through kernel.randomize_va_space sysctl. > + > +config RANDOMIZATION_NONE > + bool "NONE" > + help > + Turn the process address space randomization off by default. > + Equivalent to sysctl kernel.randomize_va_space = 0. > + > +config RANDOMIZATION_CONSERVATIVE > + bool "CONSERVATIVE" > + help > + Conservative address space randomization makes the addresses of > + mmap base and VDSO page randomized. This, among other things, > + implies that shared libraries will be loaded to random addresses. > + Also for PIE binaries, the location of code start is randomized. > + Equivalent to sysctl kernel.randomize_va_space = 1. > + > +config RANDOMIZATION_FULL > + bool "FULL" > + help > + This includes all the features that Conservative randomization > + provides. In addition to that, also start of the brk area is > + randomized. > + There a few legacy applications out there (such as some ancient > + versions of libc.so.5 from 1996), that assume that brk area starts Drop comma. s/that brk/that the brk/ > + just after the end of the code+bss. These applications break when > + start of the brk area is randomized. There are however no known > + non-legacy applications that would be broken this way, so for most > + systems it is safe to chose Full randomization. s/chose/choose/ > + Equivalent to sysctl kernel.randomize_va_space = 2. > + > +endchoice > + > config PROFILING > bool "Profiling support (EXPERIMENTAL)" > help --- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/