Software-Updates im Produktlebenszyklus Always change a running system

Bei der Elektronikentwicklung spielen Design, Software und die Update-Fähigkeit eine wichtige Rolle.
Bei der Elektronikentwicklung spielen Design, Software und die Update-Fähigkeit eine wichtige Rolle.

Wenn ein Gerät im Einsatz ist, gilt es sicherzustellen, dass es den Anforderungen eines langjährigen Lebenszyklus gerecht wird. Die Grundlagen dafür müssen bereits im Design gelegt werden – und dabei spielen Software und Update-Fähigkeit eine ebenso wichtige Rolle wie die Hardware selbst.

Product Change Management ist ein anerkanntes Thema in Bezug auf Hardware. Die geschickte Auswahl der Bauteile beim Design ist entscheidend für Änderungsaufwand und Zukunftsfähigkeit der Elektronik. Doch neben der Hardware wächst die Bedeutung von Software und Update-Fähigkeit: Mit der zunehmenden Vernetzung sind immer mehr Systeme im Internet exponiert. Zudem steigt die Bedeutung der erhobenen Daten und damit die Gefahr vor unerlaubten Zugriffsversuchen. Gleichzeitig vereinfacht die hohe Standardisierung von Protokollen und Hardware den Zugang zu Systemen, sobald eine Sicherheitslücke ausgenutzt wurde.

Die steigende Zahl der gefundenen Sicherheitsrisiken – Spectre und Meltdown haben es ja sogar in die Aufmerksamkeit der Massenmedien geschafft – zeigt eindrucksvoll, wie sich die Bedrohungslage in den letzten Jahren verändert hat.

»Never change a running system« gilt nicht mehr

Unter diesen Umständen müssen immer mehr elektronische Geräte über ihren gesamten Lebenszyklus hinweg ein Höchstmaß an Security bieten und ermöglichen, auf Sicherheitslücken und Bedrohungen zu reagieren. »Never change a running system« darf nicht mehr gelten, wenn Sicherheitslücken nicht verhindert werden können und geschlossen werden müssen.

In dieser Situation müssen die Voraussetzungen geschaffen werden, entsprechende Patches schnell und ohne großen Aufwand zu implementieren. Phytec trägt dem Rechnung und setzt für seine Board Support Packages weitgehend auf die Vorteile von Mainline-Linux. Der OpenSource-Ansatz sorgt für stabilen, vielfach erprobten Code, für schnelle Bug- und Security-Fixes und die Pflege und Weiterentwicklung von Treibern durch die Community. Dabei spielt die Aktualität der verwendeten Software eine große Rolle: Häufig sind Patches zum Schließen von Sicherheitslücken nur für die aktuellsten Betriebssystemversionen verfügbar. Ältere Versionen folgen erst verspätet, wenn sie überhaupt noch mit Patches versorgt werden.

Vom Hersteller-BSP zur Mainline-Unterstützung

Im x86-Bereich ist es schon seit vielen Jahren üblich, dass neue Bausteine bereits bei Markteinführung mit Mainline-Linux-Implementierungen angeboten werden. Mainline bedeutet, dass der Linux-Kernel ohne Modifikationen/Patches verwendet werden kann. Bei ARM-basierten Controllern hingegen ist es üblich, dass ein neuer Controller zunächst mit einem Hersteller-BSP (Board Support Package) ausgestattet ist. Darunter wird eine Linux-Implementierung des Chipherstellers verstanden, die in der Praxis tausende Patches gegen Mainline enthält und oft auch mit proprietärem Code angereichert ist, etwa zur Ansteuerung von Einheiten zur Grafikbeschleunigung. Auch für ARM gibt es Mainline-Implementierungen, aber aufgrund der vielfältigen Peripherie-Konfigurationen dauert es meistens sehr lange, bis ein Controller mit seinem vollständigen Feature-Set unterstützt wird.

Zur Pflege der Chip-spezifischen Patches ist häufig das Insiderwissen des Chiphersteller erforderlich. Trotz Open Source entsteht faktisch eine Abhängigkeit von der Pflege des Betriebssystems durch den Chiphersteller. Verschärfend kommt hinzu, dass der Chiphersteller sein Interesse an der Betriebssystempflege nach ein paar Jahren verlieren wird, spätestens dann, wenn die Neudesigns mit dem entsprechenden Controller deutlich zurückgehen. Aufgrund des hohen Pflegeaufwands der vielen Patches und weil dieser sehr weitgehend am Hersteller hängt, ist es um die Aktualität der Hersteller-BSPs im Allgemeinen nicht besonders gut bestellt.

Aber es gibt gute Nachrichten: Die Linux-Community schafft es, in relativ kurzer Zeit den Umfang der Feature-Unterstützung in Mainline für neue Controller deutlich zu verbessern. Alternative Ansätze für proprietäre Codeanteile (z. B. ETNAVIV für die Grafikbeschleunigung) finden weite Unterstützung und damit eine hohe Verbreitung. Als zweite gute Nachricht kann die zunehmende Akzeptanz (oder besser gesagt die zunehmende Einsicht) der Halbleiterhersteller für Mainline genannt werden. Es ist damit zu rechnen, dass die Halbleiterhersteller ihre Aktivitäten rund um Mainline deutlich ausbauen. Dies ist die logische Konsequenz des geschilderten Szenarios.

Die Frage, ob ein Unternehmen, das ein neues Produkt entwickelt, gleich auf Mainline setzt oder mit dem Hersteller-BSP startet, hängt schlichtweg von der Unterstützung der Features ab, die in der Anwendung benötigt werden. Es kann aktuell durchaus zwischen einem und drei Jahren dauern, bis die Mainline-Unterstützung wirklich einen Controller in allen Facetten optimal unterstützt. In dieser Zeit wird das Hersteller-BSP typischerweise sehr gut gepflegt (wenn auch, wie ausgeführt, ggf. in älteren Versionen). Praktisch gesehen führt für ein nachhaltiges Patch-Management kein Weg an einem Umstieg auf Mainline vorbei. Es ist also nur eine Frage der Zeit, wann der Einstieg in Mainline erfolgen soll.