Re: Can anyone tell me why...

[fiaid@quasi-sane.com]

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
think"?

> 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?

Tighe

-- 
Tighe Schlottog         workape         fiaid
"Nothing is too cruel if it is funny enough."


-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.