OTA-updates voor Embedded Linux, deel 1 – Grondbeginselen en implementatie

De behoefte aan updates

Zodra een Embedded Linux-product het lab verlaat en de echte wereld betreedt, wordt de vraag hoe het apparaat moet worden bijgewerkt belangrijk om te overwegen.

Updates zijn niet altijd nodig, maar het is moeilijk om software te bedenken die geen bugs bevat die op een bepaald moment worden ontdekt. Zelfs als uw software perfect is, als het apparaat via netwerken of internet communiceert met open-sourcebibliotheken, kunnen beveiligingsupdates een noodzaak worden.

Neem het voorbeeld van CVE-2104-01650 (Heartbleed). Deze kwetsbaarheid trof de OpenSSL-cryptografiebibliotheek en bij uitbreiding tweederde van de websites op het net. Zelfs nu, drie jaar later, zijn er veel Embedded Linux-apparaten met een onverdedigde versie van OpenSSL, die wijd open staat voor aanvallen.

Blokkeer versus bestandsupdates

Als je het hebt over het updaten van Linux, kan het zijn dat je updatesystemen voor "blokkeren" en "bestand" ziet. Dit verwijst naar het bijwerken van een hele partitie tegelijk door rechtstreeks naar het blokapparaat te schrijven of door afzonderlijke bestanden bij te werken om de update uit te voeren. U bent wellicht bekend met bestandsupdatesystemen van Desktop of Server Linux (“sudo apt-get upgrade” bijvoorbeeld).

In Embedded Linux zijn op blokken gebaseerde upgrades de beste keuze vanwege hun atomiciteit en het feit dat een volledig bestandssysteem normaal gesproken de uitvoer is van een Embedded Linux-buildsysteem. We verwachten dat de opslagruimte op elk ingebouwd apparaat constant is voor een bepaald product, dus maken we elke keer dezelfde partitie. Dit type update gaat hand in hand met een soort terugval- of herstelimage.

Herstel in geval van storing

We willen nooit dat het apparaat in een onbruikbare staat wordt achtergelaten (als er bijvoorbeeld een stroomstoring optreedt). We kunnen dit oplossen door ervoor te zorgen dat het altijd mogelijk is om "terug te vallen" naar een andere partitie als er iets misgaat in het updateproces.

Figuur 1. Herstel bij storing – terugvalopties (Bron:ByteSnap)

Hierboven ziet u twee mogelijke implementaties van een fallback-modus bij stroomuitval. Aan de linkerkant start de Bootloader een reddingspartitie, die vervolgens opstart naar een hoofdpartitie. Aan de rechterkant start de Bootloader een van de twee partities op basis van een switch.

De bootloader zou een methode moeten implementeren om te bepalen of een boot succesvol is geweest, en als dat niet het geval is, moet hij terugkeren naar de reddingspartitie (linker diagram), of de vorige werkpartitie (rechter diagram).

De reddingsmethode (links) maakt het mogelijk om meer ruimte te geven aan de hoofdpartitie, terwijl de dual-rootfs-methode (rechterhand) vereist dat de ruimte min of meer gelijk verdeeld wordt tussen de twee partities. Als ruimte geen probleem is, wordt aanbevolen om de dual-rootfs-methode te gebruiken, alleen omdat dit zal resulteren in minder uitvaltijd. Bijwerken via de reddingsmethode vereist twee herstarts, één in de reddingspartitie en dan een andere terug in de hoofdmap. De dual-rootfs-methode vereist slechts één keer opnieuw opstarten, omdat een update op elk moment kan worden uitgevoerd.

Wat u in deze systemen niet veilig kunt bijwerken, is de bootloader (of inderdaad de reddingspartitie). Als je ook de bootloader wilt kunnen updaten, heb je twee aparte bootloaders-partities nodig en een soort Board-Management-Controller om de logica van het schakelen tussen de twee te implementeren.

Figuur 2. Herstel bij storing – Board Management Controller (Bron:ByteSnap)

Dit is natuurlijk een gecompliceerde oplossing, waarvoor een extra microcontroller, een nieuwe set firmware en een ingewikkelder hardware-ontwerp nodig zijn (het wordt gebruikt in sommige apparaten, die bijvoorbeeld een aparte Intelligent Platform Management Interface (IPMI)-controller bevatten) . Probeer daarom een ​​bootloader te bouwen die functioneel en klein van opzet is en daarom niet hoeft te worden bijgewerkt.

U-Boot-omgevingsvariabelen

U-boot implementeert een niet-vluchtige "omgeving" waarin variabelen kunnen worden opgeslagen. Deze zijn zelfs toegankelijk vanuit Linux (op verschillende manieren, afhankelijk van hoe de omgeving is opgeslagen, zoals beschreven op elinux.org.

Dit is de meest voor de hand liggende manier om de hierboven beschreven "switch" te implementeren. Het kan ook worden gebruikt om informatie over eerdere opstartsuccessen of -mislukkingen op te slaan, zodat in het geval dat het opstarten mislukt, de switch kan worden omgekeerd en een werkende partitie kan worden hersteld.

Figuur 3. U-boot-omgevingsvariabelen (Bron:ByteSnap)