ASLR 是否会导致 Dll 加载缓慢？答案

【问题标题】：Does ASLR cause a slow loading of Dlls?ASLR 是否会导致 Dll 加载缓慢？
【发布时间】：2010-09-01 11:40:25
【问题描述】：

在 MSVC 中，Base Address Randomizaiton 是默认选项。（从 VS2005 开始？）

所以，我不再手动重新设置 dll 的基地址了。

但是当我使用 VS2003 时，我重新设置了所有 dll 以提高加载性能。

如果我使用 ASLR 选项，加载性能总是会下降吗？
（当然我可以得到其他好处）

【问题讨论】：

【解决方案1】：

简短的回答是否定的。

在没有 ASLR 的系统（例如 XP）上，在非首选地址加载 DLL 会产生多种成本：

第 2 和第 3 项是迄今为止最大的成本，也是过去需要手动重新定位 DLL 的主要原因。

使用 ASLR，操作系统透明地应用修正，使 DLL 看起来像是实际加载到其首选地址。没有写时复制错误，也没有创建进程专用页面。此外，修正仅应用于应用实际访问的页面，而不是整个图像，这意味着不会从磁盘读取额外数据。

除此之外，手动变基方案不能防止所有基地址冲突（例如，来自不同供应商的 DLL 可能会相互冲突，或者操作系统 DLL 可能会因修补程序而增加大小并溢出到为其他一些 DLL 等保留的范围）。 ASLR 在处理这些问题方面效率更高，因此从整体来看，它实际上可以提高性能。

【讨论】：

我之前写过打包器/解包器，您的第 1,2,3 点是正确的，因为您必须遍历重定位表并将所有修复程序手动应用到汇编程序中。但是我认为当一个进程分叉另一个进程时，最初它们共享相同的页表，直到 COW 机制迫使它们不同（在 ASLR 的情况下），因此需要复制页表。这也意味着在进行 MMU 页面转换时创建额外的 TLB 条目（有时甚至是 TLB 缓存刷新）。性能会因此受到影响？
@Pavel：你是从哪里得到这些信息的？我有兴趣阅读 ASLR 在 Windows 上的性能影响。除了你在这里的回答，我的搜索结果很少。
我从未读过 ASLR“修复程序是由操作系统透明地应用的”。有人对此有引用吗？