Rod Evans wrote: > 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?
Because of binary compatibility. It's two different audiences. With ld.so.1 and exec(2), the audience of users is "everyone." It includes people who are receiving binaries from vendors, who may do all sorts of crazy things, including writing SMC on the stack. With ld, the audience is primarily "developers." Changing that causes no trouble for existing executables. It's only people who are creating new ones who run into the issue, and they're in a perfect position to fix the problem or work around it if needed. That's not true for the person who gets an OCO (object code only) binary from some vendor. > We try and steer away from having the ELF file be a transportation > medium for arbitrary aspects of process creation. I believe a Yep; understood. It's unfortunate that we're here. If stacks were not intended to be executable and weren't used that way from the beginning, we'd be in a different place. It's important to note that the issue (if it exists on an application) is specific to the design of that application. It's not something that the user of the application wants or needs, nor is it something that a system administrator could or should need to consider. Since needing an executable stack is a wart in the application, it's hard to see how anything other than a tag of some sort in the executable would do. I appreciate the general principle, but I don't think it applies here. > 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 :-). ;-} The ABI question is an excellent one. It's worth noting that applications successfully built with the modified ld (with the new default) will still be ABI-compliant. The application will never try to execute on the stack, so it'll never notice that this is restricted. The only question is what the developer must do in order to get into the case where execution on the stack is permitted as per the ABI. We require people to add a non-obvious set of libraries and toss in special compiler flags to get standards-compliant behavior, and this doesn't seem so different to me, particularly given the security and brownie point benefits. Being the last OS on the planet to disable execution on the stack probably isn't a good goal. -- James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
