Software ubiquitärer Systeme - ess.cs.tu-dortmund.de · (Betriebs-)System mit großem ... - Instrumentiert alle potentiellen dynamischen Verbindungspunkte in diesem Modul, so dass

11

Software ubiquitärer SystemeBetriebssysteme und Kontext

Olaf SpinczykArbeitsgruppe Eingebettete Systemsoftware

Lehrstuhl für Informatik 12TU Dortmund [email protected]://ess.cs.uni-dortmund.de/~os/

http://ess.cs.tu-dortmund.de/DE/Teaching/SS2015/SuS/

mailto:[email protected]

03.7 – Betriebssysteme und Kontext 22

Motivation● Einschränkungen ubiquitärer Systeme: CPU, RAM,

Energie, Konnektivität mit (Funk-)Netzen, ...

● Bei kleinsten Geräten kann man den Einschränkungen mit extremer Spezialisierung begegnen.● feingranulare Maßschneiderung der Software zur Übersetzungszeit

● Auswahl der günstigsten/kleinstmöglich dimensionierten/etc. Hardware

● Beispiele: Smart Dust, RFID, ...

● Bei größeren Geräten mit mehreren Funktionalitäten reicht die statische Konfigurierung möglicherweise nicht aus!● Betrachten wir folgendes Szenario ...


Der Alltagsbegleiter● Beispiel: „Alltagsbegleiter“ PDA/Smartphone

● temporär unterschiedliche Dateisysteme (Speicherkarten)● MP3s für unterwegs● sicherheitsrelevante Daten

Hardware

BS-Kern

Anwendungen

DisplayKeypadWLAN


Der Alltagsbegleiter● Beispiel: „Alltagsbegleiter“ PDA/Smartphone● Kontext 1: eingesteckte Speicherkarte, FAT32-

Dateisystem● dynamisches Nachladen des FAT32- und des SD-Karten-

Treibers● Einschalten des SD-Kartenlese-Geräts

Hardware

FAT32

BS-Kern

Anwendungen

SDDisplayKeypadWLAN



Dateisystem● Kontext 2: Benutzer hört unterwegs MP3s

● Soundtreiber wird nachgeladen, Device eingeschaltet● WLAN-/FAT32-/SD-Treiber werden nicht mehr benötigt

Hardware

Sound

BS-Kern

Anwendungen

DisplayKeypad



Dateisystem● Kontext 2: Benutzer hört unterwegs MP3s● Kontext 3: Wechsel in ein „unsicheres“ WLAN

● Kernel wird temporär um Sicherheits-Checks erweitert● langsamer, ressourcenintensiver, aber nur in „unsicheren“

Umgebungen!

Hardware

BS-Kern

Anwendungen

DisplayKeypadWLAN



Dateisystem● Kontext 2: Benutzer hört unterwegs MP3s● Kontext 3: Wechsel in ein „unsicheres“ WLAN

● Kernel wird temporär um Sicherheits-Checks erweitert● langsamer, ressourcenintensiver, aber nur in „unsicheren“

Umgebungen!

Hardware

BS-Kern

Anwendungen

DisplayKeypadWLAN

● Je nach Kontext ein dynamisch angepasstes (Betriebs-)System● mit großem Einsparpotential (Strom, RAM, CPU)!● aber: Mit welchen Techniken ist das realisierbar?● Was kostet das (im Hintergrundspeicher, zur Lade-/Laufzeit)?


Inhalt● Kontextabhängigkeit

● ... auf Betriebssystem-Ebene?

● Varianten der Adaptierbarkeit● Adaptierbare vs. adaptive Systeme● „Große“ vs. eingebettete und Echtzeit-BS

● Dynamische Anpassung● Techniken

- dynamisches Binden

- dynamisches Aspektweben

● Betriebssysteme- SPIN

- TOSKANA

- Synthesis

● Zusammenfassung









- TOSKANA

- Synthesis

● Zusammenfassung


Kontextabhängigkeit(context awareness)

● Ziel● Computer sollen genug Wissen über die aktuelle Situation des

Nutzers ansammeln können, um zu jeder Zeit nützliche Dienste und Informationen bereitzustellen sowie Ressourcen zu sparen.

● Kontext-gewahres Verhalten erfordert ...● Erfassung

- mittels Sensoren, Kommunikation oder Nutzerinteraktion● Repräsentation der Welt im ubiquitären Rechnersystem, z.B.

- Position, z.B. GPS oder Raumnummer

- Rolle des aktuellen Benutzers

- In der Nähe befindliche Geräte

- Sensordaten, z.B. Temperatur, Windgeschwindigkeit, …

● Reaktion auf Veränderungen


... auf Betriebssystem-Ebene?● Beispiel: Handy mit

Navigations-Anwendung

● Positionsbestimmung perGPS● stromhungrig!

● Repräsentation:● GPS-Koordinaten, klassifiziert nach

„innerhalb“ / „außerhalb von Großstadt“

● Kontext wechselt zu „Großstadt“● WLAN-Modul ein-, GPS-Modul

ausschalten● Koordinatenbestimmung anhand WLAN-

Datenbank

Kontext

erfassen

reagieren

repräsentieren


... auf Betriebssystem-Ebene?● Beispiel: PDA mit sicher-

heitsrelevanten Daten

● Kontext: SSID d. WLAN,in das eingebucht ist

● Repräsentation:● SSID, klassifiziert nach „sicheres“ und

„unsicheres“ Netz

● Kontext wechselt zu „unsicher“● Kernel wird um Sicherheits-Checks

erweitert

● langsamer, ressourcenintensiver, aber nur in „unsicheren“ Umgebungen!

Kontext

erfassen

reagieren

repräsentieren









- TOSKANA

- Synthesis

● Zusammenfassung


Varianten der Adaptierbarkeit von BS

adaptierbaresBetriebssystem

Bindung Einheiten

statischkonfigurierbar

dynamischrekonfigurierbar

manuell automatisch

Module Policies untrusted

● adaptierbare Systeme können durch externe Eingriffe (statisch oder dynamisch) an veränderte Bedingungen angepasst werden

● adaptive Systeme können sich selbständig an veränderte Bedingungen anpassen → Selbstorganisation, Reflektion/Introspektion


Ausgangspunkt für Forschung (1)


Bindung Einheiten





manuellmanuell automatischautomatisch

ModuleModule Policies untrusted

● Großrechner-, Workstation- und PC-Betriebssysteme:● dynamisches Laden und Entladen von Modulen wie Treibern oder

Dateisystemen, teils automatisch, teils auch statisch konfiguriert

● ... ist der „Stand der Kunst“:


Ausgangspunkt für Forschung (2)


Bindung Einheiten




manuell automatisch


● ... ist der „Stand der Kunst“:

● Eingebettete- und Echtzeit-Betriebssysteme:● statische Konfigurierung auf Modulebene und gut modularisierte

Strategien (z.B. Scheduling), i.d.R. keine Dynamik


Im Zentrum der BS-Forschung [1]


Bindung Einheiten




● Ausführung von nicht vertrauenswürdigem Code● Adaptierbarkeit von Policies (Systemstrategien)

● vor allem dynamisch und im Hinblick auf Performance

● ... ist, was neu und herausfordernd ist:



manuellmanuell automatischautomatisch









- TOSKANA

- Synthesis

● Zusammenfassung


Adaptierbare/adaptive Systeme● teils nur adaptierbar, teils adaptiv● auf Anwendungsebene

● Infrastruktur zum dynamischen Laden und Linken notwendig!

● aber auch auf Betriebssystem-Ebene● verschiedene Granularitäten (Module, Policies)● und Problemstellungen

(untrusted code, Effizienz zurLaufzeit, Hochverfügbarkeit,...)

adaptierbaresSystem

Bindung Einheiten



manuell automatisch

Module Policies untrusted









- TOSKANA

- Synthesis

● Zusammenfassung


Techniken: dynamisches Binden● genauer: dynamisches Laden und Binden

● dynamisch gelinkte Bibliotheken lassen sich leichter aktualisieren

● Funktionalität kann zur Laufzeit nachgeladen und auch wieder entladen werden

● UNIX-Standard-Format für dynamische Bibliotheken: ELF● Executable and Linking Format

● können an beliebige Stellen geladen werden, enthalten daher PIC (Position Independent Code) → Textsegment muss nicht reloziert werden

● GOT (Global Offset Table) für Offsets der globalen Variablen

● PLT (Procedure Linkage Table) für Offsets der Funktionen


ELF mit GOT und PLTProgramm Bibliothek

Data

Text

PLT

GOT

libx_foo()

Data

Text

PLT

GOT

errno

lazy binding

● Indirektionen, Lade- und Laufzeitoverhead


Techniken: dynamisches Binden● expliziter Aufruf des dynamischen ELF-Linkers

● z.B. zum Nachladen von Plugins zur Laufzeit● dlopen() zum Laden● dlsym() zum Auflösen eines Symbols● Dasselbe passiert implizit, wenn eine Bibliothek beim Programmstart

geladen wird!


Techniken: dynamisches Binden● Nachteile

● Infrastruktur: Loader/Linker notwendig● Laufzeit-Overhead: großer Teil des Bindeprozesses muss wiederholt

werden- Relokation

- Symbolauflösung

- statische Initialisierungen

- indirekte Daten-Referenzen im PIC

- langsamerer Code durch bereits vom PIC belegte Adressierungsregister

● dynamische Bibliotheken sind deutlich größer als statische (Symboltabellen!)

● organisatorisch: Versionsinkompatibilitäten (Semantik der Aufrufe!)


Techniken: dynam. Aspektweben (1)● Ziel: Aspekte zur Laufzeit laden und entladen

Quelle: [6]

a) Klassisches adaptives System:Nachladen von ModulenDas eigentliche System (base) muss einen Einsprungpunkt im nachgeladenen Modul (m_1) kennen. Unvorhergesehene Anpassungen sind daher schlecht möglich.

a) Klassisches adaptives System:Nachladen von ModulenDas eigentliche System (base) muss einen Einsprungpunkt im nachgeladenen Modul (m_1) kennen. Unvorhergesehene Anpassungen sind daher schlecht möglich.

b) Aspektorientiertes adaptives System:Nachladen von (Aspekt-)ModulenDas nachgeladene Modul kann sich durch den Advice-Mechanismus an bel. Stelle im Basismodul „einklinken“. Das ermöglicht sehr flexible Erweiterungen.

b) Aspektorientiertes adaptives System:Nachladen von (Aspekt-)ModulenDas nachgeladene Modul kann sich durch den Advice-Mechanismus an bel. Stelle im Basismodul „einklinken“. Das ermöglicht sehr flexible Erweiterungen.


Techniken: dynam. Aspektweben (2) Fragen …● zur Semantik

● Lassen sich alle AOP-Sprachmechanismenauch für dynamische Aspekte nutzen?- Einfügungen von Typen, …

● Worauf sollen die dynamischen Aspekte wirken?- Nur auf den Code des eigentlichen Systems?

- Auch auf andere (Aspekt-)Module, die bereits geladen sind?

- Auch auf (Aspekt-)Module, die erst später geladen werden?

● zur Umsetzung● Wie manipuliert man bereits geladenen Code zur Laufzeit?

- Funktionsaufrufe umlenken, Funktionen ersetzen, Einfügungen in Klassen

● Wie groß ist der Ressourcenverbrauch für die nötige Infrastruktur?● Geht dynamisches Weben auch mit nicht-interpretierten Sprachen?● Wie kann man den Ressourcenverbrauch minimieren?


Beispiel: Dynamic AspectC++ [6] (1)● Dynamisches Aspektweben mit Einschränkungen

● Module bilden eine „Knowledge Chain“

● Dafür ist aber „Generic Advice“ möglich – essentiell für AOP mit C++

'knows' bedeutet, dass Informationen über die bereits geladenen Module bei der Übersetzung später geladener Module berücksichtigt werden können.

'knows' bedeutet, dass Informationen über die bereits geladenen Module bei der Übersetzung später geladener Module berücksichtigt werden können.

Effizient: der Aspekt 'Logging' kann im Modul m_2 wie ein normaler statischer Aspekt gewoben werden.

Effizient: der Aspekt 'Logging' kann im Modul m_2 wie ein normaler statischer Aspekt gewoben werden.

Raffiniert: Bei der Generierung von Advice-Code können die statischen Typinformationen des Zielmoduls genutzt werden.

Raffiniert: Bei der Generierung von Advice-Code können die statischen Typinformationen des Zielmoduls genutzt werden.

aspect TraceResults { advice execution("% %(...)" && !"void %(...)") : after() { cout << tjp->signature() << "returns: " << *tjp->result() << endl;} };

aspect TraceResults { advice execution("% %(...)" && !"void %(...)") : after() { cout << tjp->signature() << "returns: " << *tjp->result() << endl;} };


Beispiel: Dynamic AspectC++ (2)● Implementierung

● static weaver

- Instrumentiert alle potentiellen dynamischen Verbindungspunkte in diesem Modul, so dass später dynamisch Advice-Code angebunden werden kann.

- Webt alle Aspekte der Ebenen 0 bis i statisch.

- Generiert Informationen über alle bekannten potentiellen Join Points

- Markiert Zugriffe auf dynamisch eingefügte Attribute im Quelltext

● dynamic advice generator

- Generiert den Advice-Codefür die dyn. Join Points derEbenen 0 bis i-1

● marker post processor

- Transformiert Zugriffe aufdynamisch eingefügteAttribute


Beispiel: Dynamic AspectC++ (3)● Kosten

● Zum Test wurde der Web Proxy 'Squid' für dynamische Aspekte instrumentiert(alle potentiellen execution Join Points, keine call Join Points)

● Performance- Overhead nur bei lokalen Anfragen feststellbar

● Codegröße (durch 3099 instrumentierte Join Points)

- wächst um ca. 8%

- Größe der Aspektmodule hängt von Zahl der Join Points ab









- TOSKANA

- Synthesis

● Zusammenfassung


Betriebssysteme: dynam. Binden● State of the Art: Linux-Kernelmodule

● ähnlich dynamischen Bibliotheken (Anwendungs-Ebene)

Einordnung: dynamisch, Module


BS: Erweiterbare Kerne● Problem: nicht vertrauenswürdige Module können einen

Systemkern zum Absturz bringen oder lahm legen● unkontrollierte Speicherzugriffe● exzessiver Ressourcenverbrauch (RAM, CPU, Locks, ...)

● Lösungsansatz: Schutz● durch Isolation

- „Sandboxing“

- „Mikrokerne“● durch sichere Sprachen

- Modula 3, wie z.B. in SPIN

- Java, wie z.B. in JX

● Lösungsansatz: Überprüfung● der Quelle (z.B. Systemadministrator, BS-Hersteller)● des Verhaltens („Proof-Carrying Code“ [9])


BS: Mikrokerne (1)● Idee: Verkleinerung der „Trusted Computing Base“ und

Schutz durch Isolation

Hardware

Prozessverwaltung

Virtueller Speicher

E/A und Geräteverwaltung

Interprozesskomm.

Dateisystem

BenutzerBenutzer-modus

PrivilegierterModus

Hardware

MikrokernMikrokern

Virt

uelle

r S

peic

h er

Pro

zess

serv

er

Dat

eise

r ver

Ger

ätet

r eib

er

Ben

utze

r

Benutzer-modus

PrivilegierterModus

...

● Die Aufgabe des Mikrokerns beschränkt sich im Wesentlichen auf die Realisierung des Nachrichtenaustauschs.● Das Konzept sorgt für vergleichsweise einfache (dynamische)

Rekonfigurierbarkeit.


BS: Mikrokerne (2)● Beispiel: der externe Pager von Mach

● Nutzen: anwendungsspezifische Paging-Strategien können die Performance erheblich steigern

● Problem: viele Kontextwechsel wirken negativ auf die Performance

MikrokernMikrokern

Anwendung Pager

Seiten-fehler

Wieder-aufnahme

Aufrufe zurAdressraum-verwaltung


BS: Forschungs-Exoten● SPIN [4] (1996)

● Anwendungen können BS-Kern dynamisch erweitern- Anwendungen laufen vollständig im Userspace,

- teils im Userspace und in Kernel-Erweiterungen, oder

- vollständig im Kernel-Space→ höhere Performance durch weniger Kontextwechsel

● Sicherheit durch eingeschränkte dynamische Bindung- sichergestellt durch Typsicherheit der Sprache MODULA-3

(die bezahlt man natürlich auch zur Laufzeit)

- Namensräume innerhalb des Kerns umschließen eine Menge von Interfaces

● Mikrokernel- emittiert System-Events, auf die Erweiterungen reagieren können

- bietet selbst nur grundlegende Dienste an (Thread-, Speicherverwaltung...)→ selbst Dinge wie Dateisysteme, User-Level-Threads, Netzwerk-Dienste werden in sog. SPINDLES (SPIN Dynamic Loaded ExtensionS) implementiert Einordnung: dynamisch, untrusted code


SPIN – Event-Dispatching

Event

Dispatcher

Guards

Handlers

MachineTrap.Syscall(thread, savedState)

isMachThread? isUNIXThread? otherwise

MachHandler UNIXHandler SPINHandler


SPIN – Event-Dispatching

SPIN Core Services

Shared Extensions

Application Extensions

Thread Mgmt Dev Mgmt VMM Extension Services

Syscall Process Network File System

HTTP Net Video UNIX API Mach API

Kernel

User

UNIX ApplicationUNIX ApplicationUNIX Application Video Server Webserver


TOSKANA● dynamisches Aspektweben im NetBSD-Kern [8]

● unterstützt before-, after- und around-advice

● für execution-joinpoints in C-Funktionen

● Architektur:

● Im Kern: Bibliothek zur Instrumentierung von Kernfunktionen

● Precompiler erzeugt C-Code aus Aspekten, welcher

- obige Bibliothek verwendet

- ein nachladbares Kernelmodul implementiert

● Das Kernelmodul wird kompiliert und als solches geladen

→ voller Zugriff auf Kernel-Code und -Daten

Einordnung: dynamisch, Module / Policies


TOSKANA: Precompileraspect hardware_offload {

pointcut packet_from_to_tcp(struct tcpcb *tp):cflow(tcp_output)&& calls(int tcp_build_datapkt(struct tcpcb *tp , ..));

around ( packet_from_to_tcp ):{

/* ... */}

Aspekt

#include <sys/aspects.h>

ASPECT_NAME("hardware_offload");

void aspect_init(void) {PC *p1;p1 = POINTCUT (

"cflow (tcp_output) &&" \\"calls(int tcp_build_datapkt(struct tcpcb *tp ,..)");

AROUND (p1 , hardware_offload_advice_1);}

ADVICE hardware_offload_advice_1(struct tcpcb *tp) { ...}

PräkompilatBibliotheks-Makros

Pointcut-String zusammenbauen

eigentliches „Weben“ (übernimmt Bibliothek)


TOSKANA: Funktionsweise

● Weben durch code splicing● Instruktion am Joinpoint wird

durch Sprung auf Advice-Code ersetzt

● K.zeilentool weave● verifiziert Joinpoints (gibt es

diese Symbole im Kern?)● lädt kompilierten Aspekt als

Kernelmodul

● Eigentliches „Weben“ in aspect_init()


BS-Ebene: Forschungs-Exoten● SynthesisOS [5] (1992)

● Fokus: hohe Performance ohne Verzicht auf Flexibilität und Sicherheit des Systems

● Kernel-Code-Synthese zur Laufzeit: viel benutzte Routinen werden für bestimmte Situationen optimiert → großer Performance-Gewinn- Never evaluate something more than once.

- Verschiedene Methoden:- Factoring Invariants (spezialisierte Routinen)

- Collapsing Layers (Inlining über Architektur-Schichten hinweg)

- Executable Data Structures (Code-Spezialisierung pro Objekt)

● Self-Tuning: Scheduling-Policy passt sich in sehr kurzen Zeitperioden dem Anwendungsverhalten an

● geschickte (optimistic lock-free) Multiprozessor-Synchronisation● erweiterbarer Kernel (enge Kopplung mit Anwendungen)

Einordnung: dynamisch; adaptiv/selbstoptimierend


BS-Ebene: Forschungs-Exoten

Quelle: [5]


BS-Ebene: Forschungs-Exoten

Quelle: [5]









- TOSKANA

- Synthesis

● Zusammenfassung


Fazit (1)● Es existiert eine ganze Reihe von Ansätzen zur

dynamischen Adaptierung von Betriebssystemen.

● Aber: Dynamisch adaptierbare (oder gar adaptive) Betriebssysteme für eingebettete Systeme werden aktuell nur in der Forschung gebaut!● Höherer Ressourcenbedarf steht zu schwacher Hardware

gegenüber

● Ubiquitäre Systeme sind momentan noch sehr oft Spezialzwecksysteme, in denen diese Dynamik nicht benötigt wird.


Fazit (2)● Hardware wird kontinuierlich leistungsstärker

● vgl. PCs der 90er Jahre und heutige Unterhaltungselektronik

● Die Vergangenheit zeigt: BS-Features wandern über dieJahrzehnte von großen zu immer kleineren Systemen● Speicherschutz

● virtueller Speicher

● Mehrbenutzeretrieb

● Dateisysteme

● ... Adaptierbarkeit?

● ... Adaptivität?

● ... nicht zuletzt, weil die„kleinen“ Systeme immergrößer werden ...

Quelle: [2]


Literatur (1)[1] G. Denys, F. Piessens, and F. Matthijs, A Survey of

Customizability in Operating Systems Research.ACM Computing Surveys, Vol. 24, No. 4, Dec. 2002.

[2] Silberschatz, Operating System Concepts, 5th Edition

[3] R. Lea, Y. Yokote, and J. Itoh, Adaptive Operating SystemDesign using Reflection. 5th Workshop on Hot Topics inOperating Systems, 1995

[4] E.G. Sirer et al., Writing an Operating System with Modula-3.Workshop on Compiler Support for System Software, 1996

[5] H. Massalin, Synthesis: An Efficient Implementation ofFundamental Operating System Services (Dissertation),Columbia University, 1992

[6] R. Tartler, D. Lohmann, W. Schröder-Preikschat, and O.Spinczyk, Dynamic AspectC++: Generic Advice at Any Time. InProceedings of the 8th International Conference on SoftwareMethodologies, Tools and Techniques, 2009. (to appear)


Literatur (2)[7] J. R. Levine, Linkers and Loaders. Morgan-Kaufman, Oct. 1999

[8] M. Engel, B. Freisleben, TOSKANA: A Toolkit for OperatingSystem Kernel Aspects. T. Aspect-Oriented SoftwareDevelopment II: 182-226, Springer, 2006

[9] G. C. Necula and P. Lee. Safe kernel extensions without run-time checking. In Proceedings of the second USENIX symposium on Operating systems design and implementation (OSDI '96). ACM, New York, 1996.

Documents

Software ubiquitärer Systeme - ess.cs.tu-dortmund.de · (Betriebs-)System mit großem ... - Instrumentiert alle potentiellen dynamischen Verbindungspunkte in diesem Modul, so dass