Laufzeitumgebungen – Das Beispiel der Java Virtual Machine

Präsentation zum Thema: "Laufzeitumgebungen – Das Beispiel der Java Virtual Machine"—  Präsentation transkript:

1 Laufzeitumgebungen – Das Beispiel der Java Virtual Machine
Benjamin Leenen Im Rahmen des Seminars zur Übersetzung von künstlichen Sprachen

2 Agenda Virtuelle Maschinen als Laufzeitumgebung
Die Java Virtual Machine Sicherheit Die Squawk Java Virtual Machine Fazit und Ausblick

3 Virtuelle Maschinen als Laufzeitumgebung
Rechnerarchitektur als Software Compiler  plattformunabhängiger Zwischencode (Bytecode) Ausführung durch plattformabhängige Virtuelle Maschine (VM): Interpreter Übersetzung beim Laden Just-In-Time Compiler Quelle: Aho u. a., 2000 Rechnerarchitektur: eigener Befehlssatz, Verwaltung von Speichersegmenten für auszuführende Programme Übersetzung beim Laden in Maschinensprache  Interpreter überflüssig JIT Compiler: Übersetzung der am häufigsten genutzten Programmteile in Maschinensprache. Restlichen werden weiterhin interpretiert  Beschleunigung der Ausführung

4 Agenda Virtuelle Maschinen als Laufzeitumgebung
Die Java Virtual Machine Die Programmiersprache Java Das class-Dateiformat Speicherbereiche Verifizierung von class-Dateien Ausführung der JVM Sicherheit Die Squawk Virtual Machine Fazit und Ausblick

5 Die Java Virtual Machine Die Programmiersprache Java
Ziel schnelle und einfach Beherrschbarkeit Portabilität Sicherheit Konzept: objektorientiert hoher Abstraktionsgrad primitive - und Referenzdatentypen streng getypt Bezeichner in Unicode ljava Compiler class Gängige Java Virtual Machine (JVM): Java HotSpot VM Ziel: Ausfürhbarkeit von Programmen auf allen Rechnern, unabhängig von BS Sicherheit: gerade bei dem Transfer von Programmen über das Internet ist die Sicherheit von großer Bedeutung Konzept: einfach anzuwenden: Abstraktion von Maschinensprache und auch JVM-Instruktionen und bspw. auch automatische Speicherbereiningung (GC) primitiv: int, char usw ; Referenz: Klassen, Interface, Array; Klassen: Object u. String vordefiniert streng getypt: Alle Datentypen von Variablen und Ausdrücken sind zum Zeitpunkt des Compilierens bekannt  leichtere Fehlererkennung Unicode: Bezeichner, Kommentare und Zeichenketten (String) in Unicode  Internationalität java über Compiler in class (prinzipiell auch andere Programmiersprachen in class übersetzbar  JVM kennt die Java selbst nicht, muss nur class Datei lesen können) Java HotSpot VM: gängige JVM Implementierung von Sun Microsystems, die der Spezifikation folgt

6 Agenda Virtuelle Maschinen als Laufzeitumgebung
Die Java Virtual Machine Die Programmiersprache Java Das class-Dateiformat Speicherbereiche Verifizierung von class-Dateien Ausführung der JVM Sicherheit Die Squawk Virtual Machine Fazit und Ausblick

7 Die Java Virtual Machine Das class-Dateiformat (1/2)
ClassFile { u4 magic; u2 minor_version; u2 major_version; u2 constant_pool_count; cp_info constant_pool[constant_pool_count-1]; u2 access_flags; u2 this_class; u2 super_class; u2 interfaces_count; u2 interfaces[interfaces_count]; u2 fields_count; field_info fields[fields_count]; u2 methods_count; method_info methods[methods_count]; u2 attributes_count; attribute_info attributes[attributes_count]; } ClassFile { u4 magic; u2 minor_version; u2 major_version; u2 constant_pool_count; cp_info constant_pool[constant_pool_count-1]; u2 access_flags; u2 this_class; u2 super_class; u2 interfaces_count; u2 interfaces[interfaces_count]; u2 fields_count; field_info fields[fields_count]; u2 methods_count; method_info methods[methods_count]; u2 attributes_count; attribute_info attributes[attributes_count]; } class-Datei besteht immer aus einem Klassenkonstrukt Notation ähnlich der des Datentyps Struct der Programmiersprachen C und C++

8 Die Java Virtual Machine Das class-Dateiformat (2/2)
access_flags Regelung des Zugriffs fields[] Klassen- und Objektvariablen methods[] Auszuführender Code in: code[] constant_pool[] Verweise auf Klassen, Felder und Methoden symbolische Verweise in restl. class-Datei access_flags Angaben über die Zugriffsrechte: für ganze Klasse, aber auch für Methoden und Felder  zB public od. private fields enthält alle Variablen  Klassen- und Objektvariablen inkl. des Typs und Zugriffsrechte methods enthält alle Methoden einer Klasse inkl Rückgabewert, Zugriffsrechte und code[] code[]: auszuführender Code in JVM-Instruktionen constant_pool beinhaltet den Konstantenpool beinhaltet Referenzen auf alle Klassen, Felder und Methoden, die in der class Datei notwendig sind Referenzen in Unicode  relativ speicheraufwändig Platzsparung dadurch erreichbar  restl. class Datei verwendet symbolische Referenzen, indem sie auf Einträge im Konstantenpool verweist.

9 Agenda Virtuelle Maschinen als Laufzeitumgebung
Die Java Virtual Machine Die Programmiersprache Java Das class-Dateiformat Speicherbereiche Verifizierung von class-Dateien Ausführung der JVM Sicherheit Die Squawk Virtual Machine Fazit und Ausblick

10 Die Java Virtual Machine Speicherbereiche
JVM-abhängig Heap Methodenbereich Thread-abhängig PC (Program Counter) Register Native Methoden Stacks Java Virtual Machine Stack – umfasst Frames: Variablenarray Operandenstack Verweis auf Konstantenpool Zwei Arten von speichern 1. Speicherbereiche, die vom Start der JVM bis zu deren Ende bestehen (diese teilen sich alle Threads) Heap: Speicher für alle Klasseninstanzen und Arrays  Speicherverwaltung durch den GC Methodenbereich: klassenabhängige Daten, zB den Laufzeit-Konstantenpool, Felder- und Methodendaten und den Code der Methoden und Konstruktoren 2. SB, die abhängig von der Laufzeit eines Threads sind Thread umfasst: die Abarbeitungsabfolge mehrerer Instruktionen nacheinander, wobei die JVM die gleichzeitige Ausführung mehrerer Threads unterstützt. Thread unabhängig von anderen Threads. Allerdings können sie sich auch Objekte und Werte aus einem gemeinsamen Speicherbereich teilen Program Counter Register: Adresse der aktuell auszuführenden Instruktion; bei nativem Code: leer bei Unterstützung von nativem Code: Native Methoden Stack eigener Stack: JVM Stack: lokale Variablen und Zwischenergebnisse in Form von Frames Frame: Erstellung beim Aufruf einer Methode als Teil des Stacks des aktuellen Threads; Löschen Variablenarray (lokale Variablen) Operandenstack (Ablage und Verarbeitung von Konstanten und Variablen) Verweis auf den Laufzeit-Konstantenpool

11 Agenda Virtuelle Maschinen als Laufzeitumgebung
Die Java Virtual Machine Die Programmiersprache Java Das class-Dateiformat Speicherbereiche Verifizierung von class-Dateien Ausführung der JVM Sicherheit Die Squawk Virtual Machine Fazit und Ausblick

12 Die Java Virtual Machine Verifizierung von class-Dateien (1/2)
Überprüfung auf statische und strukturelle Bedingungen statisch: Wohlgeformtheit strukturell: gegenseitige Beziehung von Instruktionen Bytecode Verifier: Aufsplitten von code[] in einzelne Bytes Analyse einzelner Instruktionen Data-Flow Analyzer „changed“-Bit für jede Instruktion gehe zu Instruktion mit Bit auf 1 Auswirkungen auf Operandenstack und Variablenarray Bestimmung aller Folgeinstruktionen Zusammenführung von bisherigem und aktuellem Operandenstack und Variablenarray Überprüfung auf Korrektheit des Formats als erster Schritt alle notw. Bed.:  zur Laufzeit bspw. kein Überlauf (Overflow) und Unterlauf (Underflow) auf dem Operandenstack möglich und alle Parameter der verwendeten JVM Instruktionen haben einen zulässigen Datentyp  Verifizierung zum Zeitpunkt des Bindens  schnellere Ausführung durch Interpreter statische Bed: einzuhalten vom Compiler  JVM kann sich dies jedoch nicht sicher sein für die Klasse und den Code Wohlgeformtheit und syntaktische Vorgaben wie JVM-Instruktionen anzugeben sind  code[] Länge mind. 1, Überprüfung der Operanden strukturelle Bed Verhalten der JVM-Instruktionen in gegenseitiger Beziehung Bytecode Verifier: bspw. Erkennung einzelner Operanden und Überprüfung, ob diese zulässig sind vor Ausführung einer Instruktion: Erfassung des Inhalts des Operandenstacks (inkl Größe und Typ der Einträge) und des Variablenarrays (inkl des Typs) „changed“-Bit: Kontrolle, ob Instruktion noch überprüft werden muss  schleifenförmiger Durchlauf bis alle auf 0 sind suchen der nächsten Instruktion mit Bit auf 1 Simulation der Auswirkungen auf den Operandenstack und die Variablenarrays: Operandenstack lesen: genügend Werte mit notw. Typ vorhanden schreben: genügend Platz  durchführen Variablenarray: lesen: notw. Typ schreiben:  durchführen Merge von bisherigem und aktuellem Operandenstack und bisherigem und aktuellem Variablenarray wenn nicht zum ersten Mal: Stack: Anzahl und Typen der Einträge müssen übereinstimmen Array: Paarweiser Vergleich der Elemente  danach Sprung zu Schritt 1

13 Agenda Virtuelle Maschinen als Laufzeitumgebung
Die Java Virtual Machine Die Programmiersprache Java Das class-Dateiformat Speicherbereiche Verifizierung von class-Dateien Ausführung der JVM Sicherheit Die Squawk Virtual Machine Fazit und Ausblick

14 Die Java Virtual Machine Ausführung der JVM (1/2)
Erstmalige Ausführung einer Klasse: Laden, Binden und Initialisieren notwendig Laden Auslösung durch andere Klasse Durchführung: Klassenlader Bootstrap-Klassenlader: Teil der JVM nutzerdefinierte Klassenlader: von extern zu laden Quelle: Venners, 2000 Laden Ladevorgang wird durch andere Klasse ausgelöst (selber KL wie andere Klasse) Klassenlader selbst durchführen oder an anderen KLader delegieren Bootstrap-Klassenlader und nutzerdefinierte Klassenlader Bootstrap: direkter Teil der JVM nutzderdefinierte: Verhalten wie restliche Java-Objekte (geschr. in Java und Einbindung zur Laufzeit) 1. Schritt: Bootstrap: Suche nach einer bereits vorhandenen, vorgegebenen Darstellung in Byteform Nutzerdfiniert: erzeugen einer Byteform-Darstellung der Klasse Weitere Schritte: Überprüfung, ob Format korrekt

15 Die Java Virtual Machine Ausführung der JVM (2/2)
Binden Verifizierung Vorbereitung: Speicherzuweisung für Klassenvariablen Initialisierung der Speicherbereiche Auflösung der symbolischen Verweise Initialisieren: Zuweisung der vorgesehenen Werte zu Klassenvariablen Quelle: Venners, 2000 Binden Verifizierung: Prüfung, ob die Binärdarstellung von K zulässig ist, also dem class-Dateiformat genügt  s. Verifizierung; kann Laden zusätzlicher Klassen zur Folge haben Vorbereitung: Zuweisung von Speicherplätzen für die Klassenvariablen und versehen dieser Speicherbereiche mit einem initialen Wert (entsprechend dem zugewiesenen Datentyp) Auflösung: Auflösen der symbolischen Verweise und ersetzen dieser durch konkrete Werte kann auch erst zur Laufzeit geschehen wichtig: Überprüfung ob Zugriff auf Felder bzw. Methoden anderer Klassen zulässig ist Initialisieren

16 Agenda Virtuelle Maschinen als Laufzeitumgebung
Die Java Virtual Machine Sicherheit Die Squawk Java Virtual Machine Fazit und Ausblick

17 Sicherheit Hauptkomponenten der Sicherheitsarchitektur:
Bytecode-Verifier Klassenlader Sicherheitsmanager anfängliches Sicherheitsmodell: Sandbox-Modell vertrauenswürdig: Systemdomäne ansonsten: Sandbox Sicherheitsmanager: setzt das Sicherheitsmodell um, indem er alle Zugriffe auf sicherheitskritische Systemressourcen zur Laufzeit kontrolliert ersten Sicherheitsmodelle 1. Version: lokaler Code in Systemdomäne, entfernter Code in Sandbox 2. Version: entfernter Code signierbar, um ihn in Systemdomäne ausführen zu können

18 Sicherheit Aktuelles Sicherheitsmodell
Generelle Strategie: Policy-Datei Rechtevergabe abhängig von Herkunftsort und Signatur Rechte: Lese-/Schreibzugriff, Verbindungsherstellung Schutzdomänen Rechtevergabe an alle Klassen einer Domäne Zugriff auf Systemressourcen: Systemdomäne Zugriffskontrolle Access Controller im Sicherheitsmanager Zugriffsüberprüfung anhand Policy-Datei weitere Möglichkeit: Guarded Object keine Unterscheidung mehr zw. lokalem und entferntem Code  wesentlich umfangreicher generelle Sicherheitsstrategie für eine Datei wird festgelegt durch eine Policy –Datei: lokal auf Rechner wenn nicht vorhanden: Sandbox Rechtevergabe abh. von Herkunftsort und Signaturen Rechte: Lese bzw. Schreibzugriff auf best. Ordner und Verbindungsherstellung zu Internetseiten Überprüfung von Signaturen Schutzdomänen Zuweisung von Klassen zu diesen  Rechtevergabe an alle enthaltenen Klassen einzige Domäne mit Zugriff aus Systemressourcen: Systemdomäne (diese enthält zB die JVM-eigenen Klassenbibliothenekn) über Systemdomäne Kommunikation einzelner Schutzdomänen mögl., direkt nicht Zugriffskontrolle: Erweiterung des SM durch den Access Controller Weiterleitung aller Anfragen an Access Controller Überprüfung eines Zugriffsversuchs anhand der passenden Policy-Datei direktes Ansprechen des Access Controllers: direktes Übergeben von Policy-Datei und gewünschten Rechten Analyse aller Zugriffe des ganzen Threads  die erforderlichen Berechtigungen müssen dabei allen Schutzdomänen, die dieser Thread durchlaufen hat, zugewiesen sein  Verhinderung, dass ein Thread bereits durch einen einmaligen Zugriff auf die Systemdomäne freien Zugriff auf alle Systemressourcen erlangt Guarded Object: Erweiterung eines Objekts um ein Wächterobjekt, dass alle Zugriffe kontrolliert

19 Sicherheit Sicherheitsrisiken
nachträgliches Verändern von class-Dateien Hinzufügen von Instruktionen in code[] Veränderung der Zugriffsrechte in access_flags Probleme der Policy-Datei: keine Überprüfung der angegebenen Herkunftsadresse Policy-Datei einfach veränderbar Datenbank mit Signaturen vom Nutzer zu pflegen Zugriffskontrolle nur beim ersten Zugriff Nachträgliches Verändern von class-Dateien Hinzufügen von JVM-Instruktionen in bereits erstellte class Dateien. Jene müssen dann nur noch über goto referenziert werden Veränderung von Zugriffsrechten durch Änderung des Eintrags in accesss_flags  zB private in public nicht übereinstimmende Semantik von der Sprache Java und dem daraus erstellten Bytecode  Bsp: in JVM ist der Befehl goto erlaubt, in Java selbst nicht; dadurch Umgehung der festen Ein- und Ausstiegspunkte von Schleifen in Java möglich Policy-Datei: Vortäuschung einer Herkunftsadresse mögl. da diese nicht verifiziert wird Verwaltung der Signaturen als Problem: DB mit allen Signaturen ist vom Nutzer zu verwalten die Policy-Datei selbst kann ebenfalls von außen verändert werden, wenn der Nutzer seinen Rechner nicht gg Angriffe von außen schützt  Angreifer kann zB auch eigenen Policy-Datei einschleußen um Code ausführen zu können. Zugriffskontrolle findet nur beim ersten Zugriff eines Objektes statt. Bei allen weiteren Zugriffen wird dieser einfach gewährt

20 Agenda Motivation: Flexible Ausführung höherer Programmiersprachen
Virtuelle Maschinen als Laufzeitumgebung Die Java Virtual Machine Sicherheit Die Squawk Java Virtual Machine Fazit und Ausblick

21 Die Squawk Java Virtual Machine
für kleine, portable Geräte konzipiert geringer Ressourcenanspruch größtenteils in Java geschrieben lauffähig ohne Betriebssystem – z. B. auf dem SPOT (Sun Small Programmable Object Technology) verteilte Architektur: Desktoprechner: Suite Creator geräteseitige VM Squawk: gedacht für kleine, portable Geräte, die nur geringe Hardwareressourcen zur Verfügung stellen können größtenteils in Java, teilweise in C auf kleinen, portablen Geräten häufig C oder Assemlbersprachen im Einsatz hier wird auf Java gesetzt, zB aufgrund der automatischen GC und ausgereiften Thread-Verwaltung zudem: Vereinfachung der Entwicklung, zahlreiche Entwicklungswerkzeuge  Förderung der Entwicklung von Apps kann auf bestimmten Geräten ohne BS laufen (zB auf SPOT)  spart Speicherplatz Um Speicher sparen zu können, setzt die Squawk auf eine verteilte Architektur  Teil auf Desktoprechner, Teil auf tragbarem Gerät

22 Die Squawk Java Virtual Machine Suite Creator
Konvertierung von class- in suite-Dateien lsuite-Datei: 38% der Größe von class-Dateien kann Klassenstrukturen umfassen hierarchisch strukturierbar Serialisierung vor Übertragung Bytecode-Verifier Signierung von suite-Dateien Konvertierung suite-Dateiformat 38 % der Größe von class kann ganze Klassenstrukturen enthalten kann in einer Hierarchie angeordnet werden Serialisierung nach Erstellung  dies iV mit der Hierarchie führt zu einer Beschleunigung des VM-Starts und des Ladens Bytecode-Verifier nicht auf dem Gerät, sondern Desktoprechner  Platzsparung Sicherstellung, dass Konvertierung erfolgreich ist im Prinzip wie Java Bytecode Verifier Signierung mit privatem Schlüssel  Authentifizierung dann durch öffentlichen Schlüssel auf dem Gerät Quelle: Simon u. a., 2006

23 Die Squawk Java Virtual Machine Geräteseitige VM
Betriebssystemfunktionen Thread Scheduler Behandlung von Interrupts Anwendungen als Objekte (Isolates) Isolierung einzelner Anwendungen gemeinsame Nutzung von VM-Ressourcen entferntes Debugging Serialisierung jedes Zustands möglich Speicherung direkt Übertragung an andere Squawk VM Um ohne BS laufen zu können, muss die geräteseitige VM deren Fkt übernehmen Thread Scheduler: Kontrolle der Ausführung aller Threads, Umschalten zw. diesen Behandlung von Interrupts: bedeutender Bestandteil dieser Ausführungskontrolle (GC und Ausführung von Systemcode ist dabei nicht präemptiv) Isolates Ausführung und Kontrolle von Anwendungen erfolgt durch die Repräsentierung dieser in Objekten Diese sind eine Instanz der Klasse Isolate diese Klasse stellt zB Methoden zur Verfügung, um eine Anw. starten, stoppen und ihren Status abfragen zu können analog zu Prozessen in BS: ein Isolate kann mehrere Threads umfassen und diesen gemeinsame Ressourcen zur Verfügung stellen eine Anw läuft immer isoliert von den anderen ab. Im Gegensatz zu sonstigen JVM-Impl. nutzen Isolates best. Ressourcen, wie etwa die Java-Bibl., gemeinsam  nicht eine VM für jede Anw. notwendig Debugging über passende Werkzeuge auf Desktopseite, die das Java Debug Wire Protocol (JDWP) unterstützen. Auf dem Gerät läuft ein Debug-Isolate, welches das Debugging geräteseitig ausführt Serialisierung: Isolates können in jedem Zustand in einen Datenstrom serialisiert werden Speicherung auf Festplatte mögl. aber auch direkte Übertragung in andere Squawk mögl.  Anw. können in einem Zustand angehalten und auf einem anderen Gerät weitergeführt werden auch automatische Übertragung einbaubar über moveTo Quelle: Simon u. a., 2006

24 Agenda Motivation: Flexible Ausführung höherer Programmiersprachen
Virtuelle Maschinen als Laufzeitumgebung Die Java Virtual Machine Sicherheit Die Squawk Java Virtual Machine Fazit und Ausblick

25 Fazit und Ausblick Zielerreichung von Java:
Portabilität durch Kombination von Bytecode und VM Sicherheit ausgereifte Mechanismen zur Verifizierung und Zugriffskontrolle nach wie vor Verbesserungsbedarf stetiger Entwicklungsprozess Verbesserung der Sicherheit Entwicklungen im Bereich kleiner, portabler Geräten Steigerung der Performance Inwieweit erreicht Java aktuelle die ursprünglichen Ziele Portabilität: sichergestellt durch Kombination von Bytecode und VM Sicherheit: schon ausgereift und besser als noch vor vielen Jahren aber nach wie vor Verbesserungen notwendig Java ist einem stetigen Entwicklungsprozess unterworfen zum einen natürlich Verbesserung der Sicherheit im Bereich kleiner, portabler Geräte stetige Steigerung der Performance ein wichtiger Punkt dabei: Verbesserung der GC

26 Vielen Dank für die Aufmerksamkeit

27 Backup Die verteilte Architektur der Squawk VM
Quelle: Simon u. a., 2006 Suite Creator komplett in Java geräteseitige VM Interpreter in C  in Zukunft in Java und dann Übersetzung in C Bootloader auch in C: Laden.. auf das Gerät .. aller Komponenten, die in C geschrieben oder in C übersetzt wurden .. der Bootstrap-Suite (suite-Datei mit allen benötigten Java Klassenbibliotheken)

28 Backup Sicherheitsarchitektur
Quelle: Eckert, 2008

29 Backup Sicherheit: Policy-Datei
grant codeBase " signedBy "Duke" { permission java.io.FilePermission "read, write","/bob/temp/*"; permission java.io.FilePermission "read","/joe/temp/"; permission java.net.SocketPermision "connect","*.rman.com"; }; grant {permission java.net.SocketPermission "localhost:1024-","listen";}; Quelle: in Anlehnung an Eckert, 2008

30 Backup Anwendungsbeispiele für SPOT
Alltag: SPOT am Herd SPOT am Auto  Warnung, wenn Auto wegfährt und Herdplatten noch heiß sind Industrielles Umfeld: Sicherung von wertvollen Gütern z. B. gegenseitige Containerüberwachung  Alarm, wenn Container geöffnet und noch auf dem Transportweg

31 Backup Code-Beispiel Isolate
Isolate isolate = new Isolate ("com.sun.spots.SelfHibernator", url()); isolate.start(); send (isolate, outStream); ... Quelle: Simon u. a., 2006