6

In MSVC, the Base Address Randomizaiton is a default option.(Since VS2005?)

So, I do not rebase manually the dll's base address anymore.

But I rebased my all dlls to improve loading performance when I use VS2003.

If I use ASLR option, the loading performance is always decreased?
(Of cource I can get other benefits)

Benjamin
  • 10,085
  • 19
  • 80
  • 130
  • I must admit, im interested. ASLR would seem to reverse decades old performance tweaks from the OS. And I know Windows STILL takes too damn long to boot up. – Chris Becke Sep 01 '10 at 12:04

1 Answers1

10

The short answer is no.

On a system without ASLR (e.g. XP), loading a DLL at a non-preferred address has several costs:

  1. The relocations section has to be parsed and fixups have to be applied to the entire image.
  2. The act of applying fixups causes copy-on-write faults which are relatively expensive CPU-wise, and also force pages to be read from disk even if they are not referenced by the app itself.
  3. Every process that loads the DLL at a non-preferred address gets a private copy of every page that is written to, leading to increased memory usage.

Items 2 and 3 are by far the biggest costs, and are the main reason why manually rebasing DLLs used to be necessary.

With ASLR, fixups are applied transparently by the OS, making it look like the DLL was actually loaded at its preferred address. There are no copy-on-write faults, and no process-private pages are created. Also, fixups are applied only to the pages that are actually accessed by the app, rather than the entire image, which means no extra data is read from disk.

In addition to that, manual rebasing schemes can't prevent all base address conflicts (for example, DLLs from different vendors can conflict with each other, or an OS DLL could increase in size due to a hotfix and spill over into a range reserved for some other DLL, etc.). ASLR is a lot more efficient at dealing with these issues, so when looking at the system as a whole it can actually improve performance.

Pavel Lebedinsky
  • 446
  • 3
  • 3
  • I have wrote packer/unpacker before, and your points 1,2,3 is correct as you have to walk the relocation table and apply all the fixups manually into the assembly program. But I think when a process fork another, initially they shared the same pagetable, until COW mechanism force them to differ (in the case of ASLR) and thus duplicating pagetable is needed. And this also mean creating additional TLB entries (sometimes even TLB cache flushing) when doing the MMU page translation. Performance will suffer because of this? – Peter Teoh Oct 14 '11 at 00:53
  • 6
    @Pavel: Where did you come by this information? I am interested in reading up on the performance effects of ASLR on Windows. Other than your answer here, my searches have yielded very little. – mcmcc Jan 26 '12 at 20:30
  • 2
    I've never read that ASLR "fixups are applied trasnparently by the OS." Does anyone have a citation for that? – Adrian McCarthy Sep 03 '15 at 17:57