gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: exec-shield mmap & brk randomization


From: Roland McGrath
Subject: [Gcl-devel] Re: exec-shield mmap & brk randomization
Date: Tue, 18 Nov 2003 19:36:22 -0800

> Ummm, I've read this 3 times and I understand that lisp (in fact every
> lisp I've ever worked on) will break in this model. Lisp systems depend
> on managing memory. 

You are overreacting.  You have quite a lot of control over your address
space.  It's just that "presume it will be like it usually has been" does
not constitute control.  You have to use the proper explicit mechanisms.

> If I understand what you wrote it appears that in the worst case I
> could get back a page at a time which could not be remapped into a
> contiguous area! Please tell me that I'm wrong.

I don't really know what you are referring to.  Unless you have already
loaded zillions of libraries or other randomized mmaps, most of your
address space will be free.  If you want a 1GB chunk, mmap a 1GB chunk
first thing.  You know that the address space is 3GB or more and you've
decided that 1GB is enough because it makes it easier to only handle one
contiguous and that's the size you can reasonably expect, then fine.

If you want to be absolutely sure of a certain minimum size before any
shared libraries are loaded, then you need to have a PT_LOAD program header
in your executable requesting a specific mapping.  This is equivalent to
allocating a huge data area in the executable, but you can do it without
making the region accessible before your explicit mappings, and without
consuming any real RAM or disk for it.  I explained this already.

> Do you have a set of examples from the design to show me what expectations
> will be violated? I read your text but it would be helpful to see actual
> code that used to work and will no longer be guaranteed to work. Is there
> a design document I can read to understand this better?

There is a POSIX specification of what has been guaranteed and what has
always unspecified implementation detail you should never have been relying
on.  You have never been able to presume the layout mmap will use, or how
close to the break it might be.  However, you can reasonably expect that
any implementation of decent quality would endeavor make it possible to get
contiguous mappings of both small and large sizes.  The locations of small
mappings such as those for the shared libraries are not predictable, but
they do not create ludicrous amounts of fragmentation.  




reply via email to

[Prev in Thread] Current Thread [Next in Thread]