SystemCall

Im SystemCall Podcast beschäftigen wir uns mit aktueller Betriebssystemforschung. In der vierten Folge diskutieren wir SGX, also die Software Guard Extentions von Intel, deren Funktionsweise, eine Anwendung im Bereich der Function as a Service und eine Attacke, die das Sicherheitssystem von SGX aushebelt.

Zunächst besprechen wir, wie SGX funktioniert, erklären die Konzepte der Enklave, also des geschützten Speicherbereichs, der selbst vor dem Betriebssystem gesichert sein soll. Die Enklave kann selbst über das Netzwerk durch Remote Attestation geprüft werden, also dass genau der erwartete Code richtig geladen worden ist.

Clemmys ist ein auf Apache OpenWhisk basierendes System, welches mithilfe von SGX Enklaven Functions as a Service implementiert. Mit einer FaaS-Architektur können Anwendungen preiswert umgesetzt werden, die manchmal relativ viel Rechenzeit brauchen, bspw. weil Daten angekommen sind, oftmals aber nicht gebraucht werden. Dann werden dynamisch neue Funktionen aufgezogen, die die Daten verarbeitet, und danach wieder pausiert. Mit Clemmys werden beim Erhalt der Daten diese in einer Enklave verschlüsselt, der Anbieter macht dann Lodabalancing und Abrechnung und sendet diese verschlüsselten (und damit nicht veränderten) Daten an unsere Funktion weiter, die diese auspacken und bearbeiten kann.

Mit SGAxe und dem Vorgängerpapier CacheOut diskutieren wir dann einen Angriff auf die Enklaven. SGX schließt in seinem Angreifermodell Seitenkanäle aus, weshalb sich der Enklavencode selbst darum kümmern soll, ebendiese zu schließen und keine Angriffsfläche zu bieten. In SGAxe gelingt es dann den Sealing-Key der Enklaven zu leaken, die für die Remote Attestation zuständig sind und von Intel geliefert werden. Dadurch gelingt es, beliebige Enklaven, auf beliebig bösartigen Simulatoren zu bescheinigen, dass sie (andere) Enklaven auf echten Intel-Prozessoren sind.

B. Trach, O. Oleksenko, F. Gregor, P. Bhatotia, and C. Fetzer. Clemmys: towards secure remote execution in FaaS. 12th ACM International Conference on Systems and Storage (SYSTOR '19), 2019, New York, NY, USA, pg. 44–54. DOI: 10.1145/3319647.3325835

S. van Schaik, M. Minkin, A. Kwong, D. Genkin and Y. Yarom, CacheOut: Leaking Data on Intel CPUs via Cache Evictions, 2021 IEEE Symposium on Security and Privacy (SP), 2021, pp. 339-354, DOI: 10.1109/SP40001.2021.00064

Wir beschäftigen uns im SystemCall Podcast mit aktueller Betriebssystemforschung. In dieser dritten Folge sprechen wir mit Andreas Ziegler von der FAU in Erlangen über seine Forschung am Undertaker, em Totengräber für #ifdefs und das Schreckgespenst für den Kconfig Kernelkonfigurator. Außerdem haben wir noch das Papier "BlankIt Library Debloating" mitgebracht, was sich mit der Reduktion von Angriffsfläche für Return-Oriented-Programming (ROP) zur Laufzeit beschäftigt.

Der Undertaker erlaubt das Parsen von Konfigurationsdateien des kconfig Buildsystems vom Linux Kernel, sodass einzelne Stellen betrachtet werden können unter dem Gesichtspunkt, welche Konfigoptionen an- bzw abgeschaltet sein müssen, damit diese Zeile im Kernel landet. Über lange SAT-Formeln kann so auch ermittelt werden, ob es sich ausschließende oder immer wahre Optionskombinationen gibt. Mithilfe des Grundgerüsts erklärt Andreas, wie er durch Tracing ein minimales System für den getesteten Anwendungsfall generiert hat, und welche Ergebnisse dabei erzielt worden.

BlankIt: Library Debloating beschäftigt sich mit dem ausblenden von dynamisch nicht gebrauchten Bibliothekscode. Das trägt zwar nicht zur Minimierung des Diskplatzes bei, wie bspw. beim Undertaker der Fall, dafür aber minimiert das die Anzahl möglicher ROP-Gadgets. Als ROP (Return-Oriented-Programming) bezeichnet man die Ausführung und Kombination von einzelnen Codestellen durch bewusste Stackmanipulation und zur Stackmanipulation durch Returns.

Vorab werden Pfade durch den Code ausgewertet und mittels eines Machine Learning Modells ermittelt, welche Funktionen anhand des dynamischen Kontexts gebraucht werden. Bei jedem Funktionscall in eine Library werden die gebrauchten Funktionen eingeblendet, also wieder in den Speicher geschrieben, beim Zurückkehren werden die Stellen wieder überschrieben.

Am Ende noch eine Leseempfehlung zum Thema Binary Rewriting, also dem Umschreiben von Binärdateien, ohne Zugriff auf den eigentlichen Source Code. Im Survey From Hack to Elaborate Technique - A Survey on Binary Rewriting werden mögliche Ansätze und Schritte strukturiert dargestellt und mit Quellen versehen. Das Paper ist dadurch gut zu lesen und verständlich.

Reinhard Tartler, Daniel Lohmann, Julio Sincero, and Wolfgang Schröder-Preikschat. 2011. Feature consistency in compile-time-configurable system software: facing the linux 10,000 feature problem. In Proceedings of the sixth conference on Computer systems (EuroSys '11). Association for Computing Machinery, New York, NY, USA, 47–60. DOI: doi.org/10.1145/1966445.1966451

Kurmus, A., Tartler, R., Dorneanu, D., Heinloth, B., Rothberg, V., Ruprecht, A., Schröder-Preikschat, W., Lohmann, D. and Kapitza, R., 2013. Attack Surface Metrics and Automated Compile-Time OS Kernel Tailoring. In NDSS.

Ruprecht, A., Heinloth, B. and Lohmann, D., 2014. Automatic feature selection in large-scale system-software product lines. ACM SIGPLAN Notices, 50(3), pp.39-48. DOI: doi.org/10.1145/2775053.2658767

Chris Porter, Girish Mururu, Prithayan Barua, and Santosh Pande. 2020. BlankIt library debloating: getting what you want instead of cutting what you don’t. In Proceedings of the 41st ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI 2020). Association for Computing Machinery, New York, NY, USA, 164–180. DOI: doi.org/10.1145/3385412.3386017

Matthias Wenzl, Georg Merzdovnik, Johanna Ullrich, and Edgar Weippl. 2019. From Hack to Elaborate Technique—A Survey on Binary Rewriting. ACM Comput. Surv. 52, 3, Article 49 (July 2019), 37 pages. DOI: doi.org/10.1145/3316415

Wir beschäftigen uns im SystemCall Podcast mit aktueller Betriebssystemforschung. In der zweiten Sendung diskutieren wir mit "SkyBridge: Fast and Secure Inter-Process Communication for Microkernels" eine Idee zur Beschleunigung von Interprozesskommunikation für Mikrokernel und sprechen über "NrOS: Effective Replication and Sharing in an Operating System", ein Konzept für effektives Teilen von Datenstrukturen auf Manycore-Non-Uniform-Memory-Access Maschinen.

SkyBridge ist auf der EuroSys'19 erschienen und diskutiert einen Ansatz um Interprozesskommunikation zu beschleunigen. Die Performance eines Microkerns leidet sehr darunter, dass viel Funktionalität in vielen spezialisierten, abgekapselten Prozessen stattfindet und die Kommunikation nur über IPC durch den Kern möglich ist. Zunächst werden die Faktoren der Entschleunigung benannt und gemessen. So identifizieren sie die direkten Kosten (syscall, page tables wechseln, privilegien prüfen, sysexit), aber auch die indirekten Kosten (Verschmutzung der Caches).

Die Autoren stellen dann eine Möglichkeit für synchrone Kommunikation vor, die die Schutzdomänen mithilfe der VT-x Erweiterung von Intel Prozessoren wechselt. Dabei wird ein Hypervisor eingeführt, der das 2-Stage Adress Translation in der Hand hält. Durch bestimmte vmfunc-Instruktionen können die Extended Page Tables (EPT) aus dem Usermodus heraus umgeschaltet werden, sodass die Guest-Physischen Adressen nun auf andere Host-Physischen Adressen zeigen. Das wird benutzt um von den Client Page Tables zu den Server Page Tables zu springen.

nrOS (OSDI'21) ist ein Ansatz um in Systemen mit sehr vielen Prozessoren, sog. Manycore Systemen, effektiv Datenstrukturen zu teilen. In Non-Uniform-Memory-Access-Systemen (NUMA-Systmen) ist zwar der gesamte Speicher zugreifbar, aber nur ein Teil davon für bestimmte Prozessoren "nah", also schnell erreichbar. Anderer Speicher ist für andere Prozessoren näher.

Jede NUMA-Node hat ein Duplikat der Datenstruktur, bspw. der Page Tables. Änderungen daran werden pro NUMA-Node durch einen einzigen Thread durchgeführt (den Combiner), der alle Änderungen auch ins Operational Log(buch) schreibt. Die Änderungen werden in Realzeit später auf den anderen Knoten nachgezogen. Lesezugriffe durch den Prozessor bei Speicherzugriffen sind somit schnell, weil sich die Daten in "nahem" Speicher befinden. Allerdings kann es passieren, dass wir veraltete Daten lesen und Pagefaults erhalten. Dann werden im Pagefault-Handler zunächst alle Änderungen nachgezogen.

Zeyu Mi, Dingji Li, Zihan Yang, Xinran Wang, and Haibo Chen. 2019. SkyBridge: Fast and Secure Inter-Process Communication for Microkernels. In Proceedings of the Fourteenth EuroSys Conference 2019 (EuroSys '19). Association for Computing Machinery, New York, NY, USA, Article 9, 1–15. DOI: https://doi.org/10.1145/3302424.3303946

Weitere Referenzen:

Bhardwaj, Ankit, Chinmay Kulkarni, Reto Achermann, Irina Calciu, Sanidhya Kashyap, Ryan Stutsman, Amy Tai, and Gerd Zellweger. 2021. NrOS: Effective Replication and Sharing in an Operating System. In 15th USENIX Symposium on Operating Systems Design and Implementation (OSDI 21), 295–312.

Im SystemCall Podcast diskutieren wir aktuelle Themen in der Betriebssystemforschung. In der ersten Folge besprechen wir "A fork() in the Road", ein Diskussionspapier über den Systemruf fork und "Instant OS Updates via Userspace Checkpoint-and-Restart", in dem eine Möglichkeit dargestellt wird, den Betriebssystemkern auszutauschen, und die Downtime der Nutzeranwendungen gering zu halten.

In "A fork() in the Road" (HotOS'19) diskutieren die Authoren Baumann et al. den Systemruf fork. fork ist in Unix fast die einzige Möglichkeit einen neuen Prozess zu erzeugen. Dabei wird der gesamte Elternprozess kopiert, also sowohl der Adressraum, wie auch andere Kernobjekte, wie Dateideskriptoren. Daraus entstehen neue Probleme, die bei der erste Implementierung von fork in den 1970ern nicht bedacht worden sind. Baumann et al. sprechen sich dafür aus, fork als deprecated zu markieren, in neuem Code nicht mehr zu verwenden, und aus altem Code zu entfernen.

"Instant OS Updates via Userspace Checkpoint-and-Restart" verwendet Checkpoints for die Userspace Anwendungen um den Speicherinhalt bspw. für in-memory Datenbanken oder Caches über Kernwechsel hinaus zu erhalten, indem sie nach dem Restart wieder vom Kontrollpunkt gestartet werden. Dafür verwenden sie CRIU (Checkpoint-and-Restart in Userspace), eine Anwendung für das Ziehen von Kontrollpunkten für Linux. Weiter beschreiben Sie Verbesserungen im eigentlichen Umschalten zwischen den beiden Kernels durch kexec und besprechen auch Optimierungen im Ziehen und Wiederherstellen der Kontrollpunkte unserer eigentlichen Payload-Anwendungen.

Am Ende diskutieren wir kurz die aktuelle Forschung von Florian Rommel, der sich mit Adressräumen auseinander gesetzt hat und dem Wartefreien Aktualisieren von Nutzeranwendungen. Dafür wurde das Prozesskonzept von Linux derart erweitert, dass ein Prozess mehrere Adressräume beinhalten kann, zwischen denen ein Thread mehr oder weniger beliebig wechseln kann. Für das Update wird ein neuer Adressraumklon erstellt und die Änderung im neuen Adressraum vorgenommen. Änderungen von Thread in dem alten Adressraum werden auch in den neuen gespiegelt. Wenn die Threads das für angebracht halten, also wenn sie in einem sicheren Zustand sind bspw. am Ende der Abarbeitung einer Anfrage, wechseln sie in die neue Welt und arbeiten fortan auf der aktualisierten Fassung der Anwendung. Das Papier wurde auf der OSDI'20 vorgestellt.

Andrew Baumann, Jonathan Appavoo, Orran Krieger, and Timothy Roscoe. 2019. A fork() in the road. In Proceedings of the Workshop on Hot Topics in Operating Systems (HotOS'19). Association for Computing Machinery, New York, NY, USA, 14–22. DOI: https://doi.org/10.1145/3317550.3321435

Kashyap, Sanidhya, et al. "Instant OS Updates via Userspace Checkpoint-and-Restart." 2016 USENIX Annual Technical Conference (USENIX ATC'16). 2016.

Florian Rommel, Christian Dietrich, Daniel Friesel, Marcel Köppen, Christoph Borchert, Michael Müller, Olaf Spinczyk, and Daniel Lohmann. From Global to Local Quiescence: Wait-Free Code Patching of Multi-Threaded Processes. 14th Symposium on Operating System Design and Implementation (OSDI '20). 2020.