SystemCall

Fachgebiet System- und Rechnerarchitektur, Leibniz Universität Hannover

0.0 (0)
SCIENCE

Forschungspodcast über Betriebssysteme und Rechnerarchitektur

JAN 24

SC(13): Sichten auf Adressräume

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

50 min
12/02/2023

SC(12): Was wir nie über Locking wissen wollten

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

1h 8m
10/07/2023

SC(11): CHERI-Capabilities als Speicherschutz

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

50 min
06/30/2023

SC(10): GPGPU Treiber für Intel iGPUs

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

52 min
01/28/2023

SC(9): Riesenseiten und Page-Fault Latenz

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

1h 14m
12/02/2022

Advent(2): Adventskalender der Systemrufe

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ß.

1 min
10/28/2022

SC(8): MirageOS und Linux als Unikernel

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

1h 1m
07/15/2022

SC(7): Partitionierung und Paravirtualisierung

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

1h 28m

Forschungspodcast über Betriebssysteme und Rechnerarchitektur

Creator

Fachgebiet System- und Rechnerarchitektur, Leibniz Universität Hannover
Years Active

2021 - 2026
Episodes

14
Copyright

© 2021 Fachgebiet System- und Rechnerarchitektur
Show Website

SystemCall