INTERPROZESS KOMMUNIKATION

Präsentation zum Thema: "INTERPROZESS KOMMUNIKATION"—  Präsentation transkript:

1 INTERPROZESS KOMMUNIKATION
verfasst von Eyad Alkassar Seminar Ausgewählte Komponenten von Betriebssystemen INTERPROZESS KOMMUNIKATION Effizienz und Schwächen

2 INHALT 2. Effiziente Implementierung 3. Schwächen von IPC
1. IPC - Überblick 2. Effiziente Implementierung 3. Schwächen von IPC 4. Zusammenfassung

3 IPC - ÜBERBLICK Das Modell Adressräume als Mapping
Threads und Prozesse IPC als Kommunikationmechanismus

4 IPC - ÜBERBLICK PAGING Pager 2 Pager 1 Memory Manager Physical Memory
Prozesse können Virtual Memory anderen “zumappen” oder ganz überlassen Prozesse die anderen Adressräume mappen heißen Pager Pager dienen gleichzeitig als Page Fault Handler Pager 2 Pager 1 Memory Manager Physical Memory

5 IPC IMPLEMENTIERUNG Vorüberlegungen
Nach der Kernel Generation Behauptung: IPC ist prinzipiell zu langsam Geschwindigkeit wichtigstes Kriterium Dabei darf der Kernelansatz und die Sicherheit nicht verletzt werden Als Beispiel für eine schnelle Implementierung L3.3 bzw. L4 Verwenden INTEL 486 Architektur als Grundlage

6 IPC IMPLEMENTIERUNG Obere Grenze für Geschwindigkeit
Wo liegt tatsächlich die prinzipielle Geschwindigkeitsgrenze für IPC? Dafür betrachten wir den einfachsten Aufruf THREAD A (user mode) KERNEL THREAD B (user mode) lade id von B msg length:= 0 Access thread B Switch adress space Load id of A Inspect received message call Kernel 71 Zyklen return user 36 Zyklen 172 Zyklen -> 3.5 mikros

7 IPC IMPLEMENTIERUNG Kombinierte Systemaufrufe
Optimierung Eintreten und Verlassen des Kernels offensichtlich die teuersten Instruktionen Daher nach möglich vermeiden bei IPC-Aufruf Einführung kombinierter Primitive Call entspricht einem send und closed receive von Client Seite Reply & wait entspricht einem Antworten und open wait von Server Seite

8 IPC IMPLEMENTIERUNG Kombinierte Systemaufrufe
Optimierung Call entspricht einem send und closed receive von Client Seite Reply & wait entspricht einem Antworten und open wait von Server Seite Sende Anfrage THREAD A SERVER Antworte Call Reply and Wait Nur noch zwei Kernelaufrufe benötigt

9 IPC IMPLEMENTIERUNG Kopieren von großen Daten
naive Implementierung Prozess 1 und Prozess 2 mappen beide einen Kernelbereich Prozess 1 kopiert aus seinem Adressraum in gemeinsamen Bereich Prozess 2 kopiert aus gemeinsamen Bereich in seinen Adressraum Prozess1 AR Prozess2 AR Kernel Space

10 IPC IMPLEMENTIERUNG Kopieren von großen Daten
Optimierung Benötigt zwei Kopieroperationen: zu teuer Temporäres Mapping der Daten in den Kernel (Öffnet Fenster) Kernel kopiert dann die Daten nach B

11 IPC IMPLEMENTIERUNG Thread Control Blocks (TCB)
Thread Control Blöcke zum Speichern des Zustandes des Threads Kernel Stack Register Status Speicherung im Kernel Bei Aktivierung Wiederherstellung des Threads aus TCB

12 IPC IMPLEMENTIERUNG IPC - Timeouts
Jeder IPC – Aufruf kann einen Timeoutwert t spezifizieren d.h. wenn nach t ms noch keine Nachrichtenübermittlung, dann weckt Kernel Thread wieder auf und Übertragung ist gescheitert Meistens werden die Werte 0 und unendlich benutzt deren Implementierung einfach ist

13 IPC IMPLEMENTIERUNG IPC - Timeouts
naive Implementierung Andere Werte benötigen offensichtlich eine Wakeupqueue Meistens laufen die Timeouts nicht ab, daher Datenstruktur optimiert auf Einfügen und Löschen von Elementen naive Implementierung: großes Array von timeout values addressiert mit Thread ID bei jedem Zeitintervall muss komplettes Array durchsucht werden Das führt zu einer Belegung von Cache, etc. extrem schlechte Laufzeit

14 IPC IMPLEMENTIERUNG IPC - Timeouts Neue Datenstruktur
Optimierung Neue Datenstruktur n unsortierte Wakeuplisten (doppelt verkettete Listen) Definiere Aufweckwert x = aktuelle Zeit + Timeout Füge neuen Eintrag mit Aufweckwert x in Liste x mod n ein Scheduler überprüft zu Zeitpunkt T nur Liste T mod n Wenn x >> T wird der betreffende Thread in eine Winterschlafqueue gelegt

15 IPC IMPLEMENTIERUNG Beispiel n = 3 Optimierung 0 Queue 1 Queue 2 Queue
THREAD A T = 535 THREAD A T = 12 THREAD A T = 24 THREAD A T = 9 0 Queue THREAD A T = 31 THREAD A T = 535 THREAD A T = 13 1 Queue THREAD A T = 535 THREAD A T = 14 THREAD A T = 11 THREAD A T = 5 THREAD A T = 26 2 Queue

16 IPC IMPLEMENTIERUNG Beispiel n = 3 T = 9 Optimierung 0 Queue 1 Queue
THREAD A T = 535 T = 12 T = 24 T = 9 0 Queue THREAD A T = 31 THREAD A T = 535 THREAD A T = 13 1 Queue THREAD A T = 535 THREAD A T = 14 THREAD A T = 11 THREAD A T = 5 THREAD A T = 26 2 Queue

17 IPC IMPLEMENTIERUNG Analyse der Queues Gesamtzahl aller Threads sei k
Optimierung Gesamtzahl aller Threads sei k Erwartete Länge einer Liste k/n Worst case: Genausoschlecht wie erster Vorschlag Sonst überprüft Scheduler nur k/n viele Einträge pro Zyklus Einfügen und Löschen beliebiger Threads in konstanter Zeit

18 IPC IMPLEMENTIERUNG Verwaltung der Threads
Der Kernel führt Buch über den Status der Threads und muss den Status zu bestimmten Zeiten ändern einfachste Implementierung Verwendung von Queues 1. Busy-Queue 2. ready-Queue 3. polling-me Queue für jeden Thread

19 IPC IMPLEMENTIERUNG Scheduling von IPC-Befehlen
naive Implementierung Die IPC-Primitive call und reply & wait erfordern offensichtlich Arbeit durch den Scheduler: 1. Lösche den Sender-Thread von der Ready-Queue 2. Füge ihn ein in die Waiting-Queue 3. Löschen des empfangenden Threads von der Waiting Queue 4. Und Einfügen in die Readyqueue

20 IPC IMPLEMENTIERUNG Scheduling von IPC-Befehlen
naive Implementierung Die IPC-Primitive call und reply & wait erfordern offensichtlich Arbeit durch den Scheduler: Readyqueue Waitingqueue Sender Thread Empfänger Thread

21 IPC IMPLEMENTIERUNG Lazy Scheduling
Optimierung Ändere möglichst nur die Statuseintragung im TCB von wait nach ready Es gelten jeweils nur noch folgende beide Invarianten: 1. Mindestens alle Ready-Threads bis auf den aktuellen müssen in der Readyqueue sein 2. Mindestens alle wartenden Threads müssen in der Waitingqueue sein Nur noch alle Zeitabstände wird die Queue von falsche Einträgen gesäubert

22 IPC IMPLEMENTIERUNG Lazy Scheduling Vorteil:
Optimierung Vorteil: Keine Löschoperationen mehr bei IPC Einfügen bei call und receive&wait wird nicht durchgeführt Nur das IPC Primitiv send führt zu Einfügeoperation. Nachteil: Threads können in mehreren Queues auftreten Theoretisch: Interferenz mit der k/n Optimierung von Warteschlagen

23 IPC IMPLEMENTIERUNG Effizienz dieser Implementierung
Unter einem Intel 486 mit 50 MHZ Taktung erreicht Liedke einen Wert von 5 Mikrosekunden im Vergleich zu 100 bei Mach bei Short Message IPC-Aufrufen Ergebnisse beziehen sich auf eine bestimmte Rechnerarchitektur Entfernte Optimierung Prozentuale Verschlechterung bei N-byte IPCs Kurze Nachrichten über Register 49% - Lazy Scheduling 23% 16% 12% 7% 1% Reply & Wait 18% 13% 10% 5%

24 IPC SCHWÄCHEN Asymmetrisches Vertrauen …
Client kann vertrauen, dass Server Dienst nach Spezifikation ausführt Server vertraut keinem Client, muss aber allen korrekt arbeitenden Clients seine Dienste anbieten Server verfügt nur über beschränkte Ressourcen Sender Prozess Client Prozess1 Client Prozess2 … Böser Client

25 IPC SCHWÄCHEN Einfacher DOS-Angriff
CLIENT: Anfrage -> SERVER (open wait)

26 IPC SCHWÄCHEN Einfacher DOS-Angriff
CLIENT: Anfrage -> SERVER (open wait) SERVER: Antwort -> CLIENT (nicht in Wartezustand)

27 IPC SCHWÄCHEN Einfacher DOS-Angriff
CLIENT: Anfrage -> SERVER (open wait) SERVER: Antwort -> CLIENT (nicht in Wartezustand) SERVER blockiert, keine Annahme weiterer Anfragen Hauptschwäche ist der synchrone Austausch

28 IPC SCHWÄCHEN Lösungsvorschläge Buffering Multithreading
Abbruch des IPC Verwendung von Timeouts

29 IPC SCHWÄCHEN Buffering Einrichtung von Buffern im Kernel
Dadurch im Grunde asynchrone Übertragung Verlagerung eines lokalen Diensteproblem auf ein globales Platzproblem Damit ist zwar nicht mehr der Server angreifbar dafür aber der Kernel

30 IPC SCHWÄCHEN Multithreading
Anfrage von Prozessen wird durch je einen Thread des Servers behandelt Keine wirkliche Lösung: Angriff durch mehr bösartige Prozesse Dadurch sogar Angriff auf den Kernel möglich (siehe TCB) Multithreading von Servern führt zu einer erhöhten Komplexität und zu langsameren Ausführungen

31 IPC SCHWÄCHEN Weiteres Vorgehen Buffering
Keine Transformation von lokalem DOS zu globalen DOR Multithreading Komplexität auf Serverseite muss vermieden werden Nicht der Server trägt Kosten zur Erkennung bösartiger Aktionen, sondern Client

32 IPC SCHWÄCHEN Weiteres Vorgehen
1. Keine Transformation von lokalem DOS zu globalen DOR 2. Komplexität auf Serverseite muss vermieden werden 3. Nicht der Server trägt Kosten zur Erkennung bösartiger Aktionen, sondern Client

33 IPC SCHWÄCHEN Abbruch der Nachrichtenübertragung
Implementiert in Kernel EROS (J. S. Shapiro) IPC send von Server geschieht prompt, oder Abbruch Client muss also direkt in der Lage sein zu empfangen

34 DOS-Angriff durch Blockieren
ZUSAMMENFASSUNG L4 EROS DOS-Angriff durch Blockieren Prompt Receive EROS

35 IPC SCHWÄCHEN Verwendung von Timeouts
Server setzt IPC-send Timeout auf 0, oder einen kleinen Wert Die Verwendung von Timeouts hat Nachteile Die Simulation eines solchen Systems ist sehr schwierig Debugging wird wesentlich komplizierter

36 DOS-Angriff durch Blockieren
ZUSAMMENFASSUNG L4 EROS DOS-Angriff durch Blockieren Timeout Prompt Receive EROS Debugging & Testprobleme

37 IPC SCHWÄCHEN Pager Angriffe
Prompt/ Timeout läßt weitere Schwäche zu falls Pager von Client bösartig CLIENT: Adressen nicht in seinem AS -> SERVER

38 IPC SCHWÄCHEN Pager Angriffe
Prompt/ Timeout läßt weitere Schwäche zu falls Pager von Client bösartig CLIENT: Adressen nicht in seinem AS -> SERVER SERVER reagiert auf IPC -> in Warteschlange

39 IPC SCHWÄCHEN Pager Angriffe
Prompt/ Timeout läßt weitere Schwäche zu falls Pager von Client bösartig CLIENT: Adressen nicht in seinem AS -> SERVER SERVER reagiert auf IPC -> in Warteschlange KERNEL versucht Daten zu Kopieren -> Page Fault

40 IPC SCHWÄCHEN Pager Angriffe
Prompt/ Timeout läßt weitere Schwäche zu falls Pager von Client bösartig CLIENT: Adressen nicht in seinem AS -> SERVER SERVER reagiert auf IPC -> in Warteschlange KERNEL versucht Daten zu Kopieren -> Page Fault IPC an bösen PAGER, der nicht reagiert

41 IPC SCHWÄCHEN Pager Angriffe
Prompt/ Timeout läßt weitere Schwäche zu falls Pager von Client bösartig CLIENT: Adressen nicht in seinem AS -> SERVER SERVER reagiert auf IPC -> in Warteschlange KERNEL versucht Daten zu Kopieren -> Page Fault IPC an bösen PAGER, der nicht reagiert SERVER & CLIENT blockiert

42 DOS-Angriff durch Blockieren
ZUSAMMENFASSUNG L4 EROS DOS-Angriff durch Blockieren Timeout Prompt Receive EROS Page fault Attacken Debugging & Testprobleme Page fault Attacken aufrufen Page fault Attacken aufgerufen

43 IPC SCHWÄCHEN Lösung für Pager Angriff
In L4 können Pager Timeoutwerte zu Beginn der IPC festgelegt werden (erwartete Zeit um Pagefault zu handeln) Problem: Mehrere bösartige Clients können Server blockieren EROS Lösung: IPC zwingt Client zu einem Probelauf über Adressen bevor Receive oder Send Primitiv ausgeführt wird. Treten danach während des IPC Pagefaults auf wird dieser abgebrochen

44 DOS-Angriff durch Blockieren
ZUSAMMENFASSUNG L4 EROS DOS-Angriff durch Blockieren Timeout Prompt Receive EROS Page fault Attacken Debugging & Testprobleme Page fault Attacken aufrufen Page fault Attacken aufgerufen Pagerfault Timeout -Probelauf -IPC-Abbruch -Probelauf -IPC-Abbruch Angriff durch viele bösartige Clients

45 IPC SCHWÄCHEN Dynamisch große Nachrichten empfangen
EROS Ansatz birgt neues Problem Wenn Client Daten empfangen soll, aber nicht weiß wie groß diese sind, kann er keinen Probelauf durchführen Lösung in EROS: Einführung eines vertraunswürdigen Buffer TBO (trusted object buffer), der mit Server kommuniziert Client trägt Kosten für TBO

46 trusted buffer objects
ZUSAMMENFASSUNG L4 EROS DOS-Angriff durch Blockieren Timeout Prompt Receive EROS Page fault Attacken Debugging & Testprobleme Page fault Attacken aufrufen Page fault Attacken aufgerufen Pagerfault Timeout -Probelauf -IPC-Abbruch -Probelauf -IPC-Abbruch Angriff durch viele bösartige Clients Problem Nachrichten Dynamischer Größe Einführung von trusted buffer objects

47 ZUSAMMENFASSUNG Kurz: Mikrokernels können schnell & sicher geschrieben werden

48 Literatur VULNERABILITIES IN SYNCHRONOUS IPC DESIGNS Jonathan S. Shapiro, Department of Computer Science John Hopkins University, Oakland, California USA 2003 IMPROVING IPC BY KERNEL DESIGN Jochen Liedke German National Research Center for Computer Science (GMD) 1993

49 THE END DANKE!