Message-ID: <43591652.6080505@csc.ncsu.edu>
Date: Fri, 21 Oct 2005 12:24:50 -0400
From: "Vincent W. Freeh" <vin@csc.ncsu.edu>
User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720)
MIME-Version: 1.0
To: linux-kernel@vger.kernel.org
Subject: Re: Understanding Linux addr space, malloc, and heap
References: <4358F0E3.6050405@csc.ncsu.edu>	<1129903396.2786.19.camel@laptopd505.fenrus.org>	<4359051C.2070401@csc.ncsu.edu>	<1129908179.2786.23.camel@laptopd505.fenrus.org>	<43590B23.2090101@csc.ncsu.edu> <je64rqlued.fsf@sykes.suse.de>
In-Reply-To: <je64rqlued.fsf@sykes.suse.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 971
Lines: 27

I guess I live in a different world.  I do lots of things I'm not 
"supposed" to do.

Moreover, it is very sensible and usable to mprotect malloc pages.  I 
have implemented simple sandboxing this way.  For my dissertation I 
implemented a DSM by mprotect'g malloc'd memory.  This system worked for 
 >6 on several version of Linux and SunOS.  I actually have a better 
track record for this technique than for some things that are within the 
specifications.

Andreas Schwab wrote:
> "Vincent W. Freeh" <vin@csc.ncsu.edu> writes:
> 
> 
>>The point of the code is to show that one can protect malloc code.
> 
> 
> You "can" do many things.  But that does not mean that you always get any
> sensible behaviour.
> 
> Andreas.
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/