Hauptseminar

An dieser Stelle werden Themenvorschläge für studentische Vorträge in der EZAG gesammelt.

Die EZAG dient auch als Plattform für das Hauptseminar, es gibt also insbesondere keine Sondertermine für Hauptseminarvorträge. Um als Student einen Vortrag im Rahmen des Hauptseminars zu halten, sollte man sich entweder ein Thema aus der Liste auf dieser Seite aussuchen oder selbst ein Thema vorschlagen. Danach sollte man den Betreuer des gewählten Themas bzw. mich (bei einem eigenen Thema) kontaktieren, um den weiteren Ablauf und einen Vortragstermin festzulegen.

Neben dem Hauptseminarvortrag ist eine Ausarbeitung notwendig. Der genaue Inhalt ist mit dem Betreuer nach dem Vortrag abzusprechen. Die Ausarbeitung sollte 10 Seiten nicht überschreiten und ist spätestens 4 Wochen nach dem Hauptseminarvortrag beim Betreuer abzugeben. Vortrag und Ausarbeitung sind notwendig, um einen Schein zu bekommen. Allgemeine Hinweise zum Aufbau von wissenschaftlichen Arbeiten finden sich in der Rubrik „Beleg/Diplom Aufbau“, wobei die Grundstruktur wie folgt anzupassen ist: Einleitung, Problem, Related Work (1 Seite), Kernidee, Details eines Aspektes, Bewertung, Zusammenfassung. Hinweis: Die Ausarbeitung ist als Fließtext (keine Stichpunktesammlung!) zu verfassen, der Duden bzw. die Rechtschreibprüfung wird dringend empfohlen, ebenso ist eine Seitennummerierung erwünscht.

Das Publikum von Hauptseminarvorträgen besteht aus fortgeschrittenen Studenten und Mitarbeitern. Es ist evtl. sinnvoll im Vortrag kleinere Bezüge zur BS-Vorlesung herzustellen, ansonsten sollten grundlegende Konzepte als bekannt behandelt werden und die Vortragseinleitung und -einführung kann meist kompakt ausfallen. Schwerpunkt sollte ein interessantes wissenschaftliches Thema bilden, so dass alle etwas lernen können.

Der Vortrag selbst sollte, sofern nicht anders abgesprochen, für eine Dauer von ca. 30 Minuten ausgelegt sein. Anschließend stehen üblicherweise 15 Minuten für Fragen zur Verfügung. Es empfiehlt sich den Vortrag vorher etwas zu üben, damit man die eigene Geschwindigkeit besser einschätzen kann.

Themenvorschläge

Profiling auf Linux

Aufgabe: Beim Profiling wird das Verhalten eines einzelnen Programms oder eines ganzen Systems analysiert, um die Nutzung von Ressourcen wie CPU-Zeit, Speicher und I/O zu verstehen.
Profiling hilft beim Finden von Bootlenecks (z. B. häufig aufgerufene und lang laufende Funktionen) und somit bei der Optimierung ineffizienter Programme.

In der Regel wird mit Profiling-Tools der Ausführungszustand von Threads stichprobenartig aufgezeichnet, um häufig ausgeführte Codepfade zu ermitteln.
Visualisierungswerkzeuge wie Flame Graphs können diese Informationen nutzen, um die Verteilung der Ausführungszeit auf die verschiedenen Funktionen näherungsweise darzustellen.

Ziel dieses Seminarthemas ist es, Profiling-Tools für Linux-Anwendungen/Systeme zu vergleichen und zu zeigen, wie diese genau funktionieren.

Quellenvorschläge:

• Perf
• OProfile
• poor man's profiler
• gprof
• Flame Graphs

Betreuer: Viktor Reusch

Aliasing-Modelle für Rust

Aufgabe: Safe Rust-Code gewährleistet Speichersicherheitsgarantien durch Überprüfungen zur Kompilierzeit und strenge ownership-Regeln.
Unsafe Rust-Code ermöglicht es Entwicklern, diese Garantien für bestimmte Aufgaben selektiv zu umgehen, birgt aber bei unsachgemäßer Verwendung das Risiko von Speicherfehlern, Wettlaufsituation und anderen Sicherheitsverletzungen.
Insbesondere das Zusammenspiel von Referenzen und Zeigern muss bestimmten Aliasing-Regeln folgen, die sich noch in der Entwicklung befinden.

Die Aufgabe für dieses Seminarthema besteht darin, die offiziell dokumentierten Regeln für unsafe Code zu beschreiben und sie mit vorgeschlagenen Aliasing-Modellen wie Stacked Borrows zu vergleichen.
Darüber hinaus soll die Arbeit die Regeln für unsafe Rust mit den Einschränkungen in anderen Sprachen (z.B. C++) und hardware capabilities (z.B. CHERI) vergleichen.

Quellenvorschläge:

• Unsafe Rust
• Aliasing – The Rustonomicon
• std::ptr
• Behavior Considered Undefined
• Stacked Borrows
• From Stacks to Trees
• Tree Borrows
• Miri
• Strict Aliasing
• CHERI

Betreuer: Viktor Reusch

ROS 2 und microROS

Das Robot Operating System (ROS) ist ein Framework für die Programmierung von Robotern. Programme bestehen dabei aus einer Menge an interagierenden Komponenten, für die auch ein umfangreicher Baukasten an fertigen Komponenten bereitgestellt wird. Die aktuelle Version ROS 2 wirbt dabei mit Echtzeitfähigkeit und der damit verbundenen Einsatzmöglichkeit in sicherheitskritischen Umgebungen.

Ziel des Vortrags soll es sein, einerseits die Architektur von ROS 2 vorzustellen und dabei auf das Zusammenspiel der Komponenten und die Echtzeit-Eigenschaften einzugehen. Andererseits können auch alternative Implementierungen wie micro-ROS vergleichend besprochen werden, insbesondere deren Einsatz in eingebetteten Umgebungen wie Mikrocontrollern oder minimalen Betriebssystemen.

Quellenvorschläge:

• ROS
• microROS

Betreuer: Michael Roitzsch

Fortgeschrittene Aspekte von Linux

Der Linux-Kernel ist eine komplexe Codebasis, die zahlreiche spezialisierte Konstrukte umfasst. Seine Open-Source-Natur ermöglicht eine kontinuierliche Verfeinerung und Innovation. Jedoch ist es schwierig ist, mit dem ständig weiterentwickelten Code Schritt zu halten.

In diesem übergreifenden Seminarthema soll eine spezialisierte Linux-Funktion herausgegriffen, recherchiert und präsentiert werden. Einige Beispiele sind unten aufgeführt, aber auch eigene Vorschläge sind willkommen.

• Datenstrukturen, z.B. Maple-Bäume
• Speicherallokatoren (SLAB, SLOB, SLUB)
• Scheduling-Algorithmen, z.B. CFS (completely fair scheduler), EEVDF (earliest eligible virtual deadline first)
• Synchronisation, e.g. RCU (read-copy-update)
• Spezialisierte Nutzer-APIs, e.g. io_uring, eBPF
• Subsysteme, e.g. Crypto API, device mapper, work queues

Quellenvorschläge:

• The Linux Kernel Archives
• The Linux Kernel documentation
• Earliest Eligible Virtual Deadline First: A Flexible and Accurate Mechanism for Proportional Share Resource Allocation
• What is RCU, Fundamentally?, Read-copy update: Using Execution History to Solve Concurrency Problems
• The Slab Allocator in the Linux kernel
• Ringing in a new asynchronous I/O API, The rapid growth of io_uring
• eBPF Documentation, BPF Internals
• The Device Mapper, dmsetup

Betreuer: Jan Bierbaum