> > > > I had a few minutes today to try an experiment, > and I'm afraid > >the idea of having ld always generate a PT_SUNWSTACK > is a non-starter. > > > >The problem is that it overrides the behavior of > 'set noexec_user_stack=1' > >in /etc/system, and can therefore quietly allow > programs that would > >not previously been able to execute on the stack do > so. > > > > Thanks for this investigation. > > There is another issue we haven't explored is the use > a system call; > there's a sysconf(_SC_STACK_PROT) but there's no way > to set in on the > fly. If we create a function to change it on the > fly, we could make a > LD_PRELOAD object which enforce it. The current > mapped pages would not be > protected but threadstacks and additional pages would > be rw-. > > Casper
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)); 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. I haven't thought of a good way to search for what (if any) precedent there is for how other OSs handle this. -- This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
