Verlauf

P: In Stubsmi wurden als allererstes Systemcalls eingebaut, warum?
S: Bis dahin liefen Nutzerprogramme auf der Kernelebene. Es ist besser sie auf Ring 3 laufen zu lassen und Hardware-Zugriffe etc. nur über Systemcalls zu erlauben.

P: Wie wurden die Syscalls in BST implementiert?
S: Mit Interrupts, aber man kann es auch anders machen.

P: Wie denn?
S: Mit Spezialbefehlen, die schneller sind, weil sie weniger Kontext sichern.

P: Warum waren denn die Syscalls nötig? Was musste konkret als Sysclal implementiert werden?
S: Z.B. Gerätezugriffe.

P: Ob Nutzerprozesse auf das Terminal zugreifen ist nicht so wichtig. Ich meine das im Bezug auf Speicher.
S: Nutzerprozesse sollten nicht selbst neuen Speicher mappen können.

P: Aber eine Heapverwaltung lässt sich doch auch im Usermode machen. Welche Hardware macht denn Speicherverwaltung?
S: Die MMU macht das Paging.

P: Wie wird die programmiert?
S: Man setzt eine Page Directory.

P: Und wie macht man das?
S: Man setzt die Pagedirectory in einem Register.

P: Genau, das ist eine Art Spezialbefehl.
S: Achso, ja, es gibt Befehle, die nur im priviligierten Modus ausgeführt werden dürfen. (Darauf wollte er eigentlich hinaus)

P: Wie werden bei Syscalls die Parameter übergeben?
S: Bei uns über Register.

P: Und wer entscheidet welche Register verwendet werden?
S: Das Betriebssystem.

P: Welche Register sollten denn verwendte werden?
S: Am besten Caller-saved Register, die sowieso schon vom Stub-Aufrufer gespeichert werden.

P: Warum werden im Dispatcher alle Register gespeichert, auch wenn sie keine Parameter enthalten?
S: Es müssen auch Calle-Saved Register gespeichert werden. Der Stub weiß nicht, dass er mit dem Interrupt eine Art Functioncall auslöst. (Das war nicht richtig)

P: Das ist es nicht. Wie ist das denn mit dem Datenfluss der flüchtigen Register?
S: Die werden doch von aufgerufenen Funktionen auch gesichter. (Das war nicht richtig, ich wusste nicht, was er meint)

P: Nein, eigentlich nur beim Kontextwechsel. Was passiert denn, wenn eine in der Kernel aufgerufene Funktion flüchtige Register verwendet
und sie werden im Dispatcher nicht gesichert und wiederhergestellt?
S: Achso, dann kann der Nutzerprozess sie auslesen und hat Zugriff auf irgendwelche Kerneldaten.

P: Warum werden die Parameter nicht einfach vom Nutzerstack gelesen? Über die Register gibt es viel Indirektion.
S: Weil das Betriebssystem eigentlich nicht auf den Nutzerstack zugreifen können sollte. Es könnte sonst etwas kaputt machen.
Allerdings ist es meistens trotzdem eingeblendet, weil partiell private Adressräume verwendet werden.

P: Wie sehen die aus?
S: Das Betriebssystem ist in den Anwendungsadressraum eingeblendet, aber auf einer höheren Privilegienebene, sodass die Anwendung nicht auf den Bereich zugreifen kann.
Bei Syscalls muss dann nicht der Adressraum gewechselt werden und es geht schneller.

P: Was sieht dann das Betriebssystem?
S: Das sieht auch den Adressraum der aktuellen Anwendung.

P: Warum macht man das und was sind die Nachteile?
S: Man möchte möglichst selten den TLB flushen. Es ist aber gefählrich, weil ein fehlerhafter Kernel-Prozess die Anwendung kaputt machen kann.

P: Was ist die Alternative?
S: Komplett private Adressräume. Das Betriebssystem hat einen eigenen Adressraum, zu dem bei Syscalls gewechselt wird.
Das ist langsamer aber sicherer und hilft z.B. bei Meltdown.

P: Warum ist das sicherer?
S: Weil das Betriebssystem dann explizit Bereiche des Anwendungsadressraumes einblenden muss.

P: Was gibt es denn noch für ein Adressraummodell?
S: Das Einadressraummodell. Das funktioniert wenn man einen sehr großen Adressbereich hat, wie 64 Bit.
Der ist so groß, dass eine Anwendung durch Ausprobieren von Adressen praktisch nie eine anderen Adressraum finden kann.
Eine Anwendung hat dann Zugriff auf einen Speicherbereich, wenn es seine Adresse kennt.

P: Braucht man dafür eine MMU?
S: Ja, ansonsten hätte man nur den realen Adressraum, der viel kleiner ist. Nur mit MMM wird es aber problematisch beim Sharing und es ist nur Security by Obscurity.
Idealerweise werden die Speicherbereiche über Capabilities verwaltet. Ansonsten kann ein Prozess, der eine Adresse aus seinem Speicherbereich einem anderen Prozess mitteilt, von ihm manipuliert werden.

P: Capabilities sind aber mehr als Adresse.
S: Ja, sie repräsentieren das Recht auf einen Adressbereiche zuzugreifen.