Verantwortung für den Kern: Anforderungen und Rollen in der Open-Source-Entwicklung

DKE: Welche formalen Anforderungen sind notwendig, um den Linux-Kernel langfristig für funktional sichere Anwendungen fit zu machen?

Ahmann: Der erste wichtige Schritt ist, Anforderungen – die sogenannten Requirements – konsequent zu dokumentieren und zentral im Kontext des Linux-Kernels zu hinterlegen. Viele dieser Anforderungen existieren bereits, aber sie sind oft auf Mailinglisten, Patches oder in Dokumenten verteilt. Wir müssen diese Informationen systematisch aufbereiten, um eine stabile Grundlage für Tests und Dokumentation zu schaffen. Momentan ist es beispielsweise oft unklar, wogegen ein Test genau prüft. Die Tests wurden zwar mit der Intention erstellt, bestimmte Funktionen zu überprüfen, aber es fehlt häufig die Verbindung zu klar definierten Anforderungen. Mit sauber dokumentierten Requirements könnten wir nachvollziehen, ob die Tests tatsächlich die gewünschte Funktionalität abdecken und ob sie den spezifischen Konfigurationen entsprechen. 

Ein weiteres Element ist die Dokumentation. Der Linux-Kernel hat sogenannte ‚manpages‘, die als Bedienungsanleitung für Funktionen und Schnittstellen dienen. Diese sind jedoch oft nicht synchron mit der Entwicklung des Kernels, da sie parallel dazu gepflegt werden. Das birgt das Risiko von Abweichungen zwischen der Dokumentation und der tatsächlichen Funktionalität. 

DKE: Wie lässt sich dieses Risiko eindämmen?

Ahmann: Beispielsweise durch eine engere Verzahnung, damit Änderungen im Code auch automatisch die Dokumentation aktualisieren. Eine große Rolle dabei spielen Tools, die den Entwicklungsprozess unterstützen. Es gibt erste Ansätze in der Community, die beispielsweise sicherstellen sollen, dass neue Interfaces oder Änderungen automatisch geprüft werden. Solche Tools könnten helfen, die Konsistenz zwischen Anforderungen, Code und Dokumentation sicherzustellen. 

Wichtig ist jedoch, die Akzeptanz in der Entwickler-Community zu gewinnen. Funktionale Sicherheit betrifft nur einen kleinen Anteil der gesamten Linux-Nutzerschaft. Deshalb muss der Nutzen dieser Maßnahmen auch für die gesamte Community deutlich werden. Genau diese Definition des „Was ist zu tun“ und damit verbunden das „Wie kann man es umsetzen“ diskutiert das ELISA-Projekt der Linux Foundation seit Herbst 2024 mit der Linux-Kernel-Community und Maintainern.

DKE Tagung Funktionale Sicherheit: 13.05.2025 bis 14.05.2025 in Erfurt

Neue Technologien und Lösungen erobern die Welt – aber wie kann funktionale Sicherheit dabei Schritt halten? Eine berechtigte Frage, die wir diskutieren wollen und müssen! Und wo wäre das besser möglich als in Erfurt? Die "Erfurter Tage" haben sich mittlerweile als fester Begriff und Branchentreff etabliert. Alle zwei Jahren kommen Expertinnen und Experten im Kaisersaal zusammen und tauschen sich aus. Seien auch Sie dabei und freuen Sie sich auf zwei intensive Konferenztage!

Zwischen Leidenschaft und Verantwortung – Die Schlüsselrolle der Maintainer in sicherheitskritischen Systemen

DKE: Wie sieht es mit der langfristigen Wartbarkeit und Betriebssicherheit des Linux-Kernels aus?

Ahmann: Der Linux-Kernel ist über 30 Jahre alt und extrem stabil – vermutlich ist der aktuelle Kernel der beste, den es je gab. Aber über die Jahre haben sich technische ‚Schulden‘ angesammelt. Das betrifft weniger die Funktionalität, sondern eher die Art, wie Dinge dokumentiert sind oder wie Entscheidungen nachvollziehbar gemacht werden. Viele Maintainer, also die Softwarebetreuer, arbeiten seit Jahrzehnten am Kernel. Sollte hier ein Generationswechsel stattfinden, benötigen wir eine Basis, die neuen Mitwirkenden einen leichten Einstieg ermöglicht. Eine gut gepflegte Dokumentation und nachvollziehbare Requirements sind essenziell, um langfristige Betriebssicherheit über Jahrzehnte hinweg auch weiterhin zu gewährleisten.

DKE: Was wären konkrete nächste Schritte, um den Linux-Kernel weiter in Richtung funktionale Sicherheit zu entwickeln?

Ahmann: Ein Ansatz wäre, mit kleinen Subsystemen zu starten, erste Best Practices zu entwickeln und diese als Beispiele für die Community aufzubereiten. Ein schrittweiser Prozess ist hier entscheidend, da über 1.000 Entwickler in den Entwicklungsprozess eingebunden sind. Es wird Zeit und Mühe kosten, alle Beteiligten ins Boot zu holen und Akzeptanz zu schaffen. Ein weiterer Schritt könnte die Verbesserung der Nachvollziehbarkeit durch Tests, Dokumentation und Spezifikationen sein. Langfristig geht es darum, ein robustes und stabiles System zu schaffen, das auch die Anforderungen der funktionalen Sicherheit erfüllt. Der Weg dorthin ist herausfordernd, aber mit einem koordinierten Ansatz machbar.

DKE: Welche Rolle spielen Software Maintainer in der Entwicklung von sicherheitskritischen Systemen, und welche Vor- und Nachteile sind mit dieser Rolle verbunden?

Ahmann: Ein Maintainer – oder eine Gruppe von Maintainern – ist für die Wartung und Weiterentwicklung eines bestimmten Softwaremoduls verantwortlich. Ihre Aufgabe umfasst die Verwaltung von Änderungen, das Schließen von Sicherheitslücken und die Integration neuer Funktionen. Änderungen am Code werden zu großem Teil auch aus der Open-Source-Community beigesteuert und von Maintainern geprüft. In der Open-Source-Welt ist es meist so, dass Maintainer diese Rolle freiwillig übernehmen. Sie identifizieren sich stark mit ‚ihrem‘ Projekt oder ihrer Komponente, sei es, weil sie sie selbst entwickelt haben, oder weil sie die Technologie besonders spannend finden. 

In einem funktionalen Kontext entscheiden Maintainer, welche Änderungen in den Code aufgenommen werden, welche Anforderungen erfüllt sein müssen und wie die Dokumentation gepflegt wird. Diese Verantwortung erfordert ein hohes Maß an Sorgfalt. Allerdings hängt die Herangehensweise stark davon ab, wie ‚reif‘ ein Projekt oder eine Komponente ist: Bei neuen, schnell wachsenden Projekten kann es passieren, dass Änderungen sehr offen angenommen werden und Prozesse weniger streng sind. In stabilen, ausgereiften Projekten hingegen agieren Maintainer in der Regel vorsichtiger und prüfen jede Änderung sehr genau.

Mit unserem DKE Newsletter sind Sie immer top informiert! Monatlich ...

• fassen wir die wichtigsten Entwicklungen in der Normung kurz zusammen
• berichten wir über aktuelle Arbeitsergebnisse, Publikationen und Entwürfe
• informieren wir Sie bereits frühzeitig über zukünftige Veranstaltungen

Open-Source-Maintainer zwischen Vorbild und Herausforderung in sicherheitskritischen Systemen

DKE: Gibt es Unterschiede zwischen Open Source und kommerziellen Systemen in Bezug auf die Rolle der Maintainer?

Ahmann: Ja, die Unterschiede sind erheblich. In kommerziellen Systemen ist die Verantwortung der Maintainer organisatorisch eingebunden, etwa durch Unternehmensstrukturen oder Prozesse. In Open-Source-Projekten ist die Rolle viel öffentlicher. Alles, was Maintainer tun, ist transparent und für die Community sichtbar. Diese Sichtbarkeit bringt eine zusätzliche Motivation, besonders sauber und präzise zu arbeiten. Gleichzeitig ist die Qualitätssicherung, um Maintainer zu werden, oft strenger: Es kann Jahre dauern, bis jemand als Maintainer akzeptiert wird, da dafür ein tiefes technisches Verständnis und eine lange Phase der Mitwirkung erforderlich sind. In der Industrie werden Maintainer von Softwarekomponenten oft durch Führungskräfte benannt und nicht aufgrund ihrer spezifischen Leistung in diesem Projekt.

DKE: Wie wirkt sich diese Transparenz auf die funktionale Sicherheit aus?

Ahmann: Transparenz ist ein großer Vorteil. Open-Source-Maintainer stehen unter öffentlicher Beobachtung. Sie müssen sicherstellen, dass ihre Arbeit nachvollziehbar ist und die höchsten Standards erfüllt – auch, um ihren Ruf in der Community zu wahren. Diese öffentliche Verantwortung wirkt sich positiv auf die Qualität aus, was besonders für funktional sichere Systeme von Vorteil ist. Allerdings gibt es auch Herausforderungen: Maintainer sind oft stark mit ihrer Komponente verbunden. Diese persönliche Bindung kann in Einzelfällen dazu führen, dass Entscheidungen emotional geprägt sind oder auch, dass Änderungen nur zögerlich angenommen werden, sollte dem Maintainer die Motivation der Änderung nicht klar genug sein. 

In der funktionalen Sicherheit, wo Stabilität und klare Prozesse zentral sind, ist das nicht immer optimal. Andererseits sorgt diese Verbindung aber auch für eine hohe Identifikation mit der Qualität der Komponente und fördert die Stabilität.

DKE: Sind Maintainer auch ein Risiko für sicherheitskritische Systeme?

Ahmann: Das Risiko liegt weniger in der Rolle selbst, sondern in den Umständen unter der die Open-Source-Software größtenteils eingesetzt wird. In einem Consumer-Umfeld, wo funktionale Sicherheit keine Rolle spielt, können Entscheidungen oft pragmatisch und schnell getroffen werden. Hier spielt Prozesstreue und Sorgfalt eine geringere Rolle als bei funktionaler Sicherheit. Open-Source-Maintainer bringen in der Regel die nötige Expertise mit, aber die Bedeutung von Prozessen und Standards ist ein Lernfeld. Es ist wichtig, diese durch zusätzliche organisatorische Maßnahmen und automatisierte Qualitätssicherungsmechanismen zu unterstützen und die Vorteile für Maintainer und die Community aufzuzeigen. 

Ein Beispiel könnte sein, dass eine umfassende Dokumentation dazu beitragen kann, vermeintliche Fehlertickets zu vermeiden oder schneller zu klären. Wenn den Nutzern durch Dokumentation vorab klar ist, dass sie eine bestimmte Funktion nicht erwarten können und diese daher nicht verfügbar ist, oder Maintainer in Fehlertickets auf die entsprechenden Dokumentationen und Anforderungen verweisen, wird der Frust der Nutzer und Maintainer reduziert.

--- Ende von Teil 2 dieses Interviews ---

Hier endet die zweite Gesprächsrunde mit Philipp Ahmann zur Anwendung von Open Source in sicherheitskritischen Systemen.

Der erste Teil dieses Interviews thematisiert den Grundgedanken von Open Source, aktuelle Projekte und die normative Berücksichtigung in der IEC 61508.

Teil 3 dieses Interviews wird am 10.03.2025 veröffentlicht.

DKE Tagung Funktionale Sicherheit 2025: Keynotes, Fachdiskussionen, Community

Sie möchten vom 13. bis 14. Mai 2025 an der Veranstaltung in Erfurt teilnehmen? Wir freuen uns auf Sie!

Core Safety & Information Technologies umschließt alle Aspekte der Sicherheit: grundlegende  Sicherheitsanforderungen, funktionale Sicherheit, Informationssicherheit sowie deren Wechselwirkungen. Außerdem befasst sich Core Safety mit wichtigen Querschnittsthemen und definiert grundlegende Anforderungen die allgemein einzuhalten sind – zum Beispiel für Elektromagnetische Verträglichkeit, Umwelt- und Ressourceneffizienz, Schadstoffe, Größen, Einheiten und Kennzeichnungen. Weitere Inhalte zu diesem Fachgebiet finden Sie im