On Mon, Apr 23, 2012 at 04:51:06PM +0200, Corinna Vinschen wrote: >On Apr 23 14:23, James Johnston wrote: >> Perhaps I did not make it clear enough, but these issues still exist as far >> as I can tell. I have clean Windows 7 and Windows XP virtual machines, and >> a clean install of Cygwin that was updated at the time I sent my original >> message. Both issues I described still exist. This is why I wrote the >> message. If the issues weren't existing on an up-to-date Cygwin >> installation, I would not write to this mailing list and waste anyone's time >> - I am usually not that dumb! >> >> Just this morning, I turned on my Cygwin installation in the Windows 7 VM. >> This time, cygreadline7.dll decided to relocate to 0x70030000 - different >> from the original location I mentioned in my original e-mail. This DLL is >> not locating itself in a stable location. And there are still system DLLs >> located very close to the Cygwin DLLs. >> >> If having Windows randomly rebase cygreadline7.dll in a child process via >> ASLR is not a problem, I'd simply be interested to know why. I thought >> *any* Cygwin DLL relocating itself would cause fork to fail. > >Yes, it is a problem in the first place if DLLs have the dynamicbase >flag set, because, obviously, it undermines what rebaseall is doing. >It's not a problem if the new address it gets rebased to doesn't collide >with any other used DLL since ASLR on Windows only shuffles ASLR-enabled >DLL addresses when a DLL is loaded by an application for the first time. >Afterwards, it will use the new address for that DLL until reboot. >So, yes, we should make sure that the ASLR flag is not used for Cygwin >DLLs.
Is this something that rebase could turn off when it touches a DLL? cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
