From: Horst Schirmeier <horst@schirmeier.com>
To: Jiri Kosina <jkosina@suse.cz>
Cc: rdunlap@xenotime.net, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, trivial@kernel.org
Subject: Re: [PATCH] doc: missing value 2 for randomize-va-space
Date: Fri, 3 Jul 2009 02:05:23 +0200 [thread overview]
Message-ID: <20090703000523.GX26384@quickstop.soohrt.org> (raw)
In-Reply-To: <alpine.LNX.2.00.0907030109191.4994@wotan.suse.de>
On Fri, 03 Jul 2009, Jiri Kosina wrote:
> > There a few legacy applications out there (such as some ancient
>
> ... would you please fix this typo/grammo as well? (There a few ...)
>
> > versions of libc.so.5 from 1996) that assume that brk area starts
>
> Also, the text itself doesn't seem to be super-clear ... namely, it
> describes what CONFIG_COMPAT_BRK is about, but doesn't really clarify how
> exactly does this correlate with randomize_va_space == 2. Would you mind
> also fixing this bit?
I hope I didn't misread the sources :-) Opinions?
---
The documentation for /proc/sys/kernel/* does not mention the possible
value 2 for randomize-va-space yet. While being there, doing some
reformatting, fixing grammar problems and clarifying the correlations
between randomize-va-space, kernel parameter "norandmaps" and the
CONFIG_COMPAT_BRK option.
Signed-off-by: Horst Schirmeier <horst@schirmeier.com>
---
Documentation/sysctl/kernel.txt | 30 +++++++++++++++++-------------
1 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 322a00b..dd8322f 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -303,25 +303,29 @@ This option can be used to select the type of process address
space randomization that is used in the system, for architectures
that support this feature.
-0 - Turn the process address space randomization off by default.
+0 - Turn the process address space randomization off. This is the
+ default for architectures that do not support this feature anyways,
+ and kernels that are booted with the "norandmaps" parameter.
1 - Make the addresses of mmap base, stack and VDSO page randomized.
This, among other things, implies that shared libraries will be
- loaded to random addresses. Also for PIE-linked binaries, the location
- of code start is randomized.
+ loaded to random addresses. Also for PIE-linked binaries, the
+ location of code start is randomized. This is the default if the
+ CONFIG_COMPAT_BRK option is enabled.
- With heap randomization, the situation is a little bit more
- complicated.
- There a few legacy applications out there (such as some ancient
+2 - Additionally enable heap randomization. This is the default if
+ CONFIG_COMPAT_BRK is disabled.
+
+ There are a few legacy applications out there (such as some ancient
versions of libc.so.5 from 1996) that assume that brk area starts
- just after the end of the code+bss. These applications break when
- start of the brk area is randomized. There are however no known
+ 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 choose full randomization. However there is
- a CONFIG_COMPAT_BRK option for systems with ancient and/or broken
- binaries, that makes heap non-randomized, but keeps all other
- parts of process address space randomized if randomize_va_space
- sysctl is turned on.
+ systems it is safe to choose full randomization.
+
+ Systems with ancient and/or broken binaries should be configured
+ with CONFIG_COMPAT_BRK enabled, which excludes the heap from process
+ address space randomization.
==============================================================
--
PGP-Key 0xD40E0E7A
next prev parent reply other threads:[~2009-07-03 0:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-02 15:23 [PATCH] doc: missing value 2 for randomize-va-space Horst Schirmeier
2009-07-02 23:11 ` Jiri Kosina
2009-07-03 0:05 ` Horst Schirmeier [this message]
2009-07-03 10:01 ` Jiri Kosina
2009-07-03 10:24 ` Ingo Molnar
2009-07-03 10:26 ` Jiri Kosina
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090703000523.GX26384@quickstop.soohrt.org \
--to=horst@schirmeier.com \
--cc=jkosina@suse.cz \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@xenotime.net \
--cc=trivial@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.