Atualizações OTA para Embedded Linux, parte 1 - Fundamentos e implementação

A necessidade de atualizações

Depois que um produto Embedded Linux deixa o laboratório e entra no mundo real, a questão de como atualizar o dispositivo se tornará importante a ser considerada.

As atualizações nem sempre são necessárias, mas é difícil pensar em qualquer software que não tenha bugs descobertos em algum ponto. Mesmo que o seu software seja perfeito, se o dispositivo se comunicar em redes ou na Internet com qualquer biblioteca de código aberto, as atualizações de segurança podem se tornar uma necessidade.

Veja o exemplo de CVE-2104-01650 (Heartbleed). Esta vulnerabilidade afetou a biblioteca de criptografia OpenSSL e, por extensão, dois terços dos sites na rede. Mesmo agora, três anos depois, existem muitos dispositivos Embedded Linux executando uma versão indefesa do OpenSSL, totalmente aberta para ataques.

Bloquear x atualizações de arquivo

Ao falar sobre a atualização do Linux, você pode ver os sistemas de atualização de “bloqueio” e “arquivo” sendo mencionados. Isso se refere à atualização de uma partição inteira de uma vez, gravando diretamente no dispositivo de bloco ou atualizando arquivos individuais para realizar a atualização. Você pode estar familiarizado com os sistemas de atualização de arquivos do Desktop ou Server Linux (“sudo apt-get upgrade” por exemplo).

No Embedded Linux, as atualizações baseadas em bloco são o caminho a seguir devido à sua atomicidade e ao fato de que um sistema de arquivos inteiro é normalmente a saída de um sistema de compilação do Embedded Linux. Esperamos que o espaço de armazenamento em cada dispositivo incorporado seja constante para um produto específico, portanto, criamos a partição do mesmo tamanho todas as vezes. Esse tipo de atualização anda de mãos dadas com algum tipo de imagem de fallback ou recuperação.

Recuperação em caso de falha

Nunca queremos que o dispositivo fique inutilizável (se, por exemplo, ocorrer uma queda de energia). Podemos resolver isso garantindo que sempre seja possível “retroceder” para outra partição caso algo dê errado no processo de atualização.

Figura 1. Recuperação em caso de falha - opções de fallback (Fonte:ByteSnap)

Acima você pode ver duas possíveis implementações de um modo de reserva em caso de queda de energia. No lado esquerdo, o Bootloader inicializa uma partição de resgate, que então inicializa em uma partição principal. No lado direito, o Bootloader inicializa uma das duas partições com base em um switch.

O carregador de inicialização deve implementar algum método para determinar se uma inicialização foi bem-sucedida e, caso não tenha, deve retornar à partição de resgate (diagrama à esquerda) ou à partição de trabalho anterior (diagrama à direita).

O método de resgate (à esquerda) permite que mais espaço seja fornecido para a partição principal, enquanto o método dual-rootfs (à direita) requer que o espaço seja dividido mais ou menos igualmente entre as duas partições. Se o espaço não for um problema, é recomendável usar o método dual-rootfs, apenas porque resultará em menos tempo de inatividade. A atualização por meio do método de resgate requer duas reinicializações, uma na partição de resgate e outra de volta à principal. O método dual-rootfs requer apenas uma reinicialização, pois a atualização pode ser realizada a qualquer momento.

O que você não pode atualizar com segurança nesses sistemas é o bootloader (ou mesmo a partição de resgate). Se você quiser ser capaz de atualizar o bootloader também, precisará de duas partições de bootloaders separadas e algum tipo de Board-Management-Controller para implementar a lógica de alternância entre os dois.

Figura 2. Recuperação em caso de falha - Board Management Controller (Fonte:ByteSnap)

Esta é, obviamente, uma solução complicada, que requer um microcontrolador extra, um novo conjunto de firmware e um design de hardware mais complicado (é usado em alguns dispositivos, aqueles que contêm um controlador de Interface de Gerenciamento de Plataforma Inteligente (IPMI) separado, por exemplo) . Portanto, você deve ter como objetivo construir um carregador de inicialização que seja funcional, de escopo pequeno e, portanto, não precise ser atualizado.

Variáveis ​​de ambiente U-Boot

O U-boot implementa um “ambiente” não volátil no qual as variáveis ​​podem ser armazenadas. Eles podem até ser acessados ​​do Linux (de várias maneiras, dependendo de como o ambiente está armazenado, conforme detalhado em elinux.org.

Esta é a forma mais óbvia de implementar a “mudança” descrita acima. Ele também pode ser usado para armazenar informações sobre sucessos ou falhas de inicialização anteriores, de forma que, no caso de uma falha na inicialização, o switch possa ser revertido e uma partição de trabalho restaurada.

Figura 3. Variáveis ​​de ambiente de inicialização U (Fonte:ByteSnap)