Sie befinden sich hier: Termine » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Lehrstuhl 4 » BST 2016-10-05   (Übersicht)

BST 2016-10-05

Fach: Betriebssystemtechnik (5 ECTS)

Prüfer: wosch

Beisitzer: Christian Dietrich

Prüfung dauerte deutlich länger als die offiziellen 20 Minuten, eher 30. Generell steigt wosch auch nach richtigen Antwort immer wieder in längere Erklärungen ein, um das Gesagt nochmal aus einem anderen Blickwinkel zu erläutern oder zur nächsten Frage überzuleiten. Papier und Stift liegen bereit und werden auch genutzt (v.a. von wosch selbst).

Fragen

F: Systemaufrufe – was, warum, wie?

A: Privilegiertes Betriebssystem und unprivilegierte Anwendungen, die seine Funktionen nutzen wollen. Heutzutage üblicherweise Interrupt, um in privilegierten Modus zu wechseln.

F: Wie funktioniert das z.B. bei Linux genau?

A: Syscall-Stub als normale Bibliotheksfunktion, die Syscall-Nummer als Parameter speichert und den Interrupt durchführt. Im Interrupt-Handler ein Zuteiler mit Jump-Table, der dann die Betriebssystemfunktion aufruft.

F: (Malt Grafik mit zwei Seiten und Registerfile in der Mitte.) Wie werden denn hier die Parameter übergeben?

A: Anhand normaler Calling-Convention zum Stub, dieser legt sie in Register (wenn sie dort nicht eh schon liegen).

F: Was ist, wenn sie dem Stumpf eh schon in Registern übergeben werden? Müssen wir dann wirklich nichts tun?

A: Sie sollten schon auch in den richtigen Registern liegen, also wohl doch.

F: Wer legt die Register für Syscalls nämlich fest?

A: Das Betriebssystem.

F: Vor den Betriebssystemfunktionen steht ja häufig asmlinkage – zumindest in den alten Kernel-Versionen, die ich so kenne… steht das in neuen eigentlich immer noch?

Beisitzer: Weiß nicht, den Teil schau ich mir nicht so oft an.

F: Jedenfalls, was tut das denn?

A: Ich schau mit den Teil auch nicht so oft an, aber es hat wohl was mit Registerübergabe zu tun. Also entweder über Register oder über den Stack, ansich ginge bei Assembler ja auch beides.

F: Ja, es werden dann alle Parameter über den Stack übergebn. Was gibt es denn noch für alternative Möglichkeiten für Syscalls?

A: Spezialbefehle, sysenter/sysexit.

F: Gut, da ist die Parameterübergabe ja genauso; muss ich auch irgendwie über Register machen. Ich mein jetzt im Bezug auf Parameterübergabe.

A: Indem das Betriebssystem sie vom User-Stack holt.

F: Gut, aber ich mein grundlegend für Syscalls. Bisher hatten wir ja den Primitivbefehl, wie geht der Komplexbefehl?

A:

F: Aha, Vorlesungsfolien wohl nicht gelesen. Was verarbeitet denn so ein Prozessor?

A: Doch, eigentlich schon; einen Befehlsstrom.

F: Aha. Und was können wir damit für Syscalls machen?

A: Spezialinstruktionen für einzelne Syscalls?

F: Nee, nicht in Hardware. Es geht bloß um die Parameter.

A: Ja, man kann sie im Befehlsstrom enkodieren. So langsam dämmert es.

F: Und welche Einschränkung hat man damit?

A: Müssen statisch sein und zur Compile-Zeit feststehen.

F: Genau. Nochmal zurück zum Primitivbefehl, wodurch ist da die Anzahl der Parameter begrenzt?

A: Durch die Anzahl der Register.

F: Und was machen wir, wenn wir mehr haben?

A: Geht halt nicht.

F: Bei Linux geht es aber ja doch!

A: Ja, dann müssen wir doch wieder den Stack zu Hilfe nehmen und das Betriebssystem muss auf den User-Stack zugreifen.

F: Ja, irgendwie anders jedenfalls. Jetzt müsste das Betriebssystem ja auf den Benutzer-Adressraum zugreifen, geht das denn so einfach?

A: Kommt drauf an, Exklusions-/Inklusionsmodell. Beim Inklusionsmodell kann der Kernel einfach auf den Adressraum des Users zugreifen.

F: Und andersherum?

A: Natürlich nicht, das wäre schlecht.

F: Und wie stellen wir das sicher?

A: Über entsprechende Einstellungen in der Page-Table mit Überprüfung durch die MMU.

F: Existiert der Kernel-Adressraum also für die Anwendungen?

A: Kann man unterschiedlich sehen, darauf zugreifen können sie zumindest nicht.

F: Ja, deshalb sage ich er existiert für sie auch nicht. Wir haben hier also einen Adressraum, der irgendwo geteilt ist (zeichnet ihn hin).

A: Ja, z.B. in der Mitte. Dann haben Kernel und Anwendungen jeweils nur noch halb so viel Platz.

F: Bei mir SP gehört?

A: Ja.

F: Welches klassische Adressraumkonzept aus SP haben wir hier?

A:

F: Ein Gatter/Fence. Wenn jetzt bei einem Systemaufruf ein Zeiger übergeben wird, kann der Kernel den einfachen verwenden oder muss er noch irgendwas prüfen?

A: Er sollte prüfen, ob es sich wirklich um eine User-Adresse handelt. Sonst könnte die Anwendung eine Kernel-Adresse übergeben und den Kernel dazu bringen, in seinem eigenen Adressraum Dinge zu tun.

F: Genau, und wie überprüft man das?

A: Adresse sollte auf der richtigen Seite der Grenze liegen.

F: Es muss ja keine einzige Grenze geben, die Bereiche können auch feiner gestreut sein. Wie prüfen wir das dann?

A: Über den entsprechenden Eintrag in der Page-Table, muss present und für User erlaubt sein.

F: OK, was ist denn das Exklusionsmodell?

A: Betriebssystem kann nicht einfach auf User-Adressraum zugreifen, Spezialbefehle oder Fenster.

F: Fenster, was bedeutet das?

A: Teil eines Benutzer-Adressraums wird im Kernel eingeblendet, um darauf zuzugreifen.

F: Wie macht man das technisch?

A: Bei x86 gibt es da z.B. das Extra-Segment…

F: Na gut, etwas moderner vielleicht. Wie macht man es heutzutage?

A: User-Seite wird in Kernel-Page-Table gemapped.

F: Und wie finde ich diese Seite?

A: Über die User-Page-Table.

F: Das sind ja jetzt alles Mehradressraumsysteme. Was gibt es denn noch?

A: Einadressraumsysteme.

F: Wie funktionieren die?

A: Es gibt einen großen gemeinsamen Adressraum für alle Prozesse und das Betriebssystem mit Berechtigungen für die einzelnen Teile.

F: Wie funktioniert denn da die Isolation?

A: Capabilities geben vor, welcher Prozess auf welche Adressbereiche…

F: Capabilities kommen erst im zweiten Schritt, Isolation geht auch ohne sie.

A:

F: Wir brauchen etwas, das quasi jeder aktuelle Rechner hat. Man könnte Einadressraumsysteme also heute implementieren.

A: Eine MMU?

F: Nee, hier nicht. Wir groß muss denn der Adressraum sein?

A: So groß, dass alles rein passt.

F: Gut, aber 2³² ist schon ganz schön groß. Muss er trotzdem größer sein?

A:

F: Was könnte ein böser Prozess denn tun, um das System außer Kraft zu setzen?

A: Allen Speicher allokieren.

F: Genau, dann ist für das Betriebssystem auch nichts mehr übrig. Der Adressraum muss also möglichst groß sein – wie lang würde der Angriff mit 64 Bit dauern?

A: Lange.

F: Genau, 500 Jahre – so lang läuft mein Rechner nicht. Worauf muss ich denn achten, wenn ich in einem Einadressraumsystem speicher vergebe?

A:

F: Es soll ja niemand erraten könne, was wo liegt? Wie mach ich es also?

A: Zufällig.

F: Genau, und die Capabilties kommen erst im Schritt danach für Lesen/Schreiben und ähnliche Rechte. So eine Capability zum Lesen und Schreiben kann ja von Prozess zu Prozess weitergegeben werden, ohne dass das Betriebssystem davon weiß. Wie geht das?

A: Ist ein Passwort. Wenn der Prozess die Rechte bei der Weitergabe einschränken möchte, ist es natürlich komplizierter.

F: Das Stichwort Passwort reicht mir schon.

Bewertung

Die Note ist so wie sie halt so ist, wenn man an zwei Stellen recht viel Hilfe gebraucht hat und den Rest sehr gut wusste. Schon fair.

Vorbereitung

wosch erwähnt in der ersten Vorlesung, dass man sich lieber auf die Übung konzentrieren solle, falls man nicht für Vorlesung und Übung Zeit hat. Hab ich nicht gemacht (war in Vorlesung und Übung) und würde ich für die Prüfung auch nicht empfehlen. Alles Relevante steht auf den Vorlesungsfolien, man sollte aber auch über die exotischeren Verfahren Bescheid wissen.

Neben meiner Zusammenfassung der Vorlesungsfolien bin ich nochmal den Code aus der Übung durchgegangen und hab mir das Vorgehen an kritischen Stellen rausgeschrieben (für die aus BST bekannten „Wie habt ihr das denn gemacht?“-Fragen). Das hat sich nicht gelohnt, hier kommt es stärker auf die theoretischen Modelle an. In der Zeit hätte ich lieber noch ein paar Prüfungsprotokolle gelesen, dann wär ich auf die Komplexbefehle für Syscalls wahrscheinlich gekommen.