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