Técnicas recomendadas para la actualización de campo de Linux integrado de forma segura

Question

Los dispositivos integrados basados ??en Linux a menudo requieren un mecanismo para actualizar las aplicaciones y los archivos del sistema. Por ejemplo, un instrumento de laboratorio (no conectado en red) con un puerto USB puede obtener actualizaciones de software desde una memoria USB.

Sería una cuestión simple ejecutar un script para copiar archivos en su lugar en la memoria flash interna del dispositivo. Sin embargo, existe el peligro de que el dispositivo pierda energía en el medio de la actualización y termine en un ladrillo.

La situación de los archivos de la aplicación es un poco más fácil, ya que hay espacio para duplicar el directorio de la aplicación, actualizar una copia e intercambiar rápidamente los directorios antiguos y nuevos minimizando la ventana de falla.

Las cosas son más complicadas para los archivos del núcleo y del sistema, ya que se extienden por todo el sistema de archivos.

Hemos utilizado enlaces duros y blandos en el sistema de archivos para identificar archivos críticos. Utilizamos hashes en archivos y archivos para verificar la integridad de los archivos. Hemos considerado el uso de ramfs de emergencia en el kernel para proporcionar una alternativa si el sistema de archivos actualizado falla.

¿Cuáles son sus enfoques para este requisito?

Answer 1

Iría con el mismo enfoque que con los archivos de la aplicación: Cree los archivos críticos y complete su propia partición, vincúlelos y duplique la partición. En todo su init, primero debe verificar si los enlaces muestran todos a la misma partición, si no, restablecerlos (a la partición con los archivos con la fecha más reciente de un determinado archivo). Si desea actualizar, simplemente copie todo en la nueva partición, y si todo está bien (crcs ok), repita los archivos y configure para cada uno el enlace de un sistema de archivos al otro.

De esta manera, sus archivos críticos deben estar siempre en buen estado.

Escenarios:

1. La actualización falla al copiar archivos en una nueva partición

   No hay problema porque los enlaces todavía se muestran a los antiguos que funcionaban.

2. La actualización falla al vincular

   No hay problema porque todos los archivos nuevos son válidos y ya se han copiado (de lo contrario, el paso de vinculación no habría comenzado), la verificación de configuración corrige esto

Answer 2

Si debe garantizar la fiabilidad, puede tener dos particiones flash (o incluso chips), una con la configuración de trabajo actual y otra con la nueva configuración. Luego, use un watchdog de hardware que restablecerá la unidad y cambiará la partición activa del flash de arranque al último "bien conocido". configuración.

Answer 3

Tener al menos dos particiones. Sugeriría 4

• boot

• arranque alternativo

• copia de seguridad de datos del programa

• datos volátiles del programa

Use el arranque de respaldo de grub para arrancar alternativamente si el arranque falla.

Entonces, si la actualización falla, la alternativa funciona.

NUNCA actualice el gestor de arranque.

Si la partición de datos está tostada, vuelva a formatear y copie sobre la partición de datos de respaldo.

Ahora no puede fallar a menos que el disco flash muera. Si está utilizando hardware COTS, y el disco principal era, por ejemplo, Compact flash, podría tener una copia de seguridad aislada físicamente, por ejemplo, una pequeña llave USB.

Answer 4

En mi humilde opinión, cualquier actualización que no sea atómica puede dañar el sistema o dificultar la verificación de la consistencia. Estoy de acuerdo en que se debe evitar actualizar el cargador de arranque porque no es seguro. En general, un fabricante desea una actualización del firmware x.x.x a la versión y.y.y, sin molestarse si se actualizó el núcleo y / o un solo archivo. La actualización de archivos individuales puede convertirse en una pesadilla para el servicio, ya que es muy difícil entender qué se está ejecutando en el hardware del cliente. Tal vez esté mezclando un enfoque de copia doble (la aplicación es redundante) con un enfoque de copia única. Creo que esto no ayuda mucho, porque la integridad del sistema la realiza el componente débil de la cadena. Si falla una actualización del sistema de archivos raíz, no es importante que la aplicación esté duplicada.

Un enfoque de copia doble puede garantizar una actualización sin servicio, si lo necesita. Pero requiere muchos recursos, porque todos los componentes deben estar duplicados. Personalmente, utilizo un enfoque alternativo, donde se inicia un pequeño rootfs en RAM si la aplicación principal falla o si la última actualización no fue exitosa. Este sistema de respaldo, iniciado automáticamente por el gestor de arranque si algo sale mal, actualiza el sistema desde un lápiz USB (si se requiere una actualización local).

Nunca he encontrado un proyecto de OSS sobre estos problemas y recientemente comencé uno nuevo, basado en mi experiencia previa. Tengo varios productos ejecutándolo y mi cliente está contento con él.

Quizás puedas echarle un vistazo. Puede encontrar fuentes para "swupdate" (el nombre del proyecto) en github.com/sbabic/swupdate .

Stefano

Answer 5

Creo que lo que está tratando de lograr aquí es la atomicidad del proceso de actualización. La atomicidad es crítica para los dispositivos integrados, una de las razones destacadas es la pérdida de energía; pero podría haber otros como problemas de hardware / red. Una definición que uso para atomicidad en el contexto de las actualizaciones es:

• Una actualización siempre se completa por completo o no se completa
• Ningún componente de software además del actualizador ve una actualización medio instalada

Para Embedded Linux hay varios componentes de software que puede que desee actualizar y diferentes diseños para elegir; Hay un documento sobre esto aquí: https: // mender .io / user / pages / 04.resources / _white-papers / Software% 20Updates.pdf