This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [1.7] rebaseall doesn't solve the problem


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]