Safety Critical Linux

Lukas Bulwahn berichtete im ersten Vortrag, den ich am Dienstag Vormittag gehört habe, über den aktuellen Stand des OSADL SIL2LinuxMP Projekts. Dabei geht es um die Frage, ob sich ein Linux-basiertes System für den Einsatz in sicherheitskritischen Systemen, wie sie für das autonome Fahren benötigt werden, eignet. Letztlich geht es um die Frage, im Sinne der IEC61501 "unakzeptable Risiken" in einem System auszuschließen.

Um die Anforderungen von SIL2 zu erfüllen, gibt es mehrere Architektur-Möglichkeiten:

• Check des Outputs eines Systems mit einer kleinen Safety Hardware
• Safety Hypervisor
• Benutzung des Linux Kernels zur Isolierung von kritischem und nicht kritischem Teil

Im dritten Ansatz muss ein Teil des Linux-Kernels zertifiziert werden; dies ist die Variante, die im Projekt untersucht wird. Die Herausforderungen sind groß: So gilt es, einen Prozess zu finden, um einen Kernel mit 23 Millionen Lines of Code und einem Community-Entwicklungsprozess zu qualifizieren. Der Referent berichtete, dass, wenn er diesen Vortrag in der Sicherheitscommunity hält, die Hälfte des Publikums den Saal verlässt...

Eines der größten konzeptionellen Probleme ist, dass Safety-Software üblicherweise vor dem Hintergrund eines Safety-Prozesses entwickelt wird. Da dies für Linux nicht der Fall ist, werden die Prozesse mit den von den Normen vorgegebenen Prozessen verglichen und mögliche Lücken durch eigene Maßnahmen geschlossen. Dabei werden z.B. für Syscalls wie open() alle möglichen Varianten im System auf ihre Safety-Auswirkungen untersucht ("Hazard Driven Decomposition, Design & Development"). Weiterhin wird ein eigenes, nach dieser Methode designtes Init-Replacement entwickelt.

Neben den architekturellen Fragen werden git Commits auf bestimmte Faktoren untersucht. Der "patch impact tester" untersucht, auf welche Konfigurationen ein Patch Einfluss hat. Weiterhin wird ein minimales Kernel-Subset untersucht. Eine (durchaus fragwürdige) Annahme ist, dass bei einem Longterm-Kernel die Anzahl der gefundenen Fehler über die Zeit zurückgeht (es bleibt die Frage, ob dies nicht auch dadurch kommen kann, dass sich einfach niemand in der Community mehr für alte Kernel interessiert); das Safety-Projekt setzt somit bevorzugt besonders späte Longterm Kernel ein. Auf der positiven Seite wird ein Satz an Analyse-Tools entwickelt, die auch für die allgemeine Verbesserung der Kernel-Qualität benutzt werden können.

Industrial Grade Open Source Base Layer Development

Der zweite Vortrag behandelte die "Civil Infrastructure Platform" (CIP). Die CIP ist als Basis-Betriebssystem-Infrastruktur für Komponenten wie Züge, Ticketingsysteme, Energieverteilung, Industriesteuerungen, Gebäudeautomatisierung und Medizintechnik gedacht. Allen diesen Systemen ist gemein, dass sie sehr lange im Markt gepflegt und mit Sicherheitsupdates ausgestattet werden müssen; beispielsweise gibt es Zug-Beeinflussungssysteme, die 50 Jahre alt sind. Solche Systeme brauchen typischerweise allein mehrere Jahre, bis sie alle Entwicklungs- und Zertifizierungsschritte hinter sich gelassen haben. Die Idee ist, einen Super-Longterm-Kernel (4.4) und andere Komponenten wie ein Debian für mehr als 10 Jahre zu pflegen.

Der Vortrag hat meine Bedenken darüber, dass das CIP einen grundlegend falschen Weg verfolgt, nicht zerstreut. Einer der Vorteile von Linux ist, dass (halbwegs) moderne Kernel viel Testabdeckung und Community-Feedback und damit auch Bugfixing bekommen, während es für so alte Kernel, wie sie CIP nutzen möchte, nahezu niemanden mehr gibt, der sie testet und nachpflegt. Zudem bedeuten Kundenanforderungen in Industrie-Projekten oft, dass neue Features benötigt werden, die in so einem Setup mit viel Aufwand backgeportet werden müssen, was nach kurzer Zeit nicht mehr handhabbar ist. Der einzig praktikable Weg, solche Systeme über lange Zeit zu pflegen, ist, mittels Update-Systemen die Devices pflegbar zu halten und konstant mit soliden, noch vom Upstream gepflegten Kerneln zu versehen (siehe dazu Jan Lübbe's Vortrag Long Term Maintenance, or: How to (Mis-)Manage Embedded Systems for 10+ Years von der ELC-E 2016).

Opensource in Neuroimaging

Nach der Mittagspause berichtete Ben Dooks darüber, wie er mit Hilfe von Open Source herausgefunden hat, was die 1,2 kg Masse in seinem Kopf tut. Während viele Methoden der Visualisierung des Gehirns weiterhin aus Kostengründen nicht in Reichweite von Amateuren sind, gibt es in letzter Zeit z.B. Datenbanken mit anonymisierten Messdaten, die unter einer Creative Commons Lizenz stehen.

Eine weitere Möglichkeit der Informationsgewinnung ist, die elektrische Kommunikation zwischen Neuronen mittels EEG (Elektroenzephalographie) zu messen. Die interessanten Spannungen liegen im Bereich weniger µVolt, die Meßfrequenzen bei 1-100 Hz, und das Verfahren birgt keine bekannten gefährlichen Nebeneffekte. Es gibt einen Kickstarter-finanzierten Open Source Sensor (OpenBCI) mit 16 Kanälen, der mittels eines 3D Druckers hergestellt oder gekauft werden kann. Mit dem Setup können Gehirnwellen aufgezeichnet und Regionen im Gehirn zugeordnet werden. Daneben stehen andere Devices im Open Source Kontext bereit (Brainstorm, OpenEEG, HackEEG).

Eine andere Metode, die Magnetoenzephalographie (MEG), nutzt Magnetfelder im 10 fT Bereich zur Messung. Die Methode kann bessere Bilder erzeugen, ist allerdings sehr rauschanfällig. Ben hat an einem Gerät mitgearbeitet, das dieses Messverfahren nutzt. Das Steuerungssystem besteht aus mehreren Knoten, die die Daten mit bis zu 600 Kanälen bei 24 Bit Auflösung erfassen, speichern und in Echtzeit anzeigen. Das System basiert auf Debian, die Daten werden im HDF5 Format gespeichert und mit OpenGL und Python (NumPY, Arrow, HSPy) verarbeitet, während die Synchronisation der Messungen im FPGA stattfindet. Auch auf der FPGA-Seite wurde versucht, möglichst offene IP-Cores zu verwenden. Leider sind auf der FPGA-Seite weiterhin kaum offene Tools zu bekommen, zumindest nicht für die eingesetzte Hardware.

UBIFS Security Features

Richard Weinberger berichtete über Sicherheitsfeatures auf NAND Chips, ein Thema, was uns ebenfalls immer wieder umtreibt. Nach einer kurzen Einführung der verfügbaren Verschlüsselungsverfahren in Linux wurden diese darauf hin untersucht, welche sich für den Betrieb auf "nackten" NAND Flashes eignen.

Eine interessante Option ist fscrypt, ein Nachfolger von eCryptFS. Verschlüsselung ist direkt im Filesystem implementiert (in fs/crypto). Für jeden Knoten kann im Dateisystem eine Policy für den darunterliegenden Tree festgelegt werden; Die Keys werden dabei mittels des In-Kernel Keystores verwaltet. Dateien, für die der Benutzer keinen gültigen Schlüssel hat, werden im Directory mit einem Base 64 String angezeigt. Die Tools sind noch in Bearbeitung, werden aber in Kürze zur Verfügung stehen. Der Versuch, fscrypt auf UBIFS zu portieren, stellte sich als eine größere Herausforderung heraus. Inzwischen ist das Feature unter dem Konfig-Symbol CONFIG_UBIFS_FS_ENCRYPTION im Kernel verfügbar.

Neben Verschlüsselung ist ein zweites interessantes Feature, die Integrität des Dateisystems sicherzustellen. Hierfür gibt es die Integrity Measurement Architecture, IMA. Zur Zeit ist dieser Part allerdings noch nicht implementiert; die Frage, wie die beste Variante für eine Implementierung ausehen könnte, wird derzeit diskutiert. Eine Idee könnte sein, dass die Keys aus fscrypt wiederverwertet werden und nur der Index-Tree mit einer eigenen HMAC Summe gesichert wird. Hier sind aber noch weitere Untersuchungen nötig.

Preempt RT

Im letzten Dienstags-Track berichtete Sebastian Siewior über den Stand des RT Preempt Patches. Das Linux Foundation Collaborative Project läuft nun seit Oktober 2015, und die Patch-Kurven zeigen, dass zu Zeiten von 3.10-rt mehr oder weniger eine konstante Anzahl Patche vorhanden waren und kaum Fortschritte erzielt werden konnten. In 3.14-rt und 3.18-rt zeigen die Kurven ebenfalls nur sehr wenig Bewegung in der Patch-Statistik. Erst ab 4.4-rt zeigen die Kurven eine deutliche Bewegung, in dem Maße, in dem mehr und mehr Features angefasst wurden. Insofern zeigt offenbar die Tatsache, dass zunächst von OSADL und nun im Rahmen der Linux-Foundation die Arbeit an RT finanziert wird und nicht mehr nur ein Hobby-Projekt ist, Wirkung.

Seit 4.9 wurde intensiv an CPU Hotplug gearbeitet, dann wurde mit 4.11 das Timer Wheel überarbeitet. Aktuelle Baustellen wurden kurz skizziert, aber nicht weiter vertieft. Zur Zeit veröffentlichen die Entwickler einen RT-Patch für jeden zweiten Kernel und versuchen dabei, die LTS Kernel zu treffen.

Der Fortschritt beim RT-Projekt ist für mich weiterhin schwer einzuschätzen. Ein kurzer Blick in den aktuellen Patch zeigt viele Backports aus Upstream und weiterhin viele kleine alte Patche, bei denen von außen nicht wirklich erkennbar ist, warum sie nicht längst gemainlinet wurden. Viele andere Patche sind eher im Bereich "Tooling" angesiedelt und gehören nicht zur Kernfunktionalität. Während der Status der Patches früher noch im series File vermerkt war, fehlt diese Information inzwischen; allerdings bin ich der Entwicklung in letzter Zeit auch nicht mehr intensiv gefolgt, so dass sie anderswo zu finden sein mag.

Showcase

Im Showcase hat unser Team diesmal drei Open Source Projekte gezeigt, die zur Zeit eine große Rolle in unserer Arbeit spielen:

• Etnaviv (Open Source GPU Treiber für i.MX6)
• Labgrid (Testautomatisierung)
• RAUC (Field Upgrading)

Hierzu gab es viele interessante Gespräche.