Tausende Besucher trafen sich Ende Oktober auf dem Open Source Summit Europe 2019 im französischen Lyon. Dort plauderte Linus Torvalds über den Kernel, Linux-Foundation-Orakel Jim Zemlin prognostizierte Open-Source-Trends für 2020.
Jim Zemlin gehörten im Kongresszentrum Lyon die ersten Minuten. In der als großes Amphitheater gestalteten Halle brach er die nach eigenen Worten erste Regel der Linux Foundation: “Sprich nicht über die Linux Foundation.” Auf das Jahr 2019 zurückblickend, sah Zemlin vor allem Open Hardware auf dem Vormarsch. So sei die RISC-V-Foundation das am schnellsten wachsende Projekt unter dem Dach der Linux Foundation.
Für das kommende Jahr erwartet er das Thema Open Data im Aufwind. Kein Wunder: Bei Machine Learning, Big Data oder Edge Computing fallen entweder massenhaft Daten an, oder sie sind Voraussetzung für einen sinnvollen Betrieb. Es werde um Datenlizenzen gehen, den richtigen Umgang mit Daten, das Teilen von Daten und industrielle Datenwerkzeuge. Dabei will die Linux Foundation auch die Ethik nicht aussparen: Bislang haben knapp 2000 Menschen ein Manifest unterschrieben, das Regeln für einen ethischen Umgang mit Daten festlegt [1].
Linus über schwierige Linux-Bugs
Auch den schon lange in den USA lebenden Finnen Linus Torvalds hatte es diesmal nach Europa verschlagen. Er ließ sich – nicht zum ersten Mal – von seinem Tauchkumpel Dirk Hohndel interviewen (Abbildung 1). Der fragte vor dem Hintergrund eines merkwürdigen Dateisystem-Bugs, ob Linux inzwischen nicht einfach zu komplex sei. Was die Bugs angeht, zeigte sich Torvalds jedoch eher unbeeindruckt: Es gebe heute weniger von den offensichtlichen Bugs, was für ihn wiederum bedeute, dass die Entwickler solche Fehler inzwischen besser finden.

Abbildung 1: Dirk Hohndel von VMware interviewte auf dem Open Source Summit in Lyon einmal mehr seinen Tauchkumpel Linus Torvalds. Der betrachtet den Kernel auch als fit für Safety-zertifizierte Systeme.
Auch der Einsatz von Linux in sicherheitskritischen Systemen beunruhigt Torvalds nicht. In einigen Embedded-Systemen komme der Linux-Kernel bereits seit Jahren zum Einsatz und sei damit lange vor Einführung der heutigen Qualitätsmaßnahmen entstanden. Dank Letzterer werde der Kernel laut Torvalds ja nicht schlechter, sondern besser. Nicht zuletzt würden Firmen, die Linux in sicherheitskritischen Echtzeitumgebungen einsetzen, das Betriebssystem in der Regel noch weiteren eigenen Tests unterziehen.
Rückblickend sei die Kernel-Entwicklung heute in vielerlei Hinsicht einfacher als früher. Es gebe bessere Tools sowie mehr Kommunikation und Hilfe. Und was die Lernkurve angeht: Nur wenige Kernel-Entwickler würden tatsächlich im Core-Bereich anfangen, die meisten arbeiteten sich eher von der Peripherie ins Zentrum der Kernel-Entwicklung vor.
Just for Fun
Dass die Kernel-Entwicklung früher mehr Spaß gemacht habe, wollte Torvalds so nicht unterschreiben. Sicher seien heute viel mehr Regeln im Spiel, und die jüngsten CPU-Bugs seien sicherlich auch kein Spaß. Doch einer der wesentlichen Gründe, das Entwicklungsmodell ab Kernel 2.6 umzubauen, habe darin bestanden, dass die Arbeit mit dem damaligen experimentellen Kernel eben auch kein “Fun” war. Wenn er Code schreibe, den zu benutzen sich niemand traue, sei das eben wenig befriedigend für ihn, so Torvalds.
Im Gespräch gab Torvalds dann auch seinen heimlichen Stolz auf Git zu Protokoll. Er habe damals trotz des Erfolgs von Linux an sich gezweifelt: Schließlich sei das “nur” eine Unix-Implementierung gewesen. Git habe ihm jedoch bewiesen, dass er tatsächlich erfolgreiche Projekte jenseits von Linux starten könne.
Safety Dance
Ein weiteres Thema auf dem Summit war die Gefahrlosigkeit (Safety). Während der Echtzeit-Kernel allmählich in greifbare Nähe kommt, dürfte es zu gängigen Safety-Zertifizierungen noch ein längerer Weg sein. Systeme, deren Ausfall Menschenleben fordern oder signifikante Sach- und Umweltschäden anrichten kann, benötigen aber solche Zertifizierungen. Neben Kraftfahrzeugen verlangen auch medizinische Geräte, Roboter und Transportsysteme häufig Safety-Zusagen.
Die Linux Foundation hat Anfang 2019 mit ELISA (Enabling Linux In Safety Applications [2]) ein Projekt gestartet, das die Zertifizierungsmöglichkeiten auslotet. Unterstützt wird das Projekt unter anderem vom Open Source Automation Development Lab (OSADL, [3]), das seit 13 Jahren in diesem Bereich arbeitet. Für das SIL2LinuxMP-Projekt strebt OSADL beispielsweise den Safety Integrity Level 2 nach IEC 61508 Ed 2 2010 an.
Laut Kate Stewart, der Leiterin des ELISA-Programms, wünschen sich viele Industriezweige eine Safety-Zertifizierung für Linux, um ihre Produkte schneller auf den Markt zu bringen und Designfehler zu vermeiden. Dem steht aber laut einem Vortrag [4] von Nicole Pappler, Philipp Ahmann und Andreas Bärwald vom TÜV Süd unter anderem der statische Zertifizierungsprozess entgegen, der noch zu großen Teilen auf Papier und manuell erfolgt und zwei Releases pro Jahr vorsieht.
Ganz anders funktioniert zeitgemäße Software-Entwicklung, die zum Beispiel nach dem Agile-Modell abläuft. Automatische Builds, Releases und Safety-Approvals sind hier die Regel. Es geht nun um die Frage, wie sich der Entwicklungsprozess mit dem der Zertifizierung verträgt. Zugleich mache eine Zertifizierung ein System nicht automatisch sicher, erläuterte Stewart: Wer Safety für den Linux-Kernel und seine Applikationen wolle, müsse im Vorfeld gut überlegen, wie er das System bauen und testen will, damit es in der Praxis tatsächlich gefahrlos läuft.
Sicherer Kern
Obwohl die Security einen Teilbereich der Safety bildet, führt ein Mangel an Security nicht zwingend zu Tod und Zerstörung. Dennoch spielt Security vor allem beim Umgang mit vertraulichen Daten eine zentrale Rolle. Viele Industrien (Finanzen, Telekommunikation) und Behörden (Gesundheitswesen, Regierungen) zögern, ihre Daten einem Cloud-Anbieter anzuvertrauen, mit gutem Grund: Der besitzt trotz vertraglicher Beteuerungen und einiger Sicherheitsmechanismen am Ende einen Zugriff auf die verwalteten Daten – und sei es über den Arbeitsspeicher.
Dieses Cloud-Risiko will die Security-Infrastruktur TEE (Trusted Execution Environments) zumindest teilweise schmälern. TEE erlaubt es, Workloads abgeschottet vom Host auf einer CPU laufen zu lassen. Dazu nutzt die Umgebung AMDs SEV (Secure Encrypted Virtualization) oder Intels SGX (Software Guard Extension). Der Betreiber der verschlüsselten Workloads muss dann nur noch der CPU-Firmware vertrauen. Die gegen den Host abgesicherten Workloads, die in einer TEE laufen, heißen Keeps. Sie akzeptieren Anwendungen, die in verschiedenen Programmiersprachen geschrieben wurden, und übersetzen sie in Web Assembly.
Mike Bursell von Red Hat gab dem Linux-Magazin auf dem Open Source Summit nun erste Einblicke in das Enarx-Projekt [5]. Das stellt für solche Anwendungen sicher, dass es sich bei den CPUs tatsächlich um TEEs handelt. Dank Enarx übertragen die Anwendungen ihre Daten sicher an die Keeps. Das quelloffene Projekt wartet unter dem Dach des neu gegründeten Confidential Computing Consortium [6]. Was sich Red Hat von dem Projekt erhofft, liegt auf der Hand: mehr Software verkaufen. Enarx soll zögerliche Industrien dazu bewegen, ihre Daten endlich wie alle anderen in die Cloud zu schieben. (kki)
Infos
-
Manifest zum Datenumgang: https://datapractices.org/manifesto/
-
ELISA-Projekt: https://elisa.tech
-
OSADL: https://www.osadl.org/SIL2LinuxMP.sil2-linux-project.0.html
-
TÜV-Süd-Slides: https://static.sched.com/hosted_files/osseu19/f5/20191028%20A%20Story%20of%20Safety%20and%20Common%20Sense.pdf
-
Enarx-Projekt: https://enarx.io
-
Confidential Computing Consortium: https://confidentialcomputing.io






