Actualizaciones de OTA para Embedded Linux, parte 1 - Fundamentos e implementación

La necesidad de actualizaciones

Una vez que un producto de Linux embebido abandona el laboratorio y entra en el mundo real, será importante considerar la cuestión de cómo actualizar el dispositivo.

Las actualizaciones no siempre son necesarias, pero es difícil pensar en un software que no tenga errores que se descubran en algún momento. Incluso si su software es perfecto, si el dispositivo se comunica en redes o Internet con cualquier biblioteca de código abierto, las actualizaciones de seguridad pueden convertirse en una necesidad.

Tome el ejemplo de CVE-2104-01650 (Heartbleed). Esta vulnerabilidad afectó a la biblioteca de criptografía OpenSSL y, por extensión, a dos tercios de los sitios web en la red. Incluso ahora, tres años después, hay muchos dispositivos Linux embebidos que ejecutan una versión sin defensa de OpenSSL, completamente abierta al ataque.

Actualizaciones de bloque vs archivo

Cuando se habla de actualizar Linux, es posible que vea que se mencionan los sistemas de actualización de "bloque" y "archivo". Esto se refiere a actualizar una partición completa a la vez escribiendo directamente en el dispositivo de bloque o actualizando archivos individuales para realizar la actualización. Es posible que esté familiarizado con los sistemas de actualización de archivos de Desktop o Server Linux ("sudo apt-get upgrade", por ejemplo).

En Embedded Linux, las actualizaciones basadas en bloques son el camino a seguir debido a su atomicidad y al hecho de que un sistema de archivos completo es normalmente el resultado de un sistema de compilación Embedded Linux. Esperamos que el espacio de almacenamiento en cada dispositivo integrado sea constante para un producto en particular, por lo que creamos el mismo tamaño de partición cada vez. Este tipo de actualización va de la mano con tener algún tipo de imagen alternativa o de recuperación.

Recuperación en caso de falla

Nunca queremos que el dispositivo quede en un estado inutilizable (si, por ejemplo, ocurre un corte de energía). Podemos resolver esto asegurándonos de que siempre sea posible "retroceder" a otra partición en caso de que algo en el proceso de actualización salga mal.

Figura 1. Recuperación en caso de falla:opciones de respaldo (Fuente:ByteSnap)

Arriba puede ver dos posibles implementaciones de un modo de reserva en caso de un corte de energía. En el lado izquierdo, el cargador de arranque inicia una partición de rescate, que luego se inicia en una partición principal. En el lado derecho, el cargador de arranque arranca una de las dos particiones basadas en un conmutador.

El cargador de arranque debe implementar algún método para determinar si un arranque ha sido exitoso, y si no lo ha hecho, debe regresar a la partición de rescate (diagrama de la izquierda), o la partición de trabajo anterior (diagrama de la derecha).

El método de rescate (a la izquierda) permite que se proporcione más espacio a la partición principal, mientras que el método dual-rootfs (a la derecha) requiere que el espacio se divida más o menos uniformemente entre las dos particiones. Si el espacio no es un problema, entonces se recomienda utilizar el método dual-rootfs, solo porque resultará en menos tiempo de inactividad. La actualización a través del método de rescate requiere dos reinicios, uno en la partición de rescate y luego otro en la principal. El método dual-rootfs solo requiere un reinicio ya que la actualización se puede realizar en cualquier momento.

Lo que no puede actualizar de forma segura en estos sistemas es el cargador de arranque (o incluso la partición de rescate). Si también desea poder actualizar el cargador de arranque, necesitará dos particiones de cargador de arranque separadas y algún tipo de controlador de administración de placa para implementar la lógica de conmutación entre los dos.

Figura 2. Recuperación en caso de falla:controlador de administración de la placa (fuente:ByteSnap)

Por supuesto, esta es una solución complicada que requiere un microcontrolador adicional, un nuevo conjunto de firmware y un diseño de hardware más complicado (se usa en algunos dispositivos, los que contienen un controlador de Interfaz de administración de plataforma inteligente (IPMI) por separado, por ejemplo) . Por lo tanto, debes apuntar a construir un cargador de arranque que sea funcional, de alcance pequeño y, por lo tanto, no necesita ser actualizado.

Variables de entorno de U-Boot

U-boot implementa un "entorno" no volátil en el que se pueden almacenar variables. Incluso se puede acceder a estos desde Linux (de varias formas, dependiendo de cómo esté almacenado el entorno, como se detalla en elinux.org.

Esta es la forma más obvia de implementar el "cambio" descrito anteriormente. También se puede utilizar para almacenar información sobre los éxitos o fallos de arranque anteriores, de modo que, en caso de que se produzca un error al arrancar, el conmutador se pueda revertir y restaurar una partición en funcionamiento.

Figura 3. Variables de entorno de U-boot (Fuente:ByteSnap)