Virtueller Speicher und verschiebbarer Code

Question

In einem 32-Bit-System hat jeder Prozess virtuell 2^32 Byte CONTIGUOUS-Adressraum. Warum also muss der endgültige ausführbare Code, der von einem Linker generiert wird, verschoben werden? Was ist die Anforderung, da alle generierten Adressen virtuelle Adressen im eigenen Adressraum des Prozesses sind und andere Prozesse KEINEN gleichen verwenden können. Daher kann der Prozess überall platziert werden, wo er sein möchte. Warum umsetzbar?

Answer 1

Es muss verlagerbar sein, weil, um Ihren Prozess auszuführen muss in den eigentlichen Hauptspeicher in einer Warteschlange bereit gestellt werden. Nun, wo im Hauptspeicher es platziert werden soll, ist nicht festgelegt (es wird platziert, wo immer genügend Platz verfügbar ist), so dass die tatsächlichen Adressen der Befehle von seiner virtuellen Adresse abweichen.

Daher Aussagen Aufrufe von Funktionen machen, Retouren etc. müssen entsprechend der tatsächlichen Adresse dieser Funktionen

Answer 2

Einige Betriebssysteme machen den ausführbaren Code versetzbar (auf allen Betriebssystemen ist dies definitiv nicht universal) zeigt aktualisiert werden, um Erlauben Sie address space layout randomization. Dies hilft, bestimmte Angriffe zu mildern.

In der Vergangenheit, als Stacks ausführbar waren, konnte ein Pufferüberlauf ausgenutzt werden, indem ausführbarer Code direkt auf den übergelaufenen Stack oder Heap geschrieben wurde. Als die Betriebssysteme schlauer wurden und begannen, die Ausführung des Stacks und des Heaps zu verhindern, wurden die Angriffe ausgeklügelter und begannen, bekannte Codesequenzen im Speicher zu verwenden, indem return oriented programming getan wurde. Die Minderung dieser Angriffsklasse erfolgte zunächst durch Randomisierung des Speicherlayouts für Shared Libraries (da diese einfacher auszunutzen waren) und dann, wenn Angreifer zum Angreifen der Haupt-Executable wechselten, indem sie die Speicherposition der ausführbaren Datei randomisierten. Um es zu ermöglichen, muss die Haupt-ausführbare Datei verlagerbar sein.

Answer 3

Ausführbarer Code enthält nicht immer relative Adressen. Unter Windows beispielsweise ist die Adressierung oft absolut (z. B. für globale Daten).

Betrachten Sie zwei verschiedene dynamische Bibliotheken. Beide wurden für eine feste Basisadresse von 0x00100000 kompiliert. Ihr Programm versucht, beide zu laden. Wo ist der Lader, um die 2. DLL zu platzieren? Seine bevorzugte Basisadresse wird bereits von der anderen DLL verwendet.

In diesem Fall hilft verschiebbarer Code, die zweite DLL an einer anderen Adresse zu platzieren und ihre internen Zeiger an den neuen Ort zu patchen. Bei festen Basisadressen würde das Laden der zweiten DLL einfach fehlschlagen.