Windows Loader operation on DLLs

I'm reading this paragraph in John Levine's "Linkers and Loaders" book, describing the process of loading a dll in windows:

> For each imported DLL, there is an array of import addresses, typically in the program’s text segment, into which the program loader places the resolved addresses.

This surprises me in two ways:

1. Isn't the text segment read/execute only? (Perhaps the loader changes its permissions only after writing to it?)
2. doesn't this make the text segment non-shareable between processes? Linux goes to great lengths to keep the text segment the same for all instances of a library ("Position Independent Code"). Is that somehow not a goal for Windows?

The array of imported addresses is identified by one of 16 data directories in the optional header of PE file, namely as Import Address Table (IAT). It is usualy located in its own section .idata but some linkers may bundle IAT with IMPORT Table or with the .text section.

1. Yes, .text code segment is readable and executable only, but the access privileges are established only after the Windows loader has resolved all addresses of imported functions and stored them to IAT.
2. Every instance of Windows dynamic library (DLL) is loaded to memory just once. When multiple instances of the same PE program are run, all the required DLLs are mapped to identical virtual address, so the contents of their IAT is identical at run time. Nevertheless, most of DLL have distinc sections .text and .idata, thus the mapped addresses of imported functions can be randomized (ASLR).
   Microsoft doesn't seem to care of PIC much, each DLL can be loaded to arbitrary virtual address and relocated whenever needed, using their .reloc section.

> For each imported DLL, there is an array of import addresses, typically in the program’s text segment, into which the program loader places the resolved addresses.

It used to be popular to put imports in read/write .idata section, then that changed to read-only .idata, nowadays (for 64bit exes and dlls) the imports are usually parts of (read-only) .rdata. You could put the imports in .text too but I don't remember that being popular, perhaps before my time.

By the way you can make up some arbitrary section name and put the imports there, doesn't matter, the actual name of the section is not important.

> Perhaps the loader changes its permissions only after writing to it?

Yes, and it can easily do that, but it's actually worse: what about delay-loaded DLLs? Therefore if there are delay-loaded DLLs, whatever pages the imports are in, may be briefly changed to writable, modified, and then turned back to read-only, at various points during execution, whenever delay-loaded DLLs are loaded.

As a fun side fact, on x86 kernel code can write to read-only pages directly, unless it specifically enables CR0.WP. But the loader runs in user mode, so that doesn't end up mattering here.

> Doesn't this make the text segment non-shareable between processes?

If there are imports in .text, then that only affects the pages that actually have imports in them, not the whole section. Imports are not handled by changing the target addresses of various call instructions throughout the code, but by filling a central array of addresses that are then used by indirect-call instructions. So the code itself doesn't change, only a dense array somewhere. If that array is in .text, then that part of .text wouldn't be sharable, but the rest still would be.

But putting aside the case of imports in .text, what about relocations that affect the text section, do they make the text section non-sharable? 32-bit code may not commonly have imports in .text, it does commonly have relocations for .text, which seems worse: that does tend to affect most pages.

But even so, code pages end up being mostly sharable anyway. Some trickery is necessary: an attempt is made to load DLLs at consistent addresses across multiple processes, so that their code pages can be shared even though they are relocated. Since the pages were modified though, they cannot be simply memory-mapped.

x64 code is, thanks to RIP-relative addressing, for the most part naturally position-independent.

By the way it is allowed (though not recommended) to have a non-relocatable exe or dll. Being non-relocatable means they can only be loaded at their "preferred" (well, "required" in this case) base address, and are incompatible with ASLR. The exe is loaded into its address space first, so that just works. A non-relocatable dll either gets its preferred address or not, and if not, then it fails to load.