ASLR sometimes stops working on Vista with 1.7? [was: Re: Cygwin 1.7 release (was ...)]

[Charles Wilson]

(please direct replies to the main cygwin list; I can't set reply-to on
this web interface...)

For context, see the bottom of this post:
http://cygwin.com/ml/cygwin-apps/2009-06/msg00048.html

Corinna wrote:
> I never, ever saw a problem like this on my Vista/2K8 test VMs.  Nor on
> the W7 VMs.  Are you really sure this isn't some BLODA problem?

Well, you can never be SURE. I'd be surprised tho. I use AVG 8.5, which
doesn't cause any problems on my cygwin-1.5 installation under Vista,
nor on XP. Nobody has ever reported it as a BLODA before, AFAICT.  It
does do on-access scanning, which means it hooks in to the file-access
machinery just like other BLODAs (although I've turned that off for my
cygwin-1.7 and -1.5 trees, not that doing THAT would make any difference
to a true BLODA).  What I can't figure out is, if AVG were at fault, why
it would always "attack" my cygwin-1.7 tree, but never interfere with my
cygwin-1.5 tree on the same disk.  I can even run automake from a
cygwin-1.7 shell and watch it die, and immediately run automake from a
cygwin-1.5 shell in the same directory and it succeeds...so if it's a
BLODA, it's got a jones for cygwin-1.7.

I'll check the following AGAIN when I get home...
http://cygwin.com/ml/cygwin-apps/2008-04/msg00307.html

In any event, since the remap problem happens in violation of everything
MS says ASLR is supposed to do, I blame Vista (or maybe
possible-BLODA-interfering-with-ASLR directly, not with cygwin itself).
I can inspect the new (randomized) base addresses of the ASLR-marked
DLLs after each reboot by looking at running processes using the
sysinternals process viewer.  They are (a) random and (b)
non-overlapping. But when the "*** failed to remap" occurs, I can
inspect the hung process and sure enough, foo.dll is loaded in some
strange place in memory that is NOT where ASLR promised to put it (and
there is no obvious conflicting DLL loaded where foo.dll was supposed to
go).

--
Chuck