Algumas semanas atrás, um bug foi descoberto na versão do kernel Linux 5.1 que levou à perda de dados no SSD. Recentemente, os desenvolvedores
lançaram o patch
do Linux 5.1.5, que preencheu uma “lacuna”.
Discutimos qual foi o motivo.
/ Unsplash / Glen CarrieQue bug
No início do ano, os desenvolvedores fizeram várias alterações no kernel do Linux 5.1. Depois disso, em sistemas com SSDs da Samsung que usam criptografia dm-crypt / LUKS com mapeador de dispositivo / LVM, um
erro começou a aparecer , levando à perda de dados. Mas o problema
ficou conhecido apenas em meados de maio - na época eles começaram a
discuti-lo ativamente
em fóruns temáticos .
Pelo menos duas pessoas que conhecem o bug são
conhecidas: Michael Laß,
membro do LKML , que primeiro
relatou o problema , e
usuário do ArchLinux.
Michael
executou o comando fstrim, que informa à unidade quais blocos de dados não estão mais em uso para o volume btrfs montado. Depois que ele recebeu as seguintes mensagens do sistema:
attempt to access beyond end of device sda1: rw=16387, want=252755893, limit=250067632 BTRFS warning (device dm-5): failed to trim 1 device(s), last error -5 BTRFS warning (device dm-5): csum failed root 257 ino 16634085 off 21504884736 csum 0xd47cc2a2 expected csum 0xcebd791b mirror 1
Depois disso, ele descobriu que o volume btrfs estava corrompido e os volumes lógicos restantes no dispositivo físico foram destruídos.
No caso do usuário do ArchLinux, o problema afetou a proteção criptográfica do LUKS. Após a reinicialização do sistema operacional e a execução do fstrim, os cabeçalhos LUKS (que são usados para procurar volumes) ficaram ilegíveis, o que não permitia descriptografar dados criptografados.
Qual o motivo
O problema era o subsistema de
mapeador de dispositivo (DM), cuja tarefa era criar dispositivos de bloco virtual. É usado apenas para implementar o gerenciador de volume lógico LVM, o software RAID e o sistema de criptografia de disco dm-crypt.
“A equipe fstrim marcou muitos blocos de cada vez sem levar em conta o limite max_io_len_target_boundary. Como resultado, os segmentos de memória que ainda estão em uso são liberados ”, comenta Sergey Belkin, chefe do departamento de desenvolvimento 1cloud.ru . "Como o erro estava relacionado ao mapeador de dispositivos, em teoria, a perda de dados poderia ocorrer em qualquer sistema de arquivos."
Patch
Os desenvolvedores do kernel lançaram um patch para o bug no final de maio. Somente quatro linhas no arquivo drivers / md / dm.c foram
alteradas . As alterações correspondentes também foram feitas no próximo kernel Linux 5.2 (as linhas adicionadas e excluídas são marcadas com "+" e "-", respectivamente):
@@ -1467,7 +1467,7 @@ static unsigned get_num_write_zeroes_bios(struct dm_target *ti) static int __send_changing_extent_only(struct clone_info *ci, struct dm_target *ti, unsigned num_bios) { - unsigned len = ci->sector_count; + unsigned len; @@ -1478,6 +1478,8 @@ static int __send_changing_extent_only(struct clone_info *ci, struct dm_target * if (!num_bios) return -EOPNOTSUPP; + len = min((sector_t)ci->sector_count, max_io_len_target_boundary(ci->sector, ti)); + __send_duplicate_bios(ci, ti, num_bios, &len); ci->sector += len;
O patch já foi aplicado pelos desenvolvedores de distribuição
ArchLinux / Manjaro e
Fedora . A distribuição Ubuntu
não afetou o erro, pois não foi traduzido para a versão do kernel Linux 5.1.
/ Flickr / Andy Melton / CC BY-SAVocê pode eliminar a situação com perda de dados sem instalar o patch. É suficiente desativar o serviço fstrim.service / timer usando os comandos:
systemctl disable fstrim.timer systemctl stop fstrim.timer
Outra opção é renomear o executável fstrim ou remover o sinalizador de descarte ao montar o fstab. Você também pode desativar as permissões para devoluções no LUKS via dmsetup. No entanto, todos esses métodos
nada mais são do
que temporários e não resolvem a essência do problema.
Não é a primeira vez
Esta não é a primeira vez que um commit no kernel Linux leva a situações de corrupção de memória. Uma história semelhante
aconteceu no Linux versão 4.19 - então os planejadores de E / S do BLK-MQ foram os culpados. O problema foi manifestado ao criar o kernel com a opção CONFIG_SCSI_MQ_DEFAULT = y, definida por padrão. Em alguns casos, os dados do volume
foram corrompidos.
sed: error while loading shared libraries: /lib/x86_64-linux-gnu/libattr.so.1: unexpected PLT reloc type 0x00000107 sed: error while loading shared libraries: /lib/x86_64-linux-gnu/libattr.so.1: unexpected PLT reloc type 0x00000107
Na maioria das vezes, o problema se manifestava com o EXT4, mas em teoria poderia afetar outros sistemas de arquivos.
Em seguida, um dos mantenedores do kernel
preparou uma pequena correção que resolveu o problema. No entanto, o mesmo bug foi descoberto posteriormente na versão Linux 4.20. Finalmente, foi possível
se livrar dele no final de dezembro de 2018 com uma nova atualização global.
Nossos recursos e fontes adicionais:
Backup de arquivo: como se proteger contra perda de dados
Minimização de riscos: como não perder seus dados
Backup e recuperação: streaming e desduplicação inteligente, snapshots e armazenamento secundário
Como economizar dinheiro usando a interface de programação de aplicativos
DevOps em um serviço de nuvem usando 1cloud.ru como exemplo
1cloud Cloud Architecture Evolution
Como trabalhamos: o resumo da 1cloud
Ataques potenciais ao HTTPS e maneiras de se proteger contra eles