>I picture this somehow as being just a bit more functionality added to >mprotect(2): > >/* following magic to identify operating on that segment, rather than > * a particular address > */ >#define ADDR_STACK (void *) (-1) >#define ADDR_HEAP (void *) (-2) > >mprotect(ADDR_STACK, 0, (PROT_READ|PROT_WRITE|PROT_EXEC));
It's a bit harder to bolt on the current implementation of the stack protection. And what is the "ADDR_STACK" *all* current thread stacks, the stack of main or the current stack? >where a length of 0 implies something similar to what (MCL_CURRENT|MCL_FUTURE) >implies with memcntl(2), namely to apply that behavior to both the present and >future pages of the segment; that would combine applying mprotect() to the >existing pages as well as setting p_stkprot or p_datprot in the proc structure. > >Such an interface would be ideal for runtime control either by >the developer or after-the-fact with an LD_PRELOAD'ed shared object. > >Adding this functionality to mprotect() would be more understandable than >a new function, and would avoid adding an additional system call. I don't >imagine that any existing software (except _maybe_ an emulator?) would >call mprotect() so often that the addition of a couple of if's or a switch() >applied to the addr arg would present a performance problem. There is one particular issue where gcc uses a trampoline created on the stack when you are passing a nested function as a function argument. (A nested function requires an additional argument) Casper _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
