>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

Reply via email to