SystemCall

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