In that case, let me revise my earlier proposal: ADDR_HEAP would apply to the entire heap, current and future.
ADDR_STACK would alter future behavior (both for main stack and by invalidating stackprot as previously mentioned, for thread stacks), but for the sake of gcc trampolines and the complexity of determining the bounds of all existing thread stacks, need not alter behavior with respect to current stack pages. (Hypothetically, if it could on some future platform, that's great, but it probably can't now.) That seems like a reasonable, non-disruptive best effort, which, since there are apparently some exceptions that make attempting to make the stack non-executable on 32-bit (x86 or spark) somewhat less than bulletproof anyway, should probably be good enough, and better than nothing (enough to complicate the work involved in an overflow attack, anyway). And quite possibly also good enough given that an LD_PRELOADed shared object that was designed to run very early (using a #pragma init(func) perhaps) should be able to know that it didn't have to worry about stepping on existing trampolines (or about multiple threads), and could take separate action (regular mprotect() usage with a bit of knowledge of the main stack layout) to protect the existing main stack. Any later use of ADDR_STACK, by _not_ altering the protection of existing stack pages, but only future ones, would avoid breaking anything unexpectedly. -- This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
