On 4 Dec 2003, Tim Writer wrote:

Maybe. Some language environments rely on an executable stack to implement trampolines. An executable heap could be useful in languages with just-in-time compilation or dynamic loading of compiled code, although I don't know if any language implementations use such techniques.

It has definitely been done, although I'm not up to date on current examples. I think it would not be difficult to exclude executable code from the stack, given some design attention to it, but there are a number of dynamic-code-generation techniques which really need the ability to make portions of the heap executable. Mind you, just a non-executable stack would solve a lot of problems. You can envision more complicated solutions in which you could ask the kernel to make part of the heap executable but read-only: you do your dynamic code generation first, but you have to make the resulting code read-only before you can run out of it. In fact, you may need to interact with the kernel at that point *anyway*, to make sure that caches are flushed properly, so the overhead may be minimal. But it's not clear to me that this really improves things much. If you can overwrite control information, e.g. a function return address -- which is generally needed to *exploit* an executable stack or heap -- then you can always look around for places where you could branch to existing code that happens to do what you want. (For example, functions which do dynamic code generation will have a strong tendency to end with the sequence "tell the system to make the heap region pointed to by register X executable; return".) Henry Spencer henry-lqW1N6Cllo0sV2N9l4h3zg at public.gmane.org -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml