[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Can anyone tell me why...




My guess is for performance.

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).

I imagine it goes something like this:
set up process and stack, set the stack as protected, 
when the stack is accessed it the exception has to be studied for 
"legality"; if it is legal, reconfig the MMU to let it happen (provided it 
wasn't the result of resetting the program counter) -or- copy the data 
to another location and use the MMU to translate the lookup to the 
alternate location where the very next location is protected by the 
MMU, this time resulting in a seg fault -or- copy the location to a 
register and somehow wrapper the stack lookup to ultimately go to a register.

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.

So at a minimum, the CPU would probably have an extra 100 instructions 
every time the process did a function call.

That's my guess.

Mike


On Thu, 2 Jan 2003 fiaid@quasi-sane.com wrote:

> most of OS's still have an executable stack?  From windows to linux to 
> solaris, most of the OS's out there still haven't fixed this little bug.  
> I know that there is a patch for linux, and there is going to be a patch 
> included in an MU for solaris 9 in the near future.  This would be nice 
> to have to fix some rather low level bugs in the OS, buffer overflows, 
> memory races, etc.  And why hasn't something like this been incorporated 
> into the kernel as an option?  Can someone shed light on this?
> 
> Tighe
> 
> ps.  if you are bored and want to know how buffer overflows work, ill 
> write something here on the list.
> 
> 


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