Windows heaps and Cygwin heap

[Ryan Johnson]

On 17/05/2011 4:19 AM, Corinna Vinschen wrote:
> On May 13 06:32, Ryan Johnson wrote:
>> On 13/05/2011 5:29 AM, Corinna Vinschen wrote:
>>> On May 13 10:36, Corinna Vinschen wrote:
>>>> So we now know that we are actually observing a part of the ASLR
>>>> strategy of NT6.  Heap addresses are always randomized.  Yes, there is a
>>>> PE flag which controls ASLR on a per-executable basis, but unfortunately
>>>> this only influences the usage of ASLR for the executable image itself,
>>>> as well as the thread stacks.  There's no way at all to disable heap ASLR.
>>> It appears that I misread.  The PE flag might not influence stack
>>> randomization, but what I found in the net is contradictory.  However,
>>> even if stack ASLR is always on, it seems the preferred addresses of
>>> thread stacks are also in the range below 0x20000000.
>> In any case, I also have never seen problems above 0x20000000.
> I'm looking into the heap and stack addresses for a good amount of time
> now.  Since we're talking about Cygwin applications only, which don't
> use HeapCreate, we only have to care for heaps created by Win32 DLLs.
>
> What I'm observing is that even big apps like vim, emacs, octave don't
> use addresses beyond 0x03000000.  Setting the heap to an address of
> 0x20000000 appears to be a rather big waste of memory.
>
> So I'm planning to drop the bar to 0x08000000, which gives the heap
> a potential extra memory of 384 Megs. and still leaves a confortable
> cushion of 80 Megs for the OS.
>
> Does anybody see a good reason not to do that, like, say, different
> observations of the memory address usage by OS DLLs and stuff?

On my machine, running 'emacs-X11 -nw', quite a bit of stuff appears at 
0x01????? (showing only allocation bases below for brevity):
> 01390000-01391000 rw-p 00000000 0000:0000 0                   [shareable]
> 013A0000-013D9000 ---p 00000000 0000:0000 0
> 013E0000-013E1000 rw-p 00000000 0000:0000 0
> 013F0000-013F1000 rw-p 00000000 0000:0000 0                   [heap 4]
> 01400000-01439000 ---p 00000000 0000:0000 0
> 01440000-01441000 rw-p 00000000 0000:0000 0
> 01460000-014A7000 rw-p 00000000 0000:0000 0                   [heap 1]
> 01560000-01561000 r--p 00000000 2C36:17C8 281474977544475     
> /usr/bin/cygxml2-2.dll
> 01680000-01A80000 ---p 00000000 0000:0000 0
> 01A80000-01C2D000 rw-p 00400000 0000:0000 0
> 01C2D000-19A80000 ---p 005AD000 0000:0000 0

Another bunch appears in the 0x19??????-0x1C?????? range (again, 
allocation bases only):
> 19A80000-19C7B000 ---p 00000000 0000:0000 0
> 19C80000-19C87000 r--p 00000000 0000:0000 0                   [shareable]
> 19C90000-19C92000 rw-p 00000000 0000:0000 0                   [shareable]
> 19CB0000-19CB1000 rw-p 00000000 0000:0000 0                   [heap 8]
> 19CF0000-19D29000 ---p 00000000 0000:0000 0
> 19D40000-19D41000 rw-p 00000000 0000:0000 0                   [heap 5]
> 19D50000-19D89000 ---p 00000000 0000:0000 0
> 19D90000-19DA1000 rw-p 00000000 0000:0000 0                   [shareable]
> 19DC0000-19DC6000 rw-p 00000000 0000:0000 0                   [heap 3]
> 19E00000-19E39000 ---p 00000000 0000:0000 0
> 19E50000-19E57000 rw-p 00000000 0000:0000 0                   [heap 2]
> 19E60000-1A12F000 r--p 00000000 2C36:17C8 281474976729973     
> /cygdrive/c/Windows/Globalization/Sorting/SortDefault.nls
> 1A130000-1A32D000 ---p 00000000 0000:0000 0
> 1A330000-1A356000 r--p 00000000 0000:0000 0                   [shareable]
> 1A4C0000-1A641000 r--p 00000000 0000:0000 0                   [shareable]
> 1A650000-1A8BB000 r--p 00000000 0000:0000 0                   [shareable]
> 1BA50000-1BA6F000 rw-p 00000000 0000:0000 0                   [heap 2]
> 1BB50000-1BB61000 rw-p 00000000 0000:0000 0                   [shareable]
> 1BB80000-1BB83000 rw-p 00000000 0000:0000 0                   [heap 6]
> 1BB90000-1BBA1000 rw-p 00000000 0000:0000 0                   [shareable]
> 1BBB0000-1BBC1000 rw-p 00000000 0000:0000 0                   [shareable]
> 1BBD0000-1BBE1000 rw-p 00000000 0000:0000 0                   [shareable]
> 1BCD0000-1BCD1000 rw-p 00000000 0000:0000 0                   [heap 9]
> 1BD30000-1BD31000 rw-p 00000000 0000:0000 0                   [heap 7]
> 1BD70000-1BF6B000 ---p 00000000 0000:0000 0
> 1BF70000-1C16B000 ---p 00000000 0000:0000 0
> 1C170000-1C36B000 ---p 00000000 0000:0000 0
> 1C370000-1C6B7000 r--p 00000000 0000:0000 0                   [shareable]

While cygxml2-2.dll presumably needs rebased and can be made to move, I 
think the rest is there to stay.

Thoughts?
Ryan