Atomare Updates (und Fallback)

Das Zauberwort für ausfallsicheres Updaten von Systemen lautet Atomizität. Das bedeutet: Es muss sicher gestellt sein, dass ein Update vollständig erfolgreich eingespielt ist, bevor es zur Nutzung freigegeben wird.

Um das sicher zu stellen, verwendet man redundate Boot-Partitionen (auch Dual-Copy- oder A+B-Ansatz genannt). Dabei werden zwei vollkommen gleichwertige Systempartitionen benutzt, um wechselseitig Updates durchzuführen. Von der aktiven Partition wird in die Inaktive geschrieben und diese erst nach erfolgreichem Abschluss des Schreibvorgangs als neue aktive Partition geschaltet. Die Umschaltung zwischen den Partitionen erfolgt dabei im Boot-Loader. Dies bietet auch einen Verfügbarkeitsvorteil: Das Update kann mit diesem Mechanismus problemlos im Hintergrund der laufenden Anwendung durchgeführt werden ohne diese zu unterbrechen.

Die Verwendung redundanter Partitionen erlaubt es dann optional, auch im Fehlerfall des aktiven Systems auf das inaktive System zurück zu fallen und so die Verfügbarkeit der Plattform deutlich zu verbessern.

Kryptographisch gesicherte Updates

Da das Update-System den Austausch der Systemsoftware ermöglicht, handelt es sich hier um einen besonders kritischen Bereich. Um nicht-autorisierten Personen den Zugriff auf das System zu verweigern, muss das Update bei der Erstellung kryptographisch signiert werden und vor der Installation vom Zielsystem verifiziert werden. Dafür eignen sich asymmetrische Methoden hervorragend, da hier nur die Schlüssel zum Signieren geheim gehalten werden müssen, während der Schlüssel zum Verifizieren ohne weiteren Aufwand auf dem Gerät abgelegt werden können.

Die Nutzung gängiger Standards wie X.509 erlaubt darüber hinaus prinzipiell komplexere Hierarchien mit Entwicklungs-Schlüsseln, Pro-Geräte-Schlüsseln, mehreren Signaturen, etc.

Weitere Anforderungen

Der Teufel steckt oft im Detail, und so verhält es sich auch mit der Entwicklung einer Update-Strategie. Die technischen Vorgaben wie Prozessortyp, und Speichertechnologie müssen ebenso berücksichtigt werden wie Anforderungen der Applikation und das Ökosystem in dem das Gerät eingebunden ist.

Typische weitere Fragen, die sich dann ergeben sind

• Wie trennt man Daten und Logs vom Betriebssystem?
• Wie migriere man Applikations-Daten nach einem Update?
• Wie sieht eine sinnvolle Partitionierung des Speichers aus?
• Ist es möglich den Bootloader sicher zu aktualisieren?
• Wie soll sich das Gerät im Fehlerfall verhalten?
• Wie erkennt das Gerät zuverlässig, dass ein Fehler vorliegt?

Wie können wir Ihnen helfen?

Unser Integrations-Team beleuchtet mit Ihnen zusammen die offensichtlichen und weniger offensichtlichen Fragen und Anforderungen an das Update-System und entwickelt zunächst ein grundlegendes Update-Konzept, dass im weiteren Projektverlauf nachgeschärft werden kann.

Mit RAUC gibt es bereits ein von Pengutronix gepflegtes und vollkommen als Open-Source lizenziertes Update-Framework als Ausgangspunkt. Dies erlaubt die Fokussierung auf das Wesentliche ohne das Rad neu erfinden zu müssen. Trotzdem ist die Abstimmung des Gesamtsystems auf die konkreten Anforderungen des Kunden und der Einsatzumgebung alles andere als trivial und umfasst die Konfiguration diverser Komponenten, die eng verzahnt ineinander greifen müssen.

Auf Basis Ihres Board Support Packages (BSPs) implementiert unser Integrations-Team ein redundantes Boot-Setup, konfiguriert alle notwendigen System-Komponenten und bereitet alles so vor, dass Update-Artefakte erzeugen und installieren können.

Benötigen Sie zusätzliche Funktionalität, die durch die existierenden Komponenten nicht oder nicht vollständig abgedeckt ist, so erweitern wir diese gerne für Sie. Das möglichst so, dass neue Features direkt in den Hauptentwicklungszweig der Projekte zurück fließen können und sich nicht als technische Schuld im Projekt anhäufen.

Im Rahmen der Klärung der Anforderung und dem konkreten individuellen Aufsetzten der grundlegenden Update- und Boot-Loader-Konfiguration unterstützt Sie Pengutronix unter anderem bei:

• Anpassen des Boot-Loaders für redundante Boot-Partitionen (barebox, U-Boot, Grub, UEFI)
• Initiales Konfigurieren von RAUC im BSP (Yocto, PTXdist, Buildroot)
• Abstimmen des Watchdog-Verhalten
• Klärung von Security-/Verifizierungs-Verhalten
• Klärung verwandter Themen wie Konfigurations-Management, Daten-Migration etc.
• Integration in Kundenapplikation / Anbindung an Deployment-Infrastruktur
• Rückfragen im weiteren Verlauf

Die größten Fehler beim Design eines redundant bootenden Systems werden übrigens oft bereits in der Frühphase des Projektes gemacht. Gerne bewertet Pengutronix daher auf Basis von langjähriger Erfahrung für Sie schon 'von Anfang an', ob die gewählte Hardware und insbesondere die verwendete Speichertechnologie, das Power-Management oder der Prozessor, Risiken bergen.

Und warum RAUC?

Mit RAUC steht ein modernes Open-Soure-Update-Framework bereit, dass durch effiziente Nutzung etablierter Bibliotheken wie glib, OpenSSL und curl eine schlanke und gut wartbare Codebasis bietet. RAUC teilt sich dabei auf in einen Service, der auf der Zielplatform läuft und dort die Update-Artefakte verifiziert und atomar installiert und einem Host-Tool mit dem die Update-Artefakte (Bundles) erzeugt werden.

Mit der Reduzierung auf das Wesentliche und der Bereitstellung sowohl eines Kommandozeilen-Tools als auch einer D-Bus-API lässt sich RAUC gut in bestehende Kundenapplikationen integrieren.

Eine der wesentlichen Philosophien von RAUC ist die Beschreibung des redundanten Boot-Verhaltens per Konfigurations-Datei direkt auf dem Gerät. Dies lässt nicht nur eine Introspektierbarkeit des Systems zu, sondern erlaubt auch generische Update-Artefakte zu erstellen.

Zusätzliche Features wie PKCS#11-Support für das Signieren von Bundles, Möglichkeiten der Neu-Signierung von Bundles oder das Unterbringen von Intermediate-Zertifikaten in Bundles erlauben es, den Sicherheitsanforderungen im professionellen Umfeld zu begegnen.

Für die im Feldeinsatz initial oft unterschätzten doch später oft dringend notwendigen Updates des Boot-Loaders bietet RAUC für viele Anwendungsfälle die Möglichkeit, diese ebenfalls vollkommen atomar durchzuführen.

Wie lassen sich OTA-Updates umsetzen?

Wenn im Unternehmen bereist eine Deployment-Infrastruktur vorhanden ist oder auf eine gehostete Lösung gesetzt werden soll, kann RAUC mit Hilfe eines einfachen Dienstes, der Anfragen der Infrastruktur annimmt und RAUC über D-Bus oder Kommandozeile aufruft, getriggert werden.

Für OTA-Update in eigener (self-hosted) Infrastruktur bietet sich das Open-Source-Projekt hawkBit an. Dieses bietet eine umfangreich konfigurierbare Lösung für Geräteverwaltung, Deployment-Scheduling und Feedback.

Die Anbindung an RAUC ist, dank existierender Clients im RAUC-Projekt, spielend leicht umzusetzen. Mit dem rauc-hawkbit-updater steht hier eine solide in C geschriebene Client-Komponente zur Verfügung, die mittels REST mit der Device (DDI) API von hawkBit und via D-Bus mit RAUC interagiert.