Bedeutet ASLR, dass das Rebasing von DLLs nicht erforderlich ist?

Question

Bin ich der Meinung, dass es keinen Sinn hat, unsere dlls während unseres Builds neu zu erstellen, wenn wir ASLR verwenden, da die dlls sowieso wieder rebasiert werden, wenn der Kernel sie lädt?

Ich bin besorgt, dass unsere Anwendung oft auf Terminaldienst-Maschinen verwendet wird. Wenn also zum Zeitpunkt des Ladens ein Rebasing durchgeführt wird, könnten die Dlls für jeden Prozess, für den sie geladen werden, rebasiert werden (es würde pro Sitzung einen Prozess geben). Und dies würde zu mehr Speicherverbrauch und Paging führen, als wir bezahlen möchten. Muss ich besorgt sein?

Ich habe den folgenden Blogpost gefunden, der besagt, dass das Rebasieren nur einmal passiert und es systemweit ist: Matt Evans - Enabling ASLR for memory savings?. Ich habe keine anderen Referenzen zu diesem Thema gesehen, also wollte ich nur sicher sein, dass ich, wenn ich ASLR benutze und nicht während des Builds rebase, keine Speicherprobleme in einer Terminaldienste-Box verursachen werde?

Answer 1

Also basierend auf meiner Lesung sollten Sie kein Problem haben. ASLR bewirkt, dass die DLLs in die Semi-Random-Memory-Adresse geladen werden und nicht nur für jeden Prozess eine Neubasierung starten sollten. Wenn Sie die Speicherbenutzung von DLLs überprüfen möchten, gibt es ein kostenloses Tool namens MassiveRebase, mit dem Sie dynamisch zwei DLLs laden und Informationen über ihre Speicherbelegung anzeigen können. Das war entworfen, um Änderungen zu sehen, die aslr im Gedächtnis haben kann. Das Werkzeug und mehr darüber finden Sie hier: http://www.tmurgent.com/appv/index.php/en/resources/tools/137-massive-rebase

Hoffe das hilft.

Answer 2

Rebasing ist immer noch hilfreich. Wenn das Betriebssystem geladen wird, wendet es einen festen zufälligen Wert auf die DLL-Basis an.

Das Ergebnis ist, dass der Ort, an den eine DLL geladen wird, typisch für einen einzelnen Boot ist, aber unterschiedlich zwischen Maschinen und Booten.

Dies bedeutet, dass eine bestimmte DLL in vielen Prozessen zwischen Prozessen geteilt werden kann, da alle Codedaten mit demselben Wert geteilt werden.

Wenn eine DLL verschoben wird, weil ihr Adressraum belegt ist, muss sie die Korrekturen ändern, und weniger DLL wird geteilt, wodurch die Systemlast erhöht wird.

Wenn Ihre DLL nicht freigegeben ist, wirkt sich dies nicht auf Ressourcen aus.

Die Kosten für das Reparieren einer DLL waren früher billiger, wenn sie an den richtigen Platz geladen wurden, nicht sicher, ob das für ASLR zutrifft, aber sie könnten trotzdem Ressourcenladezeit sparen.