In dieser Folge stellt Stefan einen Bug im EROFS Dateisystem vor, der dafür sorgt, dass sich Dateien zwar richtig lesen lassen, aber jeder Versuch sie als Programm auszuführen katastrophal scheitert.

Nach der Vorstellung des Bugs und seiner Lösung führt Lucas uns in die Tiefen der Computerarchitektur und erklärt uns, wie der falsche Umgang mit CPU-Caches zu diesem Fehler geführt hat.

In dieser Folge kommen wir an Themen vorbei wie Read-Only-Dateisysteme, Memory-Mapping von Dateien und Programmen, virtuelle Speicheradressierung, Adressierung in CPU-Caches und warum "Flushen" ein unpräziser Begriff ist.

Ein thematischer Deep-Dive also vom Lesen von Dateien im Userspace bis hinunter zur Prozessorarchitektur.

Über den Kernel Panic - Board on Fire Podcast

In wahrscheinlich jedem Berufsfeld gibt es Schauergeschichten, die man sich abends am Lagerfeuer mit einer Taschenlampe am Kinn erzählen kann. So auch in der Welt der Software. In diesem Podcast geben wir in unregelmäßigen Abständen Entwicklerinnen und Entwicklern die Möglichkeit ihre Schauergeschichten zu erzählen. Es geht um monatelange Fehlersuchen, deren Ergebnis nur eine Hand voll Zeilen falscher Code sind, um subtil fehlerhafte Hardware, die zu sporadisch auftretenden Geistern im System führt, um bröckelnde Software, deren Quellcode schon vor Jahren verloren gegangen ist, und manchmal auch um ganz was anderes.

Shownotes

Wer nicht die ganze Folge hören möchte kann sich an den folgenden Zeitmarken orientieren:

00:00

Einleitende warme Worte. Stefan und Lucas stellen sich vor. Lucas ist schon "Board on Fire"-Veteran und ansonsten im Pengutronix Grafikteam unterwegs. Stefan bestreitet seine erste Folge und ist sonst im Kernel Team beschäftigt.

05:00

Stefan stellt den Bug vor. Er hat ein System mit 32Bit ARM Prozessor vom SquashFS Read-Only Dateisystem auf das neuere EROFS umgestellt. Im Anschluss crashte das System immer direkt beim Ausführen des Init-Prozess.

16:00

Exkurs zu dm-verity und wie es benutzt werden kann, um die Authentizität des Root-Dateisystem im laufenden Betrieb zu gewährleisten.

22:00

Zurück zu den Read-Only-Dateisystemen SquashFS und EROFS.

25:00

Wir kommen auf den eigentlichen Bug zu sprechen. Sobald in den Init-Prozess auf dem EROFS gesprungen wird crashed das System wegen "Illegal Instruction"- oder "Segmentation Fault"-Fehler.

29:00

Was hat Stefan versucht um das Problem einzugrenzen? Wird das Image schon falsch gebaut? Geht etwas beim Übertragen auf das System schief? Oder doch erst beim Auslesen? Deshalb an jedem Punkt Hash-Summen über die Init-Datei berechnen und vergleichen.

Das Ergebnis: die Datei sieht überall gleich aus.

Noch schlimmer: wenn man die Datei ersteinmal ganz gelesen hat, kann man sie auch ausführen.

35:00

Der erste Kontakt mit dem EROFS-Maintainer und gemeinsame Fehlersuche.

Neue Erkenntnisse: bei deaktivierter Komprimierung tritt der Fehler nicht auf und in QEMU ist er nicht reproduzierbar.

39:00

Der Verdacht: es könnte ein Problem mit den Prozessor-Caches sein.

41:00

Exkurs zum Memory-Maping von Datein und Demand-Paging.

42:00

Unterbrechung der Fehlersuche und stattdessen Weiterverwendung von SquashFS, bis ein anderer Contributor die Lösung liefert: ein Cache Flush nach dem Dekomprimieren der Daten.

45:00

Lucas übernimmt und erklärt, warum dieser Cache Flush notwendig ist um den Fehler zu beheben und warum es wahrscheinlich Glück war, dass das Problem nicht auch auf ARM64 Systemen augetreten ist.

50:00

Lucas erklärt warum sich der Fall ohne Komprimierung und der Fall mit Komprimierung so unterschiedlich verhalten. Im ersten Fall schreibt direkt der eMMC-Controller im SoC die Daten per DMA an die richtige Speicherstelle. Im zweiten Fall schreibt Software im Kernel die Daten an die Speicherstelle. Aus Sicht der CPU-Caches sind diese Fälle sehr unterschiedlich.

53:30

Lucas erklärt Virtually/Physically Indexed/Tagged Caches, warum wo welche Arten zum Einsatz kommen und welche Implikationen das jeweils hat.

70:00

Lucas erklärt was der Kernel machen muss, um eine frisch geschriebene Speicherstelle an den Userspace zu übergeben: zuerst für die virtuelle Speicherstelle aus Kernel-Sicht ein Zurückschreiben der Daten aus dem L1-Cache in den L2-Cache auslösen, dann für alle Speicherstellen aus Userspace-Sicht die möglicherweise existierenden Daten im L1-Cache invalidieren.

89:00

Ein kleiner Ausblick auf x86-Systeme, wo solche Probleme nicht auftreten, weil mit großem Aufwand die Caches zumindest so tun als wären sie Physically Indexed und Tagged.

90:00

Zusammenfassung und Abschluss.

Ausblick darauf, dass wir uns irgendwann mal das Thema Distributed Switch Architecture, und Netzwerkswitches im Allgemeinen anschauen können.

Außerdem hinweise auf Messen und Konferenzen, auf denen man uns in der nächsten Zeit treffen könnte, um einen Kernel Panic BoF Aufkleber abzustauben.