[PATCH] randomized mmap

Robert Watson rwatson at FreeBSD.org
Mon May 30 01:46:04 PDT 2005


On Sun, 29 May 2005, Suleiman Souhlal wrote:

> The patch at http://people.freebsd.org/~ssouhlal/testing/ 
> mmap_random-20050528.diff implements random mmap addresses (unless of 
> course MAP_FIXED is being used), again from OpenBSD. This behavior can 
> be disabled setting the vm.mmap_random sysctl to 0. I think this could 
> greatly increase memory fragmentation, so I'm not sure it would be such 
> a good idea to have it on by default. Also, it doesn't really make 
> attacks unfeasable, but the implementation is so simple that I don't 
> think we really lose anything by letting users decide if they want to 
> enable it or not.

Presumably the goal of this change is to make it harder to work around 
stack gap randomization, lack of execute bit on pages where code can be 
injected via data, etc by setting the return address in the overflowed 
buffer to a well-known address in a library rather than code injected into 
the stack?

On a 32-bit system, this sort of change would be disastrous in terms of 
address space fragmentation, I would think.  However, on a 64-bit system, 
it might be quite a bit less so.  However, I'm not sure I'd implement it 
this way: in a 64-bit address space, we may want to do a bit more 
structuring of the address space and set aside a specific region for 
mmap's.  Does it make sense to do the randomization only for mappings with 
the executable bit set, or implicitly set, when talking about 64-bit 
architectures that have a more reasonable notion of executable than i386?

Were you aware that procfs has a 'map' feature that allows you to see what 
the practical effect of policy chnages in address space have on processes 
is?  You might want to experiment a bit and see what the practical impact 
of maximum mapping is after loading a few shared libraries (etc) with this 
policy in place.  If it turns out that, after 40 shared libraries are 
mapped into an address space, the process can no longer mmap more than a 
few megs, I'd definitely vote against it being included.  Konqueror, btw, 
maps about 40 shared libraries by default on my notebook :-).

How was the adjustment value of 256k selected, btw?

Robert N M Watson


More information about the freebsd-arch mailing list