[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Can anyone tell me why...
Guess I'll watch for the answer then. I've never noticed that the MMU
could get state from the CPU regarding what exactly the fetch was for
(loaded as a result of PC or just a plain ol' fetch).
On Thu, 2 Jan 2003 email@example.com wrote:
> Trust me, I am no expert on this, but it was an interesting discussion I
> was having with those guys, hopefully they will be on later.
> > From what little I've messed with process stacks ( so be nice if I'm
> > ignorant on the subject ), you'd have to make every push/pop from the
> > stack handled by the kernel (obviously). You'd have to enforce it with
> > the MMU (which you'd be reconfiguring twice as often).
> In the creation of the stack though, doesn't the VMM flag the MMU as
> execute/non-excute? At this point the stack is flaged non-execute and it
> only takes that one step. So at the beginning of the process running or
> at the fork when the new MMU's are created, why doesn't the underlying
> subsystems just say "all stacks are non-executable, i don't care what you
> > If you did something like one of the above and someone managed to set
> > the program counter to a stack location, it would hang the process or
> > kill it. Which I guess would be a good thing.
> Not all the time though, if you use a noop sled to catch the pointer into
> the stack and have it fall down to your machine code it still hasn't
> caught a signal yet. This really depends on how smart the buffer overflow
> writer was, if he created a large enough sled then they would be able
> direct the pointer into a large enough location that it would be able to
> noop slide down the code and execute it.
> > So at a minimum, the CPU would probably have an extra 100 instructions
> > every time the process did a function call.
> I am not sure about this, there might be additional instructions, but they
> would be at a machine code level and wouldn't really take up all that much
> CPU power.
> Like I said earlier, I really know very little about this but I am
> curious. I know that we got some real developers here on the list, can
> they shed some light?
To unsubscribe, send email to firstname.lastname@example.org with
"unsubscribe silug-discuss" in the body.