Livrarea de firmware prin aer (OTA) este funcționalitatea care transformă un produs într-o flotă pe care o poți îmbunătăți după ce a părăsit fabrica. Este, de asemenea, funcționalitatea cu cea mai mare probabilitate de a transforma acea flotă într-un câmp plin de cărămizi. O actualizare greșită împinsă către zece mii de dispozitive pe care nu le poți atinge fizic nu este un bug; este o rechemare. Întreaga disciplină constă în a face acel rezultat imposibil prin construcție.
Două bănci, un rollback
Fundamentul este o schemă de partiționare A/B. Fiecare dispozitiv are două sloturi de firmware; imaginea care rulează stă într-unul, în timp ce o actualizare este scrisă în celălalt, neatinsă și inertă. Abia după ce noua imagine este primită complet și integritatea ei este verificată, bootloaderul comută slotul activ — și chiar și atunci, noul firmware trebuie să raporteze și să confirme că este sănătos într-o fereastră de watchdog, altfel bootloaderul revine la imaginea cunoscută ca fiind bună la următoarea resetare. Un dispozitiv care nu reușește să pornească noul firmware revine automat la cel vechi. Nu există nicio stare în care o imagine scrisă pe jumătate sau defectă să devină singurul lucru pe care dispozitivul îl poate rula.
Semnează totul, nu te încrede în nimic
Un canal de actualizare este o suprafață de atac, iar un dispozitiv care scrie orice i se înmânează este un dispozitiv care așteaptă să fie transformat în botnetul altcuiva. Fiecare imagine este semnată criptografic, iar bootloaderul verifică acea semnătură în raport cu o cheie inscripționată în hardware înainte de a executa o singură instrucțiune. Transportul poate fi compromis, serverul de actualizare poate fi impersonat, octeții pot fi modificați în zbor — nimic din toate acestea nu contează dacă semnătura nu se verifică, pentru că o imagine nesemnată sau alterată este pur și simplu refuzată, iar cea veche continuă să ruleze.
Sarcina bootloaderului nu este să instaleze noul firmware. Este să garanteze că dispozitivul are întotdeauna un firmware la care poate reveni.— Protocore · Inginerie firmware
Lansează în valuri, urmărește metricile
Chiar și un mecanism de actualizare perfect nu justifică livrarea către întreaga flotă deodată. Eșalonăm lansările: mai întâi o mică cohortă canar, apoi inele tot mai largi, cu telemetrie de sănătate — succesul pornirii, ratele de blocare, regresiile de baterie și de conectivitate — care condiționează fiecare extindere. Dacă cifrele canarului se clatină, lansarea se oprește automat și nimic dincolo de acel inel nu primește vreodată build-ul. Așa ajunge un bug latent care a scăpat de testare la o sută de dispozitive în loc de o sută de mii și este prins cât timp o remediere este încă ieftină.
Dispozitivele din teren sunt neiertătoare într-un mod în care serverele nu sunt niciodată: nu există o consolă în care să te conectezi prin SSH, nicio redesfășurare rapidă, uneori nicio a doua șansă. Așa că siguranța trăiește sub aplicație, într-un bootloader și un sistem de lansare în care poți avea încredere tocmai pentru că sunt simple, semnate și reversibile. Fă bine acel strat o singură dată și actualizările de firmware încetează să mai fie cel mai înfricoșător buton din clădire. Fă-l greșit și înveți de ce „cărămidă” a devenit un verb.
Ai un sistem de construit?
Spune-ne care e problema. Revenim cu o arhitectură și un plan.
Începe un proiect