Hauptseminar
Verantwortlicher | Sandy Seifarth-Haupold |
Modul | DSE-14-E13, DSE-E13, INF-04-HS, INF-AQUA, INF-D-940, INF-DSE-20-E-BDSE, MINF-04-HS |
Umfang und Art |
2 SWS Übung |
Turnus | Ganzjährig |
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
Sicherheit in Programmiersprachen auf Basis von Capabilities
Aufgabe: Capabilities sind ein Mechanismus um Zugriffskontrolle zu implementieren. Im Kontext von Programmiersprachen werden Capabilities dazu verwendet Programme nach dem Principle of Least Authority (PoLA) zu schreiben. Das Ziel dieses Seminarthemas ist es, einen Überblick über die Anwendung von Capabilities im Rahmen von Programmiersprachen zu geben (z.B.: E, Pony, Monte, ...) und wie diese Capabilities sich mit Capabilities aus Mikrokern-basierten Betriebssystemen vergleichen lassen.
Quellenvorschläge:
- ERights (E)
- ERights Wiki
- Pony
- Capability-Based Type Systems for Concurrency Control (Dissertation)
- Monte
Betreuer: Matthias Hille
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:
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:
Betreuer: Michael Roitzsch