Re: Non-executable stack
Re: Non-executable stack
- Subject: Re: Non-executable stack
- From: Jim Magee <email@hidden>
- Date: Mon, 31 Mar 2003 22:54:19 -0500
On Monday, March 31, 2003, at 8:11 PM, Ragnar Sundblad wrote:
On den 31 mars 2003 19:52 -0500 Jim Magee <email@hidden> 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 | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.