X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Sat, 28 Feb 2009 11:43:37 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: [1.7] rebaseall doesn't solve the problem
Message-ID: <20090228104337.GG19887@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <499F6682 DOT 1090204 AT cwilson DOT fastmail DOT fm> <20090224100616 DOT GC6035 AT calimero DOT vinschen DOT de> <49A85971 DOT 6070300 AT cwilson DOT fastmail DOT fm>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <49A85971.6070300@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 Feb 27 16:21, Charles Wilson wrote:
> Corinna Vinschen wrote:
> [...]
> > I'm wondering if that's a result of ASLR in Vista.  The document
> > http://taossa.com.nyud.net:8080/archive/bh08sotirovdowd.pdf [...]
> [...]
> > If so, there's nothing Cygwin can do against that.  In the long run,
> > only a native fork() implementation would help.
> 
> Well, maybe not! From the document you referenced:
> 
>     Since Windows relies on relocations instead of position
>     independent code, a DLL must be loaded at the same address
>     in each process that uses it to allow the physical memory
>     used by the DLL to be shared. To facilitate this behaviour,
>     a global bitmap called _MiImageBitMap is used to represent
>     the address space from 0x50000000 to 0x78000000. The bitmap
>     is 0x2800 bits in length with each bit representing 64KB
>     of memory. As each DLL is loaded, its position is recorded
>     by setting the appropriate bits in the bitmap to mark the
>     memory where the DLL is being mapped. When the same DLL
>     is loaded in another process, its section object is reused
>     and it is mapped at the same virtual addresses.
> 
> So, by marking a particular (or all but cygwin1.dll?) DLL as
> ASLR-compatibile, we may be able to coerce the Windows runtime loader
> into ensuring that the DLLs are loaded at the same memory location for
> all concurrent processes (unless the parent has filled up the space from
> 0x50000000 to 0x78000000, and so is forced to put an ASLR-compatible DLL
> somewhere else that is not tracked by _MiImageBitMap).
> 
> I wrote a little utility to explicitly mark a DLL as ASLR-compatible.
> Using it on Cwd.dll -- the offending one in my situation -- I was able
> to eliminate the problem!

Way cool, Chuck.  Especially the fact that this tool can also mark
executables with the TS-aware flag (doesn't make sense for DLLs, afaik).
This helps to test if setting this flag in Cygwin binaries will
allow Cygwin to run on 2008 with TS without disabling DEP.

If so, I'm wondering if setting the TS-aware flag shouldn't become
default in GCC.  What do you say, Dave?  Would that be possible?

That would also allow to drop the ugly TS hack I added to Cygwin 1.7.
All newly built binaries would have the flag set already, and older
binaries could be tweaked with the aslr utility.


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/