Embedded Linux OTA Updates – Teil 1: Fundamentals & Implementation

Die Notwendigkeit für Updates

Sobald ein Embedded Linux Produkt das Labor verlässt und ins Feld eintritt, wird die Bestimmung, wie es Updates empfangen wird, zu einer kritischen Design Entscheidung.

Während eine fehlerfreie Applikation immun gegen Change scheinen mag, ist die Realität, dass Software unweigerlich Bugs akkumuliert und, für Devices, die sich mit Netzwerken oder dem Internet verbinden, Security Patches oft unvermeidbar sind. Selbst theoretisch perfekte Firmware muss Vulnerabilities in Third-Party Libraries accommodieren.

Betrachten Sie die Heartbleed Vulnerability (CVE-2014-0160), die die OpenSSL Kryptografie Library exponierte. Der Flaw affected ungefähr zwei-Drittel aller Websites und, bis heute, shippen unzählige Embedded Linux Devices noch mit ungepatchtem OpenSSL Build, was sie Exploitation aussetzt.

Block-basierte vs. File-basierte Updates

Update Mechanismen für Linux können grob in Block-basierte und File-basierte Ansätze klassifiziert werden. Block Updates überschreiben eine gesamte Partition oder Block Device in einer atomaren Operation, während File Updates einzelne Files oder Packages ersetzen – ähnlich wie „apt-get upgrade“ auf Desktop oder Server Distributionen funktioniert.

Für Embedded Linux werden Block-basierte Upgrades bevorzugt, weil das gesamte Filesystem typischerweise von einer einzelnen Build Pipeline produziert wird und der Storage Footprint eines Produkts fix ist. Das Updaten einer ganzen Partition in einem Schritt vereinfacht auch Rollback: Eine Kopie des vorherigen Images kann retained werden, bis das neue verifiziert ist.

Recovery nach Failed Update sicherstellen

Kein Device sollte in einem unusable State verbleiben, besonders wenn Power Loss oder Write Failure mid-flash auftritt. Die übliche Mitigation ist, eine Secondary Partition zu maintain, die übernimmt, wenn das Primary Image nicht bootet.

Abbildung 1. Recovery im Event eines Failures – Fallback Optionen (Quelle: ByteSnap)

Zwei gängige Patterns existieren:

• Rescue-Partition Strategie – Der Bootloader startet ein kleines Rescue Image, das das Main Firmware nach Update Completion launchen kann. Dies erlaubt dem Main Partition, den meisten Storage Space zu okkupieren, erfordert aber zwei Reboots (in Rescue, dann in Main).
• Dual-Rootfs Strategie – Zwei volle Root Filesystems werden Side-by-Side gehalten. Der Bootloader switched zwischen ihnen zur Boot Time. Wenn ein Update applied wird, wird das inaktive Image überschrieben, und nur ein Reboot ist nötig. Dieser Ansatz halbiert den verfügbaren Space per Image, aber liefert schnellere Recovery und Zero Downtime.

Wenn Storage abundant ist, wird die Dual-Rootfs Methode meist für ihre Einfachheit und Performance empfohlen. Der Rescue Ansatz ist nützlich, wenn das Main Image groß ist und der Spare Space für ein Duplikat Rootfs limitiert ist.

Beachten Sie, dass Bootloader selbst typischerweise immutable in diesem Setup sind. Um einen Bootloader zu updaten, bräuchten Sie eine zusätzliche Bootloader Partition und einen Board-Management Controller (BMC), der den Switch orchestrieren kann – eine Lösung, die Hardware Komplexität und Cost erhöht.

Abbildung 2. Recovery im Event eines Failures – Board Management Controller (Quelle: ByteSnap)

Weil der BMC extra Hardware und Firmware addiert, bevorzugen die meisten Designer, den Bootloader so klein und reliable wie möglich zu machen, sodass er nie ein OTA Update braucht.

U-Boot Environment Variables nutzen

U-Boot speichert ein Non-Volatile Environment, das von Linux gequeryed und während Boot manipuliert werden kann. Diese Variables sind ideal für Encoding der Active Partition, Tracking Boot Successes, und Orchestrierung von Failover Logic.

Typische Patterns inkludieren:

• Setting eines Flags vor Switch zum neuen Image.
• Inkrementieren einer „Boot Count“ Variable bei jedem erfolgreichen Boot.
• Resetten des Flags nach Erreichen eines Thresholds erfolgreicher Boots.

Durch Speichern dieses States in U-Boot kann der Bootloader automatisch zum vorherigen Image roll back, wenn das neue eine konfigurierbare Anzahl mal nicht bootet.

Abbildung 3. U-Boot Environment Variables (Quelle: ByteSnap)