Automatisches Firmware-Update für Embedded-Linux

					[url=/automatisches-firmware-update-fuer-embedded-linux-a-833310/][b]Automatisches Firmware-Update für Embedded-Linux[/b][/url]


					In Embedded Systemen wird die Notwendigkeit, die Firmware des Systems durch Updates auf dem neuesten Stand zu halten, immer wichtiger – nicht nur aus Sicherheitsgründen. Doch wie lässt sich ein automatisches Firmware-Update für Embedded-Linux elegant und auch für Nutzer leicht handhabbar implementieren?

					[url=/automatisches-firmware-update-fuer-embedded-linux-a-833310/]zum Artikel[/url]

					[url=/automatisches-firmware-update-fuer-embedded-linux-a-833310/][b]Automatisches Firmware-Update für Embedded-Linux[/b][/url]


					In Embedded Systemen wird die Notwendigkeit, die Firmware des Systems durch Updates auf dem neuesten Stand zu halten, immer wichtiger – nicht nur aus Sicherheitsgründen. Doch wie lässt sich ein automatisches Firmware-Update für Embedded-Linux elegant und auch für Nutzer leicht handhabbar implementieren?

					[url=/automatisches-firmware-update-fuer-embedded-linux-a-833310/]zum Artikel[/url]

Disclaimer: ich bin der Author von SWUpdate. Ich finde den abgeschätzten Gesamtaufwand bei Der Umsetzung mit SWUpdate sehr erschreckend. Einer könnte sich schon 3 Monaten damit beschäftigen, aber er wird sich sehr langweiligen. Eine Umsetzung einer Lösung mit schweren Anforderungen als im Artikel fordert einen Aufwand durchschnittlich von 1-2 Wochen. Einige Konzepte sind im Artikel nur ober flächig gehandelt und können den Leser verwirren. Im Artikel wird ein A/B Konzept gewählt und als Grund, neben
dass es genügenden Speicher gibt, dass der Ansatz für moderne Geräte empfohlen wird. Das stimmt nicht. Die Auswahl zwischen dual-copy (A/B) oder single-copy hängt von vielen Faktoren ab. Die Wahl nach single-copy ist nicht altmodisch - die könnte die richtigste für einen Projekt ab.
Der Vergleich zwischen Updater wird überhaupt nicht vertieft. Man bekommt noch eine falsche Nachricht. Alle Updater (die vorgeschlagen und noch andere) müssen heutzutage sehr stark Security Features in Fokus haben. Man geht an Security nicht vorbei. Ich habe den Eindruck beim Lesen, dass SWUpdate (und Mender) nicht stark die Security einsetzen - was nicht wahr ist. Security Features wie Signed Images, Verschlüsselung, privilege separation, usw., die in SWUpdate implementiert worden sind, werden überhaupt nicht genannt. SWUpdate wird für das Beispiel ausgewählt - man versteht nicht warum. Vor allem kann man nicht verstehn, warum Mender aus gelassen wird. Das Beispiel mit SWUpdate ist nicht komplett und noch fehlerhaft. Ich rate den Lesern, stattdessen die Dokumentation im Projekt zu lesen. Security war komplett raus (gut wenn es explizit genannt wird), aber es gibt im Prinzip zwei Probleme:

Ds Renaming von UBI Volume sollte innerhalb SWUpdate passieren. Statt einem Skript sollte man den entsprechenden Handler aufrufen und in sw-description eintragen.
Dieses Beispiel verbraucht jede Menge Resources. Es ist unklar, warum das Update Package auf einem Server angelegt wird und dann wget aufgerufen wird. Das hat die harte Konsequenz, dass die ganze SWU erst auf /tmp kopiert wurde. /tmp ist oft RAM, und man verbraucht einen großen Stuck von RAM. SWUpdate hat einen integrierten Downloader - das Beispiel sollte eigentlich :
in sw-description:

images: (
{
filename = rootfs.ubifs;
volume = root2;
installed-directly = true;
}
);

Und SWUpdate wird gestartet mit:

swupdate -d -u http://update.example.com/image-v1.swu

SWUpdate unterstützt zero-copy: keine Zwischenkoie auf dem Target.

Ich finde noch enttäuschen, dass der Artikel auf einen Vortrag referenziert, aber dieser Vortrag nicht frei ist und man kann kein Review machen. Das heißt, es gibt keinen Vortrag. Stattdessen gibt es mehrere Vorträge und Videos, die SWUpdate und die andere Updater beschreiben und auch vergleichen. Der Leser sollte besser an diese andere frei zugänglich Dokumentation im Netz anwenden.
Viele Grüße,
Stefano Babic