Architektur und Schlüsselkomponenten von Windows
Werbung
Agenda Architektur und Schlüsselkomponenten von Windows I. II. I. II. III. III. IV. V. von Stefan Lietsch Steffen Sommer Architektur und Schlüsselkomponenten von Windows I. Geschichte Architektur und Schlüsselkomponenten von Windows Merkmale eines kompletten Betriebsystems (u.a. virtueller Speicher, Prozessmanagement, Multiprogramming) Hatte noch große Teile des 16-Bit-Assembler-Codes von DOS (mit einigen 32-Bit-Erweiterungen) Benutzte MS-DOS-Dateisystem Keine großen Veränderungen zu Windows 95 Kerndatenstrukturen im Benutzerraum (1993) Windows NT 3.1 (New Technologie) komplett neues 32-Bit-BS Ziele bei Entwicklung: Sicherheit und hohe Zuverlässigkeit Multiprocessing und Multiuser lediglich Anhänger im Servermarkt (1996) Windows NT 4.0 Stefan Lietsch und Steffen Sommer Geschichte (1998) Windows 98 bzw. später Windows ME VIII. Alle Programme liefen im selben Adressraum und ein Fehler in irgendeinen Programm konnte das gesamte System zum Absturz bringen. (1995) Windows 95 VII. Auf MS-DOS aufgesetzt DOS hatte noch immer Kontrolle über Maschine und Dateisystem VI. Hardware Abstraction Layer (HAL) Kernel Executive Objekte in Windows Win32-API Teilsysteme für andere Systeme ( Registry ) Quellen Fragen I. (1985) erste graf. Oberfläche für MS-DOS (Windows 1.0) (1990) kommerzielle Erfolge mit Windows 3.0 / 3.1 / 3.11 Stefan Lietsch und Steffen Sommer Geschichte Architektur graf. Benutzeroberfläche, wie Win 95 (2000) Windows NT 5.0 bzw. Windows 2000 Zusammenführung der zwei Windowsstränge echtes 32-Bit-System mit Trennung von Kern- und Benutzermodus Unterstützung für Plug-and-Play / USB / FireWire / IrDa / PowerManagement u.v.m. Jedes Programm konnte also diese Kerndatenstrukturen überschreiben und so das ganze System zum Absturz bringen. Architektur und Schlüsselkomponenten von Windows Stefan Lietsch und Steffen Sommer Architektur und Schlüsselkomponenten von Windows Stefan Lietsch und Steffen Sommer II. Architektur Ursprünglich auf Betrieb von mehreren verschiedenen Teilsystemen ausgelegt, die Ausführung von Programmen verschiedener BS (z.B. Unix, OS/2, Windows) ermöglicht So konzipiert, dass Absturz eines Teilsystems nicht zu Absturz anderer Teilsysteme oder des Ganzen BS führt (bzw. führen soll) Aufgliederung in Schichten: Hardwareabstraktionsschicht (HAL) Zentraler Zuweisungsmechanismus = Kernel Executive (Gerätetreiber) Schichten bieten die Möglichkeit durch Abstraktion mit einfachen Systemaufrufen komplexere Befehle zur Verfügung zu stellen Windows 2000 hat eine modulare Struktur mit relativ kleinem Kern Windows 2000 ist Pseudo-Objektorientiert Architektur und Schlüsselkomponenten von Windows Stefan Lietsch und Steffen Sommer Architektur und Schlüsselkomponenten von Windows II.I Architektur und Schlüsselkomponenten von Windows Stefan Lietsch und Steffen Sommer Stefan Lietsch und Steffen Sommer Hardwareabstaraktionsschicht (HAL) Ziel: BS soll portierbar sein Problem: untere Ebene des BS arbeitet mit Geräteregistern, Interrupts und anderen Hardwaremerkmalen, die sich von Maschine zu Maschine grundlegend unterscheiden → Abstrahierte Sicht auf Hardware durch HAL Die HAL stellt Dienste zur Verfügung, die darüber liegende Schichten nutzen können um mit der Hardware zu kommunizieren/interagieren (z.B. Zugriff auf Geräteregister, busnahe Geräteadressierung, Multiprozessorsynchronisation etc.) Architektur und Schlüsselkomponenten von Windows Stefan Lietsch und Steffen Sommer II.I Hardwareabstraktionsschicht (HAL) Gerätespezifische Adressen, Interrupts etc. werden in systemweite, logische Adressen, Interrupts etc. umgewadelt um ein eindeutiges ansprechen der Geräte zu ermöglichen Informationen über im System vorhandene Geräte, Busse etc. bekommt die HAL beim Hochfahren direkt vom BIOS/CMOS Erweiterung der HAL durch z.B. DirectX möglich, dadurch können zusätzliche, spezialisierte Prozeduren für z.B. Multimediaanwendungen implementiert werden Architektur und Schlüsselkomponenten von Windows II.II Stefan Lietsch und Steffen Sommer Kern Architektur und Schlüsselkomponenten von Windows II.II Kein Mikrokern, da von Anfang an Dienste wie Speicherverwaltung und andere Systemkomponenten im Kern integriert waren Der Kern soll den Rest des BS vollständig von der Hardware unabhängig und somit hochgradig portierbar machen → Kern benutzt einfache Prozeduren der HAL um höhere Abstraktionsstufen zu erreichen Der Kern ist für das Scheduling der Threads und Prozesse zuständig und führt z.B. bei abgelaufener Zeitscheibe oder E/AUnterbrechung notwendig gewordene Kontextwechsel durch ohne das darüber liegende Schichten sich darum kümmern müssen Architektur und Schlüsselkomponenten von Windows Stefan Lietsch und Steffen Sommer Kern (Objekte) Der Kern verwaltet die internen Objekte: Stefan Lietsch und Steffen Sommer Kontrollobjekte (steuern das System): Einfache Prozessobjekte, Unterbrechungsobjekte Defferred Procedure Call (DPC) Objekte: trennen zeitlich kritischen Teil einer Unterbrechungsroutine von zeitlich unkritischem und ordnet dann die Teile in der DPC-Warteschlange zur Bearbeitung Asynchronous Procedure Call (APC) Objekte: wie DPC, werden aber im Kontext eines bestimmten Prozesses ausgeführt Dispatcherobjekte Semaphore, Mutexe, Ereignisse, Stoppuhren und andee Objekte auf die Threads warten können Sind in den Kern eingelagert, weil sie eng mit Thread/Prozess-Scheduling zusammenarbeiten Architektur und Schlüsselkomponenten von Windows Stefan Lietsch und Steffen Sommer II.III Executive Besteht aus 10 Komponenten, wobei jede eine Sammlungvon Prozeduren darstellt um bestimmte Ziele zu erreichen: Object Manager: E/A Manager II.III Executive Garantiert das Sicherheitsstandards nach Orange Book eingehalten werden Z.B. authentifizierende Anmeldung, Zugriffskontrolle etc. Plug and Play Manger Überprüft beim Hochfahren und im Betrieb (z.B. bei USB) ob neue Geräte angeschlossen wurden und leitet Treibersuche/-installation ein Power Manager Configuration Manager Local Procedure Call Manager Beschleunigt Speicherzugriff indem zuletzt oder häufig verwendete Speicherblöcke im Speicher behalten werden Arbeitet für alle Dateisysteme und eng mit Virtual Memory Mgr zusammen Executive Ursprünglich im Benutzerraum, seit NT 4.0 zur Leistungssteigerung im Kernraum Behandelt Bilddaten für Monitor und Drucker Verwaltet Grafiktreiber und Window Manager Systemdienste Herrscher über Energieverwaltung Stefan Lietsch und Steffen Sommer Graphics Device Interface (GDI) File System Cache Verwaltet virtuellen Speicher (Einlagerung , Überwachung) Behandelt Systemaufrufe, die virtuellen Speicher betreffen Architektur und Schlüsselkomponenten von Windows II.III Security Reference Monitor Stefan Lietsch und Steffen Sommer Behandelt Prozesse und Threads (Erstellung und Vernichtung) Schlüssel zur Multiprogrammierung Virtual Memory Manager Architektur und Schlüsselkomponenten von Windows Verwaltet E/A-Geräte und stellt E/A-Dienste zur Verfügung „Heimat der Gerätetreiber“ Auch Dateisysteme (NTFS, FAT) sind technisch gesehen Gerätetreiber und werden deshalb im E/A Manager verwaltet Process Manager Verwaltet alle „Objekte“, die dem BS bekannt sind (z.B. Threads, Prozesse, Dateien, Verzeichnisse, Semaphore, E/A-Geräte etc.) Eigenständige, dünne Schicht über der Executive Dient als Schnittstelle zur Executive Akzeptiert echte Windows 2000 Systemaufrufe und ruft Teile der Executive zur Ausführung auf Verwaltet die Registry Interprozesskommunikation zw. Prozessen und Subsystemen Effizienz sehr wichtig weil für Systemaufrufe benötigt Architektur und Schlüsselkomponenten von Windows Stefan Lietsch und Steffen Sommer Architektur und Schlüsselkomponenten von Windows Stefan Lietsch und Steffen Sommer II.IV Gerätetreiber III. Objekte in Windows 2000 Jeder Treiber kann ein oder mehrere E/A-Geräte steuern aber auch z.B. Datenstrom verschlüsseln oder Zugang zu den Datenstrukturen des Kerns verschaffen Kein Bestandteil des Kerns (im Gegensatz zu UNIX) → Vorteil: Kern ist für (fast) jede Hardwarekonstellation gleich, die Treiber werden dynamisch beim Start geladen und ermöglichen so trotzdem eine individuelle Konfiguration Architektur und Schlüsselkomponenten von Windows III. Stefan Lietsch und Steffen Sommer Objekte in Windows 2000 IV. Einheitliche und konsistente Schnittstelle zu den Systemressourcen und Datenstrukturen (Prozesse, Threads, offene Dateien etc.) Alle Objekte werden auf gleiche Art benannt und können über sog. Objekt-Handles angesprochen werden Alle Objekte laufen über den Objektmanager, dadurch wird eine zentrale Sicherheitskontrolle ermöglicht und nicht mehr benutzte Objekte können schnell ermittelt und gelöscht werden Jedes Objekt hat einen Bestimmten Typ, der durch eine Zeiger auf ein Typobjekt festgelegt wird, diese Typobjekte haben Standardoperationen um die jeweiligen Objekte aufzurufen, zu schließen und zu löschen Jedes Objekt hat seine eigenen Adressraum, da sie dynamisch erzeugt werden Win32-API bietet Methoden um Objekte zu erschaffen oder zu öffnen Architektur und Schlüsselkomponenten von Windows Architektur und Schlüsselkomponenten von Windows Stefan Lietsch und Steffen Sommer Stefan Lietsch und Steffen Sommer API allgemein API = Anwendungsprogrammierschnittstelle (Application Programming Interface) „Eine API besteht aus einem Satz von Funktionen, die von Programmierern benutzt werden, um festzulegen, wie Programme interagieren.“ Bsp. CryptoAPI von MS: Wen ein Programm eine Verschlüsselung vornehmen muss, kann es dafür diese CryptoAPI von MS aufrufen. Diese enthält Standardfunktionen für die Verschlüsselung. Das Programm selbst muss nicht wissen, wie die Verschlüsselung funktioniert. Wenn MS eine neue Verschlüsselungfkt. entwickelt, kann diese problemlos in die API integriert werden. Solange sich die Schnittstellen nicht ändert, können die Programme unverändert auf diese API zugreifen. Architektur und Schlüsselkomponenten von Windows Stefan Lietsch und Steffen Sommer IV. Win32-API Dokumentierte Bibliothek mit Funktionen Systemaufrufe oder Arbeit direkt im Benutzerraum Speicherverwaltung Dateiein- und Ausgabe Demzufolge abwärtskompatibel bis Win95, wenn man grundlegende Änderungen beachtet. (z. Bsp.: Sicherheitsaufrufe…) Sicherheit, Handles gehören zu dem Prozess der das Objekt erzeugt hat. Handles referenzieren das Objekt. Bsp.: Beim Laden eines Gerätetreibers wird ein Objekt erzeugt, das alle Eigenschaften und Zeiger auf all seine Funktionen enthält. Innerhalb des BS wird der Treiber nur über dieses Objekt referenziert. Stefan Lietsch und Steffen Sommer Weitere Teilsysteme (MS-DOS-VM / WOW) Ein- und Ausabegeräte … Architektur und Schlüsselkomponenten von Windows V. POSIX-Teilsystem (Portable Operating System Interface for Unix) Minimale Unterstützung für UNIX-Anwendungen Wandelt C-Aufrufe in Win32-API-Aufrufe um MS-DOS-Teilsystem NTVDM (NT Virtual DOS Machine) führt alle DOS-Anwendungen aus, indem die MS-DOS-5.0 –Umgebung emuliert wird. Jede DOS-Anwendung läuft in ihrer eigenen NTVDM und in ihrem eigenen Adressraum. Es wird ein vollständiger Netzwerk-Redirector sowie Unterstützung für Maus und CD-ROM-Laufwerken bereitgestellt. 16-Bit-Windows-Teilsystem Stefan Lietsch und Steffen Sommer allerdings keine Threads, kein Fenstersystem und kein Netzwerk Demzufolge vom Win32-Teilsystem abhängig. Das Posix-Teilsystem kann nur das was auch das Win32-Teilsystem kann. Und nicht mal das. Es steht nicht die gesamte Win32-Schnittstelle zur Verfügung. OS/2-Teilsystem für OS/2 1.x Zeichenmodusanwendungen konvertiert ebenfalls OS/2-API-Aufrufe in Win32-API-Aufrufe WOW (Windows on Windows) für Windows 3.1 / 3.11- Anwendungen Mittels Prozess Thunking werden 16-Bit-Aufrufe in entsprechende 32-BitAufrufe der Win32-API umgewandelt Architektur und Schlüsselkomponenten von Windows Während der Entwurfsphase von Windows NT, war die POSIX-Kompatibilität eine Anforderung an BS, das von der US-Bundesregierung gekauft wurde. Es gibt drei Posix-Ebenen. Windows 2000 unterstützt die unterste: POSIX.1. Stefan Lietsch und Steffen Sommer Weitere Teilsysteme (POSIX und OS/2) Teilsysteme agieren mit dem Win32-Teilsystem, das als Einziges direkt mit der Ausführungsschicht interagiert. Es gibt hunderte von Aufrufen zum Erzeugen, Zerstören, Verwalten, Benutzen von Fenstern, Menüs, Toolbars, Statusanzeigen, Rollbalken, Dialogboxen, Symbolen und vieles mehr. Sicherherheitsdeskriptor legt genau fest, wer welche Operationen auf dem Objekt ausführen darf und wer nicht. Architektur und Schlüsselkomponenten von Windows Jeder Prozess besitzt eine ID, die ihn eindeutig identifiziert. Jedes Objekt besitzt eine Zugriffskontrolle, die festlegt, welcher Benutzer welche Operatione ausführen darf. graf. Schnittstelle über 60 Aufrufe zum Erzeugen, Löschen, Schließen, Lesen, Schreiben von Dateien, sowie Auslesen und Setzen von Dateiattributen Kontrollierte Zugriff auf Objekte mittels Sicherheitsdeskriptor V. Jedes BS besitzt Systemaufrufe. Allerdings hat MS diese nie öffentlich bekannt gegeben. Und MS ändert die Systemaufrufe von Ausgabe zu Ausgabe Win32-Aufrufe erzeugen Betriebssystemkernobjekte, wie Dateien, Prozesse, Threads, Pipes usw. Ergebnis = Handle, welches das Objekt referenziert Win32-Aufrufe decken alle Operationen ab, die eine WindowsAnwendung bei der Ausführung benötigt Win32-Aufrufe ändern sich nicht (es kommen nur neue hinzu) IV. Win32-API Sehr beschränkt. Kann keine graf. Anwendungen oder OS/2 2.x Programme oder höher ausführen. Enthält nur Kern-API von OS/2 1.x und einige grundlegende NetzwerkaufrufeAufrufe. Womit es den POSIX-Teilsystem einen Schritt voraus ist. Architektur und Schlüsselkomponenten von Windows Stefan Lietsch und Steffen Sommer VI. Registry VI. Alle Boot- und Konfigurationsinformationen, sowie aktuelle Benutzeranpassung in einer großen zentralen Datenbank Verzeichnis = Key / Verzeichniseintrag = value (Name, Typ, Daten) alle benutzerspezifischen Einstellungen (Sounds, Grafikeinstellungen usw.) Generell alles was man mit der Systemsteuerung einstellen kann Wir beim Systemstart vom Plug-and-Play-Manager aufgebaut und nicht auf der Festplatte gespeichert. HKEY_CLASSES_ROOT ( SAM = Security Account Manager (Benutzernamen, Gruppen, Passwörter usw. ) Security (Systemweite Sicherheitsrichtlinien) HKEY_CURRENT_CONFIG HKEY_CURRENT_USER Hardware (alle Informationen über Hardware, Treiber) HKEY_USERS HKEY_PERFORMANCE_DATA (Systemleistung über „perfmon“) HKEY_LOCAL_MACHINE Registry Mindestlänge der Passwörter, geduldete Anzahl falscher Anmeldeversuche. Software (Informationen von Programmen externer Hersteller) System (Informationen zum Systemstart) Liste der Treiber, die geladen werden müssen, und eine Liste der Dieste, die nach dem Hochfahren gestartet werden müssen. Architektur und Schlüsselkomponenten von Windows Stefan Lietsch und Steffen Sommer Hunderte von internen Zählern, die die Systemleistung beobachten. Link auf COM-Objekte = Dateiendungen Link zum aktuellen Hardwareprofil Link zum aktuellen Benutzerprofil Wenn das System heruntergefahren wird, wird das meiste der Registry auf der Festplatte gespeichert, und zwar in Dateien, die Hives genannt werden. Hardware-Informationen werden nicht abgespeichert. Architektur und Schlüsselkomponenten von Windows Stefan Lietsch und Steffen Sommer VII. Quellen Andrew S. Tanenbaum, Moderne Betriebssysteme, Kapitel 11 David A. Solomon, Inside MS Windows 2000 3. Edition, Kapitel 2 Brown, Miller, Windows 2000 Server Kompendium, Kapitel 2 Fragen ? Vielen Dank für Eure Aufmerksamkeit! Architektur und Schlüsselkomponenten von Windows Stefan Lietsch und Steffen Sommer Architektur und Schlüsselkomponenten von Windows Stefan Lietsch und Steffen Sommer