LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Florian Weimer <fw@deneb.enyo.de>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Samium Gromoff <_deepfire@feelingofgreen.ru>,
	Pavel Machek <pavel@ucw.cz>,
	Valdis.Kletnieks@vt.edu, David Wagner <daw@cs.berkeley.edu>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Undo some of the pseudo-security madness
Date: Thu, 01 Feb 2007 09:05:53 +0100	[thread overview]
Message-ID: <8764amb8v2.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <1170237588.2865.2.camel@laptopd505.fenrus.org> (Arjan van de Ven's message of "Wed, 31 Jan 2007 17:59:48 +0800")

* Arjan van de Ven:

>> No amount of carefulness will prevent vendors stick arbitrarily
>> damaging values of stack and mmap base randomisation, severely reducing
>> the usefullness of MAP_FIXED.
>
> MAP_FIXED is useful still. The only safe way is to use addresses you got
> from mmap(), eg you overmap something.
> Anything else is madness, with or without randomization. The C library
> for example is free, and does, allocate memory and stacks etc etc.

This reminds me of a different matter: What is the recommended way to
reserve address space (so that libc etc. won't use it) *without*
increasing the VM committed memory counter?  In other words, without
allocating backing store for it?

IIRC, mmap(PROT_NONE) followed by mprotect(PROT_READ | PROT_WRITE)
seems to work, but I wonder if this is just an accident, or if this is
part of the API.

This is an interesting topic because such functionality is required to
make many virtual machines work with address space randomization and
(especially) vm.overcommit_memory=2.  They don't need the backing
store from the beginning, but they really like (if not need, even)
huge regions of continuous address space.

  reply	other threads:[~2007-02-01  8:06 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-21 23:23 Samium Gromoff
2007-01-21 23:34 ` David Wagner
2007-01-22  0:36   ` Kyle Moffett
2007-01-22  1:53     ` Samium Gromoff
2007-02-24  9:40       ` Florian Weimer
2007-02-24 13:33         ` Samium Gromoff
2007-02-24 13:49           ` Florian Weimer
2007-01-22 15:20 ` Valdis.Kletnieks
2007-01-22 17:39   ` Samium Gromoff
2007-01-23  8:48     ` Pavel Machek
2007-01-23 14:03       ` Samium Gromoff
2007-01-23 15:41         ` Alan
2007-01-23 20:21           ` [PATCH 0/2] Mechanism to turn of ASR on a per-ELF binary basis Samium Gromoff
2007-01-23 20:28           ` [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit Samium Gromoff
2007-01-23 20:50             ` Jakub Jelinek
2007-01-23 21:06               ` Samium Gromoff
2007-01-23 21:16                 ` Jakub Jelinek
2007-01-23 21:54                   ` Samium Gromoff
2007-01-23 23:21                   ` Samium Gromoff
2007-01-24 17:08                     ` Pavel Machek
2007-01-29  1:18             ` Arjan van de Ven
2007-01-23 20:31           ` [PATCH 2/2] Make the EF_AS_NO_RANDOM e_flag bit disable PF_RANDOMIZE Samium Gromoff
2007-02-24  9:51           ` [PATCH] Undo some of the pseudo-security madness Florian Weimer
2007-02-24 13:36             ` Samium Gromoff
2007-01-31  9:59         ` Arjan van de Ven
2007-02-01  8:05           ` Florian Weimer [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-01-22  0:54 Samium Gromoff
2007-01-20 14:37 Samium Gromoff
2007-01-20 16:12 ` Samium Gromoff
2007-01-20 21:58 ` David Wagner
2007-01-21  2:16 ` Arjan van de Ven
2007-01-21 21:38   ` Samium Gromoff
2007-01-21 22:09   ` Samium Gromoff
2007-01-21 22:16     ` David Wagner
2007-01-22  0:35     ` Arjan van de Ven
2007-01-22  1:15       ` Samium Gromoff
2007-01-22 17:52       ` Samium Gromoff
2007-01-23  8:44         ` Pavel Machek

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=8764amb8v2.fsf@mid.deneb.enyo.de \
    --to=fw@deneb.enyo.de \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=_deepfire@feelingofgreen.ru \
    --cc=arjan@infradead.org \
    --cc=daw@cs.berkeley.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --subject='Re: [PATCH] Undo some of the pseudo-security madness' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).