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.

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

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.

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

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.

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.

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

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

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

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.

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

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

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.

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

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.

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

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.

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.

unikernel.org

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

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

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.

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

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

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.

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

Programm des Fachgruppentreffens

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.

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

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

the_emergent