Fallbeispiel: UNIX/Linux

Transkript

1 Fallbeispiel: UNIX/Linux Referat PS Moderne Betriebssysteme Christian Bayer, Gliederung 1. Geschichte 2. Designkonzepte/Überblick 3. Prozesse in UNIX 4. Speicherverwaltung 5. Ein-/Ausgabe 6. Dateisystem(e) 7. Sicherheit 8. Quellen

2 1. Geschichte

3 1. Geschichte Familie von Betriebssystemen: AIX, Free/Net/OpenBSD, HP/UX, AT&T System V, Solaris, Linux -> POSIX Grundlage: MULTICS, von den Bell-Labs entwickelt Ken Thompson: UNICS in Assembler für die PDP : Dennis Ritchie, Brian W. Kernighan (C- Implementierung) für PDP-11 Portierungen auf diverse andere Architekturen Vernetzung wurde nötig -> TCP/IP

4 2. Überblick

5 2. Überblick Multiuser-, Multitasking-System, Interaktives System UNIX ist der Betriebssystemkern mit Treibern, Speicherverwaltung, Dateisystem, Prozessverwaltung, Netzwerk UNIX ist aber auch und vor allem eine Sammlung von Tools: sh, cc, as, vi, mv, cp, ps,... -> Distribution UNIX = Terminal, Grundlage für komplexere Anwendungen wie X-Server, OpenOffice, KDE

6 2. Überblick: Schichtenmodell [1]

7 2. Überblick: Designkonzepte Thompson wollte eine Entwicklungsumgebung für sich selbst und sein Team -> Programmierer-OS, Textverarbeitung Small is beautiful mächtige Werkzeuge, die ihren Zweck erfüllen, und nur diesen gilt auch für OS-Schnittstelle: Systemrufe: open(), read(), write(), close(), fork() auch diese erfüllen nur ihren Zweck, nicht mehr die meisten Systemrufe basieren auf diesen: execve(), creat() insgesamt nur ca. 100 Systemrufe, Windows: > 1000

8 3. Prozesse

9 3. Prozesse in UNIX Multiprogrammsystem: Mehrere Prozesse von versch. Benutzern Neuer Prozess: int pid = fork() Erzeugt komplette Kopie des Elternprozesses mit gleichen Daten und gleichem Code, allen offenen Dateien: Warum? einfachster Weg, Änhlich dem Thread-Modell (Kind kann Dateien schreiben), schnell (Copy on Write), Konsistenz

10 3. Prozesse: IPC Über Pipes, Sockets (für entfernte Prozesse) Signale (Software-Interrupts): alle Prozesse innerhalb einer Prozessgruppe -> Mutter aller Prozesse : init einige von POSIX geforderte Signale: SIGABRT SIGALRM SIGFPE SIGHUP SIGKILL SIGSEGV Beenden + Core-Datei Zeitgeber-Alarm Gleitkommafehler (z.b. Div 0) Restart (Hangup) Abbruch des Prozesses (nicht abfangbar) Referenz auf ungültige Speicheradresse

11 3. Prozesse: Unterschied zu Windows UNIX pid = fork(); execve("/bin/ls", args, envp); WINDOWS BwStartInfo.cb = sizeof(bwstartinfo); BwStartInfo.lpReserved = 0; BwStartInfo.lpDesktop = 0; BwStartInfo.lpTitle = 0; BwStartInfo.dwFlags = 0; BwStartInfo.cbReserved2 = 0; BwStartInfo.lpReserved2 = 0; CreateProcess("starcraft.exe \0", 0, 0, 0, 0, CREATE_SUSPENDED, 0, 0, BwStartInfo,BwProcessInfo );

12 3. Prozesse: Threads spezifiziert nach POSIX c Unterstützung von binären Semaphoren (Mutexen), Condition- Variablen für Synchronisation (z.b. Wechsellaufwerke) versch. UNIXe haben Threads im Kern oder im Userspace Linux: Userspace, Solaris: Kern Linux hat speziellen Systemruf clone(), der Threads erzeugt

13 3. Prozesse: Datenstrukturen im Kern Bei Systemruf wechselt Prozess in Kernmodus -> Benutzerdaten müssen gesichert werden (z.b. Plattenzugriff kann länger dauern) Datenstrukturen, die der Kern verwaltet: Prozesstabelle Verwaltet Informationen über alle Prozesse, wichtig für Scheduling bleibt immer im Speicher Benutzerstruktur für jeweiligen Prozess Enthält Informationen über alle Kernel-Ressourcen des Prozesses kann ausgelagert werden, falls Prozess nicht im Speicher ist

14 3. Prozesse: fork() Was passiert bei fork()? Prozess wechselt in den Kern Suchen eines freien Eintrags in der Prozesstabelle Tabelleneintrag des Vaters kopieren Textsegment (Code) wird entweder kopiert oder gemeinsam genutzt (Zeiger setzen), da es nur lesbar ist Benutzerstruktur (oft am Ende des Stack-Segments) wird mit Stack zusammen kopiert jetzt ist Kind bereits lauffähig!

15 3. Prozesse: Priority-Queues

16 3. Prozesse: Scheduling Zwei Stufen: Höhere Stufe verschiebt Prozesse zwischen Speicher und Platte untere Stufe wählt aus Prozessen im Speicher den nächsten aus Round-Robin in der unteren Stufe: mehrere Warteschlangen, jede ist mit Prioritätswerten assoziiert mehrere Schichten für unterschiedliche Aufgaben je kleiner die Priorität, desto höher ist ein Prozess in der Schlange Prozess mit kleinster Priorität darf als nächstes Rechnen wenn dieser fertig ist, wird er ans Ende der Liste gesetzt, reschedule

17 3. Prozesse: Scheduling 1x pro sek. wird Priorität neu berechnet priority = CPU_usage + nice + base priority / Konstante = neue Schicht in Prioritätswarteschlange CPU_usage verfällt mit der Zeit -> auch rechenintensive Prozesse kommen wieder dran nice-wert: kann vom Superuser von -20 bis +20 gesetzt werden, erhöht Chance eines Prozesses, wieder zu rechnen Idee: Prozesse sollen schnell wieder aus dem Kernmodus kommen Kernmodus: read, write... -> I/O Aufgaben, die sehr lange dauern

18 4. Speicherverwaltung

19 4. Speicherverwaltung: Grundlagen Ziel: lauffähig auf Systemen mit praktisch keiner (IBM PC) und sehr ausgefeilter Speicherverwaltung UNIX-Prozesse haben 3 Segmente: Text, Daten und Stack Text-Segment: nur lesend -> mehrere Prozesse des selben Programms nutzen gleiches Textsegment Unter Windows auch möglich, aber nicht per default (Umweg über DLLs)

20 4. Speicherverwaltung: Grundlagen Daten-Segment: compile-zeit-variablen und uninitialisierte Daten nicht initialisierte Variablen in C: immer 0 -> 4000 solche Variablen = 4KB Nullen -> Zusammenfassung, nur Größe gespeichert Stack-Segment: enthält z.b. Parameter, Umgebungsvariablen wächst dynamisch, wenn Größe überschritten wird -> Speicherverletzung -> OS alloziiert neue Seite mit brk() Prozesse können Dateien in ihren Speicher einblenden -> memory mapped files mit mmap(), munmap()

21 4. Speicherverwaltung: Abbildung

22 4. Speicherverwaltung: Paging Idee: Prozess muss nicht vollständig im Speicher sein, ausreichend für Lauffähigkeit: Benutzerstruktur und Seitentabellen Text, Daten und Stack werden dynamisch eingebracht, wenn Seitenfehler für diese Segmente auftreten es ist nur der Code im Speicher, der auch wirklich gebraucht wird Auslagerung von Text-Segmenten und speicherabgebildete Dateien auf ihre Inodes im Dateisystem bei fork()-systemruf werden bekanntlich nur Zeiger neu gesetzt, erst beim Schreiben wird der Inhalt kopiert -> Zusammen mit Paging wird sehr viel Speicher gespart

23 4. Speicherverwaltung: Linux freier Speicher = ungenutzte Ressource = verschwendeter Speicher -> fast nie ist mehr als 10% Speicher frei genutzt für: Kernel selbst, wird nicht ausgelagert, Plattencache mit Prefetching, Benutzerseiten (beide gleicher Pool), Paging-Puffer Buddy-Algorithmus als Seitenersetzungsalgorithmus: Einteilung der Seiten in Blöcke (64 Seiten), Anforderung wird auf nächste Zweierpotenz gerundet (Problem: Fragmentierung) Block wird solange geteilt, bis entsprechende Seitenanzahl erreicht Freigabe: benachbarte Blöcke verschmelzen wieder zu großem Block

24 4. SV: Abbildung Buddy-Algorithmus

25 4. Speicherverwaltung: Windows Working-Set-Algorithmus Ziel: Gewisser Anteil des Speichers soll frei bleiben -> keine Auslagerung laufender Prozesse bei Seitenfehlern WS ist Teilmenge aller eingelagerten Seiten eines Prozesses WS hat minimale und maximale Größe Bei Seitenfehler: wenn WS < min: Seite zum WS hinzufügen WS > max: Seite aus WS entfernen, verbleibt aber im Speicher mehr Speicher benötigt: Prozesse auslagern, die lange unbeschäftigt waren, viel Speicher benutzen Prozesse mit WS < min bleiben im Speicher [3]

26 5. Ein-/Ausgabe

27 5. Ein-/Ausgabe: Grundlagen alle I/O-Geräte sehen wie Dateien aus und lassen sich auch so ansprechen (open, read, write, close) sind ins Dateisystem integriert (/dev, /proc, /sys...) Einteilung in Blockorientierte Geräte (Platten, Wechselmedien) Zeichenorientierte Geräte (Terminals, Serielle-Schnittstelle) I/O regelt ein Gerätetreiber pro Gerätetyp -> Einteilung in Majors und Minors: alle Geräte eines Typs haben selben Major, wenn mehrere vorhanden sind, werden sie durchnummeriert Treiber isoliert Kern von Eigenheiten der jeweiligen Hardware

28 5. Ein-/Ausgabe: Konzepte Blockorientiert: Ziel: Minimierung von I/O, da meist sehr langsam: Puffercache ist angeforderter Block im Puffer, so wird er daraus genommen Puffer hat eigentlich feste Größe -> doppelt verkettete Liste angeforderter Block wird an Anfang der Liste verschoben Blocks am Ende der Liste wird entfernt, falls Speicher knapp alle 30s werden "verschmutzte" Blöcke auf die Platte geschrieben Zeichenorientiert: Streams = "Puffer" Zeilendisziplin "kocht" Zeichenstrom: entfernt gelöschte Zeichen, Tabs Roher Modus auch möglich

29 5. Ein-/Ausgabe: Netzwerk Sockets, sind wieder Dateien, werden automatisch erstellt 3 Typen: 1. Zuverlässiger, verbindungsorientierter Byte-Strom (Pipe, TCP) 2. Zuverlässiger, verbindungsorientierter Packet-Strom 3. unzuverlässige Packetübertragung (UDP) z.b. Streaming Sender erstellt Socket, führt listen() darauf aus -> Puffer wird erstellt und blockiert, bis Daten eintreffen Empfänger erstellt auch Socket, führt connect()aus -> Pipe

30 6. Dateisystem

31 6. Dateisystem: Konzepte Kein MIME-Orientiertes Dateisystem wie z.b. MacOS oder Windows 255 ASCII Zeichen lange Dateinamen, beliebig viele Erweiterungen alle Verzeichnisse unterhalb der Wurzel "/" -> keine "Laufwerke" Medien können in den Baum eingehangen (gemountet) werden Merkmale: Links, Locking (sperren von Dateien oder Teilbereichen)

32 6. Dateisystem: Linux-Dateisystem Dateien im Dateisystem werden durch Inodes verwaltet Ext2-Dateisystem: Einteilung der Partition in Blockgruppen jede Blockgruppe hat Superblock: Anzahl der Blöcke, I-Nodes Inode-Größe 128 Byte, ist Zeigertabelle auf Datenblöcke enthält 12 direkte Zeiger auf Datenblöcke und 3 indirekte direkte Datenblöcke: speichern 1KB Daten -> Dateien bis 12 KB können direkt gelesen werden (UNIX hat viele kleine Dateien) indirekte Datenblöcke verweisen wiederum auf Datenblocktabellen

33 6. Dateisystem: Windows NTFS: 255 Zeichen Unicode Dateinamen, Zeichen Pfad Dateien bestehen nicht aus linearen Sequenzen, sondern aus mehreren Streams: Name, Daten, Objekt-ID, geklaut von MacOS Anwendung: Bilddatei mit Datenstream und Thumbnail-Stream

34 6. Dateisystem: Windows MFT/Master File Table: 1KB Records, beschreibt eine Datei oder Verzeichnis, enthält Dateiattribute, ist selbst eine Datei, (= Inode) Dateiattribut "Data" verweist auf andere Plattenblöcke -> Streams kleine Verzeichnisse sind als Dateiliste mit Head im MFT gespeichert große V. sind als B-Bäume implementiert Daten: direkt im MFT, falls Datei < ~1KB Liste mit Blockadressen, falls Datei > ~1 KB für neue größere Dateien werden mehrere Blöcke angefordert -> Datei kann sequentiell auf Platte geschrieben werden, ein Record beschreibt einen zusammenhängenden Bereich von Blöcken

35 7. Sicherheit

36 7. Sicherheit in UNIX mehrere Benutzer möglich, die sich per Passwort einloggen login hasht eingegebenes Passwort und vergleicht Hash mit dem in /etc/passwd -> Passwörter werden nicht im Klartext gespeichert ein Prozess läuft automatisch mit UID/GID des Benutzers -> mit setuid() und setgid() setzt sich login auf Benutzer -> startet Shell als der richtige Benutzer, alle anderen Prozesse erben UID/GID Dateisicherheit: getrennt für Besitzer, Gruppe, Andere: rwx Superuser (root) darf ALLES, auch best. Systemrufe ausführen Rechte gelten genauso für alle Spezialdateien (Geräte, Pipes) SETUID-Bit: Prozess läuft mit der UID des Besitzers (passwd)

37 8. Quellen [1] [2] [3] Textquelle: Andrew S. Tannenbaum: Moderne Betriebsysteme