Der Generische Flash Bootloader (GenFBL) von Ingenics Digital

Ein Flash-Bootloader für Mikrocontroller (MCU) ist eine essenzielle Softwarekomponente, die das Laden und Aktualisieren von Firmware ohne spezielle Programmiergeräte ermöglicht. Dafür verwendet sie die von dem System verwendeten Kommunikationskanäle, was insbesondere für Wartung und Updates in eingebetteten Systemen vorteilhaft ist.

Vorgeschichte: Wieso ein Generischer Flash-Bootloader (FBL)?

Wir haben sehr viel Erfahrung mit der Entwicklung von Flash-Bootloadern, da wir schon für zahlreiche Kunden solche FBLs entwickelt haben. Teilweise kann man frühere FBLs durch Teil-Neuprogrammierung an eine neue Hardware anpassen, teilweise muss man aber fast ganz neu anfangen. Beides bedeutet meist erheblichen Entwicklungsaufwand mit entsprechenden Kosten. Daher lag die Idee nahe, einen generischen Flash-Bootloader zu entwickeln, der mit vergleichsweise geringem Aufwand an möglichst viele Einsatzzwecke angepasst werden kann und so ganz wesentlich Entwicklungskosten spart.

Anforderungen an einen Generischen Flash-Bootloader

Um vor allem dieses Ziel der Anpassbarkeit ohne viel Aufwand und breiter Einsetzbarkeit zu erreichen, muss der GenFBL mindestens folgende Eigenschaften aufweisen:

• Nach einem Power-On Reset (POR) soll der generische FBL als erstes angesprungen werden.
• Danach soll der GenFBL ohne Benutzerinteraktion entscheiden, welche Applikation als nächstes angesprungen wird.
• Der GenFBL soll Applikationen in den nichtflüchtigen Speicher schreiben.
• Der GenFBL soll Failsafe-, Downgrade-, Sicherheits- und Konsistenz-Schutzalgorithmen implementieren.
• Der GenFBL soll in der Lage sein, verschiedene Kommunikationskanäle zu nutzen.
• Der GenFBL soll so designt werden, dass er auf verschiedene MCU-Familien portiert werden kann.

Ziel erreicht: Der Generische Flash-Bootloader ist da!

Im März 2024 wurde die erste Version des GenFBL bei Ingenics Digital intern vorgestellt. Er besteht aus dem Flash-Bootloader selbst sowie einem Flash Client.

Beim Einschalten oder nach dem Reset der MCU führt der GenFBL grundlegende Hardware-Initialisierungen durch, überprüft und lädt neue Firmware aus verschiedenen Quellen wie USB, UART oder Ethernet und übergibt anschließend der geladenen Applikation die Kontrolle. Fortgeschrittene Konzepte wie Two-Stage Bootloader und Multibanking erhöhen die Flexibilität und Zuverlässigkeit, indem sie den Bootvorgang in mehrere Phasen unterteilen und mehreren Firmware-Versionen starten können. Zusätzlich bietet unser GenFBL Vorteile wie Plattformunabhängigkeit, vereinfachte Entwicklungsprozesse und reduzierte Kosten, da er aufgrund seiner Architektur auf mehreren verschiedenen Hardwareplattformen eingesetzt werden kann. Diese Mechanismen verbessern die Sicherheit, Fehlertoleranz und Benutzerfreundlichkeit von MCU-basierten Systemen und ermöglichen eine effizientere Verwaltung und Verteilung von Firmware-Updates.

Merkmale unseres Bootloaders

• Multibanking: Verwaltung und Starten von mehreren Applikationen gleichzeitig im nichtflüchtigen Speicher.
• Secure Firmware durch Authentifizierung und Sicherheit: Verwendung von SHA 265 und ECDSA oder RSA 2048 zur Sicherstellung der Integrität und Authentizität der Firmware.
• Secure Boot-Implementierung durch optionalen Two-Stage Bootloader: Secure Boot durch die optionale Aufteilung des Bootloaders in zwei Teile.
• Fail Safe: Robustheit des Flashvorgangs gegenüber Abbrüchen und älteren bzw. inkompatiblen Software-Versionen. Letzteres dient als Downgrade-Schutz.
• Einfache Portierung: Modulare Softwarearchitektur mit Bereitstellung von Schnittstellen zur einfachen Portierung auf neuen Mikrocontroller-Plattformen und Kommunikationsschnittstellen wie USB, UART, CAN und Ethernet.
• Bereitstellung des Flash Tools: Das Flashtool ist sowohl als graphische Desktopversion oder in der Kommandozeile ausführbar. Letzteres lässt sich in eine HiL(Hardware-in-the-Loop)-Testumgebung integrieren.
• Inkl. CI/CD Pipeline: Off the shelf-Buildskripte für die Tools CMake und GCC.
• Der Source Code des GenFBL und dem zugehörigen Flash Client ist open source.
• Automatisierte Integrationstests: Bereits durchgeführte HW-Tests mit unserem Testframework HiL 2.0.

Wie funktioniert

... das Multibanking?

Das wird in der Abbildung 1 dargestellt:

• Bei mehreren gültigen Applikationen entscheidet der GenFBL, in welche gesprungen wird (1).
• Dabei überprüft der Flashbootloader über die SW-Version immer, welche Applikation die neueste ist (2). Hier ist das Applikation A.
• Erst wenn die Authentizität und Integrität sichergestellt ist, wird in die Applikation A gesprungen (3).
• Falls keine anwendbare Software gefunden wird, bleibt der GenFBL im Bootloader-Modus und sendet eine entsprechende Meldung.

... das Signieren der Software vor dem Flashen?

Dazu siehe Abbildung 2:

• Durch die Asymmetrische Verschlüsselung der Software mit einem privaten Schlüssel wird gewährleistet, dass die Software von einer vertrauenswürdigen Quelle stammt (Abb. 2 oben: Die Signatur, also der verschlüsselte Hash-Wert wird quasi an die Software gehängt.)
• Die Authentizität, Integrität und Gültigkeit wird vor einem Sprung in die Applikation überprüft.
• Dabei vergleicht der Flashbootloader, ob die Hash-Werte nach der Entschlüsselung mit dem öffentlichen Schlüssel gleich sind. Dies zeigen die zwei Pfade in Abb. 2 unten: Der "Ja"-Pfad bedeutet, dass der Hash-Wert der Software gleich dem erwarteten Wert ist. Der Software kann vertraut werden und sie wird installiert. Stimmt der gefundene Hash-Wert an der Software nicht mit dem Erwartungswert überein ("Nein"-Pfad in Abb. 2), werden der Flash- und Bootvorgang mit einer entsprechenden Fehlermeldung angehalten.
• Aktuell sind asymmetrische Verschlüsselungsverfahren über ECDSA und RSA implementiert. Der GenFBL kann aber auf beliebige andere Kryptoverfahren erweitert werden.

... der Failsafe-Mechanismus?

Dieser Ablauf wird in Abbildung 3 gezeigt:

• Das Flashtool signiert die Applikation vor dem Flash-Vorgang (Abb. 3 oberes Drittel: signFirmware()).
• Die Applikation wird über das Kommunikationsmedium segmentiert versendet (loop writing into data section(s)).
• Wenn der Datentransfer fehlerfrei und die Applikation aus vertrauter Quelle kommt, war der Vorgang OK (alt Flashing OK).
• War der Datentransfer fehlerbehaftet oder die Applikation stammt aus nicht vertrauenswürdigen Quellen, schlägt der Flashvorgang fehl (alt Flashing NOK).

... die leichte Portierbarkeit?

Das erläutert Abbildung 4:

• Die Software des GenFBL wurde so designt, dass bei Portierungen auf verschiedene Controller und Kommunikationskanäle so wenig wie möglich angepasst werden muss. Dabei werden die SW-Module in der Business Logic (grün) nicht verändert.
• Der Interface Layer (gelb) dient zur Delegation der Funktionen in die hardwareabhängigen Treiber.
• Für den GenFBL müssen die Treiber (rot) entwickelt werden. Dabei müssen die im Interface Layer vorgegeben Funktionssignaturen implementiert werden. Aktuell sind sie verfügbar für STM32H/F und GD32450 über UART/Ethernet/CAN. Aurix ist in Entwicklung.

Beispiele für die Fail Safe-Funktionalitäten

... am Beispiel "Applikation flashen über UART"

Eine Demonstration der Failsafe-Funktion, Überprüfung der SW-Größe und Authentifizierung über RSA wird in Abbildung 5 gezeigt:

Vorbedingungen für den Mikrocontroller STM32F4:

• Im Flashspeicher liegen der FBL und die Applikationen 1 und 2.
• Ist Applikation 1 geladen, blinkt die LED im Zyklus von 3 sec.
• Bei Applikation 2 blinkt sie im Zyklus von 1 sec.
• Bei Applikation 3 blinkt sie im Zyklus von 0,2 sec.

Testablauf:

• Nach einem POR wird die Applikation 2 angesprungen.
• Applikation 3 wird mit RSA geflasht. LED blinkt mit 0,2 sec. Applikation 3 ist also geladen.
• Applikation 3 wird mit RSA geflasht, dabei wird eine Spannungsunterbrechung erzeugt.
• Nach einem PowerOnReset wird die Applikation 2 angesprungen. LED blinkt mit Zyklus von 1 sec, was anzeigt, dass nun Applikation 2 läuft.
• Es wird versucht, Applikation 4 zu flashen, die zu groß ist. Der GenFBL meldet einen Fehler und springt nach einem PowerOnReset zurück in die Applikation 2. LED blinkt mit Zyklus von 1 sec.

... am Beispiel "Applikation flashen über Ethernet"

Abbildung 6 veranschaulicht eine Demonstration der Recovery-Funktionen und SW-Integrität mit CRC als Prüfsumme oder SW-Version:

Vorbedingungen für den Mikrocontroller STM32H7:

• Im Flashspeicher liegen der GenFBL und die Applikation 1.
• Bei Ausführung des GenFBL blinkt die orangefarbene LED.
• Bei Ausführung der Applikation 1 blinkt die grüne LED.
• Bei Ausführung der Applikation 2 blinkt die blaue LED.

Testablauf:

• Nach einem POR wird Applikation 1 angesprungen, die LED blinkt grün.
• Applikation 2 wird mit CRC geflasht. LED blinkt nach dem Vorgang blau.
• Applikation 2 wird erneut geflasht. Dabei wird die Ethernetverbindung unterbrochen. Da wieder der GenFBL angesprungen wird, blinkt die orangene LED.
• Nach einer gewissen Zeitspanne im GenFBL wird bei immer noch unterbrochener Ethernetverbindung Applikation 1 angesprungen. LED blinkt grün.
• Applikation 2 wird mit abweichender SW-Version geflasht. Eine Fehlermeldung wird angezeigt, Applikation 2 wird nicht geladen und da der FBL angesprungen wird, blinkt die orangene LED. Die Verbindung wird getrennt.
• Applikation 1 wird angesprungen, da sie die neueste, gültige Applikation ist. LED 1 blinkt grün.

... am Beispiel "Applikation flashen über CAN"

In Abbildung 7 wird eine weitere Demonstration der Failsafe-Funktion sowie des SW-Downgradeschutzes gezeigt:

Vorbedingungen für den Mikrocontroller GD32:

• Im Flashspeicher liegen der GenFBL und die Applikation 1.
• Bei Ausführung des GenFBL blinken LED 1 und LED 2 jeweils im Zyklus von 0,2 sec.
• Bei Ausführung der Applikation 1 blinkt die LED 1 im Zyklus von 1 sec.
• Bei Ausführung der Applikation 2 blinkt die LED 2 im Zyklus von 0,1 sec.

Testablauf:

• Nach einem POR wird Applikation 1 angesprungen. LED 1 blinkt im Zyklus von 1 sec.
• Applikation 2 wird mit ECDSA-Signatur geflasht. LED 2 blinkt im Zyklus von 0,1 sec.
• Es wird versucht, Applikation 2 mit einer älteren SW-Version zu flashen.
• Es erscheint eine Fehlermeldung, da die SW-Version zu alt ist. Da der GenFBL ausgeführt wird, blinken die LED 1 und 2 im Zyklus von 0,2 sec. Die Verbindung wird getrennt.
• Dann wird die zuvor mit der ECDSA-Signatur geflashte Applikation 2 (in gültiger SW-Version) angesprungen. LED 2 blinkt im Zyklus von 0,1 sec.
• Beim erneuten Versuch, eine Applikation 2 mit unzulässiger SW-Version zu flashen, wird die CAN-Verbindung unterbrochen. Da der GenFBL ausgeführt wird, blinken zunächst die LED 1 und 2 im Zyklus von 0,2 sec.
• Nach einer gewissen Zeitspanne wird die Applikation 1 angesprungen und LED 1 blinkt mit einem Zyklus von 1 sec.
• Beim letzten Versuch, eine Applikation 2 mit CRC-Auswahl zu flashen erscheint eine Fehlermeldung, da nur ECDSA unterstützt wird. Da immer noch der GenFBL ausgeführt wird, blinken LED 1 und 2 im Zyklus von 0,2 sec.
• Nach dem Flashvorgang gibt es eine Fehlermeldung und die Verbindung wird getrennt.
• Darauf wird Applikation 1 angesprungen und LED 1 blinkt.

Unterstützte Mikrokontroller

STM32F4, STM32H7, GD32F450 und AURIX TC375

Unterstützte Protokolle

UART, CAN, Ethernet

Auf einen Blick: Die Vorteile unseres Generischen Bootloaders GenFBL

• Der wesentliche Vorteil unseres Bootloaders ist die Kombination der verfügbaren Features und die dadurch schnelle Einsetzbarkeit in einem neuen Projekt: Kostspielige Entwicklungszeit ist nicht notwendig, lediglich etwas Zeit zur Anpassung.
• Durch die modulare Architektur ist der GenFBL mit wenig Aufwand auf verschiedene MCU-Plattformen und Kommunikationsmedien portierbar.
• Zudem sichern Secure Boot und Secure Update über gängige und frei erweiterbare Kryptomechanismen die Vertrauenswürdigkeit der Software-Quelle.
• Multibanking ermöglicht automatische Auswahl der zu installierenden Software ohne Userinteraktion, wobei ein Downgrade-Schutz das Flashen inkompatibler bzw. alter Softwarestände verhindert.

Aktuell wird der Bootloader wird mit unserem HiL-Testframework getestet und bei Bedarf können wir auch beide zusammen integriert ausliefern.