Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-f.b-one.net (mx-f.one.com [91.198.169.53])
	by mail9.b-one.net (Postfix) with ESMTP id 715F2400364
	for <info@awaresystems.be>; Tue,  5 May 2009 20:35:11 +0200 (CEST)
X-Virus-Scanned: by one.com
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=0 required=6 tests=[none]
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144])
	by mx-f.b-one.net (Postfix) with ESMTP id CD8072800133
	for <info@awaresystems.be>; Tue,  5 May 2009 20:35:10 +0200 (CEST)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id EFD6D1D371C3D;
	Tue,  5 May 2009 13:34:32 -0500 (EST)
Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74])
	by lists.maptools.org (Postfix) with ESMTPS id 44F951D371BE8
	for <tiff@lists.maptools.org>; Tue,  5 May 2009 13:32:49 -0500 (EST)
Received: from freddy.simplesystems.org (freddy.simplesystems.org
	[65.66.246.65])
	by blade.simplesystems.org (8.13.8+Sun/8.13.8) with ESMTP id
	n45IWkBw023992; Tue, 5 May 2009 13:32:46 -0500 (CDT)
Date: Tue, 5 May 2009 13:32:46 -0500 (CDT)
From: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
X-X-Sender: bfriesen@freddy.simplesystems.org
To: Albert Cahalan <acahalan@gmail.com>
In-Reply-To: <787b0d920905051109x403a90cx78debf54f55b7238@mail.gmail.com>
Message-ID: <Pine.SOC.4.64.0905051319090.1108@freddy.simplesystems.org>
References: <op.usz7voo3foqvse@simon.fritz.box> 
	<0E2E76C8-CAF8-45B5-BAAD-BDC4939B6CF0@telegraphics.com.au> 
	<787b0d920904300041y16f836bx87caec73e17e9ebf@mail.gmail.com> 
	<869A614C-C44E-4F4F-821D-B1934573CAD2@telegraphics.com.au> 
	<787b0d920904301212l5ef55bf8q90ae726b091f07df@mail.gmail.com> 
	<DE7A57F5-D99E-4B61-8ABD-55B611D24277@telegraphics.com.au> 
	<787b0d920904301231m5b5998ecr994847b922badf0f@mail.gmail.com> 
	<B108E18B-4822-4A7B-BFC4-BFA68F2384E2@telegraphics.com.au> 
	<787b0d920904302334s33c4d02aw1de835acd5795293@mail.gmail.com> 
	<Pine.SOC.4.64.0905051111450.1108@freddy.simplesystems.org>
	<787b0d920905051109x403a90cx78debf54f55b7238@mail.gmail.com>
MIME-Version: 1.0
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2
	(blade.simplesystems.org [65.66.246.90]);
	Tue, 05 May 2009 13:32:47 -0500 (CDT)
Cc: TIFF list <tiff@lists.maptools.org>
Subject: Re: [Tiff] Packbits worst case encoded length
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

On Tue, 5 May 2009, Albert Cahalan wrote:

>> wrong that the malloc library can not detect.  Guard pages are only somewhat
>> useful since they only cover the case where there is a linear overwrite past
>> the end of the allocated buffer.
>
> Sure, but this is a **very** common and dangerous case.

Is it more dangerous than the other cases?  What would cause one case 
to be more dangerous than another?

> Guard pages are pages of memory that you can't read or write.
> There is no "original guard content" to preserve. Any attempt
> to read or write to a guard page will cause an immediate crash.

Ahhh, I see.  This wastes a whole MMU page (4K, 8K, 16K, or ???) per 
memory allocation.  It also needs to start on a MMU page boundary, 
which may be far beyond the user-requested allocation.  If the user 
requests 128 bytes, then that leaves a long region which is unchecked 
and the underlying allocation really needs to be at least a page long. 
In order to be safe, there needs to be protection against underflow, 
so the page below needs to be a guard page as well.  The end result is 
that there is huge waste of memory if the user allocations are small.

It seems that the strategy taken can be controlled by which malloc 
library is linked to at library link time, program link time, or 
preloaded via an OS specific means.

> Sure, though decompression code isn't dealing with those.
> Decompression code is a common source of trouble.

No doubt.

Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
