Large-Address awareness on 64 bit systems
Sun Jun 19 08:03:00 GMT 2011
On Jun 18 16:32, Ryan Johnson wrote:
> On 18/06/2011 4:17 PM, Corinna Vinschen wrote:
> >That means, if we make all Cygwin binaries large address aware, somebody
> >using a 64 bit system could rebase all Cygwin DLLs, except for the
> >Cygwin DLL itself into the virtual memory area beyond 0x80000000. Given
> >that this memory area is not at all used by Windows itself, it's free
> >for usage by Cygwin alone. This would affect the memory allocation not
> >only for Cygwin DLLs, but also for mmaps and for thread stacks, which
> >both use the MEM_TOP_DOWN flag.
> Wouldn't we want thread stacks to stay in the low 2GB, given
> Windows' bad habit of moving them around? In general, how does ASLR
I'm not talking about stacks crated by Windows. Did you notice my
pthread stack related changes from back in May (see CygwinCreateThread
in miscfuncs.cc), which allows Cygwin to take full control of the thread
stack address? This is what I mean. The threads created by the signal
code, or by select are not affected by this problem. They are not
inherited by the child process.
> affect things? Do heaps and system dlls risk wandering into high
Try it. AFAICS, Windows does not use the large address area at all.
> >it might be quite tricky to maintain a sane system, given that
> >gcc creates executables with the large address awareness flag switched
> >off, and given the fact that the flag is reset for a distro executable
> >every time it gets updated via setup.
> It seems like a small shell script could be a drop-in replacement
> for gcc, calling gcc and peflags under the hood. However,
> rebase[all] is a bit trickier. I would imagine that gcc's auto
> basing feature would not target high memory addresses.
Fortunately! You would badly break standard 32 bit installations if
you rebase DLLs into the large address area by default.
> >However, if anybody feels confident to test this on the own machine,
> >I'd be curious if that has the desired effect of letting fork work
> >more reliable. I'm not sure I have the required use cases to test
> >this sufficiently.
> Test cases I can think of that really expose the weaknesses of fork:
> - perl, python, and friends which use tons of dll modules
> - lisp-like languages which dynamically compile and load code
> - bootstrapping a gcc compiler
> - deliberately dlopen-ing two dlls with the same base address and
> trying to fork
Are you going to try? I started perl and python, but don't know what
to do next :)
> The first case tests fork's robustness for known dlls; the middle
> two uncover issues with dlls that are created on the fly; the last
> is just mean and nasty, in spite of its simplicity.
The last one is unhelpful, it just shows the usual problem which, of
course, does not change by rebasing into the large address area. The
sole idea is to *avoid* collisions by getting a much bigger arena.
If you enforce the collision you're back at square one.
That's why we could need a better rebase algorithm. Some kind of
rebaseall executable or perl script which scans all Cygwin DLLs and
notes the used and free address slots as well as the size of the DLLs
and then, afterwards, uses this knowledge to move the DLLs around, as
collision-free as possible. It would also allow to rebase just a single
DLL into a as yet free memory slot instead of having to specify the
address on the command line.
Btw., for testing I rebased the Cygwin DLL into the large address
area as well. No problems here so far.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
More information about the Cygwin-developers