>Thanks for the info. > >Doesn't help with existing binaries, but it's good to know for >when one can re-link. If there's a way to construct an >LD_PRELOAD'able shared object to do the trick for existing >binaries, I don't see how given the description of mprotect(2), >to specify the entire present (and future) stack or heap of a process.
True. That's why we have the /etc/system tunable. Before we created the tunable, I created a "poke the kernel" script. Because of the limitations in where I could poke the kernel, I modified the routine which created all the "zero-fill-on-demand" pages; this includes the stack but everything allocated in on the heap, including the BSS segment. >From some of the stuff I've looked at, it seems that executables were >first widely built to disable an executable stack >(using something as boring as /usr/bin/who as the test case) >in Solaris 9; on Solaris 8, I didn't see a program header for the stack for >the "who" executable, but when I recompiled with the -M option you >gave, and checked the new binary with elfdump, I saw the additional >program header. I'm not sure when we added support for that header in the kernel. >There are a few oddball programs that legitimately want a segment >that's both writable and executable (because they compile on-the-fly); >some LISP interpreters used to do that, I think; and I can imagine that >some Forth implementations might want to do strange things. (I wonder >if the JVM does anything like that?) But I suppose they ought >to create an explicit anonymous mapping with the permissions they >desire for that use. With the patch script above, we did find that java and some other runtime create code run into the problem. But we limit it to the stack as the kernel does, there is no issue apart from some of the cases where gcc creates code on the stack. >Now...if there only weren't still 32-bit executables that aren't large-file >aware. :-) The only issue we were able to fix was the inability to open more than 256 FILE*s and we have a pre-loaded script. I don't think we have a routine to change the stack protection on the fly. Casper _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
