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

Re: Can anyone tell me why...




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.