Ein Fehler in Linux 5.1 führte zu Datenverlust - ein Korrektur-Patch wurde bereits veröffentlicht

Vor einigen Wochen wurde in der Linux 5.1-Kernelversion ein Fehler entdeckt, der zu Datenverlust auf der SSD führte. Kürzlich haben Entwickler den Linux 5.1.5-Patch-Patch veröffentlicht, der eine „Lücke“ geschlossen hat.

Wir diskutieren, was der Grund war.


/ Unsplash / Glen Carrie

Was für ein Fehler

Zu Beginn des Jahres haben Entwickler eine Reihe von Änderungen am Linux 5.1-Kernel vorgenommen. Danach trat auf Systemen mit SSDs von Samsung, die dm-crypt / LUKS-Verschlüsselung mit Device-Mapper / LVM verwenden, ein Fehler auf , der zu Datenverlust führte. Das Problem wurde jedoch erst Mitte Mai bekannt - zu dieser Zeit wurde in thematischen Foren aktiv darüber diskutiert .

Es sind mindestens zwei Personen bekannt, die den Fehler kennen: LKML- Mailinglistenmitglied Michael Laß, der das Problem zuerst gemeldet hat , und ArchLinux- Benutzer .

Michael hat den Befehl fstrim ausgeführt, der dem Laufwerk mitteilt, welche Datenblöcke für das bereitgestellte btrfs-Volume nicht mehr verwendet werden. Nachdem er die folgenden Systemmeldungen erhalten hat:

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 

Danach stellte er fest, dass das btrfs-Volume beschädigt war und die verbleibenden logischen Volumes auf dem physischen Gerät zerstört wurden.

Im Fall des ArchLinux-Benutzers wirkte sich das Problem auf den kryptografischen Schutz von LUKS aus. Nach dem Neustart des Betriebssystems und dem Ausführen von fstrim erwiesen sich die LUKS-Header (die zur Suche nach Volumes verwendet werden) als unlesbar, sodass keine entschlüsselten verschlüsselten Daten zulässig waren.

Was ist der Grund

Das Problem war das Device Mapper (DM) -Subsystem, dessen Aufgabe es war, virtuelle Blockgeräte zu erstellen. Es wird nur verwendet, um den LVM Logical Volume Manager, das Software-RAID und das dm-crypt-Festplattenverschlüsselungssystem zu implementieren.

„Das fstrim-Team hat zu viele Blöcke gleichzeitig markiert, ohne das max_io_len_target_boundary-Limit zu berücksichtigen. Dadurch werden die noch verwendeten Speichersegmente freigegeben “, kommentiert Sergey Belkin, Leiter der Entwicklungsabteilung 1cloud.ru . "Da der Fehler mit dem Geräte-Mapper zusammenhängt, kann theoretisch ein Datenverlust auf jedem Dateisystem auftreten."

Patch

Kernel-Entwickler haben Ende Mai einen Patch für den Fehler veröffentlicht. Nur vier Zeilen in der Datei drivers / md / dm.c wurden geändert . Die entsprechenden Änderungen wurden auch am kommenden Linux 5.2-Kernel vorgenommen (hinzugefügte und gelöschte Zeilen sind mit "+" bzw. "-" gekennzeichnet):

 @@ -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; 

Der Patch wurde bereits von ArchLinux / Manjaro- und Fedora- Distributionsentwicklern angewendet. Die Ubuntu-Distribution hatte keinen Einfluss auf den Fehler, da sie nicht in die Linux 5.1-Kernelversion übersetzt wurde.


/ Flickr / Andy Melton / CC BY-SA

Sie können die Situation mit Datenverlust beseitigen, ohne den Patch zu installieren. Es reicht aus, den Dienst fstrim.service / timer mit den folgenden Befehlen zu deaktivieren:

 systemctl disable fstrim.timer systemctl stop fstrim.timer 

Eine andere Möglichkeit besteht darin, die ausführbare Datei fstrim umzubenennen oder das Verwerfungsflag beim Mounten von fstab zu entfernen. Sie können das Zulassen von Rückwürfen in LUKS auch über dmsetup deaktivieren. Alle diese Methoden sind jedoch nur vorübergehend und lösen nicht das Wesentliche des Problems.

Nicht das erste Mal

Dies ist nicht das erste Mal, dass ein Commit im Linux-Kernel zu Speicherbeschädigungssituationen führt. Eine ähnliche Geschichte ereignete sich in Linux Version 4.19 - dann waren die BLK-MQ I / O-Scheduler schuld. Das Problem trat auf, wenn der Kernel mit der standardmäßig festgelegten Option CONFIG_SCSI_MQ_DEFAULT = y erstellt wurde. In einigen Fällen waren die Volumendaten beschädigt.

 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 

Meistens manifestierte sich das Problem mit EXT4, aber theoretisch könnte es andere Dateisysteme betreffen.

Dann bereitete einer der Kernel-Betreuer eine kleine Lösung vor , die das Problem löste. Der gleiche Fehler wurde jedoch später im Linux 4.20-Build entdeckt. Es war endlich möglich, es Ende Dezember 2018 mit einem neuen globalen Update loszuwerden .

<sup>Unsere zusätzlichen Ressourcen und Quellen:

Dateisicherung: So schützen Sie sich vor Datenverlust
Risikominimierung: So verlieren Sie Ihre Daten nicht
Backup & Recovery: Streaming und intelligente Deduplizierung, Snapshots und Sekundärspeicher
So sparen Sie Geld mit der Anwendungsprogrammierschnittstelle
DevOps in einem Cloud-Dienst am Beispiel von 1cloud.ru
1cloud Cloud Architecture Evolution

Wie wir arbeiten: die 1cloud Digest
Mögliche Angriffe auf HTTPS und Möglichkeiten zum Schutz vor HTTPS</sup>