documentation/address-space.sgml

   1 <chapter id="address-space">
   2   <title> Address space management </title>
   3
   4   <para>
   5     Every Win32 process in Wine has its own dedicated native process on the host system, and
   6     therefore its own address space. This section explores the layout of the Windows address space
   7     and how it is emulated.
   8   </para>
   9
  10   <para>
  11     Firstly, a quick recap of how virtual memory works. Physical memory in RAM chips is split
  12     into <emphasis>frames</emphasis>, and the memory that each process sees is split
  13     into <emphasis>pages</emphasis>. Each process has its own 4 gigabytes of address space (4gig
  14     being the maximum space addressable with a 32 bit pointer). Pages can be mapped or unmapped:
  15     attempts to access an unmapped page cause an EXCEPTION_ACCESS_VIOLATION which has the
  16     easily recognizable code of 0xC0000005.  Any page can be mapped to any frame, therefore you can
  17     have multiple addresses which actually "contain" the same memory. Pages can also be mapped to
  18     things like files or swap space, in which case accessing that page will cause a disk access to
  19     read the contents into a free frame.
  20   </para>
  21
  22   <sect1>
  23     <title>Initial layout</title>
  24
  25     <para>
  26       When a Win32 process starts, it does not have a clear address space to use as it pleases. Many pages
  27       are already mapped by the operating system. In particular, the EXE file itself and any DLLs it
  28       needs are mapped into memory, and space has been reserved for the stack and a couple of heaps
  29       (zones used to allocate memory to the app from). Some of these things need to be at a fixed
  30       address, and others can be placed anywhere.
  31     </para>
  32
  33     <para>
  34       The EXE file itself is usually mapped at address 0x400000 and up: indeed, most EXEs have
  35       their relocation records stripped which means they must be loaded at their base address and
  36       cannot be loaded at any other address.
  37     </para>
  38
  39     <para>
  40       DLLs are internally much the same as EXE files but they have relocation records, which means
  41       that they can be mapped at any address in the address space. Remember we are not dealing with
  42       physical memory here, but rather virtual memory which is different for each
  43       process. Therefore OLEAUT32.DLL may be loaded at one address in one process, and a totally
  44       different one in another. Ensuring all the functions loaded into memory can find each other
  45       is the job of the Windows dynamic linker, which is a part of NTDLL.
  46     </para>
  47
  48     <para>
  49       So, we have the EXE and its DLLs mapped into memory. Two other very important regions also
  50       exist: the stack and the process heap. The process heap is simply the equivalent of the libc
  51       malloc arena on UNIX: it's a region of memory managed by the OS which malloc/HeapAlloc
  52       partitions and hands out to the application. Windows applications can create several heaps but
  53       the process heap always exists. It's created as part of process initialization in
  54       dlls/ntdll/thread.c:thread_init().
  55     </para>
  56
  57     <para>
  58       There is another heap created as part of process startup, the so-called shared or system
  59       heap. This is an undocumented service that exists only on Windows 9x: it is implemented in
  60       Wine so native win9x DLLs can be used. The shared heap is unusual in that anything allocated
  61       from it will be visible in every other process. This heap is always created at the
  62       SYSTEM_HEAP_BASE address or 0x80000000 and defaults to 16 megabytes in size.
  63     </para>
  64
  65     <para>
  66       So far we've assumed the entire 4 gigs of address space is available for the application. In
  67       fact that's not so: only the lower 2 gigs are available, the upper 2 gigs are on Windows NT
  68       used by the operating system and hold the kernel (from 0x80000000). Why is the kernel mapped
  69       into every address space?  Mostly for performance: while it's possible to give the kernel its
  70       own address space too - this is what Ingo Molnars 4G/4G VM split patch does for Linux - it
  71       requires that every system call into the kernel switches address space. As that is a fairly
  72       expensive operation (requires flushing the translation lookaside buffers etc) and syscalls are
  73       made frequently it's best avoided by keeping the kernel mapped at a constant position in every
  74       processes address space.
  75     </para>
  76
  77     <para>
  78       On Windows 9x, in fact only the upper gigabyte (0xC0000000 and up) is used by the kernel, the
  79       region from 2 to 3 gigs is a shared area used for loading system DLLs and for file
  80       mappings. The bottom 2 gigs on both NT and 9x are available for the programs memory allocation
  81       and stack.
  82     </para>
  83
  84     <para>
  85       There are a few other magic locations. The bottom 64k of memory is deliberately left unmapped
  86       to catch null pointer dereferences. The region from 64k to 1mb+64k are reserved for DOS
  87       compatibility and contain various DOS data structures. Finally, the address space also
  88       contains mappings for the Wine binary itself, any native libaries Wine is using, the glibc
  89       malloc arena and so on.
  90     </para>
  91
  92   </sect1>
  93
  94   <sect1>
  95     <title> Laying out the address space </title>
  96
  97     <para>
  98       Up until about the start of 2004, the Linux address space very much resembled the Windows 9x
  99       layout: the kernel sat in the top gigabyte, the bottom pages were unmapped to catch null
 100       pointer dereferences, and the rest was free. The kernels mmap algorithm was predictable: it
 101       would start by mapping files at low addresses and work up from there.
 102     </para>
 103
 104     <para>
 105       The development of a series of new low level patches violated many of these assumptions, and
 106       resulted in Wine needing to force the Win32 address space layout upon the system. This
 107       section looks at why and how this is done.
 108     </para>
 109
 110     <para>
 111       The exec-shield patch increases security by randomizing the kernels mmap algorithms. Rather
 112       than consistently choosing the same addresses given the same sequence of requests, the kernel
 113       will now choose randomized addresses. Because the Linux dynamic linker (ld-linux.so.2) loads
 114       DSOs into memory by using mmap, this means that DSOs are no longer loaded at predictable
 115       addresses, so making it harder to attack software by using buffer overflows. It also attempts
 116       to relocate certain binaries into a special low area of memory known as the ASCII armor so
 117       making it harder to jump into them when using string based attacks.
 118     </para>
 119
 120     <para>
 121       Prelink is a technology that enhances startup times by precalculating ELF global offset
 122       tables then saving the results inside the native binaries themselves. By grid fitting each
 123       DSO into the address space, the dynamic linker does not have to perform as many relocations
 124       so allowing applications that heavily rely on dynamic linkage to be loaded into memory much
 125       quicker. Complex C++ applications such as Mozilla, OpenOffice and KDE can especially benefit
 126       from this technique.
 127     </para>
 128
 129     <para>
 130       The 4G VM split patch was developed by Ingo Molnar. It gives the Linux kernel its own address
 131       space, thereby allowing processes to access the maximum addressable amount of memory on a
 132       32-bit machine: 4 gigabytes. It allows people with lots of RAM to fully utilise that in any
 133       given process at the cost of performance: as mentioned previously the reason behind giving
 134       the kernel a part of each processes address space was to avoid the overhead of switching on
 135       each syscall.
 136     </para>
 137
 138     <para>
 139       Each of these changes alter the address space in a way incompatible with Windows. Prelink and
 140       exec-shield mean that the libraries Wine uses can be placed at any point in the address
 141       space: typically this meant that a library was sitting in the region that the EXE you wanted
 142       to run had to be loaded (remember that unlike DLLs, EXE files cannot be moved around in
 143       memory). The 4G VM split means that programs could receive pointers to the top gigabyte of
 144       address space which some are not prepared for (they may store extra information in the high
 145       bits of a pointer, for instance). In particular, in combination with exec-shield this one is
 146       especially deadly as it's possible the process heap could be allocated beyond
 147       ADDRESS_SPACE_LIMIT which causes Wine initialization to fail.
 148     </para>
 149
 150     <para>
 151       The solution to these problems is for Wine to reserve particular parts of the address space
 152       so that areas that we don't want the system to use will be avoided. We later on
 153       (re/de)allocate those areas as needed. One problem is that some of these mappings are put in
 154       place automatically by the dynamic linker: for instance any libraries that Wine
 155       is linked to (like libc, libwine, libpthread etc) will be mapped into memory before Wine even
 156       gets control. In order to solve that, Wine overrides the default ELF initialization sequence
 157       at a low level and reserves the needed areas by using direct syscalls into the kernel (ie
 158       without linking against any other code to do it) before restarting the standard
 159       initialization and letting the dynamic linker continue. This is referred to as the
 160       preloader and is found in loader/preloader.c.
 161     </para>
 162
 163     <para>
 164       Once the usual ELF boot sequence has been completed, some native libraries may well have been
 165       mapped above the 3gig limit: however, this doesn't matter as 3G is a Windows limit, not a
 166       Linux limit. We still have to prevent the system from allocating anything else above there
 167       (like the heap or other DLLs) though so Wine performs a binary search over the upper gig of
 168       address space in order to iteratively fill in the holes with MAP_NORESERVE mappings so the
 169       address space is allocated but the memory to actually back it is not. This code can be found
 170       in libs/wine/mmap.c:reserve_area.
 171     </para>
 172
 173   </sect1>
 174
 175 </chapter>