Faz sentido ter volumes ubi separados para segurança com ubifs?

Question

Nos dias pré-ubifs, era prática comum em sistemas embarcados configurar várias partições (MTD) em flash para proteção. Por exemplo, uma partição contendo um sistema de arquivos somente para leitura pode ser montada como /, com uma partição gravável separada para dados de configuração montados como / home ou / data ou qualquer outra coisa.

Por outro lado, uma das principais características do UBI é que ele fornece "volumes UBI" lógicos e, ao mesmo tempo, faz o nivelamento de desgaste em todo o dispositivo flash. Citando o site do MTD :

UBI implements wear-leveling across whole flash device (i.e., you may continuously write/erase only one logical eraseblock of an UBI volume, but UBI will spread this to all physical eraseblocks of the flash chip);

A minha pergunta é: faz sentido ter volumes UBI separados, por ex. um sistema de arquivos somente leitura versus dados de configuração? Ou isso é inútil devido ao fato de que todo o flash participa internamente do nivelamento de desgaste?

    

Answer 1

Sim, certamente pode fazer sentido. Os sistemas embarcados normalmente manterão duas ou mais imagens de inicialização separadas no flash. Dessa forma, eles podem apagar e atualizar um e voltar para o outro caso a atualização falhe. Se você estiver mantendo seu sistema de arquivos raiz e seus dados de configuração no mesmo volume, estará tornando seu processo de upgrade muito mais complicado, já que você precisa gerenciar a movimentação dos dados de configuração para o novo volume (e rastrear quais dados são " correto "nos vários casos de falha / fallback).

Portanto, manter os dados do programa estático em um volume separado dos dados de configuração mutáveis é uma boa ideia em geral. Considerando especificamente o UBIFS, existem várias opções:

• Mantenha os rootfs em um squashfs sobre um volume UBI bruto. Você pode usar a opção de kernel MTD_UBI_BLOCK para apresentar um volume UBI como um dispositivo de bloco e montar os squashfs a partir daí. Nesse caso, você poderia escrever uma nova imagem diretamente do U-Boot, já que o U-Boot pode gravar volumes UBI brutos, mas só pode ler arquivos em um UBIFS.
• Mantenha os rootfs como um UBIFS separado. Isso requer muito espaço extra, já que o UBIFS é muito menos eficiente que o squashfs no armazenamento de metadados do sistema de arquivos, e se o seu rootfs é somente leitura, não há nenhum benefício real.
• Mantenha o rootfs como um arquivo squashfs no volume UBIFS e monte-o em loop. Isso usa um pouco de espaço extra (os metadados para o arquivo rootfs em si), mas tem uma flexibilidade extra, já que você não precisa se preocupar com quanto espaço reservar para imagens de inicialização versus dados de configuração. (No entanto, essa flexibilidade pode ser uma coisa ruim se você acidentalmente usar todo o seu espaço em imagens de inicialização.)
• Mantenha os rootfs diretamente no MTD. Isso perde os benefícios de nivelamento de desgaste inteiramente para os rootfs e diminui a eficácia do nivelamento de desgaste para os volumes graváveis, já que há menos blocos de apagamento disponíveis para serem rotacionados.