Wozu Relocation?

[Namenloser]

Ich bereite mich gerade auf eine Betriebssysteme-Klausur vor, und da bin ich gerade am Punkt Relocation.

Also dabei werden ja wohl irgendwelche Adressen angepasst, wenn das Image (z.B. Exe, DLL) an eine bestimmte Stelle im Speicher geladen wird.

Ich frag mich nur: Wo braucht man das überhaupt? Ich habe mich ja mal ein bisschen mit der Generierung von Assembler-Code befasst, und alle JMPs, CALLs usw. beziehen sich in der Regel auf relative Offsets an und nicht auf absolute Adressen. Ich weiß, dass es auch zwar entsprechende Codes für absolute Adressen gibt, hab die aber noch nie in Verwendung gesehen. Ist Relocation nur für diese Instruktionen nötig, die sowieso in der Praxis praktisch nie verwendet werden? Bei relativen Sprüngen wüsste ich nicht, warum da etwas angepasst werden müsste.

Wozu/Wann verwendet man absolute Adressen überhaupt jemals? Der einzige Grund, den ich mir vorstellen könnte, wäre eine minimale Performancesteigerung, da man z.B., wenn man Code aus einer DLL anspringen will, nicht erst einen Pointer dereferenzieren muss, um das Sprungziel zu ermitteln*. Aber das könnte man auch zur Not im Programm selbst regeln mit selbstmodifizierendem Code, Betriebssystemunterstützung bräuchte man eigentlich nicht.

* Häufig macht man das ja so (in der Art):

Delphi-Quellcode:

type
  TMyAPICall = procedure (Foo: DWord); cdecl;
var
  MyAPICall: TMyAPICall = nil;
initialization
  MyAPICall := GetProcAdress(...);

Delphi-Quellcode:

MyAPICall(42); 
// =>
// MOV EAX, [MyAPICall]; <- dereferenzierung 
// CALL EAX; 
// (oder so ähnlich zumindest)

[dummzeuch]

Zitat von Namenloser:

Ich bereite mich gerade auf eine Betriebssysteme-Klausur vor, und da bin ich gerade am Punkt Relocation.

Also dabei werden ja wohl irgendwelche Adressen angepasst, wenn das Image (z.B. Exe, DLL) an eine bestimmte Stelle im Speicher geladen wird.

Ich frag mich nur: Wo braucht man das überhaupt? Ich habe mich ja mal ein bisschen mit der Generierung von Assembler-Code befasst, und alle JMPs, CALLs usw. beziehen sich in der Regel auf relative Offsets an und nicht auf absolute Adressen.

Das kann nicht sein, denn dazu muessten alle Prozessoren das auch koennen. Das ist aber definitiv nicht der Fall. Du hast Dir vermutlich nur halbwegs aktuelle Intel-kompatible Prozessoren angeschaut.

Zitat von Namenloser:

Ich weiß, dass es auch zwar entsprechende Codes für absolute Adressen gibt

Genau.

Zitat von Namenloser:

Wozu/Wann verwendet man absolute Adressen überhaupt jemals? Der einzige Grund, den ich mir vorstellen könnte, wäre eine minimale Performancesteigerung, da man z.B., wenn man Code aus einer DLL anspringen will, nicht erst einen Pointer dereferenzieren muss, um das Sprungziel zu ermitteln*. Aber das könnte man auch zur Not im Programm selbst regeln mit selbstmodifizierendem Code, Betriebssystemunterstützung bräuchte man eigentlich nicht.

Wie schon oben geschrieben: Nicht alle Prozessoren beherrschen relative Adressierung oder es ist ggf. ineffizienter als absolulte Adressierung. Selbst modifizierender Code wiederum ist ein Sicherheitsrisiko und wird deshalb von aktuellen Betriebssystemen teilweise blockiert.

[Namenloser]

Zitat von dummzeuch:

Das kann nicht sein, denn dazu muessten alle Prozessoren das auch koennen. Das ist aber definitiv nicht der Fall. Du hast Dir vermutlich nur halbwegs aktuelle Intel-kompatible Prozessoren angeschaut.

Ja, bei Prozessoren, die nur absolute Adressen unterstützen, leuchtet es mir ein. Also braucht man das wirklich nur da?

Und wenn Relocation ausgeführt wird, dann wird vom Betriebssystem jeder einzelne Sprung gepatcht, ist das richtig? Das heißt, das Betriebssystem müsste unter Umständen Assembler-Code disassemblieren können? Denn es ist ja nicht gesagt, dass auf jeder Prozessorarchitektur die Zieladresse einfach so „als Klartext“ an einer Byte-Grenze im Code steht.

[Uwe Raabe]

Zitat von Namenloser:

Und wenn Relocation ausgeführt wird, dann wird vom Betriebssystem jeder einzelne Sprung gepatcht, ist das richtig? Das heißt, das Betriebssystem müsste unter Umständen Assembler-Code disassemblieren können? Denn es ist ja nicht gesagt, dass auf jeder Prozessorarchitektur die Zieladresse einfach so „als Klartext“ an einer Byte-Grenze im Code steht.

Dafür schreibt der Compiler oder Linker eine Relocation Table mit den Adressen die gepatcht werden müssen.

[Namenloser]

Zitat von Uwe Raabe:

Zitat von Namenloser:

Und wenn Relocation ausgeführt wird, dann wird vom Betriebssystem jeder einzelne Sprung gepatcht, ist das richtig? Das heißt, das Betriebssystem müsste unter Umständen Assembler-Code disassemblieren können? Denn es ist ja nicht gesagt, dass auf jeder Prozessorarchitektur die Zieladresse einfach so „als Klartext“ an einer Byte-Grenze im Code steht.

Dafür schreibt der Compiler oder Linker eine Relocation Table mit den Adressen die gepatcht werden müssen.

Ja, aber es könnte ja sein, dass ein Pointer z.B. 20 Bits lang ist und die JMP-Instruction so aussieht:

Code:

jjjj aaaa aaaa aaaa aaaa aaaa

Wobei hier jedes Zeichen für 1 Bit stehen soll. Die ersten 4 Bit kodieren die JMP-Instruktion selbst, und die restlichen 20 Bit geben die Zieladresse an.

Dann kann man nicht einfach dem Betriebssystem eine Byte-Adresse zum Patchen geben, weil die zu patchende Adresse nicht an einer Byte-Grenze anfängt.

[BUG]

Zitat von Uwe Raabe:

Dafür schreibt der Compiler oder Linker eine Relocation Table mit den Adressen die gepatcht werden müssen.

Relocation ist das Konzept, wie es konkret umgesetzt wird, ist eine andere Sache. Es könnte auch einfach bedeuten, eine Sprungtabelle an einer wohl-bekannten Stelle im Code zu patchen.

Wenn Relocation vom Betriebssystem auf eine bestimmte Weise unterstützt wird, dann müssen sich die Programme daran halten. Wenn das Betriebssystem einen Sprungbefehl nicht unterstützt, darf der eben nicht verwendet werden.

[himitsu]

Zitat:

Ich frag mich nur: Wo braucht man das überhaupt?

Einer der Hauptgründe liegt z.B. dran, daß Viele einfach so doof sind und und blind die Vorgaben verwenden.

Drum liegen auch fast alle Delphi-DLLs an der selben Stelle, wenn man mal eigentliche Zieladresse aus den DLLs ausliest.
Nur gibt es da ein Problem, denn an einer Stelle kann nur eine DLL geladen werden, also müssen Nachfolgende verschoben werden.

Und dann gibt es auch noch den Sicherheitsaspekt, wo dann das System die DLLs absichtlich verschiebt.
Wenn eine DLL immer an der selben Stelle liegt, dann können Angreifer direkt auf statische Adressen zugreifen und z.B. Buffer-Overruns so auslegen, daß sie geziehlt bestimmte Strukturen angreifen.
Tja, und wenn man nun absichtlich die DLLs jedes Mal an einer anderen Stelle läd, dann kann man nicht mehr so einfach auf diese "festen" Adressen losgehen.

[Bernhard Geyer]

Zitat von Namenloser:

Ja, aber es könnte ja sein, dass ein Pointer z.B. 20 Bits lang ist ...

Kann er nicht! Für ein 32-Bit Anwendung sind die Pointer immer 32 Bit lang, unter 64 Bit immer 64 Bit. "Früher" gabs mal noch 16-Bit Adressen und sowas wie Pages um mehr als 64 kByte Adressraum zu haben.

[Bernhard Geyer]

Zitat von himitsu:

Zitat:

Ich frag mich nur: Wo braucht man das überhaupt?

Einer der Hauptgründe liegt z.B. dran, daß Viele einfach so doof sind und ...

Dem möchte ich widersprechen. Ich habe absichtlich alle unserer DLL's an die gleiche Base-Adresse gelegt damit Windows (auch ohne Adressverwürfler) diese immer nach eigener Logik optimal läd. Was nützt mir eine unterschiedliche Angabe pro DLL wenn ich nicht weiß wie viel Platz die aktuelle DLL-Inkarnation benötig und ich mit einer unterschiedlichen Base-Adresse mir meinen beschränkten 32-Bit Adressraum "zukleistere" so das ich nur noch sehr kleine nicht unterbrochene Adressräume habe.

Und die Zeit die Windows benötigt die zwangsweise nötige Realocation durchzuführen ist seit Jahren irrelevant.

[mkinzler]

Das gilt für heutige Intelprozessoren. Bei anderen Prozessoren kann es anders sein, bzw. war es.
So hatten 8-Bit-Prozessoren 16-Bit Adressregister ( den 256 Bytes wären etwas wenig Speicher). 68000er Prozessoren hatten auch bei 16-Bit Datenbus schon 32-Bit für Prozessoren ( von denen aber anfänglich nur 24 Bit ausgewertet wurden).