OTA-Updates für Embedded Linux, Teil 1 – Grundlagen und Implementierung

Der Bedarf an Updates

Sobald ein Embedded-Linux-Produkt das Labor verlässt und in die Praxis eingetreten ist, wird die Frage, wie das Gerät aktualisiert werden soll, immer wichtiger.

Updates sind nicht immer notwendig, aber es ist schwer an Software zu denken, die keine Fehler aufweist, die irgendwann entdeckt werden. Selbst wenn Ihre Software perfekt ist, können Sicherheitsupdates erforderlich werden, wenn das Gerät über Netzwerke oder das Internet mit Open-Source-Bibliotheken kommuniziert.

Nehmen Sie das Beispiel von CVE-2104-01650 (Heartbleed). Diese Schwachstelle betraf die OpenSSL-Kryptografiebibliothek und damit auch zwei Drittel der Websites im Netz. Sogar jetzt, drei Jahre später, gibt es viele Embedded-Linux-Geräte, auf denen eine unverteidigte Version von OpenSSL läuft, die für Angriffe weit offen ist.

Blockieren vs. Dateiaktualisierungen

Wenn Sie über das Aktualisieren von Linux sprechen, werden möglicherweise "Block"- und "Datei"-Aktualisierungssysteme erwähnt. Dies bezieht sich auf das Aktualisieren einer gesamten Partition auf einmal, indem direkt auf das Blockgerät geschrieben oder einzelne Dateien aktualisiert werden, um das Update durchzuführen. Möglicherweise kennen Sie Dateiaktualisierungssysteme von Desktop- oder Server-Linux (z. B. „sudo apt-get upgrade“).

In Embedded Linux sind blockbasierte Upgrades aufgrund ihrer Atomarität und der Tatsache, dass ein ganzes Dateisystem normalerweise die Ausgabe eines Embedded Linux-Buildsystems ist, der richtige Weg. Wir erwarten, dass der Speicherplatz auf jedem eingebetteten Gerät für ein bestimmtes Produkt konstant ist, daher erstellen wir jedes Mal dieselbe Partitionsgröße. Diese Art von Update geht Hand in Hand mit einer Art Fallback- oder Recovery-Image.

Wiederherstellung im Fehlerfall

Wir möchten niemals, dass das Gerät in einem unbrauchbaren Zustand bleibt (wenn beispielsweise ein Stromausfall auftritt). Wir können dies lösen, indem wir sicherstellen, dass es immer möglich ist, auf eine andere Partition „zurückzugreifen“, falls beim Update-Prozess etwas schief geht.

Abbildung 1. Wiederherstellung im Fehlerfall – Fallback-Optionen (Quelle:ByteSnap)

Oben sehen Sie zwei mögliche Implementierungen eines Fallback-Modus bei einem Stromausfall. Auf der linken Seite bootet der Bootloader eine Rettungspartition, die dann in eine Hauptpartition bootet. Auf der rechten Seite bootet der Bootloader eine von zwei Partitionen basierend auf einem Schalter.

Der Bootloader sollte eine Methode implementieren, um festzustellen, ob ein Bootvorgang erfolgreich war, und wenn nicht, sollte er zur Rettungspartition (linkes Diagramm) oder zur vorherigen Arbeitspartition (rechtes Diagramm) zurückkehren.

Bei der Rescue-Methode (links) kann der Hauptpartition mehr Platz zur Verfügung gestellt werden, während bei der Dual-Rootfs-Methode (rechts) der Platz mehr oder weniger gleichmäßig auf die beiden Partitionen aufgeteilt werden muss. Wenn der Platz kein Problem darstellt, wird empfohlen, die dual-rootfs-Methode zu verwenden, nur weil dies zu weniger Ausfallzeiten führt. Das Aktualisieren über die Rescue-Methode erfordert zwei Neustarts, einen in die Rescue-Partition und dann einen weiteren zurück in die Hauptpartition. Die Dual-Rootfs-Methode erfordert nur einen Neustart, da das Update jederzeit durchgeführt werden kann.

Was Sie in diesen Systemen nicht sicher aktualisieren können, ist der Bootloader (oder tatsächlich die Rettungspartition). Wenn Sie auch den Bootloader aktualisieren möchten, benötigen Sie zwei separate Bootloader-Partitionen und eine Art Board-Management-Controller, um die Logik des Umschaltens zwischen den beiden zu implementieren.

Abbildung 2. Wiederherstellung im Fehlerfall – Board Management Controller (Quelle:ByteSnap)

Dies ist natürlich eine komplizierte Lösung, die einen zusätzlichen Mikrocontroller, eine neue Firmware und ein komplizierteres Hardware-Design erfordert (es wird in einigen Geräten verwendet, die beispielsweise einen separaten Intelligent Platform Management Interface (IPMI)-Controller enthalten) . Daher sollten Sie darauf abzielen, einen Bootloader zu erstellen, der funktional und klein ist und daher nicht aktualisiert werden muss.

U-Boot-Umgebungsvariablen

U-Boot implementiert eine nichtflüchtige „Umgebung“, in der Variablen gespeichert werden können. Auf diese kann sogar von Linux aus zugegriffen werden (auf verschiedene Weise, je nachdem, wie die Umgebung gespeichert ist, wie auf elinux.org beschrieben.

Dies ist der naheliegendste Weg, den oben beschriebenen „Schalter“ zu implementieren. Es kann auch verwendet werden, um Informationen über vorherige Boot-Erfolge oder -Fehler zu speichern, sodass im Falle eines Boot-Fehlers der Switch rückgängig gemacht und eine funktionierende Partition wiederhergestellt werden kann.

Abbildung 3. U-Boot-Umgebungsvariablen (Quelle:ByteSnap)