interprozess kommunikation effizienz und schwächen

IPC SCHWÄCHEN UND OPTIMIERUNG

INTERPROZESS KOMMUNIKATIONEffizienz und Schwächen

verfasst von Eyad Alkassar

Seminar Ausgewählte Komponenten von Betriebssystemen


INHALT

1. IPC - Überblick

2. Effiziente Implementierung3. Schwächen von IPC4. Zusammenfassung


IPC - ÜBERBLICK

Das Modell

Adressräume als Mapping

Threads und Prozesse

IPC als Kommunikationmechanismus


PAGING

Prozesse können Virtual Memory anderen “zumappen” oder ganz überlassen

IPC - ÜBERBLICK

Prozesse die anderen Adressräume mappen heißen Pager

Pager dienen gleichzeitig als Page Fault Handler

Physical Memory

Memory Manager

Pager 1

Pager 2


IPC IMPLEMENTIERUNGVorüberlegungen

Nach der 1. Kernel Generation Behauptung:

IPC ist prinzipiell zu langsam

Als Beispiel für eine schnelle Implementierung L3.3 bzw. L4

Dabei darf der Kernelansatz und die Sicherheit nicht verletzt werden

Geschwindigkeit wichtigstes Kriterium

Verwenden INTEL 486 Architektur als Grundlage


Obere Grenze für Geschwindigkeit

IPC IMPLEMENTIERUNG

Wo liegt tatsächlich die prinzipielle Geschwindigkeitsgrenze für IPC?

Dafür betrachten wir den einfachsten Aufruf

lade id von Bmsg length:= 0

THREAD A(user mode)

KERNELTHREAD B

(user mode)

Access thread B

Switch adress spaceLoad id of A

Inspect received message

71 Zyklen

36 Zyklen

call Kernel

return user

172 Zyklen -> 3.5 mikros


Kombinierte Systemaufrufe

Eintreten und Verlassen des Kernels offensichtlich die teuersten Instruktionen

IPC IMPLEMENTIERUNG

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

Optimierung


Kombinierte Systemaufrufe

IPC IMPLEMENTIERUNG

Call entspricht einem send und closed receive von Client Seite

Reply & wait entspricht einem Antworten und open wait von Server Seite

THREAD A SERVER

Sende Anfrage

Call

Nur noch zwei Kernelaufrufe benötigt

Antworte

Reply and Wait

Optimierung


Kopieren von großen Daten

Prozess 1 und Prozess 2 mappen beide einen Kernelbereich

IPC IMPLEMENTIERUNGnaive Implementierung

Prozess 1 kopiert aus seinem Adressraum in gemeinsamen Bereich

Prozess 2 kopiert aus gemeinsamen Bereich in seinen Adressraum

Prozess1 AR

Prozess2 AR

Kernel Space


Kopieren von großen Daten

Benötigt zwei Kopieroperationen: zu teuer

IPC IMPLEMENTIERUNG

Temporäres Mapping der Daten in den Kernel (Öffnet Fenster)

Kernel kopiert dann die Daten nach B

Optimierung


Thread Control Blocks (TCB)

Thread Control Blöcke zum Speichern des Zustandes des Threads

IPC IMPLEMENTIERUNG

Kernel Stack Register Status

Bei Aktivierung Wiederherstellung des Threads aus TCB

Speicherung im Kernel


IPC - Timeouts

IPC IMPLEMENTIERUNG

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



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


IPC IMPLEMENTIERUNG

Neue Datenstruktur n unsortierte Wakeuplisten (doppelt verkettete Listen)

Füge neuen Eintrag mit Aufweckwert x in Liste x mod n ein

Scheduler überprüft zu Zeitpunkt T nur Liste T mod n

Definiere Aufweckwert x = aktuelle Zeit + Timeout

Wenn x >> T wird der betreffende Thread in eine Winterschlafqueue gelegt

IPC - Timeouts Optimierung


Beispiel n = 3

IPC IMPLEMENTIERUNG

THREAD AT = 535

THREAD AT = 12

THREAD AT = 24

THREAD AT = 9

THREAD AT = 535

THREAD AT = 31

THREAD AT = 13

THREAD AT = 535

THREAD AT = 14

THREAD AT = 11

THREAD AT = 5

THREAD AT = 26

Optimierung

2 Queue

1 Queue

0 Queue


Beispiel n = 3

IPC IMPLEMENTIERUNG

THREAD AT = 535

THREAD AT = 31

THREAD AT = 13

THREAD AT = 535

THREAD AT = 14

THREAD AT = 11

THREAD AT = 5

THREAD AT = 26

Optimierung

2 Queue

1 Queue

THREAD AT = 535

THREAD AT = 12

THREAD AT = 24

THREAD AT = 9

0 Queue

T = 9


Analyse der Queues

IPC IMPLEMENTIERUNGOptimierung

Gesamtzahl aller Threads sei k

Erwartete Länge einer Liste k/n

Sonst überprüft Scheduler nur k/n viele Einträge pro Zyklus

Einfügen und Löschen beliebiger Threads in konstanter Zeit

Worst case: Genausoschlecht wie erster Vorschlag


Verwaltung der Threads

Der Kernel führt Buch über den Status der Threads

IPC IMPLEMENTIERUNG

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


Scheduling von IPC-Befehlen

Die IPC-Primitive call und reply & wait erfordern offensichtlich Arbeit durch den Scheduler:

IPC IMPLEMENTIERUNG

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

naive Implementierung


Scheduling von IPC-Befehlen

Die IPC-Primitive call und reply & wait erfordern offensichtlich Arbeit durch den Scheduler:


Sender ThreadEmpfänger

Thread

Readyqueue Waitingqueue


Lazy Scheduling

Es gelten jeweils nur noch folgende beide Invarianten:

IPC IMPLEMENTIERUNG

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

Optimierung

Nur noch alle Zeitabstände wird die Queue von falsche Einträgen gesäubert

Ändere möglichst nur die Statuseintragung im TCB von wait nach ready


Lazy Scheduling

IPC IMPLEMENTIERUNG

Nachteil: Threads können in mehreren Queues auftreten Theoretisch: Interferenz mit der k/n Optimierung von Warteschlagen

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.

Optimierung


Effizienz dieser Implementierung

IPC IMPLEMENTIERUNG

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

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


Asymmetrisches Vertrauen

Client kann vertrauen, dass Server Dienst nach Spezifikation ausführt

IPC SCHWÄCHEN

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ÄCHENEinfacher DOS-Angriff

CLIENT: Anfrage -> SERVER (open wait)


IPC SCHWÄCHENEinfacher DOS-Angriff


SERVER: Antwort -> CLIENT (nicht in Wartezustand)


IPC SCHWÄCHEN


SERVER: Antwort -> CLIENT (nicht in Wartezustand)

SERVER blockiert, keine Annahme weiterer Anfragen

Einfacher DOS-Angriff

Hauptschwäche ist der synchrone Austausch


Lösungsvorschläge

Buffering

IPC SCHWÄCHEN

Multithreading

Abbruch des IPC

Verwendung von Timeouts


Buffering

Einrichtung von Buffern im Kernel

IPC SCHWÄCHEN

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


Multithreading

IPC SCHWÄCHEN

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


Weiteres Vorgehen

IPC SCHWÄCHEN

Buffering

Multithreading

Komplexität auf Serverseite muss vermieden werden

Keine Transformation von lokalem DOS zu globalen DOR

Nicht der Server trägt Kosten zur Erkennung bösartiger Aktionen, sondern Client


Weiteres Vorgehen

IPC SCHWÄCHEN

2. Komplexität auf Serverseite muss vermieden werden

1. Keine Transformation von lokalem DOS zu globalen DOR

3. Nicht der Server trägt Kosten zur Erkennung bösartiger Aktionen, sondern Client


Abbruch der Nachrichtenübertragung

Implementiert in Kernel EROS (J. S. Shapiro)

IPC SCHWÄCHEN

IPC send von Server geschieht prompt, oder Abbruch

Client muss also direkt in der Lage sein zu empfangen


ZUSAMMENFASSUNGDOS-Angriff durch Blockieren

Prompt Receive EROS

EROSL4


Verwendung von Timeouts

Die Verwendung von Timeouts hat Nachteile• Die Simulation eines solchen Systems ist sehr schwierig• Debugging wird wesentlich komplizierter

IPC SCHWÄCHEN

Server setzt IPC-send Timeout auf 0, oder einen kleinen Wert



Timeout Prompt Receive EROS

Debugging & Testprobleme

EROSL4


Pager Angriffe

IPC SCHWÄCHEN

Prompt/ Timeout läßt weitere Schwäche zu falls Pager von Client bösartig

CLIENT: Adressen nicht in seinem AS -> SERVER


Pager Angriffe

IPC SCHWÄCHEN



SERVER reagiert auf IPC -> in Warteschlange


Pager Angriffe

IPC SCHWÄCHEN




KERNEL versucht Daten zu Kopieren -> Page Fault


Pager Angriffe

IPC SCHWÄCHEN





IPC an bösen PAGER, der nicht reagiert


Pager Angriffe

IPC SCHWÄCHEN





IPC an bösen PAGER, der nicht reagiert

SERVER & CLIENT blockiert




Page fault Attackenaufrufen

Page fault Attackenaufgerufen


Page fault Attacken

EROSL4


Lösung für Pager Angriff

IPC SCHWÄCHEN

In L4 können Pager Timeoutwerte zu Beginn der IPC festgelegt werden (erwartete Zeit um Pagefault zu handeln)

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

Problem: Mehrere bösartige Clients können Server blockieren






-Probelauf-IPC-Abbruch



Page fault Attacken

Pagerfault Timeout

EROSL4

Angriff durch viele bösartige Clients


Dynamisch große Nachrichten empfangen

IPC SCHWÄCHEN

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








Problem NachrichtenDynamischer Größe


Page fault Attacken

Pagerfault Timeout

EROSL4

Einführung von trusted buffer objects

Angriff durch viele bösartige Clients


ZUSAMMENFASSUNG

Kurz: Mikrokernels können schnell & sicher geschrieben werden


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

interprozess kommunikation effizienz und schwächen

Documents