Re: Can anyone tell me why...

["john doe" <ophidian_snake@hotmail.com>]

now IIRC, the reason its not done is because its impossible to do properly 
on x86 hardware (at least if im remembering the kernel list discussion about 
it accurately)

Casey



>From: Mike Connor <mikec@silug.org>
>Reply-To: silug-discuss@silug.org
>To: silug-discuss@silug.org
>Subject: Re: Can anyone tell me why...
>Date: Thu, 2 Jan 2003 13:23:59 -0600 (CST)
>MIME-Version: 1.0
>Received: from web1.lanscape.net ([64.240.156.194]) by 
>mc10-f12.bay6.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 2 Jan 
>2003 11:24:11 -0800
>Received: from silug.org (localhost [127.0.0.1])by web1.lanscape.net 
>(8.11.6/8.11.6) with ESMTP id h02JO8425497;Thu, 2 Jan 2003 13:24:08 -0600
>Received: from localhost (mikec@localhost)by web1.lanscape.net 
>(8.11.6/8.11.6) with ESMTP id h02JNxh25444for <silug-discuss@silug.org>; 
>Thu, 2 Jan 2003 13:23:59 -0600
>X-X-Sender: mikec@web1.lanscape.net
>In-Reply-To: <Pine.LNX.4.44.0301021230010.8488-100000@n00bz.net>
>Message-ID: <Pine.LNX.4.44.0301021312440.25210-100000@web1.lanscape.net>
>Organization: Southern Illinois Linux Users Group
>Precedence: bulk
>Sender: silug-discuss-owner@silug.org
>Return-Path: silug-discuss-owner+M4290@silug.org
>X-OriginalArrivalTime: 02 Jan 2003 19:24:11.0338 (UTC) 
>FILETIME=[873952A0:01C2B294]
>
>
>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).
>
>Mike
>
>
>On Thu, 2 Jan 2003 fiaid@quasi-sane.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
> > 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
> >
> >
>
>
>-
>To unsubscribe, send email to majordomo@silug.org with
>"unsubscribe silug-discuss" in the body.


_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* 
http://join.msn.com/?page=features/virus


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