Software Updates on Embedded Linux

Bevor man generisch über „Software-Updates“ auf einem Embedded Linux System spricht, sollte man definieren, welche Software-Teile es in einem Embedded Linux System gibt:

• Bootloader: Er ist der Einsprungspunkt des Embedded Linux Systems, sobald der Strom eingeschaltet wird, initialisiert die Hardware und startet den Linux Kernel. Der Bootloader kann meist auch einfache externe Dateisysteme mounten (z.B. USB-Update-Sticks) oder einfache Netzwerk-Protokolle zum Flashen einer Partition nutzen, bevor das Linux-Betriebssystem hochgefahren ist. Der Bootloader ist bei Embedded Linux Systemen häufig in einem speziellen Speicherbereich abgelegt.
• Linux Kernel: Hier laufen im Betrieb alle Fäden zusammen: CPU-, RAM- und Dateisystem-Verwaltung, Scheduler,… Der Linux-Kernel wird manchmal separat vom Linux-Filesystem abgelegt (z.B. in einer eigenen Boot-Partition), kann aber auch Teil des Root File Systems sein.
• Root File System: Das komplette Dateisystem des gesamten Linux System mit System-Dateien, allen installierten Bibliotheken und Verzeichnisse für Logs.
• Data Partition: Diese ist optional, aber viele Embedded Linux Systeme haben eine separate Partition, auf welcher nur Anwendungsdaten abgelegt wird. Dies hat auch den Vorteil, dass man das Root-File-System „Readonly“ machen kann und nur die Data-Partition für Anwendungsdaten beschreibbar ist.
• Applikation: Die Applikation ist entweder Teil des Root File Systems oder liegt auf der Data-Partition. Hier kann es sich um einen einzigen Prozess handeln (z.B. eine Qt-Anwendung), oder es handelt sich um mehrere Prozesse, welche über Interprozess-Kommunikation zusammenarbeiten.
• Externe Hardware: Diese ist über Bus-Systeme (z.B. CAN-Bus, Ethernet,..) an die Embedded Linux Platine angeschlossen und soll bei einem Software-Update gegebenenfalls auch aktualisiert werden können.

Meist gibt es zwei grundsätzlich verschiedene Software-Update Typen: Applikations-Software-Update: Hier wird nur die Anwendung, welche am Linux-System läuft, aktualisiert. Meist reicht die Kopie eines einzigen Binaries oder eines kleinen ZIP-Archivs. Das Embedded-Linux-System muss nicht neu gestartet werden, nur die Anwendung selbst wird meist neu gestartet. Dieser Start ist meist in wenigen Sekunden erledigt, sodass dies der Endanwender häufig kaum bemerkt. Dieses Update wird meist Anwendungs-spezifisch implementiert und ist häufig vom Update-Zyklus des restlichen Linux-Systems entkoppelt. Linux-System-Update: Hier wird meist mindestens eine relevante Linux-System-Komponente aktualisiert: Bootloader, Root-Filesystem und/oder Kernel. Meist wird das Root-Filesystem und der Kernel in einem Zug aktualisiert. Technisch relevant hier ist jedoch, dass ein laufendes Embedded-Linux-System sich nicht (sinnvoll und sicher) selbst überschreiben kann und es somit eine Strategie braucht, wie ein neues Linux-System kopiert werden kann. Linux-System-Update Strategien sind unter anderem:

• Bootable USB update stick / recovery partition
• A/B system updates
• Delta updates
• Container-based updates

Bootable USB Update Sticks: Sehr verbreitet sind bootfähige USB-Update-Sticks, welche selbst ein kleines Betriebssystem beinhalten und von denen dann das neue Linux-System geflasht wird. Technisch gesehen funktioniert es ähnlich wie bei einer „recovery partition“, nur dass im Falle des USB-Sticks die recovery partition eben auf dem USB Stick abgelegt wird. Größter Nachteil hier ist, dass es jeweils einen Reboot-Vorgang braucht, um zuerst zur Update-Software, und dann weiter noch einmal einen Reboot Vorgang braucht, um wieder in den normalen Betriebszustand zu kommen. Software-Over-The-Air-Updates können so nur bedingt gut umgesetzt werden. A/B System Updates: Hier wird der lokale Flash-Speicher von vornherein so aufgeteilt, dass es permanent zwei Linux-System-Partitionen am Embedded Gerät gibt, aber nur eines davon aktiv ist (Active/Passive Linux System). Im Falle eines Linux-System-Updates überschreibt dann das aktive Linux-System das passive Linux-System und setzt am Ende des Updates-Vorgangs in einer atomaren Operation die Variable im Bootloader so, dass beim nächsten Neustart die bisher passive Partition nun zur neuen aktiven Partition wird. Dies hat den großen Vorteil, dass ein Linux-System-Update während des gesamten Update-Vorganges den User-Space nicht verlassen muss, und nur genau ein Reboot-Vorgang am Ende des erfolgreichen Updates vorgenommen werden muss. Sollte der Update-Vorgang scheitern (weil z.B. während des Update-Vorgangs der Strom ausfällt), kann das Gerät nach wie vor normal booten und den Update-Vorgang einfach erneut starten. Gerade wenn hohe Verfügbarkeit und ein sicherer Betrieb von Embedded Geräten wichtig ist, ist diese Methode sehr vorteilhaft. Delta Updates haben den Vorteil, dass nicht das gesamte Linux-System als Update-Datei übertragen werden muss, sondern nur die Differenz-Dateien zur neuen aktualisierten Version. Um eine eindeutige Reproduktion mit den Differenz-Daten zu gewährleisten, ist es technisch notwendig, das Root-File-System als read-only zu betreiben. (Abgesehen davon: Auch ohne der Nutzung von Delta-Update ist ein „Read-Only-Betrieb“ des Linux-Root-File-Systems sinnvoll). Häufig werden Delta-Updates in Kombination mit einer A/B System Update Strategie genutzt. Container-based Updates nutzen die flexiblen Möglichkeiten von Containern, um ein Gesamtsystem in einer eingegrenzten Ausführungsumgebung zu starten. In diesem Fall kümmert sich dann die Container-Software um den reibungslosen Austausch auf den neuen Container. Größte Hürde hier ist, dass das gesamte Linux-System sich dieser Container-Technologie unterwerfen muss, und hier eine zusätzliche Indirektionsschicht hinzukommt. Dass Container-Updates auch auf Embedded Systemen nutzbar sind zeigt z.B. Torizon von Toradex. Am Desktop haben sich Container-based Updates bereits auf breiter Linie etabliert. Weiters muss noch unterschieden werden, wie die Software Update Daten auf das Embedded Gerät kommen: Lokale Software Updates: Um ein Software-Update zu machen, ist die physische Präsenz eines Technikers vor Ort notwendig. Meist wird ein USB-Stick genutzt, aber auch der physische Austausch einer SD-Karte ist manchmal noch anzutreffen. Insbesondere bei großen Stückzahlen ist eine reine lokale Software-Update Strategie ungeeignet, da jedes Software Update auch beträchtliche (Arbeitszeit-)Kosten verursacht. Weiters ist zu bedenken, dass am Embedded Gerät physisch auch Zugang zur Datenschnittstelle vorhanden sein muss. Remote Software Updates (Over The Air Software Updates): Software-Updates können von der Ferne gemacht werden, physische Präsenz eines Technikers vor Ort ist nicht notwendig. Meist befinden sich die Geräte in einem Wifi Netz oder sind an ein Telematik-Modul oder einem Internet-Router angeschlossen. In manchen Fällen verfügt das Embedded Linux Gerät sogar selbst über eine SIM-Karte und kann selbstständig eine Internetverbindung herstellen. Die zentrale Verwaltung aller Geräte mit Software Updates wir meist komfortabel in einem „Fleet Management“ System umgesetzt, welches neben den aktuellen Software-Versionen auch weitere Daten aller ausgelieferten Geräte zugänglich macht (Logs, aktuelle Fehler, Standort,…) Unter optimalen Voraussetzungen erfüllt ein Embedded Linux System folgende Anforderungen für ein modernes Software-Update-System:

• Updates via USB Stick: Wenn eine Online-Verbindung nicht möglich ist, soll ein USB-Stick als Datenquelle für das Update möglich sein.
• Automatische Updates via Internet: Stichwort OTA – Over The Air Software Updates: Das Software-Update kann entweder manuell vom Benutzer angestoßen und durchgeführt werden, oder je nach Möglichkeit können auch automatische Updates aktiviert werden, sodass der Benutzer nur mehr den Zeitpunkt des Neustarts festlegt.
• Cloud Fleet Management: Es soll eine gewisse Plattform zur Administration von Software-Updates in der Cloud zur Verfügung stehen. Hier können dann auch zusätzliche Geräte-Analysedaten, Logs oder Funktionen zur Fernwartung mit abgelegt werden. Häufig gibt es auch die Möglichkeit, dass der Hersteller (falls er die Zustimmung vom Kunden erhält) selbstständig Hot-Fixes bzw. Software-Updates auf das Gerät aufspielen kann. Auch die Möglichkeit von der Ferne Einzelzugriff auf ein Gerät zu erhalten um Fehler zu korrigieren oder dem Benutzer bei einer Fehlersituation zu helfen, wird häufig gleich mit integriert.
• Robustheit: Hier geht es um die Absicherung des Update-Vorgangs selbst. Stichwort hier ist „Fail Safe Update & Rollback“. Sollte während dem Update-Vorgang etwas schiefgehen (z.B. Strom fällt aus), soll es nicht zu einem unbrauchbaren Gerät (bricked device) führen. Stattdessen soll das Gerät erkennen, dass der Update-Vorgang nicht vollständig abgeschlossen werden konnte und nutzt dann die bisher noch funktioniertende Linux-Software am Gerät. In weiterer Folge kann dann das Software-Update erneut gestartet werden.
•  Sicherheit: Hier kann man in mindestens drei Kategorien unterteilen:
  • Trusted source: Es muss gewährleistet werden, dass Software-Update-Daten nur von einer einzigen vertrauenswürdigen Quelle auf das Gerät kopiert werden können.
  • Original: Es muss gewährleistet werden, dass die betriebene Software am Gerät selbst der originalen Herstellersoftware entspricht und nicht (mutwillig) von jemanden verändert wurde. (Siehe auch Secure Boot)
  • Confidential: Daten von vertrauenswürdiger Art (insbesondere personenbezogene oder sicherheitsrelevante Informationen) müssen verschlüsselt werden und dürfen nicht über ungesicherte Kanäle transportiert werden.
• Vollständig: Es soll möglich sein sämtliche Linux-System-Teile zu aktualisieren, auch den Bootloader.
• Benutzerfreundlich: Der Software-Update Vorgang soll für den Endbenutzer so angenehm wie möglich umgesetzt werden. Ideal sind Status-Informationen während dem Software-Update-Vorgang inklusive einer groben Zeitabschätzung, wie lange das Update noch dauern wird (Fortschrittsanzeige).
• Integrationsfähig: Idealerweise muss der Benutzer nicht sein gewohntes Software-Umfeld verlassen, um ein Software Update durchzuführen. Ein Click auf den „Software-Update“ Button in den Einstellungen sollte genügen, um einen Update-Vorgang anzustoßen. Dies bedeutet jedoch auch, dass sämtliche Software-Updates auch in die Geräte-Software als Vorgang integriert werden können müssen.
• Anpassbar: Je nach Komplexität des Gerätes ist es unter Umständen notwendig, vor oder nach dem Software Update Vorgang Daten zu exportieren, zu migrieren oder auf neue Datenquellen umzustellen. Die Nutzung von sogenannten „Hooks“ (z.B. pre-install, post-install,…) soll ermöglicht werden.
• Linux-Build-System-Support (=Yocto Support): Es soll möglich sein, ein finales Linux-Image inklusive dem Update System zu bauen.

  Build vs. Open-Source vs. Buy? Ein Linux-Update System selbst zu bauen ist ein aufwändiges Unterfangen. Um auch in Zukunft die Anforderungen an Sicherheit und Integrationsfähigkeit in Linux-Build-Systeme zu unterstützen, ist es sicherlich klug, sich an bisher erfolgreichen Systemen zu orientieren. In letzter Zeit sind auch Systeme am Markt aufgetaucht, welche per se Open Source sind, die erweiterte Nutzung in der Cloud dann aber mit einer kommerziellen Version verfügbar sind (z.B. Mender.io). Hier eine kurze unsortierte Auswahl:

• Update agents: SWUpdate, RAUC, Swupd, Mender, OSTree, Torizon
• Update Cloud solutions: Mender, Torizon, qbee.io, Balena.io, AWS IoT

Aus unserer Sicht hat SWUpdate in den letzten Jahren immer eine gute Figur gemacht: Open Source, umfangreich dokumentiert, Unterstützung von Yocto, häufig auch von größeren Herstellern verwendet und unterstützt. Die fehlende Cloud-Schnittstelle muss entweder selbst umgesetzt werden, oder man setzt auf Projekte wie qbee.io oder Balena.io. Mender erfährt ebenfalls viel Aufmerksamkeit, sodass wir uns entschlossen haben, eine Bachelor-Arbeit im Umfeld Mender.io durchzuführen (siehe Video unten). Bisher hatten wir bei unseren zahlreichen embedded Projekten jedoch noch keinen konkreten Fall, wo ein Kunde mender.io tatsächlich eingesetzt hat. Bedenkt man die steigenden Anforderungen an Software-Update-Systeme, macht es jedenfalls Sinn, sich mit den erfolgreichen bestehenden Systemen auseinanderzusetzen, um das Beste für sein Projekt herauszuholen. Interesse? Kontaktieren Sie mich unter für einen persönlichen Austausch!