1 / 49

INTERPROZESS KOMMUNIKATION Effizienz und Schwächen

verfasst von Eyad Alkassar. Seminar Ausgewählte Komponenten von Betriebssystemen. INTERPROZESS KOMMUNIKATION Effizienz und Schwächen. INHALT. 1. IPC - Überblick. 2. Effiziente Implementierung. 3. Schwächen von IPC. 4. Zusammenfassung. IPC - ÜBERBLICK. Das Modell.

jersey
Télécharger la présentation

INTERPROZESS KOMMUNIKATION Effizienz und Schwächen

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. INHALT 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 • 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 1. 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 Optimierung Kombinierte Systemaufrufe • 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 & waitentspricht einem Antworten und open wait von Server Seite

  8. IPC IMPLEMENTIERUNG Optimierung Kombinierte Systemaufrufe Call entspricht einem send und closed receive von Client Seite Reply & waitentspricht 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 naive Implementierung Kopieren von großen Daten • 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 Optimierung Kopieren von großen Daten • 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 naive Implementierung IPC - Timeouts • 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 Optimierung IPC - Timeouts • 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 Optimierung Beispiel n = 3 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. THREAD A T = 12 THREAD A T = 535 THREAD A T = 24 THREAD A T = 9 0 Queue IPC IMPLEMENTIERUNG Optimierung Beispiel n = 3 T = 9 THREAD A T = 535 THREAD A T = 31 THREAD A T = 13 1 Queue THREAD A T = 14 THREAD A T = 535 THREAD A T = 11 THREAD A T = 5 THREAD A T = 26 2 Queue

  17. IPC IMPLEMENTIERUNG Optimierung Analyse der Queues • 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: Waitingqueue Readyqueue 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 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

  24. ClientProzess1 Client Prozess2 Sender Prozess … Böser Client 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

  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. 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. 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. 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. 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. 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!

More Related