Hallo.
Ich möchte eine sichere Methode für ein Linux-Firmware update einsetzen.
Mein Konzept bis jetzt besteht aus 3 Komponenten:
Linux-Firmware : Das eigentliche System. Dieses soll hin und wieder
upgedated werden.
Linux-Fail-Save-Firmware : Ein minimales Linux-System, welches einen
SSH-Zugriff erlaubt bzw. ein Update des normalen Systems vornimmt.
Eigener Kernel und eigenes Initramfs, welches nie verändert werden soll.
U-Boot : Startet in abhängigkeit der Umgebungsvariablen eines der
beiden Linuxe.
Meine Frage ist jetzt.
Wie bemerke ich, dass die normale Linux-Firmware kaputt ist?
Angenommen das System kann aus irgendeinen Grund nicht mehr starten, wie
kann ich U-Boot dazu bringen, die Fail-Safe Firmware zu booten?
lgw
Hi,
-> irgendein Flag durch U-Boot löschen und durch dein Linux setzen
wenn es vollständig funktionsfähig ist. Beim nächsten Bootvorgang prüfst
du ob das Flag da ist oder nicht.
-> Checksumme über wichtigste Teile
-> Taster mit dem du das eine oder das andere startest
hallo
Die Idee mit dem Flag hatte ich auch schon.
Aber bleibt Linux z.B. mit einen Kernel-Panic hängen, brauche ich
irgendeinen Watchdog, der das System resetiert.
Kann ich in U-Boot einen watchdog starten?
Wäre es besser, die Fail-Save-Firmware als eine art 2nd-Stage Bootloader
zu verwenden?
Taster ist nicht gut, da das Gerät eine Art Wetterstation sein soll,
welches nicht ohne weiteres erreichbar ist.
Die Updates werden dann über mobiles Internet eingespielt.
Mirco Controller schrieb:> -> Checksumme über wichtigste Teile
Meinst du über den Kernel oder wie kann ich mir das vorstellen?
Hi,
die Idee mit dem Watchdog ist gut, du kannst ja z.B. einen kleinen
µC nehmen über den du das ganze machst.
-> U-Boot setzt Ausgang, Linux setzt zurück
-> wenn nach Zeit t nicht zurückgesetzt wurde
--> hauptreset und hinweis an U-Boot
Checksumme über den komprimieten Kernel und die anderen wichtigen Teile.
Vill das Rootfs nochmal splitten in Systemprogramme und deine Anwendung
dann könnte man das readonly machen und dadrüber nochmal eine Checksumme
(da bin ich mir aber nicht so sicher)
Eine Wetterstation mit fern-updatebarem Linux... wow. Aus Angst die
Wetterstation wird gehackt, muss das update drauf? Was ist denn die
erwartete Lebensdauer des Geraetes? Falls das Geraet kein Modefurz sein
soll, dh von ueber 10 Jahren ausgegangen werden soll, wuerd ich mir das
update schenken, denn nach 3,4 Jahren gibt es eh kein update mehr. Wenn
dasupdate feature einfah dabei ist,nimmt man's natuerlich.
LFU schrieb:> Es gibt immer wieder Personen deren Meinung einfach NICHT gefragt ist!
In deinem Post stand nichts darüber, dass nur bestimmte Personen
antworten dürfen und wer das sein soll. Fast hätte ich auch was
geantwortet, deine Warnung kam gerade noch rechtzeitig.
Gruss Reinhard
Einige Sun-Server hatten ein sogenanntes Lights-Out-Management (LOM)
Modul. Das war ein separater Prozessor, der das Hauptsystem resetten,
an- und ausschalten, Errorlogs lesen und vieles mehr steuern konnte. Mit
einer Escape-Sequenz (.~. oder so) kam man auf die Console des
Hauptsystems und wieder zurück. Für wichtige ("missionskritische")
Server war das genau das richtige, und auch für Maschinen, die einige
100km weiter in einem RZ stehen, ist das sehr nützlich, wenn mal was
passiert. Das LOM funktioniert ja unter allen Umständen, unabhängig vom
Zustand des Hauptsystems.
Ich weiß ja nicht, was das jetzt für eine Hardware ist, aber rein
theoretisch könnte man über das LOM auch das Flash beschreiben. Wenn die
Kiste von einem SPI-Flash oder einer SD-Karte bootet, wäre das überhaupt
kein Problem.
fchk
Was irgendwie nicht durchkam ist weshalb das System ueberhaupt
runtergefahren werden soll. eingebettete System laufen sonst eigentlich
durch. Ein Hibernate liegt ja drin.
Frank K. schrieb:> Das war ein separater Prozessor, der das Hauptsystem resetten,> an- und ausschalten
Im Prinzip kommt man nicht um Folgendes herum, wenn es immer
funktionieren muss:
1. Ein unabhängiges System, also wie beschreiben ein Zusatzprozessor.
2. ein unabhängiger Zugang - man muss das System nach Punkt 1 bedienen
können, egal in welchem Zustand sich das überwachte System befindet.
Punkt 2 dürfte schwer zu garantieren sein, wenn nur ein Netzwerkzugang
besteht und den beide Systeme gemeinsam benutzen müssen.
Gruss Reinhard
Reinhard Kern schrieb:> Punkt 2 dürfte schwer zu garantieren sein, wenn nur ein Netzwerkzugang> besteht und den beide Systeme gemeinsam benutzen müssen.
Intels AMT kann es.
> Wie bemerke ich, dass die normale Linux-Firmware kaputt ist?> Angenommen das System kann aus irgendeinen Grund nicht mehr starten, wie> kann ich U-Boot dazu bringen, die Fail-Safe Firmware zu booten?
Du kannst die Probleme aufteilen. Ist der Image in Flash kaputt ? Dann
merkt U-Boot einen CRC-Fehler beim laden des Kernels. In U-Boot kannst
du einen Skript schreiben, der den zweite System in diesem Fall startet.
Ist rootfs kaputt ? Dann wird rootfs hochwahrscheinlich nicht gemountet.
Der kernel Parameter "panic" lässt dein System wieder starten. Aber
watchdog muss auch sein. In U-Boot findest du mehrere Treiber, um den
Watchdog für den spezifischen Prozessor einzuschalten.
Es gibt noch den Fall, wenn kernel+rootfs laufen, aber deine Applikation
nicht richtig gestartet werden kann. In U-Boot gibt es den "boot
counter" feature: wenn der Bootcounter nicht von Applikation
zurückgesetzt wird, startet U-Boot automatisch einen anderen Skript
("altbootcmd" statt "bootcmd").
Übrigens habe ich einen OSS Projekt gestartet, um ein Update für
Embedded System gewährzuleisten. Falls du noch brauchst und einen Blick
werfen möchtest, ist der link https://github.com/sbabic/swupdate
Gruss,
Stefano
Hallo,
ich habe eine Kombination aus Bootcounter und Watchdog verwendet.
Hab mir gerade deine Seite angesehen - sehr interessant muss ich sagen.
Vielen dank für den Link.
lg
