Tecniche consigliate per l'aggiornamento sul campo di Linux embedded in sicurezza

Question

I dispositivi basati su Linux integrati spesso richiedono un meccanismo per aggiornare applicazioni e file di sistema. Ad esempio, uno strumento di laboratorio (non in rete) con una porta USB può ottenere aggiornamenti software da una chiavetta USB.

Sarebbe semplice eseguire uno script per copiare i file nella memoria flash interna del dispositivo. Tuttavia, esiste il pericolo che il dispositivo perda energia durante l'aggiornamento e finisca per diventare un mattone.

La situazione dei file dell'applicazione è un po 'più semplice poiché c'è spazio per duplicare la directory dell'applicazione, aggiornare una copia e scambiare rapidamente vecchie e nuove directory minimizzando la finestra di errore.

Le cose sono più naturali per i file del kernel e del sistema poiché sono sparse in tutto il file system.

Abbiamo utilizzato i collegamenti hard e soft nel file system per identificare i file critici. Usiamo hash su file e archivi per verificare l'integrità dei file. Abbiamo preso in considerazione l'uso di un ramfs di emergenza nel kernel per fornire un fallback se l'avvio dal file system aggiornato fallisce.

Quali sono i tuoi approcci a questo requisito?

Answer 1

Vorrei andare con lo stesso approccio dei file dell'applicazione: Crea i file critici e completa la propria partizione, collega ad essi e duplica la partizione. In tutti i tuoi init dovresti prima controllare se i collegamenti mostrano tutti sulla stessa partizione, altrimenti ripristinali (sulla partizione con i file con la data più recente di un certo file). Se vuoi aggiornare, copia tutto sulla nuova partizione e, se tutto va bene (crcs ok), passa sopra i file e imposta per ciascuno il collegamento da un filesystem all'altro.

In questo modo i tuoi file critici dovrebbero essere sempre in buono stato.

Scenari:

1. L'aggiornamento non riesce durante la copia dei file in una nuova partizione

   Nessun problema perché i collegamenti mostrano ancora quelli vecchi.

2. L'aggiornamento non riesce durante il collegamento

   Nessun problema perché tutti i nuovi file sono validi e già copiati (altrimenti il ??passaggio di ricollegamento non avrebbe avuto inizio), il controllo dell'installazione corregge questo

Answer 2

Se è necessario garantire l'affidabilità, è possibile avere due partizioni flash (o persino chip), una con la configurazione di lavoro corrente e una con la nuova configurazione. Quindi utilizza un watchdog hardware che ripristinerà l'unità e commuta la partizione flash di avvio attiva sull'ultimo "bene noto" configurazione.

Answer 3

Hanno almeno due partizioni. Suggerirei 4

• avvio

• avvio alternativo

• backup dei dati del programma

• programma dati volatili

Utilizzare l'avvio di fallback di grub per l'avvio alternativo se l'avvio non riesce.

Quindi, se l'aggiornamento non riesce, l'alternativa funziona.

MAI aggiornare il boot loader.

Se la partizione dati è tostata, riformattare e copiare sulla partizione dati di backup.

Ora non puoi fallire a meno che il disco flash non muoia. Se stai usando l'hardware COTS, e il disco principale diceva, Compact flash, potresti avere un backup fisicamente isolato su una piccola chiavetta USB.

Answer 4

IMHO qualsiasi aggiornamento che non sia atomico può rompere il sistema o rendere abbastanza difficile la verifica della coerenza. Concordo sul fatto che l'aggiornamento del boot loader debba essere evitato perché non è spento in modo sicuro. Generalmente, un produttore desidera un aggiornamento dal Firmware x.x.x alla versione y.y.y, senza preoccuparsi se il kernel e / o un singolo file sono stati aggiornati. L'aggiornamento di singoli file può diventare un incubo per il servizio, perché è molto difficile capire cosa è in esecuzione sull'hardware del cliente. Forse stai mescolando un approccio a doppia copia (l'applicazione è ridondante) con un approccio a copia singola. Penso che questo non sia di grande aiuto, perché l'integrità del sistema è fatta dal componente debole della catena. Se un aggiornamento del filesystem di root fallisce, non è importante che l'applicazione sia duplicata.

Un approccio a doppia copia può garantire un aggiornamento senza servizio, se necessario. Ma richiede molte risorse, perché tutti i componenti devono essere duplicati. Personalmente, utilizzo un approccio di fallback, in cui viene avviato un piccolo rootfs nella RAM se l'applicazione principale non riesce o se l'ultimo aggiornamento non ha avuto esito positivo. Questo sistema di fallback, avviato automaticamente dal bootloader in caso di problemi, aggiorna il sistema da una penna USB (se è necessario un aggiornamento locale).

Non ho mai trovato un progetto OSS su questi problemi e ne ho recentemente avviato uno nuovo, basato sulla mia esperienza precedente. Ho diversi prodotti in esecuzione e i miei clienti ne sono soddisfatti.

Forse puoi dare un'occhiata. Puoi trovare fonti per " swupdate " (il nome del progetto) all'indirizzo github.com/sbabic/swupdate .

Stefano

Answer 5

Penso che ciò che stai cercando di ottenere qui sia l'atomicità del processo di aggiornamento. L'atomicità è fondamentale per i dispositivi integrati, uno dei motivi evidenziati è la perdita di potenza; ma potrebbero essercene altri come problemi hardware / di rete. Una definizione che uso per atomicità nel contesto degli aggiornamenti è:

• Un aggiornamento è sempre o completamente completato o per niente
• Nessun componente software oltre al programma di aggiornamento vede mai un aggiornamento installato per metà

Per Embedded Linux ci sono diversi componenti software che potresti voler aggiornare e diversi design tra cui scegliere; c'è un articolo su questo qui: https: // mender .io / user / pagine / 04.resources / _white-papers / Software% 20Updates.pdf