On Monday, March 31, 2003, at 8:11 PM, Ragnar Sundblad wrote: On den 31 mars 2003 19:52 -0500 Jim Magee <jmagee@apple.com> wrote: Do you want us to change the PowerPC architecture? Yes, wherever it has shortcomings, I would like you to! :-) Except that we don't control it. It's part of the documented architecture for 32-bit processors. It is not an implementation feature of aspecific processor in the family. It's kind of like you asking Intel to change the P5 MMU (in a way that means old OSes aren't going to run on it). They won't do it. We can make suggestions for the next architecture. But we'll never have any luck changing the one that's sitting on your desk. Or do you think it is worth taking 256MB of virtual address space from each task and making it no-execute, and then forcing all stacks to be in there (requiring many/most programs to be re-built to adapt to it)? What is the limit today, 2.5G or something? How many apps fits well in 2.5G but absolutely not in 2.25G? Sure, more space to apps is good, but if you are that close you will probably have to take other measures to handle it anyway. It's the contiguous and aligned nature of the requirement that is the problem. In essence, given all the legacy reserved memory ranges, we would likely have to put this at 0x70000000 and you would be limited to 2GB contiguous space in an application (plus there are some available ranges up above there as well, just not a big contiguous blob). Besides, all this is on the assumption that you have to execute code on the stack. More common (from a PowerPC hack perspective) is to just change link register values saved on the stack to trick the program into running code that already exists (the blr instruction is used to both call and return from a function). The only stuff that has to be on the stack is the argument data and the stomped address. Jumping to the well-known address for the system() library routine should do nicely. ;-) In fact, arranging to execute code just written on the stack is fairly tricky on the PowerPC. You have to manually synchronize the icache to the dcache. Finding code to do that in an existing application (since you can't reliably execute even it from the stack until you run it) and then getting a branch back to your code is much less likely to be successful. I can only imagine that was one of the thoughts behind the processors lack of granular no-execute permissions. Most data pages "behave" that way often enough (because of the cache issues) to sway hackers into other means (like the one I described above which would not be helped by no-execute permissions on any data). --Jim _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.