# Speichersicherheit in C ohne Rust > [! hinweis]- > Der Inhalt dieser Seite ist durch Audio/Video-Transkribtion und Text-Transformation aus dem Inhalt und Links dieser Quelle generiert. Quelle: [https://fosdem.org/2025/schedule/event/fosdem-2025-6606-imposing-memory-security-in-c/](https://fosdem.org/2025/schedule/event/fosdem-2025-6606-imposing-memory-security-in-c/) <video src="https://video.fosdem.org/2025/h2215/fosdem-2025-6606-imposing-memory-security-in-c.av1.webm" controls></video> ## Zusammenfassung & Highlights: Die Session 'Imposing Memory Security in C' von Maria Matejka auf der FOSDEM 2025 behandelt die Herausforderungen und Lösungen zur Verbesserung der Speichersicherheit in C-Programmen, ohne auf Rust umzusteigen. **Einleitung** Maria Matejka argumentiert, dass Rust nicht unbedingt C ersetzen muss, um speichersichere Anwendungen zu entwickeln. Sie teilt ihre Erfahrungen mit der Verbesserung der Speichersicherheit im BIRD-Projekt, einem 25 Jahre alten C-Code, durch Automatisierung und Entwickler-Richtlinien. **Herausforderungen und Lösungen** Der Vortrag hebt hervor, dass es wichtig ist, bestehende Codebasen nicht unnötig zu ersetzen, sondern durch gezielte Maßnahmen wie statische Analyse, Unit-Tests und die Vermeidung globaler Variablen zu verbessern. Matejka zeigt, wie man durch den Einsatz von Makros und spezifischen Codierungsrichtlinien die Sicherheit erhöhen kann. **Techniken zur Verbesserung der Speichersicherheit** Matejka erläutert verschiedene Techniken wie die Verwendung von unions statt void-Pointern, die Implementierung von Cleanup-Hooks und die Nutzung von Makros zur Erkennung von Typumwandlungen. Diese Methoden helfen, den Code sowohl sicherer als auch wartbarer zu machen. **Praktische Anwendungen und Beispiele** Anhand von Beispielen aus dem BIRD-Projekt wird gezeigt, wie man speichersichere Operationen in C implementieren kann. Die Nutzung von hierarchischen Speicherpools und temporären Allokationen wird als effektive Strategie zur Speicherverwaltung vorgestellt. ## Bedeutung für eine öko-soziale Transformation Die Bedeutung dieser Session für eine ökosoziale Transformation liegt in der nachhaltigen Nutzung bestehender Ressourcen, indem bestehender C-Code speichersicher gemacht wird, ohne auf neue Technologien wie Rust umzusteigen. Dies spart Entwicklungsressourcen und reduziert Abfall durch unnötige Neuentwicklung. Soziale Fragestellungen betreffen die Ausbildung und Führung von Entwicklern, um sichere und nachhaltige Software zu schreiben. Herausforderungen bestehen in der Verbreitung dieser Praktiken und der Überzeugung von Entwicklerteams, etablierte Workflows anzupassen. ## Slides: | | | | --- | --- | | ![[FOSDEM 2025/assets/Imposing-memory-security-in-C/preview_001.jpg\|300]] | Maria Matejka beschreibt, wie man Speichersicherheit in C gewährleisten kann, ohne auf Rust umzusteigen. Sie stellt Methoden vor, die im BIRD-Projekt angewendet werden, um Speicheroperationen sicher zu gestalten. | ![[FOSDEM 2025/assets/Imposing-memory-security-in-C/preview_002.jpg\|300]] | Die Herausforderung besteht darin, eine alte C-Codebasis speichersicher zu machen, ohne sie in Rust umzuschreiben. Matejka argumentiert, dass bestehende Systeme oft stabil sind und nicht unbedingt neu geschrieben werden müssen. | ![[FOSDEM 2025/assets/Imposing-memory-security-in-C/preview_003.jpg\|300]] | Die Anforderungen umfassen das Beibehalten funktionierender Systeme, automatisierbare Refaktorisierung und die Führung von Entwicklern zu guten Praktiken. Es soll schwer sein, schlechten Code zu schreiben, aber nicht unmöglich. | ![[FOSDEM 2025/assets/Imposing-memory-security-in-C/preview_004.jpg\|300]] | Unsicherer Code sollte offensichtlich fehlerhaft sein, sei es durch Build-Fehler, statische Analyse oder Unit-Tests. Solche Fehler sollten klar erkennbar sein. | ![[FOSDEM 2025/assets/Imposing-memory-security-in-C/preview_005.jpg\|300]] | Unsicherer Code sollte in Form von Build-Fehlern oder statischen Analysefehlern auffallen. Der Code sollte von Natur aus unschuldig sein, wenn er als solcher gedacht ist. | ![[FOSDEM 2025/assets/Imposing-memory-security-in-C/preview_006.jpg\|300]] | Die einfachste Methode besteht darin, lokale statt globale Variablen zu verwenden und überall 'const' zu verwenden. Funktionen, die nicht rein sind, sollten einen guten Grund haben, zu existieren. | ![[FOSDEM 2025/assets/Imposing-memory-security-in-C/preview_007.jpg\|300]] | Globale Variablen sollten vermieden werden, indem Kontexte als Argumente übergeben werden. Wirklich geteilte Daten sollten explizit gesperrt werden. | ![[FOSDEM 2025/assets/Imposing-memory-security-in-C/preview_008.jpg\|300]] | Void-Pointer sollten durch unions ersetzt werden. Generierter Code ist sicherer, und eigene Datentypen für Listen oder Hashtables sind vorzuziehen. | ![[FOSDEM 2025/assets/Imposing-memory-security-in-C/preview_009.jpg\|300]] | Ressourcen sollten lokal erworben und explizit freigegeben werden. Cleanup-Hooks können in Makros verpackt werden, um die Zuverlässigkeit zu erhöhen. | ![[FOSDEM 2025/assets/Imposing-memory-security-in-C/preview_010.jpg\|300]] | Ein Beispiel zeigt die Verwendung eines Unlock-Makros, das eine Sperre automatisch freigibt, wenn der gesperrte Kontext verlassen wird. | ![[FOSDEM 2025/assets/Imposing-memory-security-in-C/preview_011.jpg\|300]] | Das Makro definiert eine Cleanup-Funktion, die beim Verlassen des gesperrten Blocks aufgerufen wird, um die Sperre freizugeben. | ![[FOSDEM 2025/assets/Imposing-memory-security-in-C/preview_012.jpg\|300]] | Ein Cleanup-Hook wird definiert, der sicherstellt, dass die Sperre korrekt freigegeben wird, wenn der gesperrte Block verlassen wird. | ![[FOSDEM 2025/assets/Imposing-memory-security-in-C/preview_013.jpg\|300]] | BIRD verwendet hierarchische Speicherpools, die alles nachverfolgen. Temporäre Allokationen werden am Ende der Aufgabe freigegeben. | ![[FOSDEM 2025/assets/Imposing-memory-security-in-C/preview_014.jpg\|300]] | Globale Ressourcen können temporär bezogen und am Ende der Aufgabe freigegeben werden. Derzeit gibt es zu viel expliziten Code. | ![[FOSDEM 2025/assets/Imposing-memory-security-in-C/preview_015.jpg\|300]] | Arrays sollten immer die Längen speichern und Bereiche überprüfen. Makros und einfache Bibliotheken können dies erleichtern. | ![[FOSDEM 2025/assets/Imposing-memory-security-in-C/preview_016.jpg\|300]] | Der Ereignisloop ist ein unendlicher Zyklus um 'poll()'. Am Ende der Aufgabe werden temporäre Ressourcen bereinigt. | ![[FOSDEM 2025/assets/Imposing-memory-security-in-C/preview_017.jpg\|300]] | Globale Datenstrukturen sollten vollständige Referenzen ermöglichen, um ordnungsgemäße Prüfungen zu erlauben. Cleanup-Hooks helfen bei der automatischen Freigabe. | ![[FOSDEM 2025/assets/Imposing-memory-security-in-C/preview_018.jpg\|300]] | Diese Techniken werden im BIRD Internet Routing Daemon Version 3 angewendet. Eine Trennung der BIRDlib für die öffentliche Nutzung ist in Arbeit. | ![[FOSDEM 2025/assets/Imposing-memory-security-in-C/preview_019.jpg\|300]] | Maria Matejka arbeitet bei CZ.NIC als Expertin für C, Performance und Multithreading und ist Entwickler, Maintainer und Teamleiter. | ![[FOSDEM 2025/assets/Imposing-memory-security-in-C/preview_020.jpg\|300]] | Ende der Präsentation von Maria Matejka am 2. Februar 2025. ## Links [Video recording (AV1/WebM)](https://video.fosdem.org/2025/h2215/fosdem-2025-6606-imposing-memory-security-in-c.av1.webm) [Video recording (MP4)](https://video.fosdem.org/2025/h2215/fosdem-2025-6606-imposing-memory-security-in-c.av1.mp4) [Video recording subtitle file (VTT)](https://fosdem.org/2025/events/attachments/fosdem-2025-6606-imposing-memory-security-in-c/subtitles/238498/subtitles.vtt)