SystemCall Archiv

In dieser dreizehnten Folge vom SystemCall haben wir nach langer Zeit Flo dazu bekommen, seine Dissertation vorzustellen. Zunächst wiederholen wir das Konzept des virtuelles Adressraums bzw. virtuellen Speichers. Dann erzählt Dr. Florian Rommel von der Hauptidee seiner Doktorarbeit: den Adressraumsichten. Dabei wird das Konzept eines virtuelles Adressraums, was eigentlich auf der Abstraktionsstufe "Prozess" arbeitet, erweitert um pro Thread verschiedene Adressräume möglich zu machen. Dadurch können Code- oder Datenseiten nur für bestimmte Threads ein- oder ausgeblendet werden.

Darauf aufbauend, beschreibt Flo zwei Anwendungen: Zunächst wird Laufzeit-Patching genauer beschrieben. Ziel ist es, eine Anwendung, die viel internen, non-persistenten Zustand hält, zu patchen ohne die Anwendung neu starten zu müssen und den Zustand zu verlieren. Bspw. bei Memcached kann das Sinn machen, weil das Wiederaufbauen der im Arbeitsspeicher gehaltenen Daten sehr lange dauern kann. Facebook berichtet bspw. von einem Zeitraum von Tagen eines verminderten Services, wenn sie Memcached Instanzen neu starten müssen. Hier wendet Flo die Adressraumsichten an. Bei einem Patch wird eine neue Sicht erstellt. Jetzt kann jeder Thread einzeln in die neue, gepatchte Sicht wechseln, wenn es ihm passt, also an einem wohldefinierten Punkt in seinem Programmcode, aber ohne sich mit den anderen Threads explizit abstimmen zu müssen.

Ein weitere Anwendung der Adressraumsichten ist das dynamische Debloating, bei dem Programmcode-Teile für jeden Thread einzeln überschrieben werden, um Angriffsfläche für u.A. ROP (return-oriented-programming) Angriffe zu reduzieren. Normalerweise muss Programmcode für den gesamten Prozess ausgeblendet werden, weil jeder Thread in einem Prozess den gleichen Adressraum sieht. In Flos Ansatz bekommt jeder Thread eine eigene Sicht und blendet sich selbst nur den Code ein, den er braucht. Das wird durch bestimmte Überprüfungen abgesichert, dass auch nur echter Anwendungscode andere Funktionen wieder einfügen darf, nicht etwa ein ROP-Angriff.

Links Dissertation: Address-Space Views: A Kernel Concept for Thread-Level Memory Polymorphism

Florian Rommel. Address-Space Views: A Kernel Concept for Thread-Level Memory Polymorphism. 2025. DOI: 10.15488/19722

PDF

Wait-Free Code Patching of Multi-Threaded Processes

Florian Rommel, Christian Dietrich, Birte Friesel, Marcel Köppen, Christoph Borchert, Michael Müller, Olaf Spinczyk, Daniel Lohmann. From Global to Local Quiescence: Wait-Free Code Patching of Multi-Threaded Processes. 2020. In OSDI'20.

PDF

Video

Thread-Level Attack-Surface Reduction

Florian Rommel, Christian Dietrich, Andreas Ziegler, Illia Ostapyshyn, Daniel Lohmann. Thread-Level Attack-Surface Reduction. 2023. In Proceedings of the 24th ACM SIGPLAN/SIGBED International Conference on Languages, Compilers, and Tools for Embedded Systems. DOI: 10.1145/3589610.3596281

PDF

Video

Scaling Memcache at Facebook

Rajesh Nishtala, Hans Fugal, Steven Grimm, Marc Kwiatkowski, Herman Lee, Harry C. Li, Ryan McElroy, Mike Paleczny, Daniel Peek, Paul Saab, David Stafford, Tony Tung, Venkateshwaran Venkataramani. Scaling Memcache at Facebook. 2013. In NSDI'13.

Usenix

Facebook Research

Intro-/Outrotheme

the_emergent

In der zwölften Folge vom SystemCall haben wir uns einen Gast eingeladen, den Promotionspreisträger der Fachgruppe Betriebssysteme der GI, Alexander Lochmann. Alex erzählt uns von seinem Dissertationsprojekt: dem LockDoc. Mithilfe des LockDocs kann auf Basis des Fehlerinjektionsframeworks FAIL* (Fail-Star) Lockingprobleme in Betriebssystemen feststellen, also Probleme bei denen es zu einer Race Condition kommen kann. Gegenseitiger Ausschluss wird verwendet, wenn es Nebenläufigkeit im System gibt, wodurch zwei Threads gleichzeitig auf die gleiche Datenstruktur zugreifen können und sich so ins Gehege kommen können.

Der Lockdoc zeichnet dabei Benchmarkläufe auf. Alle Objektallokationen werden aufgezeichnet, sowie Zugriffe darauf und Locking-Operationen. In einem zweiten Schritt werden daraus Hypothesen aufgestellt, wie bestimmte Member von Objekten vermutlich gesichert sind, also welche Locks gehalten werden sollten um den Zugriff abzusichern. Dazu werden die gezählten Lockingmuster analysiert und eine Hypothese über dem Threshold ausgewählt. Der Lockdoc kann dann dafür benutzt werden, echte Bugs zu finden, Dokumentation zu bestätigen oder zu generieren.

Alex berichtet auch über seine Erfahrungen im Austausch mit den Linux-Kernel Entwickler*innen über die gefundenen Probleme und die dort aufgedeckten Ausnahmen, die er lieber keinem*r Studierenden zeigen würde.

Der SystemCall ist ein Podcast über Betriebssystemforschung.

Links Dissertation: Aufzeichnunsbasierte Analyse von Sperren in Betriebssystemen

Alexander Lochmann. Aufzeichnungsbasierte Analyse von Sperren in Betriebssystemen. 2021. DOI: 10.17877/DE290R-22500

PDF

Paper

Alexander Lochmann, Horst Schirmeier, Hendrik Borghorst, Olaf Spinczyk. LockDoc: Trace-Based Analysis of Locking in the Linux Kernel. In EuroSys'19. ACN, New York, Article 11, 1–15. DOI: 10.1145/3302424.3303948

ACM

Vorträge bei der Fachgruppe

Alexander Lochmann, Horst Schirmeuer. Beastie In For Checkup: Analyzing FreeBSD with LockDoc. 2021. Tagungsband des Fachgruppe Betriessysteme Herbsttreffens 2021. DOI: 10.18420/fgbs2021h-04

GI

Soundeffekte

Modem Einwahl

Dialing Tone

Intro-/Outrotheme

the_emergent

In dieser elften Folge des Systemcalls geht es um das CHERI Capability Model als Speicherschutzmechanismus. Wir diskutieren die Vorteile gegenüber herkömmlichem Speicherschutz und auch einige Randfälle.

Zunächst wiederholen wir herkömmliche Speicherschutzverfahren, also das Paging und die Segmentierung. Beim Paging wird der Speicher in gleich große Pages bzw. Frames (im physischen Adressraum) eingeteilt, die aufeinander gemappt werden können. Segmentierung teilt den physischen Speicher hingegen in unterschiedlich große Segmente ein, die nicht an alignten Adressen starten müssen. Beides implementiert sowohl Abstraktion von physischem auf virtuellen Speicher, als auch Speicherschutz, also Isolation der Prozesse untereinander.

CHERI implementiert auf Basis einer FPGA-MIPS Implementation ein anderes Modell des Speicherschutzes. Prozesse verwenden immer noch den gewohnten, durch Paging bereitgestellten virtuellen Speicher, aber auch zum Schutz einzelner Objekte so genannte Capabilities. Dazu werden (im Grunde) alle Pointer durch Capabilities ersetzt, die neben der Zieladresse noch die Länge des adressierten Objekts und einige Permissionbits enthalten. Diese Informationen sind untrennbar und unveränderbar aneinander gekoppelt. Der Prozessor selbst stellt das sicher. Die Authoren haben auf dem FPGA ein modifiziertes FreeBSD zum Laufen gebracht, eine Idee für legacy Programme entwickelt und auch Benchmarks und eine Limit-Study durchgeführt gegen andere Speicherschutzansätze.

Links

Capability Hardware Enhanced RISC Instructions (CHERI)

Jonathan Woodruff, Robert N.M. Watson, David Chisnall, Simon W. Moore, Jonathan Anderson, Brooks Davis, Ben Laurie, Peter G. Neumann, Robert Norton, and Michael Roe. The CHERI capability model: revisiting RISC in an age of risk. In Proceeding of ISCA'14. IEEE Press, 457–468. DOI: 10.1145/2678373.2665740

ACM

Jeremy Singer. Towards Secure MicroPython on Morello (WIP). In Proceedings of LCTES'2023. ACM, New York, NY, USA, 134–137. (2023) DOI: 10.1145/3589610.3596272

ACM

Intro-/Outrotheme

the_emergent

In dieser zehnten Folge vom SystemCall geht es um die Arbeit von Marcel Lütke Dreimann. Er stellt uns in dieser Folge seinen GPGPU-Treiber für die neunte Grafikgeneration der Intel integrierten Grafikchips vor, die in den Prozessen der 6. bis 10. Generation eingebaut sind. Der Treiber wurde für das Forschungsbetriebssystem MxKernel entwickelt.

MxKernel ist ein Betriebssystem was speziell für Manycore Systeme und Systeme mit heterogener Hardware entwickelt worden ist, d.h. Systeme mit vielen Prozessorkernen und unterschiedlichen Typen an Prozessoren. Marcel hat dafür einen GPGPU-Treiber entwickelt, der dafür verwendet werden kann vorkompilierte OpenCL Programme auf MxKernel auf der integrierten Intel Grafikkarte zum Laufen zu bringen. Er erklärt uns sein Vorgehen, die Initialisierung, die Besonderheiten und Fallstricke der Treiberentwicklung.

PS: Leider ist bei der Aufnahme etwas schief gelaufen, weshalb Marcel etwas übersteuert. Das ist unsere Schuld, aber jetzt nicht mehr lösbar. Das wird im Verlauf der Folge besser.

Links

Betriebssysteme.org Vortrag

Folien

Paper

MxKernel

Jan Mühlig, Michael Müller, Olaf Spinczyk und Jens Teubner. mxkernel: A Novel System Software Stack for Data Processing on Modern Hardware. In Datenbank Spektrum 20, 223–230 (2020). DOI: 10.1007/s13222-020-00357-5

Springer Link

Intro-/Outrotheme

the_emergent

Diese neunte Folge des SystemCalls dreht sich um Huge Paging in Linux und die Betrachtung der Latenz von Page Faults mit aufkommenden niedrig-latenten Hintergrundspeichern. Normalerweise erfolgt(e) Paging auf der x86 Plattform auf der Granularität von 4K Speicherseiten. Jede Seite beginnt dabei von einer auf 4096 Byte ausgerichteten Adresse, d.h. die letzten 12 Bits der ersten Adresse einer jeden Seite sind Null. Dieses Bedingung gilt sowohl im physischen, wie auch im virtuellen Adressraum. Zwischen dem physischen Frame (oder Kachel) und einer virtuellen Page (Seite) kann dann beliebig durch die Memory-Management Unit abgebildet werden, gesteuert durch die Page Table.

Im ersten Thema geht es um Ingens, einem Algorithmus um Transparent Huge Pages vergeben zu können. Die Autoren decken einige Probleme der zu der Zeit aktuellen Linux-Implementation auf, bspw. Latenz beim Herausgeben von 2M Seiten und Probleme im Same Page Merging, wobei 2M Seiten wieder nach 4K Seiten aufgespalten werden, falls 4K Seiten identisch sind und geteilt werden können. Ingens sieht dabei Kontiguität als Ressource. Die Verwaltung der Seiten wird außerdem intelligent an die Zugriffsmuster der Anwendungen ausgerichtet. Durch zwei Bitvektoren werden die Zugriffs- und Benutztheitsmuster aufgezeichnet, anhand dessen die Verwaltung der Huge Pages gesteuert wird.

Das zweite Thema beschäftigt sich mit der Latenz von Page Faults. Ein Page Fault entsteht, wenn eine zugegriffene virtuelle Seite nicht im Arbeitsspeicher vorhanden ist, bspw. weil sie auf Hintergrundspeicher (SSDs, HDDs) ausgelagert wurde. Bislang sind die Page Faults Algorithmen davon ausgegangen, dass der Hintergrundspeicher bedeutend langsamer ist, als die Kosten für einen Kontextwechsel, also das Schlafenlegen des zugreifenden Threads und das Einwechseln eines anderen, bis die betreffende Seite eingelesen worden ist. Mit dem Aufkommen von Intel Optane Speichern ist die Annahme, so die Autoren, aber nicht länger gültig; die Latenz kommt nun in Bereiche, dass ein aktives Warten darauf, dass einzelne Seiten eingelesen wird, attraktiv wird, weil die Kosten eines Context Switch überwiegen können.

Links Coordinated and Efficient Huge Page Management with Ingens

Youngjin Kwon, Hangchen Yu, Simon Peter, Christopher J. Rossbach and Emmett Witchel (2016). Coordinated and Efficient Huge Page Management with Ingens. In OSDI (Vol. 16, pp. 705-721).

Usenix

When Storage Response Time Catches Up With Overall Context Switch Overhead, What Is Next?

Chun-Feng Wu, Yuan-Hao Chang, Ming-Chang Yang and Tei-Wei Kuo (2020). When Storage Response Time Catches Up With Overall Context Switch Overhead, What Is Next?. In IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 39, no. 11, pp. 4266-4277, Nov. 2020, DOI: 10.1109/TCAD.2020.3012322.

IEEE

Intro-/Outrotheme

the_emergent

Hier nur eine kurze Werbung: Es gibt den Adventskalender der Systemrufe. Hier geht es um die Systemrufe und Interfaces von Linux. Jeden Tag wird ein neuer vorgestellt, und eine Aufgabe gestellt, die euch dazu bringen soll mit dem Ruf rumzuspielen. Am nächsten Tag gibt es dann jeweils auch eine Auflösung der Aufgabe. So könnt ihr euch mit dem Linux-System beschäftigen und einige Systemrufe kennenlernen.

Das Ganze gibt es auf osg.tuhh.de/Advent. Viel Spaß.

In dieser achten Sendung des SystemCalls beschäftigen wir uns mit dem Thema Unikernels. Unter Unikernels versteht man auf die Zielanwendung optimierte, oftmals im Cloud-Bereich eingesetzte Images für virtuelle Maschinen. Durch die zielgenaue Anpassung an die Anwendung soll nur Code enthalten sein, der wirklich gebraucht wird, was die Kosten dieser VMs im Gegensatz zu einem Standard-Linux deutlich senkt, Bootzeiten erheblich verkürzt und Angriffsfläche reduziert. Dadurch sollen physische Server besser mit virtuellen Maschinen ausgenutzt werden, weil nicht jede virtuelle Maschine, die effektiv ohnehin nur eine einzige Aufgabe in der Cloud hat, ein volles Linux und den vollen Userspace mitbringen muss.

Stefan stellt den "Großvater" der Unikernel vor - MirageOS (ASPLOS'13), was die Idee in einem clean-slate Ansatz erarbeitet hat. Mirage wurde in OCaml geschrieben, einer typsicheren funktionalen/objektorientierten Programmiersprache. Basierend auf der Idee der Bibliotheksbetriebesysteme (Library OS) ist das gesamte System, in ein Image für den Xen-Hypervisor zusammengelinkt. Betriebssystemfunktionalität kann so von der Anwendung wie eine normale Bibliothek verwendet werden. So kann die OCaml Toolchain das gesamte System, also Betriebssystemfunktionalität und die Anwendung durchoptimieren (Whole-System-Optimization), d.h. nur Code im VM Image einschließen, der wirklich von der Anwendung gebraucht wird. Configurationsoptionen werden hier auch als Code gesehen, der dem Compiler zur Optimierung zur Verfügung steht. Wir besprechen neben einigen Grunddaten von MirageOS, vor allem die durchgeführte Evaluation.

Im zweiten Thema beschreibt Florian den nächsten Schritt in Richtung Linux' Dominanz (HotOS'19). Die Autoren beschreiben in dem Paper die Entwicklung eines prototypischen Linux-Targets, bei dem die Anwendung zusammen mit dem Kernel gebunden wird und die Unterscheidung zwichen Kernel- und Userspace eingerissen wird. Dazu wurden die Systemrufe durch Funktionsaufrufe überarbeitet und das main-Symbol für den Startpunkt der Anwendung eingefügt. In einer ersten Evaluation konnte die Latenz eines Echo-Servers halbiert werden.

Links

unikernel.org

Unikernels: Library Operation Systems for the Cloud

Anil Madhavapeddy, Richard Mortier, Charalampos Rotsos, David Scott, Balraj Singh, Thomas Gazagnaire, Steven Smith, Steven Hand and Jon Crowcroft (2012). Unikernels: Library Operating Systems for the Cloud ACM SIGARCH Computer Architecture News 41.1. DOI: 10.1145/2490301.2451167

ACM

unikernel.org

Unikernels: The Next Stage of Linux's Dominance

Ali Raza, Parul Sohal, James Cadden, Jonathan Appavoo, Ulrich Drepper, Richard Jones, Orran Krieger, Renato Mancuso, and Larry Woodman (2019). Unikernels: The Next Stage of Linux's Dominance. In Proceedings of the Workshop on Hot Topics in Operating Systems (HotOS '19). DOI: 10.1145/3317550.3321445

ACM

Authors Copy

Intro-/Outrotheme

the_emergent

Der SystemCall Podcast beschäftigt sich mit mehr oder weniger aktueller Betriebssystemforschung. In dieser siebten Folge haben wir uns wieder einen Gast eingeladen - den Ralf Ramsauer, Wissenschaftlicher Mitarbeiter in Regensburg. Er beschäftigt sich mit dem partitionierendem Hypervisor Jailhouse. Außerdem in dieser Folge: Florian Rommel stellt die Kunst der Paravirtualisierung mit Xen dar.

Virtualisierung in eingebetteten, mixed criticality Systemen unterscheidet sich grundlegend von der Virtualisierung im Cloud-Bereich. Hier wie da findet zunehmend eine Konsolidierung statt, also es werden mehrere einzelne Systeme (bspw. Einkernsysteme oder Systeme mit nur einer Aufgabe) auf ein einziges System migriert, bspw. Mehrkernsysteme oder sie teilen sich die Resourcen in virtuellen Maschinen. In mixed criticality Systemen müssen wir dafür Sorge tragen, dass Anwendungen, die weniger wichtig sind, keine wichtigen Anwendungen beeinflussen.

Ralf beginnt damit mixed criticality Systeme vorzustellen und darauf aufbauend den Hypervisor Jailhouse. Jailhouse lässt erst ein Linux durchbooten um sich dann als Hypervisor drunter zu schieben. Dann kann er dem Linux-System Teile der Hardware entziehen, und auf andere Kerne neue Zellen aufsetzen mit Echtzeitsystemen wie FreeRTOS. Dadurch, dass Jailhouse die Zuweisung zwischen Zellen und Prozessorkernen statisch lässt und fast alle Hardware Peripherie direkt an die Gäste durchreicht, erspart der Hypervisor sich den Scheduler und kommt fast ohne VMExits aus, also ohne dass die Hardware aus der VM ausbrechen muss und der Hypervisor aktiv werden muss. Damit lassen sich bereits erzielte Zertifizierungen für Echtzeit-Zellen leichter erneuern und die Echtzeitgarantien bleiben bestehen.

Florian hat sich die Kunst der Paravirtualisierung vorgenommen - im Grunde das Paper zum Hypervisor Xen. Xen ist ein paravirtualisierender Hypervisor, d.h. er virtualisiert nicht die echte Hardware, sondern vereinfacht die virtuelle Hardware, damit die Performance maximiert werden kann. Die Gäste wissen dann zwar, dass die nur in einer virtuellen Maschine laufen, dafür genießen sie den Vorteil der schöneren Abstraktionen durch Xen. Mit dieser Art der Virtualisierung erreicht Xen im Cloud-Umfeld sehr gute Performance und erlaubt damit, dass viele VMs auf einem Host nebeneinander augeführt werden können.

Links Look Mum, No VM Exists (Almost)

Ramsauer, R., Kiszka, J., Lohmann, D., & Mauerer, W. (2017). Look mum, no VM exits!(almost). Proceedings of the 13th Annual Workshop on Operating Systems Platforms for Embedded Real-Time Applications (OSPERT '17).

arXiv

Xen: The Art of Virtualization

Pratt, I., Warfield, A., Barham, P., & Neugebauer, R. (2003). Xen and the Art of Virtualization. In Proceedings of the 19th ACM Symposium on Operating Systems Principles (pp. 113-1118). DOI: 10.1145/945445.945462

ACM

University of Cambridge

Intro-/Outrotheme

the_emergent

Im SystemCall Podcast beschäftigen wir uns mit aktueller Betriebssystemforschung - diesmal besprechen wir zwei Vorträge vom Fachgruppentreffen Betriebsyssteme in Hamburg. Florian stellt eine Art exokerniges Dateihandling vor, wo das Betriebssystem so wenig wie möglich Funktionalität beisteuert. Stefan stellt dar warum die Größe von Threadpools nicht händisch bestimmt werden sollte und beschreibt ein System nachdem die Anzahl der Threads dynamisch anhand Systemparameter eingestellt wird.

Ein Exokernel ist eine Betriebssystemarchitektur, bei der der Betriebssystemkernel die minimale Funktionalität bereitstellt und ansonsten die Userspace Anwendungen alle Aufgaben der Abstraktion übernehmen müssen. Im vorgestellten Vortrag wurde gezeigt, dass aktuelle implizite Ansätze mit Dateien auf Linux zu arbeiten, eine SSD kaum auslasten könnten, d.h. mmap-Rufe und vor allem das Freigeben von Speicher mit madvice sind zu langsam. Mit expliziten Systemrufen wie read und write wäre das aber möglich, das ist aber aufwändig, besonders sich zu merken auf welchen Adressen welche Daten der Datei stehen. Also wurde ein System vorgestellt, wo durch ein Kernelmodul physischer Hauptspeicher fest reserviert wird und Anwendungen zur Verfügung gestellt wird. Diese können dann explizit Dateiseiten einlesen und an die richtige Stelle im Hauptspeicher schreiben. Wird der Speicher nicht mehr benötigt kann er mit madvice zurückgegeben werden; beim nächsten Zugriff erhält die Anwendung dann wieder neuen Speicher vom Kernelmodul und die Anwendung kann die Seite erneut einlesen.

Threadpools zeichnen sich dadurch aus, dass ahead-of-time also bevor sie eigentlich gebraucht werden, eine Menge an Threads erzeugt werden, die solange leerlaufen bis es Aufgaben (also Tasks) für sie gibt. Viele Anwendungen schreiben sich eigene Threadpool-Bibliotheken und verlangen vom Endnutzer, dass die richtige Anzahl Threads statisch eingestellt wird. Das ist aufwändig und teilweise sinnlos, besonders wenn die Anwendung aus mehreren unterschiedlichen Phasen besteht (bspw. einlesen großer Datenmengen, lange Berechnungen, zurückschreiben). Es wird ein System vorgestellt, wo ein Controller das Einstellen der richtigen Anzahl von Threads übernimmt. Dabei wird der Durchsatz der Festplatte verwendet um Bottlenecks zu erkennen und ein Bergsteigeverfahren angewandt um eine gute Anzahl Threads für die aktuelle Situation zu finden.

Links

J. Timm & J. S. Rellermeyer, Why Multi-Threading Should No Longer Be a DIY Job. Tagungsband des FG-BS Frühjahrstreffens 2022. Bonn: Gesellschaft für Informatik e.V.. DOI: 10.18420/fgbs2022f-02

GI Digital Library

Folien

Programm des Fachgruppentreffens

Intro-/Outrotheme

the_emergent

Im SystemCall Podcast beschäftigen wir uns mit aktueller Betriebssystemforschung. Diese fünfte Folge ist eine besondere Folge, denn wir sprechen mit dem Preisträger des Promotionspreises der Fachgruppe Betriebssysteme, Alexander Züpke über einen Teil seiner Dissertation. Alex ist Postdoc an der TU München und hat im Bereich Echtzeit-Mikrokernel unter Anderem an schnellen Mechanismen für gegenseitigen Ausschluss geforscht.

Alex beschreibt uns den Stand von Futexes, also schnellem Gegenseitigen Ausschluss im Userspace, in Linux. Dieser optimistische Ansatz geht davon aus, dass die meisten Locks oder Mutexes genommen werden, obowohl wahrscheinlich kein Wettstreit darum herrscht, d.h. die meiste Kerninteraktion für diesen gegenseitigen Ausschluss nicht nötig wäre.

Beim Futex arbeiten die Synchronisationsprimitive erst einmal optimistisch mit atomaren Operationen im Userspace, und erst falls festgestellt wird, dass das Futex umstritten ist, wird in den Kernel gewechselt um passives Warten umzusetzen. Atomare Operationen sind dabei Prozessorinstruktionen, die bspw. ein Laden und das Setzen einer Speicherstelle in einem Zug erledigen, also aus der Sicht der anderen Prozessoren untrennbar (atomar). Das wird benutzt um gleichzeitig einen neuen Wert zu schreiben und den alten Wert zu lesen, um den gegen bekannte Werte zu vergleichen. Bspw. bedeutet 0, der kritische Abschnitt ist nicht besetzt, 1 er ist besetzt und 2 er ist besetzt und es warten Threads.

Alex beschreibt die Defizite der Implementierung der Warteschlangen im Linux-Kernel, und diskutiert die Implementierung der Futexe in einem Echtzeit-Mikrokernel. Echtzeit bedeutet in dem Kontext, dass jede Operation im System gewisse Zeitgarantien einhalten kann, und das belegbar ist. Bspw. dass eine kritische Anwendung auch mit diesen Futexen, aller X Millisekunden läuft und seine Berechnungen durchführen kann.

Links

https://blexi.de/papers/

A. Zuepke, R. Kaiser, Deterministic Futexes: Addressing WCET and Bounded Interference Concerns, RTAS 2019, DOI: 10.1109/RTAS.2019.00014

IEEE

Authors Copy

A. Zuepke, Turning Futexes Inside-Out: Efficient and Deterministic User Space Synchronization Primitives for Real-Time Systems with IPCP, ECRTS 2020, DOI: 10.4230/LIPIcs.ECRTS.2020.11

Dagstuhl

Authors Copy

Intro-/Outrotheme

the_emergent

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.

Links Was ist SGX?

Hackaday: SGX Deprecation Prevents PC Playback of 4k Blu-Ray Discs

kernel.org: Software Guard eXtensions (SGX)

Overview of Intel SGX - Part 1, SGX Internals

medium.com: The Magic of Intel's SGX

Intel: Innovative Instructions and Software Model for Isolated Execution

Übersicht über SGX-Papiere

SG Papers

Functions as a Service: aber sicher

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

ACM

SGAxe: How SGX fails in Practise

Website zur Schwachstelle

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 .

IEEE

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.

Links Undertaker

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

ACM

Authors Copy

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.

NDSS

Authors Copy

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

ACM

Authors Copy

BlankIt Library Debloating

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

ACM

Leseempfehlung: From Hack to Elaborate Technique - A Survey on Binary Rewriting

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

ACM

Introsounds

Boxing Bell from Benboncan on freesound.org

Punching and Uppercut from 18hiltc on freesound.org

Fight Arena 1 and 4 from SyntaxSeed on freesound.org

Wilhelm Scream on archive.org

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.

Links SkyBridge: Fast and Secure Inter-Process Communication for Microkernels

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

ACM: SkyBridge

Authors Copy

Weitere Referenzen:

Gerald J. Popek and Robert P. Goldberg. 1974. Formal requirements for virtualizable third generation architectures. Commun. ACM 17, 7 (July 1974), 412–421. DOI: https://doi.org/10.1145/361011.361073

Enabling Intel Virtualization Technology Features and Benefits: https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/virtualization-enabling-intel-virtualization-technology-features-and-benefits-paper.pdf

NrOS: Effective Replication and Sharing in an Operating System

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.

Usenix: nrOS

Introsounds

Menschenmenge: InspectorJ freesound.org