SystemCall

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