linux-kernel - Re: [PATCH] Undo some of the pseudo-security madness

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8764amb8v2.fsf@mid.deneb.enyo.de>
Date:	Thu, 01 Feb 2007 09:05:53 +0100
From:	Florian Weimer <fw@...eb.enyo.de>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Samium Gromoff <_deepfire@...lingofgreen.ru>,
	Pavel Machek <pavel@....cz>, Valdis.Kletnieks@...edu,
	David Wagner <daw@...berkeley.edu>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Undo some of the pseudo-security madness

* 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/