técnicas recomendadas para o campo atualizando Linux embarcado com segurança

Question

incorporados dispositivos baseados em Linux muitas vezes requerem um mecanismo para atualizar aplicativos e arquivos do sistema. Por exemplo, um (sem rede) instrumento de laboratório com uma porta USB pode obter actualizações de software de um stick USB.

Seria uma questão simples de executar um script para copiar arquivos no lugar de memória flash interna do dispositivo. No entanto, existe o perigo de que o dispositivo seria perder o poder no meio da atualização, e acabam por um tijolo.

A situação para os arquivos do aplicativo é um pouco mais fácil, pois há espaço para duplicar o diretório do aplicativo, atualização de uma cópia de, e rapidamente trocar diretórios antigos e novos minimizando a janela de fracasso.

As coisas são mais arriscado para os arquivos do kernel e do sistema, uma vez que estão espalhados por todo o sistema de arquivos.

Temos usado ligações duros e moles no sistema de arquivos para identificar arquivos críticos. Usamos hashes de arquivos e arquivos para verificar a integridade do arquivo. Nós consideramos usando um ramfs de emergência no kernel para fornecer uma alternativa se a partir do sistema de arquivos atualizado falhar.

Quais são as suas abordagens a esta exigência?

Answer 1

Eu iria com a mesma abordagem com os arquivos do aplicativo: Faça para os arquivos críticos e partição própria completa, ligar para eles, e duplicar a partição. Em toda a sua inicialização você deve como primeiro verificar se os links mostrar tudo para a mesma partição, se não, redefini-las (para a partição com os arquivos com a data mais recente de um determinado arquivo). Se você quiser atualizar apenas copiar tudo para a nova partição, e se está tudo bem (CRCs ok) loop sobre os arquivos e conjunto para cada link de um sistema de arquivos para o outro.

Desta forma, seus arquivos críticos deve ser estar sempre em estado saudável.

Cenários:

1. Atualização falha ao copiar arquivos para nova partição

   No Problem porque as ligações mostram ainda que os antigos de trabalho.

2. Atualização falha ao ligar

   No Problem, porque todos os novos arquivos são válidos e já copiado (senão o passo relink não teria início), verificação de configuração corrigir este

Answer 2

Se você deve assegurar a confiabilidade, você pode ter duas partições de flash (ou mesmo chips), um com a configuração de trabalho atual e um com a nova configuração. Em seguida, use um cão de guarda hardware que irá reiniciar o aparelho e muda a partição flash de inicialização ativo para a configuração "última boa conhecidos".

Answer 3

Ter pelo menos duas partições. Eu sugiro 4

• boot

• boot alternativo

• backup de dados do programa

• programa de dados volátil

Use grub fallback inicialização para alternar inicialização se inicialização falhar.

Então, se a atualização falhar, os trabalhos alternativos.

NUNCA atualizar o gerenciador de inicialização.

Se a partição de dados é torrado, reformatação e copiar a partição de dados de backup.

Agora, você não pode falhar a menos que as matrizes de disco de flash. Se você estiver usando hardware COTS, e do disco principal era digamos, Compact Flash, você poderia ter um backup fisicamente isolado no digamos, uma pequena chave USB.

Answer 4

IMHO qualquer atualização que não é atômica pode quebrar o sistema ou fazer a verificação de consistência bastante difícil. Concordo que atualizar o carregador de inicialização deve ser evitado porque não é o desligamento seguro. Geralmente, um fabricante quer uma atualização de firmware para a versão x.x.x y.y.y, sem se preocupar se kernel e / ou um único arquivo foi atualizado. Atualizar arquivos individuais podem se tornar um pesadelo para o serviço, porque é muito difícil entender o que está sendo executado no hardware do cliente. Talvez você está misturando uma abordagem cópia dupla (aplicação é redundante) com uma abordagem de cópia única. Eu acho que isso não ajuda muito, porque a integridade do sistema é feito pelo componente fraco na cadeia. Se uma atualização do sistema de arquivos raiz falhar, não é importante que a aplicação é duplicada.

Uma abordagem cópia dupla pode garantir uma atualização sem fora de serviço, se você precisa disso. Mas isso requer uma grande quantidade de recursos, porque todos os componentes devem ser duplicados. Pessoalmente, eu uso uma abordagem fallback, onde um pequeno rootfs na RAM é iniciado se o aplicativo principal falhar ou se a última atualização não foi bem sucedida. Este sistema de fallback, iniciado automaticamente pelo bootloader se alguma coisa der errado, atualizar o sistema a partir de uma pen USB (se uma atualização local é necessária).

Eu nunca encontrei um projeto OSS sobre estas questões e eu comecei recentemente um novo, baseado na minha experiência anterior. Tenho vários produtos que funcionam e meu cliente está feliz com isso.

Talvez você pode dar uma olhada nisso. Você pode encontrar fontes para "swupdate" (o nome do projeto) em github.com/sbabic/swupdate .

Stefano

Answer 5

Eu acho que o que você está tentando alcançar aqui é atomicity do processo de actualização. Atomicidade é crítico para dispositivos embarcados, uma das razões realçadas é a perda de energia; mas poderia haver outros como problemas de hardware / rede. A utilização definição I para atomicity no contexto das alterações é a seguinte:

• Uma atualização é sempre ou totalmente concluída, ou não em todos
• componente de software Sem além do atualizador nunca vê uma meia atualização instalada

Para Embedded Linux há vários componentes de software que você pode querer atualizar e desenhos diferentes para escolher; há um artigo sobre isso aqui: https: // mender .io / user / pages / 04.resources / _white-papers / Software% 20Updates.pdf