Autoren: Matthias Schaff und Dominik Helleberg, inovex GmbH<\/p>\n
Im Embedded-Bereich gibt es kaum ein Lastenheft ohne die Anforderung, die Firmware eines linuxoiden, eingebetteten Systems im Feld aktualisieren zu k\u00f6nnen. Die Umsetzung hierf\u00fcr ist vielf\u00e4ltig: Vom Vor-Ort-Termin eines Technikers \u00fcber das Versenden von CF-Cards bis hin zur Selbst-Flash-Anleitung f\u00fcr den Kunden ist alles dabei. Im Zeitalter des IoT, von Industrie 4.0 und der damit Einzug haltenden allgemeinen Vernetzung der Komponenten erscheinen diese Vorgehensweisen geradezu antiquiert. Ein moderner Update-Mechanismus arbeitet vollautomatisch, w\u00e4hrend weder Sicherheit noch Stabilit\u00e4t des Prozesses darunter leiden. Im Folgenden wollen wir neben den Anforderungen an solch einen Prozess kurz verschiedene Update-Architekturen besprechen, um abschlie\u00dfen den Android FOTA-Prozess im Detail zu beleuchten.<\/strong><\/p>\n Die dominierende Anforderung an einen FOTA-Mechanismus ist Stabilit\u00e4t. Darunter fallen Punkte wie das \u00dcberstehen von Stromausf\u00e4llen w\u00e4hrend des Update-Vorgangs und der Umgang mit fehlerhaften Update-Paketen (bedingt durch \u00dcbertragungs- oder Speicherfehler). Neben der Stabilit\u00e4t ist Sicherheit von zentraler Bedeutung: Nur echte, vom Hersteller passend signierte FOTA-Updates sollen akzeptiert werden, und der Vorgang soll keine Einfallstore f\u00fcr Angreifer \u00f6ffnen.<\/p>\n Bei der Bewertung verschiedener Update-Architekturen ist zu beachten, dass die Komponenten eines eingebetteten Systems mit unterschiedlichen Update-Risiken verbunden sind. Ebenso ist die zu erwartende Update-H\u00e4ufigkeit von Komponente zu Komponente unterschiedlich. Je n\u00e4her sich eine Komponente an der Hardware befindet, desto seltener wird sie upgedatet, aber desto h\u00f6her ist das Risiko. Jede Update-Architektur positioniert sich hierbei unterschiedlich in der Abw\u00e4gung zwischen H\u00e4ufigkeit und Risiko. Welcher Fokus dabei der Richtige ist, l\u00e4sst sich nicht pauschal sagen, sondern ist von Fall zu Fall individuell zu entscheiden.<\/p>\n Im Folgenden sollen drei Update-Architekturen genauer dargestellt und deren Vor- und Nachteile kurz erl\u00e4utert werden. In allen F\u00e4llen ist der Ablauf \u00e4hnlich: Das System, welches aktualisiert werden soll, initiiert den Updateprozess, nachdem es erfolgreich ein Update-Paket heruntergeladen und ggf. verifiziert hat. Dabei wird in einem vom Bootloader zug\u00e4nglichen persistenten Speicher des aktuell laufenden Systems eine Boot-Markierung (boot-flag) gesetzt und anschlie\u00dfend ein Reboot initiiert. Der Bootloader \u00fcberpr\u00fcft das boot-flag und startet ggf. den Update-Vorgang. Erst nach einem erfolgreichen Boot des upgedateten Systems wird das boot-flag wieder zur\u00fcckgesetzt.<\/p>\n Der Bootloader agiert als eigenst\u00e4ndiger Updater. Moderne Bootloader k\u00f6nnen auf block- oder flashbasierte Dateisysteme zugreifen und eignen sich daher als Updater. Jedoch mangelt es in einer so eingeschr\u00e4nkten Arbeitsumgebung normalerweise an notwendigen Werkzeugen, um einen stabilen Updateprozess durchzuf\u00fchren. Grunds\u00e4tzlich kann diese Funktionalit\u00e4t komplett im Bootloader integriert werden, jedoch ist dabei zu beachten, dass der Bootloader nicht ohne Grund so minimalistisch gehalten ist: Er ist ein elementarer Teil eines Systems, und jedes Feature ist eine potentielle Fehlerquelle, zudem ist ein Bootloader-Update risikoreich. Daher sollte man davon absehen, weitere Komplexit\u00e4t in den Bootloader zu bringen, und stattdessen das eigentliche Update einem daf\u00fcr besser geeignetem Systemteil \u00fcberlassen.<\/p>\n Das eingebettete System enth\u00e4lt zwei komplett funktionsf\u00e4hige Betriebssysteme inklusive aller Devicetreiber und jeweils einem Kernel. Es ist je nur eine Version des Betriebssystems gebootet, und diese kann damit das aktuell inaktive System aktualisieren. Das boot-flag zeigt dabei an, welches der beiden Systeme gebootet werden soll. Erst nach einem erfolgreichen Flashvorgang und dem erfolgreichen Abgleich der Pr\u00fcfsumme wird das boot-flag getoggelt. Damit ist stets eine funktionsf\u00e4hige Systemversion vorhanden. Im Fehlerfall kann jederzeit wieder auf die Vorg\u00e4ngerversion zur\u00fcckgewechselt werden. Das System ist immer im normalen Betriebsmodus, die Ausfallzeiten durch das Update sind minimal und der Bedarf an Speicherplatz verdoppelt sich.<\/p>\n Diese Architektur \u00e4hnelt der „OS-Switching“ Architektur, mit dem Unterschied, dass nur ein System \u00fcber den vollen Funktionsumfang verf\u00fcgt, das Zweite dient nur dem Updatevorgang. Dazu beinhaltet es einen eigenen Kernel und alle Devicetreiber, aber nur eine kleine Anzahl Userland-Tools, die Funktionalit\u00e4ten wie Flashen und Verifizieren abdecken. Meist wird das Recovery-OS wird vom Haupt-OS aktualisiert, welches ebenfalls die notwendigen Tools beinhaltet.<\/p>\n Der Android-Updateprozess basiert auf der zuletzt vorgestellten Recovery-OS-Architektur. Dabei l\u00e4sst sich der gesamte Prozess in vier Stufen aufteilen, die untereinander eng verzahnt sind und ineinander greifen. Das Ergebnis ist ein sehr robuster, sicherer und flexibler Updateprozess, der sich in der Praxis schon millionenfach bew\u00e4hrt hat.<\/p>\n Der Android-Updateprozess ist best\u00e4ndig gegen \u00dcbertragungsfehler und Unterbrechungen und stellt die Integrit\u00e4t und Authentizit\u00e4t von Update-Paketen sicher. Zudem sind die Update-Pakete auf minimale Gr\u00f6\u00dfe getrimmt, um die zu \u00fcbertragende Datenmenge so klein wie m\u00f6glich zu halten (Delta-Updates). Die genaue Umsetzung wollen wir im Folgenden betrachten.<\/p>\n Das Paketformat f\u00fcr ein Android-Update ist ein gew\u00f6hnliches, digital signiertes ZIP-Archiv. Die Partitionen und Verzeichnisstrukturen des Android-Systems finden sich auch im Update-Paket wieder: Das „recovery-Verzeichnis enth\u00e4lt die Updates des Recovery-OS, das „system“-Verzeichnis analog alles f\u00fcr das Android-OS.<\/p>\n Kernel und\u00a0 „root“ Dateisystem des Android-OS werden als „boot.img“ ausgeliefert. Da sich Recovery-OS und „root“ Dateisystem des Android-OS nur minimal unterscheiden, wird das Recovery-OS als Bin\u00e4r-Diff aus dem boot.img generiert.<\/p>\n Das Verzeichnis „META-INF“ enth\u00e4lt neben den Signaturinformationen, sowie dem Public-Key zur Verifikation eine Datei namens „updater-script“. Dieses Script beschreibt in Androids „edify“ Scriptspache jeden der einzelnen Schritte des Updates. „edify“ wurde extra f\u00fcr Update-Aufgaben geschaffen, um unter anderem ein einfaches Mounten, Formatieren, Kopieren und Patchen von Partitionen bzw. Dateien zu erm\u00f6glichen.<\/p>\n Als letzter relevanter Teil des Update-Pakets ist die Binary „update-binary“ zu nennen. Diese ist der Script Interpreter, welcher das edify Script ausf\u00fchrt. Dieser wird von Recovery-OS gestartet und f\u00fchrt das eigentliche Update aus. Durch diesen Aufbau ist das Update-Paket an keine bestimmte Recovery-OS-Version gebunden.<\/p>\n Das Update-Paket ist ein Build Artefakt aus dem Android AOSP Buildsystem und wird vollkommen automatisch erzeugt. F\u00fcr ger\u00e4tespezifische Anpassungen verf\u00fcgt das Buildsystem \u00fcber entsprechende Schnittstellen f\u00fcr Plugins. Bei der Erstellung eines Update-Pakets kann einen Ausgangsversion mit angegeben werden. So kann das Buildsystem ein inkrementelles Update erzeugen, welches nur Unterschiede zur Ausgangsversion enth\u00e4lt. In diesem Fall wird pro Datei nur ein Bin\u00e4r-Diff zur entsprechenden Vorg\u00e4ngerversion als Patch im Update-Paket gespeichert, was gerade bei kleinen Bugfix-Firmware-Updates die Dateigr\u00f6\u00dfen extrem reduziert.<\/p>\n Teil 1 – Android-OS: Herunterladen, Verifizieren, Neustarten<\/strong><\/p>\n Android macht keine Vorgaben, wie das Update-Paket auf das System kommt. Im Normalfall \u00fcberpr\u00fcft eine App bei bestehender Internetverbindung ob ein neues Update-Paket auf einem zuvor konfiguriertem Update-Server verf\u00fcgbar ist. Ist das der Fall, so wird es nach einer expliziten Best\u00e4tigung des Users heruntergeladen. Da es sich nur um ein Zip-Archiv handelt, kann es sowohl via USB als auch \u00fcber eine SD-Karte auf das System gebracht werden.<\/p>\n Anschlie\u00dfend wird die digitale Signatur des Update-Pakets mittels\u00a0RecoverySystem.verifyPackage()<\/span>\u00a0kontrolliert, bevor die Installation startet. Die Signatur wird gegen die OTA-Public-Keys [1], welche im Android-OS hinterlegt sind, \u00fcberpr\u00fcft. Folglich kann man nur ein g\u00fcltiges Update-Paket erzeugen, wenn man \u00fcber die entsprechenden Private-Keys verf\u00fcgt.<\/p>\n Bei passender Signatur wird mittels\u00a0RecoverySystem.installPackage()<\/span>\u00a0der Installationsvorgang gestartet. Dieser Aufruf erzeugt zun\u00e4chst eine command – Datei [2], welche die vom Recovery-OS auszuf\u00fchrenden Aktionen enth\u00e4lt. In unserem Falle w\u00e4re der Inhalt beispielsweise “ –update-package=\/data\/update.zip“.<\/p>\n Im letzten Schritt des ersten Teils wird mit\u00a0PowerManager.reboot(PowerManager.REBOOT_RECOVERY)<\/span>\u00a0das boot-flag gesetzt und ein Reboot ins Recovery-OS angesto\u00dfen. Das boot-flag selbst wird erst beim Kernelaufruf f\u00fcr den Reboot gesetzt.<\/p>\n Teil 2 – Recovery-OS: Verifizieren, Entpacken, Ausf\u00fchren<\/strong><\/p>\n Beim Bootvorgang wertet der Bootloader das boot-flag aus und bootet entsprechend das Recovery-OS, welches am Ende die „recovery“ Binary startet. Diese verifiziert nun die Signatur des Update-Pakets erneut, nun jedoch gegen die Recovery-OS gespeicherten Public-Keys [3]. Bei Erfolg wird nun die update-binary aus dem Update-Paket entpackt und ausgef\u00fchrt.<\/p>\n Teil 3 – Update-Binary: Update Einspielen<\/strong><\/p>\n Die update-binary beginnt nun mit der Interpretation des update-script [4] und f\u00fchrt die somit eigentliche Aktualisierung des Android-OS aus. Im Falle eines inkrementellen Updates wird die zu patchende Datei zun\u00e4chst kopiert, dann gepatched und eine Pr\u00fcfsumme gebildet. Nur wenn diese mit der im update-script angegebenen Pr\u00fcfsummer \u00fcbereinstimmt, wird die gepatchte Datei zur\u00fcckgeschrieben. Da sich das Recovery-OS nicht selbst im laufenden Betrieb flashen kann, werden hier der Patch, welcher das Recovery-OS aus dem boot.img erzeugt, sowie ein Shellscript[5], welches diesen Patch anwendet, auf die Systempartition des Android-OS geschrieben.<\/p>\n Nach erfolgreichem Update geht der Kontrollfluss zur\u00fcck zur recovery Binary, welche das boot-flag wieder zur\u00fccksetzt und einen Reboot initiiert.<\/p>\n Teil 4 – Android-OS: Recovery updaten und aufr\u00e4umen<\/strong><\/p>\n Der Bootloader startet nun das aktualisierte Android-OS zum ersten Mal. W\u00e4hrend des Init-Prozesses wird nun das im Recovery-OS kopierte Shellscript zur Installation des Recovery-OS ausgef\u00fchrt. Dieses berechnet die Pr\u00fcfsumme der Recovery-OS-Partition. Sollte diese nicht dem neuen Recovery-OS entsprechen, so wird es nun aktualisiert. Abschlie\u00dfend wird das Update-Paket selbst gel\u00f6scht, und das System kann wieder seinen normalen\u00a0 Betrieb aufnehmen.<\/p>\n [1] siehe \/system\/etc\/security\/otacerts.zip Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Open Source \/ Embedded Software Engineering.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Modellierung \/Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nAnforderungen<\/h2>\n
G\u00e4ngige Update-Architektur<\/h2>\n
Der Bootloader als Updater<\/h2>\n
OS-Switching Architektur<\/h2>\n
Recovery OS-Architektur<\/h2>\n
Der Android-Updateprozess<\/h2>\n
Das Android Update-Paket<\/h2>\n
Der Android-Updateprozess in Schritten<\/h2>\n
Quellen<\/h2>\n
\n[2] siehe \/cache\/recovery\/command
\n[3] siehe \/res\/keys
\n[4] siehe im Update Paket unter META-INF\/com\/google\/android\/update-binary
\n[5] siehe \/system\/etc\/install-recovery.sh<\/p>\n
\nOpen Source – unsere Trainings & Coachings<\/h2>\n
\nOpen Source – Fachwissen<\/h2>\n