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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 8 12 128 512 4096 Kurze Nachrichten über Register 49% - Lazy Scheduling 23% 16% 12% 7% 1% Reply & Wait 18% 13% 10% 5%

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

THE END DANKE!