[patch/rebase]: Makefile support for cross-builds and static linking with gcc-4

[Charles Wilson]

On 6/21/2011 4:06 AM, Corinna Vinschen wrote:
> Btw., did anybody experiment with setting the ASLR flag for DLLs?
> Chuck's description sounds as if this really might help to reduce
> collision problems at fork time.  If so, the ASLR flag should 
> become default for DLLs.

(1) I thought the end result of those experiments was that it really
didn't help, and sometimes hurt...especially as Reini wrote last december:

http://cygwin.com/ml/cygwin/2010-12/msg00091.html
>> I'm trying now to turn off ASLR: peflags -d0 for all perl dll's.
> Yes. Adding a -d0 solved so far the problems on Win7 for me.

More recently on the mingw list:
http://lists-archives.org/mingw-users/19902-msys-perl-regression.html
>> I thought we (on cygwin) had pretty much come to the conclusion that
>> chasing after ASLR and peflags -d0
[ed: that is, turning ASLR *off*]
>> was a red herring?  Well, I guess
>> it's not too hard to patch the Makefile to run peflags on miniperl...
>
> Not really. I tested recently perls on Windows 7 with peflags -d1
[ed: that is, with ASLR turned on]
> and
> came to the conclusion that in perl forking a perl which load dll's
> (XS) we get random problems.

(2) Most of the problems lately seem to occur with 64bit OS's. I think
your idea of rebasing into high memory on those systems is something
good to try -- but in that case, ASLR will not apply anyway:

    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.

With regards to #1, we had a long thread a few years ago, where we
investigated an issue where DLLs would allocate memory 'right next to'
their own .text segment -- but this extra memory doesn't show up in the
"next_dll_image_base = my_dll_image_base + my_dll_image_size"
calculation.  Hence, boom.  We "solved" the problem by explicitly
increasing the rebaseall offset to 0x20000, and fixing one other issue
related to allocating a large buffer for a filename in the PEB or something:
http://cygwin.com/ml/cygwin/2009-06/msg00266.html (*)


One statement in that thread:
http://cygwin.com/ml/cygwin/2009-06/msg00226.html
> In that sense, ASLR would be a disimprovement over what we can do with
> rebase, because we can apply a larger quantization (e.g.
> DefaultOffset=0x20000).
referred the fact that ASLR will *always* compute the next image base
based on a 64k quantization size, and can't be 'tweaked' to make room
for allocations in the first dll, that happen after the "next" dll is
loaded and ASLRed.


=====
so, the upshot is, I'm not sure if ASLR really is a silver bullet, since
Reini's experiments in late 2010 are certainly after the buffer-size
changes from June 2009.

I'd love to be wrong...

--
Chuck



(*) This series of patches, I believe
2009-06-06  Corinna Vinschen  <>

  * dll_init.cc (dll_list::alloc): Allocate memory using a section
  object.  Explain why.  Drop call to GetSystemInfo, rather call
  getpagesize to get allocation granularity.  Only align to allocation
  granularity under WOW64.  Use roundup2 to align.
  (dll_list::detach): Call NtUnmapViewOfSection instead of VirtualFree.

2009-06-06  Corinna Vinschen  <>

  * mmap.cc: Use NtUnmapViewOfSection instead of UnmapViewOfFile
  throughout for symmetry.
  (fhandler_dev_mem::munmap): Use correct process handle in call to
  NtUnmapViewOfSection.

2009-06-06  Corinna Vinschen  <>

  * dll_init.h (struct dll): Set size of name element to ANYSIZE_ARRAY.
  * dll_init.cc: Fix formatting.
  (dll_list::alloc): Only allocate as much memory for struct dll as
  necessary for given DLL name.
  (dll_list::load_after_fork): Only read a single page of parent memory.
  Only read more if namelen indicates that it's necessary.