Il y a quelques semaines, un bug a été découvert dans la version du noyau Linux 5.1 qui a entraîné une perte de données sur le SSD. Récemment, les développeurs ont
publié le correctif Linux 5.1.5, qui comblait un «vide».
Nous discutons de la raison.
/ Unsplash / Glen CarrieQuel bug
Au début de l'année, les développeurs ont apporté un certain nombre de modifications au noyau Linux 5.1. Après cela, sur les systèmes équipés de SSD de Samsung qui utilisent le cryptage dm-crypt / LUKS avec device-mapper / LVM, une
erreur a commencé à apparaître , entraînant une perte de données. Mais le problème n'est
devenu connu qu'à la mi-mai - à ce moment-là, ils ont commencé à en
discuter activement
lors de forums thématiques .
Au moins deux personnes qui connaissent le bogue sont
connues: Michael Laß,
membre de la liste de diffusion
LKML , qui a
signalé le problème pour la première
fois , et
utilisateur d' ArchLinux.
Michael a
exécuté la commande fstrim, qui indique au lecteur quels blocs de données ne sont plus utilisés pour le volume btrfs monté. Après avoir reçu les messages système suivants:
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
Après cela, il a découvert que le volume btrfs était corrompu et les volumes logiques restants sur le périphérique physique ont été détruits.
Dans le cas de l'utilisateur ArchLinux, le problème a affecté la protection cryptographique de LUKS. Après avoir redémarré le système d'exploitation et exécuté fstrim, les en-têtes LUKS (qui sont utilisés pour rechercher des volumes) se sont révélés illisibles, ce qui ne permettait pas les données chiffrées déchiffrées.
Quelle est la raison
Le problème était le sous-système
Device Mapper (DM), dont la tâche était de créer des périphériques de bloc virtuel. Il est juste utilisé pour implémenter le gestionnaire de volumes logiques LVM, le RAID logiciel et le système de chiffrement de disque dm-crypt.
«L'équipe fstrim a marqué trop de blocs à la fois sans tenir compte de la limite max_io_len_target_boundary. En conséquence, les segments de mémoire encore utilisés sont libérés », commente Sergey Belkin, chef du département de développement 1cloud.ru . "Étant donné que l'erreur était liée au mappeur de périphériques, en théorie, une perte de données pourrait se produire sur n'importe quel système de fichiers."
Patch
Les développeurs du noyau ont publié un correctif pour le bogue fin mai. Seules quatre lignes du fichier drivers / md / dm.c ont été
modifiées . Les modifications correspondantes ont également été apportées au prochain noyau Linux 5.2 (les lignes ajoutées et supprimées sont marquées respectivement par «+» et «-»):
@@ -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;
Le correctif a déjà été appliqué par les développeurs de distribution
ArchLinux / Manjaro et
Fedora . La distribution Ubuntu
n'a pas affecté l' erreur, car elle n'a pas été traduite dans la version du noyau Linux 5.1.
/ Flickr / Andy Melton / CC BY-SAVous pouvez éliminer la situation de perte de données sans installer le correctif. Il suffit de désactiver le service fstrim.service / timer à l'aide des commandes:
systemctl disable fstrim.timer systemctl stop fstrim.timer
Une autre option consiste à renommer l'exécutable fstrim ou à supprimer l'indicateur de rejet lors du montage de fstab. Vous pouvez également désactiver allow-discards dans LUKS via dmsetup. Cependant, toutes ces méthodes
ne sont
que temporaires et ne résolvent pas l'essence du problème.
Pas la première fois
Ce n'est pas la première fois qu'un commit dans le noyau Linux entraîne des situations de corruption de mémoire. Une histoire similaire
s'est produite dans la version 4.19 de Linux - alors les planificateurs d'E / S BLK-MQ étaient à blâmer. Le problème s'est manifesté lors de la construction du noyau avec l'option CONFIG_SCSI_MQ_DEFAULT = y, définie par défaut. Dans certains cas, les données de volume
étaient corrompues.
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
Le plus souvent, le problème s'est manifesté avec EXT4, mais en théorie, il pourrait affecter d'autres systèmes de fichiers.
Ensuite, l'un des responsables du noyau a
préparé un petit correctif qui a résolu le problème. Cependant, le même bogue a été découvert plus tard dans la version Linux 4.20. Il a finalement été possible de
s'en débarrasser fin décembre 2018 avec une nouvelle mise à jour globale.
Nos ressources et sources supplémentaires:
Sauvegarde de fichiers: comment être à l'abri de la perte de données
Minimisation des risques: comment ne pas perdre vos données
Sauvegarde et restauration: streaming et déduplication intelligente, instantanés et stockage secondaire
Comment économiser de l'argent en utilisant l'interface de programmation d'application
DevOps dans un service cloud en utilisant 1cloud.ru comme exemple
1cloud Cloud Architecture Evolution
Comment nous travaillons: le résumé 1cloud
Attaques potentielles contre HTTPS et moyens de se protéger contre celles-ci