tags:

views:

98

answers:

4

Rebasing a DLL means to fix up the DLL such, that it's preferred load adress is the load address that the Loader is actually able to load the DLL at.

This can either be achieved by a tool such as Rebase.exe or by specifying default load addresses for all your (own) dlls so that they "fit" in your executable process.

The whole point of managing the DLL base addresses this way is to speed up application loads. (Or so I understand.)

The question is now: Is it worth the trouble?

I have the book Windows via C/C++ by Richter/Nazarre and they strongly recommend making sure that the load addresses all match up so that the Loader doesn't have to rebase the loaded DLLs.

They fail to argue however, if this speeds up application load times to any significant amount.

Also, with ASLR it seems dubious that this has any value at all, since the load addresses will be randomized anyway.

Are there any hard facts on the pro/cons of this?

+3  A: 

You have to consider that user DLLs (that are not already loaded into another processes) has to be read from HDD. Usually the memory mapping is used for that (and it uses lazy loading), so if they have to be relocated, they'll have to be actually read from HDD before the process can start.

For those loaded by other processes the copy-on-write mechanism is used. So, again, relocating them will mean additional operations.

What's about ASLR, it's intended for security purposes, not for performance.

ruslik
A: 

Yes, you should do it. ASLR only impacts "system" DLLs and therefore the ones you are writing should not be impacted by ASLR. Additionally, ASLR doesn't completely "randomize" the location of these system binaries, it simply shuffles them around in the basic spot in the vm map.

John
The question specifically asked for "hard facts" - do you have any? How can you be sure that something that was imporant 10 years ago is still important now, when RAM, harddrives/SSDs, CPUs have become orders of magnitudes faster?
nikie
+2  A: 

Patching the relocatable addresses isn't the big deal, that runs at memory speeds, microseconds. The bigger issue is that the pages that contains this code now need to be backed up by the paging file instead of the DLL file. In other words, when pages containing code are unmapped, they need to be written to the paging file instead of just getting discarded.

The cost of this isn't that easy to measure, especially on modern machines with lots of RAM. It only counts when the machine starts to get under load with lots of processes competing for memory. And the fragmentation of the paging file.

But clearly, rebasing is a very cheap optimization. And it is very easy to see in the Debug + Windows + Modules window, there's a bright icon on the rebased DLLs. The Address column gives you a good hint what base address would be a good choice. Leave ample space between them so you don't constantly have to tweak this as your program grows.

Hans Passant
This situation where this makes a big difference is running the application in a Terminal server environment. If fixups are applied, then the memory used by the modules cannot be effectively shared across sessions. If no fixups are applied than the memory used by a module can be shared. Not sharing modules can have a significant memory impact when many sessions are running the same applications (quite common in terminal server environments). I honestly don't know what ALSR does in a Terminal Server environment.
Michael Burr
Rebasing does not seem "cheap" anymore when you have 300 DLLs to manage. At most 30 or so of them will be loaded together, but they are all optional plugins that are potentially loaded into the app (and each customer uses a different combination). So I have to keep them off each other and that becomes a bit annoying :-)
Martin
A: 

They fail to argue however, if this speeds up application load times to any significant amount.

The load time change is minimal, because the v-table is what gets updated with the new addresses. However, if you have low memory - enough that stuff gets loaded in/out of the page file, then the system has to keep the dll in the page file (since the addresses are changed). If the dlls were rebased - and the rebased dlls don't collide with any other dlls - then instead of swapping them out to the page file (and back), the system just overwrites the memory and reloads the dll from the original on the hard drive.

The benefit is only relevant when systems are paging stuff in and out of main memory. The last time I made efforts to keep databases of applications and their base addresses was back in VB6 days, when the computers in our offices and data centers were lucky to have even 256MB of RAM.

Also, with ASLR it seems dubious that this has any value at all, since the load addresses will be randomized anyway.

At the moment ASLR only affects dlls and executables with the dynamic-relocation flag set. This includes Vista/Win7 system dlls and executables, and any developer made items where the developer intentionally set that flag during the build.

If you are going to set the dynamic-relocation flag, then don't bother rebasing the dlls. If all your clients have 4GB of RAM, then don't bother. If your boss is a cheapskate, then maybe.

Tangurena
I should add a quote (slightly paraphrased) from Win-via-C here: *... the relocation section contains a list of byte offsets ... identifying memory addresses used by machine code instructions ... if the module cannot be mapped at its preferred base address, the loader opens the relocation section and iterates through all entries .... goes to the page of storage ... and adds to the address the difference*
Martin