X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Sun, 7 Jun 2009 21:32:41 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: ASLR sometimes stops working on Vista with 1.7? [was: Re: 	Cygwin      1.7  release (was ...)]
Message-ID: <20090607193241.GH25832@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <4A286B99 DOT 6020702 AT users DOT sourceforge DOT net> <20090605120936 DOT GD23519 AT calimero DOT vinschen DOT de> <4A293237 DOT 2010102 AT cwilson DOT fastmail DOT fm> <20090605163510 DOT GF23519 AT calimero DOT vinschen DOT de> <4A296778 DOT 2080507 AT cwilson DOT fastmail DOT fm> <20090605213012 DOT GG23519 AT calimero DOT vinschen DOT de> <4A29B510 DOT 3020601 AT gmail DOT com> <20090606084924 DOT GI23519 AT calimero DOT vinschen DOT de> <20090607082308 DOT GA25832 AT calimero DOT vinschen DOT de> <4A2BB5BB DOT 4000402 AT cwilson DOT fastmail DOT fm>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4A2BB5BB.4000402@cwilson.fastmail.fm>
User-Agent: Mutt/1.5.19 (2009-02-20)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Jun  7 08:42, Charles Wilson wrote:
> Corinna Vinschen wrote:
> > The structure is allocated right after the space occupied by the DLL
> > itself, using VirtualAlloc.  I changed the struct layout so that the
> > size depends on the length of the pathname to the DLL.  In most, if not
> > all cases this will fit into a single 4K page.
> ...
> > However, in most cases the DLL itself will not occupy the
> > entire 64K slot, but one or more 4K pages are left free, which will
> > never be used while the application is running.
> 
> So, while the following are probably not practical concerns, there are
> still a few failure modes, correct?
> 
> 1) if the ImageSize of the DLL is between N*64k-4k+1 and N*64k, the next
> 4k page allocated for the struct will again clobber the next DLL's ImageBase

Yes, but that was always the case, even before Cygwin 1.7, since the
method is not exactly new.  The only new property is that the pathname
is stored as wchar_t and that it can have a length of up to 32K.  So far
the next 64K slot was always taken.  Now it's only taken if the DLL
occupies the last page in the 64K slot by itself, or...

> 2) if the length of the actual pathname to the DLL is more than 2k wide
> characters (e.g. 4k bytes) then issue #1 is made increasingly likely,
> because the "dangerous DLL size" becomes N*64k-M*4k+1 .. N*64k, with
> 1<M<=16.  Once the pathname to the DLL gets to be near 32k wide chars
> (e.g. M=16, for 64k bytes in the struct) then the new solution devolves
> to the status quo ante.

... the path is very long.

> 3) This new solution can never work properly for WOW64

Right.  However, even without my patch to utilize the trailing pages
in a 64K slot, we're at least back to the "usual" rebase problem.
On 32 bit OSes, it got better now.

Anyway, the discussion is moot since Chris' patch to use cygheap to
store the per-DLL struct seems to work nicely.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/