Prüfer: Wosch
Beisitzer: Bernhard
Zwei direkt aufeinanderfolgende Prüfungen, die sehr ähnlich waren, deshalb nur ein Protokoll. Wosch stellt jeweils Fragen (und redet gern auch mal zwischendurch etwas länger überleitend, davon nicht irritieren lassen) und Beisitzer schreibt mit.
Verlauf
F: Warum brauchen wir überhaupt System Calls?
A: Wir wollten ja Adressräume trennen, und damit braucht man auch Privilegientrennung, damit nur das Betriebssystem die Möglichkeit hat Adressraumänderungen zu machen. Um weiterhin Dienste (über Aufrufe) bereitstellen zu können brauchen wir dann eine neue Schnittstelle → System Calls.
F: Wie sind die Implementiert?
A: int 0x80, syscall/sysenter, letzteres 2-3 mal so schnell. parameterübergabe in registern
F: *malt kästchen: user-instruktionen, platz vor und nach dem INT und kernel sowie jeweils stack und CPU-register* was passiert da wann wie?
A: parameter vom C-artigen aufruf (übergabe stack) in die register schieben, INT, kernel packt register wieder auf den stack und ruft behandlungs-C-funktion auf.
F: warum macht man da immer den umweg über register, das ist doch langsam? kann der kern nicht direkt vom userstack parameter holen?
A: muss man halt zusätzlich user-stackpointer validieren vorher, bei rein privaten adressräumen sowieso kein direkter zugriff möglich (→ dann spezialbefehle oder fenster)
F: warum pusht man das im kernel alles nochmal?
A: damit man den kernelzustand nicht preisgibt will man später alle register wiederherstellen, und damit der systemcall-handler selbst wieder wie eine C-funktion aufgerufen werden kann
F: partiell privat/vollst. privat adressraum, was ham wir implementiert
A: stubsmi partiell privat, d.h. der kern ist immer (mit supervisor-mode-bit) in den anwendungen eingeblendet → performanter weil kein adressraumwechsel beim syscall
F: wie holt sich das BS die parameter in den beiden fällen?
A: spezialbefehle/fensterbasiert einblenden, oder beim partiellen einfach hin langen
F: der memory management-code is ja fast der gleiche, warum wird der private teil trotzdem als sicherer angesehen?
A: linux: 75% treiber, muss nicht alles perfekt sein/fehler kommen halt vor, im komplett privaten kann der kernel da nix kaputt machen aus versehen
F: einadressraumsysteme, how do they work?
A: alles in einem, sharing durch adressen weitergeben
F: braucht's da immer noch ne MMU?
A: ja, weil physikalischer speicher begrenzt/adressübersetzung nötig
F(Prüfung 1): muss der TLB in dem fall noch rein in hardware implementiert sein?
A: ne, braucht man an sich für die übersetzung, aber man hat ja keine umschaltung mehr, per software programmierbar potentiell sogar besser
F: MMU nur noch adressraumverwaltung, wie rechteverwaltung?
A: stichwort „capabilities“, z.B. „nur lesen und nicht an andere weitergeben“