15

Am I right in thinking there is no point in rebasing our dlls during our build if we use ASLR as the dlls will be rebased again anyway when the kernel comes to load them?

I am concerned that our application is often used on Terminal Services machines. So, if rebasing occurs at load time, we could end up with dlls being rebased for each process they are loaded into (there would be one process per session). And this would result in more memory usage and paging than we want to pay for. Do I need to be concerned?

I've found the following blog post that says the rebasing only happens once and it is system wide: Matt Evans - Enabling ASLR for memory savings?. I haven't seen any other references about this, so just wanted to be sure if I use ASLR and don't rebase during our build I won't cause memory problems on a Terminal Services box?

Scott Langham
  • 58,735
  • 39
  • 131
  • 204
  • Another reference to back up the "once and system wide" bit: Windows Internals, Sixth Edition, Part 2, p.249 says that directly. – Chris O Jan 14 '16 at 17:12
  • And you've tried attaching debuggers to multiple processes (in different sessions) on the Terminal Services box? That should show what the address of your DLL is. – Chris O Jan 14 '16 at 17:20
  • https://blogs.msdn.microsoft.com/oldnewthing/20170118-00/ – Sachin Joseph Jan 18 '17 at 21:40

2 Answers2

1

So based on my reading you should not have a problem. ASLR causes the the dll's to be loaded to semi random memory address and should not just start rebasing for every process. If you want to check memory use of dll's there is a free tool called MassiveRebase that lets you dynamically load two dll's and view info about their memory use. The was designed to view changes that aslr may have on memory. The tool and more about it can be found here: http://www.tmurgent.com/appv/index.php/en/resources/tools/137-massive-rebase

Hope this helps.

Jacobr365
  • 846
  • 11
  • 24
-3

Rebasing is still helpful. When the operating system loads, it applies a fixed random value to the DLL base.

The result is that the location a DLL is loaded to, is typical for a single boot, but different between machines and boots.

This means that a given DLL in lots of processes can be shared between processes, as all its code data is shared with the same value.

When a DLL is moved because it's address space is taken, it has to modify the fixups, and less of the DLL is shared, increasing system load.

If your DLL is not shared, then it does not affect resources.

The cost of fixing up a DLL used to be cheaper if it was loaded to the correct place, not sure if that is true for ASLR, but may still save resource loading time.

mksteve
  • 12,614
  • 3
  • 28
  • 50
  • When you say 'rebasing is still helpful', do you mean it's useful to manually rebase my dlls before shipping them? If so, why? Or, do you mean it's still useful, but I don't need to do it myself because ASLR always does the rebasing at runtime regardless of any manual rebasing I do or don't do before shipping? – Scott Langham Jan 19 '16 at 09:27
  • The aslr doesn't move DLL random;y. Without aslr, if you get collisions, then you will get them with aslr. These I believe will slow loading and increase system memory usage (less shared memory) – mksteve Jan 19 '16 at 10:21