ASLRを使用する場合、ビルド中に dll をリベースしても意味がないと考えるのは正しいでしょうか。カーネルがロードするときに dll が再びリベースされるからです。
私たちのアプリケーションがターミナル サービス マシンで頻繁に使用されていることを懸念しています。そのため、ロード時にリベースが発生すると、DLL がロードされるプロセスごとにリベースされる可能性があります (セッションごとに 1 つのプロセスがあります)。そして、これにより、支払いを希望する以上のメモリ使用量とページングが発生します。心配する必要がありますか？
次のブログ投稿を見つけました。リベースは 1 回だけ行われ、システム全体で行われると書かれています: Matt Evans - メモリ節約のために ASLR を有効にしますか? . これに関する他の参考文献は見たことがありません。ASLR を使用し、ビルド中にリベースしない場合、ターミナル サービス ボックスでメモリの問題が発生しないことを確認したかっただけですか?
したがって、私の読書に基づいて、問題はないはずです。ASLR により、dll が半ランダムなメモリ アドレスにロードされ、プロセスごとにリベースを開始するだけではいけません。dll のメモリ使用量を確認したい場合は、MassiveRebase という無料のツールがあり、2 つの dll を動的にロードし、それらのメモリ使用量に関する情報を表示できます。は、aslr がメモリに与える可能性のある変更を表示するように設計されています。ツールとその詳細については、http ://www.tmurgent.com/appv/index.php/en/resources/tools/137-massive-rebase を参照してください。
お役に立てれば。
リベースは引き続き役に立ちます。オペレーティング システムが読み込まれると、固定のランダム値が DLL ベースに適用されます。
その結果、DLL がロードされる場所は、1 回の起動では一般的ですが、マシンと起動では異なります。
これは、すべてのコード データが同じ値で共有されるため、多くのプロセス内の特定の DLL をプロセス間で共有できることを意味します。
アドレス空間が使用されているために DLL が移動されると、フィックスアップを変更する必要があり、共有される DLL が少なくなり、システム負荷が増加します。
DLL が共有されていない場合、リソースには影響しません。
DLL を修正するコストは、それが正しい場所に読み込まれた場合に以前は安くなっていましたが、それが ASLR に当てはまるかどうかはわかりませんが、それでもリソースの読み込み時間を節約できる可能性があります。