Betriebssystemtechnik 7.5 ECTS Prüfung 2023-07-24

• Fach: Betriebssystemtechnik 7.5ECTS, SS 23
• Datum: 24.07.2023
• Prüfungsart: mündlich
• Prüfer/Beisitzer: Volkmar/Phillip
• Note: Sehr gut
• Vorbereitung
  • 3-4 Tage Vorbereitung, war allerdings auch in den Vorlesungen (was beim initialverständnis der Folien gut geholften hat). Hauptsächlich habe ich mir eine Zusammenfassung geschrieben und alte Protokolle (auch wenn von anderen Prüfer (wosch)) durchgearbeitet.
• Evaluation
  • Prüfung war eher ein entspanntes Gespräch
  • An manchen Stellen haben wir gefühlt etwas aneinander vorbei geredet - Volkmar wollte auf etwas anderes hinaus, während ich einen anderen möglichen Ansatz präsentierte
  • Am Anfang sollte man frei etwas erzählen - sobald man dann elaboriert hat, gings dann sehr schnell in die Tiefe der Themen
  • Fragen gingen doch sehr tief, auch bis auf Assembler-Ebene (Beispiel: PIC) musste man Zusammenhänge wissen

* Jo, Einadressraumsysteme, was sind das?

Kurz die Definiotion erklärt. War ihm zu wenig, ich sollte dann also noch etwas ausschweifen. Das Thema hab ich dann anhand der Unauffindbarkeit von Adressen, TLB-Flushes und IPC motiviert.

* Du hast nun unter anderem „Capabilities“ erwähnt. Was genau sind denn das?

Anhand von send() erklärt, dass man ggf. nicht will das der Empfänger den Sender-Buffer modifiziert. Sender muss beim BS sich eine neue virtuelle Adresse erzeugen, auf der nur Leserechte gelten, die dann weiter gegeben werden kann.

* Das reicht jetzt gegebenenfalls nicht aus. Wieso und was kann man da noch tun?

Der Objekterverwalter (also der Sender-Benutzerprozess) kann zusätzlich noch ein Passwort definieren, welches dann mit der Adresse mit geschickt wird. Durch z.B. ein XOR kann dann die richtige Adresse erzeugt werden.

* Kann man Capabilities auch wieder weg nehmen?

Ja, das ist zwar problematisch mit den Ewig gültigen Adressen, aber man kann über das BS natürlich das Mapping wieder aufheben.

* Wenn das SASOS jetzt so toll ist, wieso macht das denn heutzutage keiner?

Auf x86 hat man z.B. keine echten 64-Bit (virtuellen) Adressen, sondern nur 48 bzw. 52 Bit-Adressen. Somit dauert das Durchsuchen jetzt nicht mehr ~500 Jahre, sondern geht viel viel schneller.

* Praktisch gesehen, ja. Aber angenommen die Adressbreite wäre jetzt kein Problem, was gibt es denn sonst für Gründe?

Die guten „Altlasten“ aka Legacy Code - z.B. fork verlangt eine Mehrdeutigkeit von Adressen - ist bei einem SASOS aber nicht ohne weiteres möglich.

* Jo, wie könnte man denn ein fork auf einem SASOS implementieren?

Man braucht Position-Indipendent-Code (PIC). Hier habe ich zuerst erklärt dass man das Code-Segment nicht unbedingt duplizieren muss, ist aber falsch, da PIC auf dem Instruction-Pointer aufbaut. Man muss also das Code-Segment kopieren, dann funktionieren auch PIC-Daten.

* Okay, und was ist mit den return-Adressen?

Die return-Adressen muss man jetzt natürlich auch alle anpassen, diese liegen ja auf dem Stack. Würde man das nicht tun, würde der Kind-Prozess einfach wieder in den Elternprozess springen und dann wäre wieder alles kaputt. Auf sein Nachhaken, wie genau das funktioniert habe ich erklärt, dass man diese vielleicht relativ zu einer Basisadresse berechnen kann - allerdings würde dann call und ret nicht mehr so einfach funktionieren. Wir haben uns darauf geeinigt, dass es einfach viel Betriebssystemseitiger Mehraufwand ist.

* Und was ist mit dem Stack?

Man muss im Prozesskontrollblock einen neuen top-of-stack verwenden, damit der Stack woanders liegen kann. Hier bin ich kurz darauf ausgeschweift, dass auch heutzutage der Stack oft randomisiert wird, um vor Schadsoftware zu schützen. Im Grunde genommen ist das aber nicht kritisch, da push-pop ja immer relativ zum Stackpointer ist, d.h. man muss effektiv den Stackpointer im Kindprozess in den neu erzeugten Stack setzen.

* Okay, was für ein System-Call fällt dir denn noch ein, der in einem SASOS kritisch wäre?

Der gute mmap-Syscall. Damit kann man sich große Brocken an virtuellen Speicher allozieren. Schlägt dies fehl, weiß man aufgrund der ewigen Adressen, dass dort ein Speicherbereich eingeblendet sein könnte. Man kann jetzt rekursiv im Buddy-Verfahren weiter suchen, und die Region immer weiter eingrenzen. D.h. man kann innerhalb von Sekunden dann Speicher finden.

* Okay, in StuBS habt dir das ja irgendwie anders gelöst. Wie genau?

Wir haben partiell private Adressräume verwendet. Kurz geschildert dass jeder Prozess einen eigenen Adressraum hat, indem auch das BS eingeblendet ist, welches dann auf die Nutzerdaten zugreifen kann.

* Joa, das verschwendet jetzt aber schon viel Speicher. Kann ich das auch irgendwie besser machen?

Hier wusste ich nicht genau worauf er hinaus will.

* Angenommen, man hat jetzt z.B. eine Grafikkarte, diese möchte man jetzt für den Kernel einblenden, aber in zwei Prozessen. Wie genau geht das?

Naja, man muss halt in jedem Prozess die Mappings anpassen. Wusste immer noch nicht ganz worauf er hier hinaus will.

* Ich behaupte das geht auch einfacher.

Hier hab ich dann versucht herauszufinden was genau er hören will. Zuerst hab ich dann einen Zugriff ohne gemappte Page durchgespielt. Im Pagefault-Handler könnte man dann evtl. eine Behandlung einbauen, dann muss man die Seite nicht in beiden Prozessen mappen.

* Ja, das würde in der Theorie zwar auch funktionieren, aber es geht noch leichter.

???

* Als Tipp: Ihr habt ja eine mehrstufige Seitenhierarchie.

Ah, muss natürlich nicht zwei Mappings erzeugen, sondern es reicht eins, z.B. erst ab der 2. Page-Stufe. Dann trägt man dieses gemeinsame Mapping einfach in beiden Page Tables ein.

* Genau. Was kann den hier allerdings problematisch werden?

Wenn ein Prozess jetzt die GraKa ausblendet, darf die Tabellenhierarchie nicht einfach freigegeben werden, da ein anderer Prozess sie ja noch benötigt. Über einen Referenzzähler kann man dann Buch führen, wie viele Pages noch die Seite eingeblendet haben, der letzte blendet sie dann aus.

* Okay! Nehmen wir nun einmal an, wir haben mehrere Threads im selben Adressraum. Warum ist denn das unmap() problematisch?

Wegen den TLBs. Jeder Prozessor hat seinen eigenen TLB, wenn wir jetzt allerdings das Mapping verändern sind auf anderen Prozessoren TLB und Page-Tabelle nun inkonsistent.

* … und die Lösung ist?

Man kann es mit fences machen…

* Nein.

Okay, dann müssen wir es mit Inter-Process-Interrupts (IPI) lösen. Wenn jetzt ein Prozess eine Seite ausblenden will, sendet dieser einen IPI an alle anderen Prozessoren, diese müssen ggf. die Seite aus ihrem TLB flushen. Allerdings kann es hier zu einer Race-Condition kommen.

* Und wie behebt man diese Race-Condition?

Hier haben wir etwas aneinander vorbei geredet. Im Grunde genommen wollte er, dass ich ihm alle Schritte sage, die man hier durchführen muss, während ich ihm erklärt habe, wie das mit den IPIs von statten gehen soll. Es muss das Mapping angepasst werden, der Unmap-Prozess schickt dann IPIs an andere Prozessoren, die flushen entsprechend ihren TLB-Eintrag und schicken ein IPI zurück. Es muss auf alle Antworten gewartet werden, erst dann darf die Seite wieder in der Freispeicherverwaltung eingeblendet werden.

* Okay, dann ist auch schon die Zeit um!