2016-06-15 21 views
1

Wenn ich richtig verstehe, wenn der Benutzer versucht, dynamisch verknüpfte ausführbare (mit execve("foo", "", "")) anstelle des Ladens von Text Segment von "foo" Dynamic Linker wird geladen (ld-linux.so.2) und ausgeführt. Es muss Bibliotheken laden, die für Programm ("foo") benötigt werden, um einige Adressen in "foo" zu laufen und zu ändern und Kontrolle an foo zu übergeben, aber wie wird das geleistet?Wie ändert Dynamic Linker Textsegment des Prozesses?

Wie (welches System nennen es nutzt) und wo tut dynamische loader laden Bibliotheken und „foo“ s-Code und Daten im Speicher (ich bin zu raten, einfach nicht malloc oder mmap verwenden und dann auf Code springen seit das sollte unmöglich sein, richtig? Es scheint auch unwahrscheinlich, dass es erstellt temporäre Datei mit vollständigen ausführbare (wie statisch verbunden) und Aufrufe wieder exceeve.).

+0

"da sollte das unmöglich sein, oder?" Falsch. –

+1

Seltsam, das Unmögliche funktioniert sehr gut auf meinem Desktop und anderen Computern, einschließlich Mobile. Vielleicht möchten Sie selbst etwas über die dynamische Verknüpfung und die Initialisierung von Programmen auf Linux (und anderen modernen Betriebssystemen) herausfinden. – Olaf

Antwort

0

Die eigentliche Implementierung ist ziemlich komplex, da sie auf ELF aufbaut, was ziemlich komplex ist, da es versucht, viele Szenarien zu berücksichtigen, aber konzeptionell ist es ziemlich einfach.

Grundsätzlich (nachdem die Bibliothek Abhängigkeiten befinden und open ed) es ist ein paar Mmap s, mprotect s, einige Modifikationen, um die Verknüpfung durch Bindung Symbole zu implementieren (kann aufgeschoben werden) und dann auf Code springen .

Im Idealfall wird der verknüpften Shared Libraries mit -fpic/-fPIC zusammengestellt werden, die der Linker sich im Adressraum Prozesse überall erlauben zu platzieren, ohne auf den .text Abschnitt (= ausführbarer Code) der Bibliothek zu schreiben. Eine solche Bibliothek/eine ausführbare Datei ruft Funktionen aus anderen Bibliotheken über eine veränderbare Tabelle auf, die der Linker (wahrscheinlich träge) repariert, um auf die tatsächlichen Speicherorte zu verweisen, an denen er die abhängige Bibliothek geladen hat. Der Zugriff auf Variablen von einer gemeinsam genutzten Bibliothek zu einer anderen ist ähnlich. Die Begrenzung der modifizierenden Bibliotheksdaten/-codes so weit wie möglich ermöglicht es, Codeabschnitte als schreibgeschützt (über den MMU/mprotect-Systemaufruf) zu markieren und in einen Speicher abzubilden, der von allen Prozessen, die diese bestimmte Bibliothek verwenden, gemeinsam genutzt wird.


Um eine Vorstellung davon zu bekommen, was auf der syscall Ebene geschieht, können Sie versuchen, zB:

strace /bin/echo hello world 

und alle syscalls bis zu etwa sbrk enthalten (= Einstellung der Heap/.data Segment nach oben) sollte das Tun des dynamischen Linkers sein.


(malloc ist in der Tat nicht verfügbar an den Linker als malloc ein Merkmal der C-Bibliothek ist, nicht das System. malloc ist über das Erwachsenwerden und die Verwaltung den Abschnitts Heap und möglicherweise mmap ping andere separate Blöcke und die auch die Verwaltung als der beschreibbare "Heap", und der dynamische Linker ist nicht an diesen Abschnitten eines Prozessabbildes interessiert, hauptsächlich nur an seinen beschreibbaren Indirektionstabellen und wo er Bibliotheken abbildet).