To stir the pot some more ... If we want to change the default for all applications to be that the stack is non-executable, then why don't we have exec() do it? We already do this for amd64, no?
We try and steer away from having the ELF file be a transportation medium for arbitrary aspects of process creation. I believe a similar concept was the whole large page story, where various folks wanted to tell ld(1) that they wanted large pages, and ld(1) would squirrel this intent into the ELF file, or for ld.so.1 retrieval, so that the request would be passed onto the kernel. That's why we invented mmapobj(2), to get out of this game. The user shouldn't know about large pages, let alone be expected to tell the kernel it wants them. The kernel should use the best resources available for the file in question. This seems the same concept as an executable stack. Having the user record their intent, or ld(1) do it by default for them, just seems silly. Have the kernel do for everyone. Now, what do we do for folks who want an executable stack? Well, I guess these, hopefully few, folks can use a mapfile to set an executable stack. But there's also the ABI question. Under the "Managing the Process Stack" section of the SPARC ABI, it states "On SPARC, the stack segment is read, write, and execute permissions". Interestingly, for Intel it states "On the Intel386, the stack has read and write permissions". Although I believe our default for Intel is the same as SPARC. Our model used to be that by default we built ABI compliant applications and by default provided an environment for ABI execution. Should we consider these "rules" antiquated now? and default more to a secure environment? I'm not aware of anyone really updating any ABI's anymore, and the force of evolution seems to be de-facto standards (meaning whatever Linux does :-). -- Rod. Everybody to Everest! April 2010, I'll climb to Mt. Everest Base Camp as a fund raiser for The Challenged Athletes Foundation - www.everybodytoeverest.com. Visit www.everestchallenge.kintera.org/rie to show your support. Thanks!
