Executable memory: further programs that fail

[Ingo Molnar]

On Mon, 24 Nov 2003, Tim Daly wrote:

> I react to the notion that shared libraries can be placed "at random" in
> free space. [...]

this is not how it works. It is random to a certain degree but it doesnt
sacrifice free VM space!

> [...] Lisp systems, database systems, numeric systems (e.g. large matrix
> computations), all rely on large, contiguous blocks of storage. [...]

yes, and the new VM rule that allocates anonymous mmap()s [ie. large
matrix allocations] from below the stack helped a number of scientific
projects around the globe to use more VM. (they use the exec-shield patch
to get the benefit of the new VM layout.)

> [...] I don't understand why fragmenting free storage helps security.
> [...]

we dont fragment free storage. We randomize _executable_ library addresses
in a quite small, ~100 MB range, but normal program objects like matrices,
etc. are still allocated in an as compact way as possible. In fact the new
VM layout is better for scientific apps because the old way put the mmap
base to 1 GB virtual, which made it impossible to use small malloc()s
larger than ~900 MB. Now you can malloc up to 3 GB. (or 4 GB if using the
4G/4G kernel.) Also, the old VM layout only left 2 GB for mmap()s - now
that has a maximum of 3 GB too.

	Ingo