Hallo zusammen, wir teilen mit Ihnen den zweiten Teil der Veröffentlichung "Virtuelle Dateisysteme in Linux: Warum sie benötigt werden und wie sie funktionieren?" Den ersten Teil können Sie lesen . Wir erinnern daran, dass diese Serie von Veröffentlichungen im Rahmen der EinfĂŒhrung eines neuen Kurses , der schon bald beginnt.
Wie man VFS mit eBPF- und bcc-Tools ĂŒberwacht
Der einfachste Weg zu verstehen, wie der Kernel mit Dateien umgeht sysfs â besteht darin, dies praktisch zu beobachten, und der einfachste Weg, auf ARM64 zu beobachten, besteht darin, eBPF zu verwenden. eBPF (AbkĂŒrzung fĂŒr Berkeley Packet Filter) besteht aus einer virtuellen Maschine, die im , auf die privilegierte Benutzer ĂŒber die Kommandozeile zugreifen können (query). Der Kernel-Quellcode informiert den Leser darĂŒber, was der Kernel tun kann; die AusfĂŒhrung von eBPF-Tools in einem ausgelasteten System zeigt, was der Kernel tatsĂ€chlich tut.
GlĂŒcklicherweise ist es relativ einfach, eBPF mithilfe von Tools zu verwenden, , die als Pakete aus der allgemeinen Distribution verfĂŒgbar sind und detailliert dokumentiert sind Die Werkzeuge bcc â das sind Python-Skripte mit kurzen C-Code-EinfĂŒgungen, was bedeutet, dass jeder, der mit beiden Sprachen vertraut ist, sie problemlos anpassen kann. In bcc/tools gibt es 80 Python-Skripte, was bedeutet, dass wahrscheinlich ein Entwickler oder Systemadministrator etwas Passendes zur Lösung seiner Aufgaben finden kann.
Um zumindest einen groben Ăberblick darĂŒber zu bekommen, welche Aufgaben VFS in einem laufenden System erfĂŒllt, versuchen Sie es bitte mit vfscount oder vfsstat. Dies zeigt zum Beispiel, dass Dutzende von Aufrufen vfs_open() und dessen âVerwandtenâ buchstĂ€blich jede Sekunde auftreten.
vfsstat.pyâ ist ein Python-Skript mit C-Code-EinfĂŒgungen, das einfach die Aufrufe der VFS-Funktionen zĂ€hlt.
Lassen Sie uns ein triviales Beispiel anfĂŒhren und sehen, was passiert, wenn wir einen USB-Stick in den Computer stecken und das System ihn erkennt.
Mit eBPF kann man sehen, was passiert in
/sys, wenn ein USB-Stick eingesteckt wird. Hier wird ein einfaches und ein komplexes Beispiel gezeigt.
Im oben gezeigten Beispiel bcc Tool gibt eine Nachricht aus, wenn der Befehl sysfs_create_files()ausgefĂŒhrt wird. Wir sehen, dass sysfs_create_files() es mit Hilfe von kworker gestartet wurde. Im Kontext der Reaktion auf das Einstecken eines USB-Sticks, welche Datei wurde dabei erstellt? Das zweite Beispiel veranschaulicht die gesamte LeistungsfĂ€higkeit von eBPF. Hier trace.py zeigt die Kernel-Backtrace (Option -K) und den Namen der Datei, die erstellt wurde. sysfs_create_files()Das EinfĂŒgen in einfache Aussagen ist ein C-Code, der eine leicht erkennbare Formatzeichenfolge beinhaltet, bereitgestellt durch ein Python-Skript, das LLVM ausfĂŒhrt. Just-in-Time-Compiler. Diese Zeichenfolge wird kompiliert und in einer virtuellen Maschine innerhalb des Kernels ausgefĂŒhrt. Die vollstĂ€ndige Funktionssignatur sysfs_create_files() muss im zweiten Befehl reproduziert werden, damit die Formatzeichenfolge auf einen der Parameter verweisen kann. Fehler in diesem C-Code-Segment fĂŒhren zu erkennbaren C-Compilerfehlern. Wenn beispielsweise der Parameter -l fehlt, sehen Sie die Meldung "Failed to compile BPF text." Entwickler, die gut mit C und Python vertraut sind, finden die Tools bcc einfach zu erweitern und zu Ă€ndern.
Wenn der USB-Stick eingesteckt ist, zeigt die Kernel-Backtrace, dass PID 7711 der Prozess ist kworker gestartet wurde., der die Datei erstellt hat "events" in sysfs. Entsprechend zeigt der Aufruf von sysfs_remove_files() dass das Entfernen des Speichermediums zur Löschung der Datei events, was der allgemeinen Konzept der LinkzÀhlung entspricht. Dabei zeigt die Ansicht sysfs_create_link () , dass eBPF wÀhrend des Einsteckens eines USB-Sticks nicht weniger als 48 symbolische Links erstellt.
Was ist also der Sinn der Datei events? Die Verwendung von zum Suchen von , zeigt, dass es disk_add_events (), entweder "media_change", oder "eject_request" in die Ereignisdatei geschrieben werden können. Hier informiert die Blockschicht des Kernels den Userspace ĂŒber das Erscheinen und Entfernen des âDisksâ. Beachten Sie, wie informativ diese Forschungsmethode am Beispiel des Einsteckens eines USB-Sticks im Vergleich zu dem Versuch, herauszufinden, wie alles nur aus dem Quellcode funktioniert.
Nur-Lese-Wurzel-Dateisysteme ermöglichen eingebaute GerÀte.
NatĂŒrlich schaltet niemand seinen Server oder Computer einfach aus, indem er den Stecker zieht. Aber warum? Das liegt daran, dass die gemounteten Dateisysteme auf physischen Speichermedien verzögerte SchreibvorgĂ€nge haben können und die Datenstrukturen, die ihren Zustand festhalten, möglicherweise nicht mit den Aufzeichnungen im Speicher synchronisiert sind. Wenn dies geschieht, mĂŒssen die Systembesitzer auf den nĂ€chsten Boot warten, um das Tool fsck filesystem-recovery auszufĂŒhren und im schlimmsten Fall Daten zu verlieren.
Dennoch wissen wir alle, dass viele IoT-GerĂ€te sowie Router, Thermostate und Autos mittlerweile mit Linux betrieben werden. Viele dieser GerĂ€te haben praktisch keine BenutzeroberflĂ€che, und es gibt keinen Weg, sie "sauber" herunterzufahren. Stellen Sie sich vor, Sie starten ein Auto mit einer leeren Batterie, wĂ€hrend die Stromversorgung der Steuereinheit stĂ€ndig schwankt. Wie kann das System starten, ohne einen langen fsckauszufĂŒhren, wenn der Motor schlieĂlich anspringt? Die Antwort ist einfach. Eingebettete GerĂ€te verlassen sich auf das Wurzel-Dateisystem (abgekĂŒrzt ro-rootfs (read-only root filesystem)).
ro-rootfs bieten viele Vorteile, die weniger offensichtlich sind als die UnverĂ€nderlichkeit. Ein Vorteil besteht darin, dass Malware nicht in schreiben kann, wenn kein Linux-Prozess dazu in der Lage ist. /usr oder /libEin weiterer Vorteil ist, dass ein weitgehend unverĂ€nderliches Dateisystem entscheidend fĂŒr die UnterstĂŒtzung von Remote-GerĂ€ten ist, da das Support-Personal lokale Systeme nutzt, die nominell identisch mit den Systemen vor Ort sind. Möglicherweise ist der wichtigste (aber auch hinterhĂ€ltigste) Vorteil, dass ro-rootfs Entwickler zwingt, zu entscheiden, welche Systemobjekte unverĂ€nderlich sein werden, bereits in der Planungsphase des Systems. Der Umgang mit ro-rootfs kann unangenehm und schmerzhaft sein, Ă€hnlich wie es oft mit const-Variablen in Programmiersprachen der Fall ist, aber ihre Vorteile rechtfertigen leicht die zusĂ€tzlichen Kosten.
Erstellung rootfs im Nur-Lesen-Modus erfordert einige zusĂ€tzliche Anstrengungen von Entwicklern eingebetteter Systeme, und hier kommt das VFS ins Spiel. Linux erfordert, dass Dateien in /var waren fĂŒr die Konfiguration verfĂŒgbar, und zusĂ€tzlich werden viele beliebte Anwendungen, die auf eingebetteten Systemen laufen, versuchen, Konfigurationsdateien zu erstellen. dot-files in $HOME. Eine der Lösungen fĂŒr Konfigurationsdateien im Home-Verzeichnis besteht normalerweise darin, diese im Voraus zu generieren und zu bĂŒndeln. rootfs. FĂŒr /var eine mögliche Vorgehensweise besteht darin, es in einem separaten, beschreibbaren Bereich zu mounten, wĂ€hrend das System selbst / nur im Lesemodus gemountet wird. Eine andere beliebte Alternative ist die Verwendung von bind- oder overlay-mounts.
Bind- und overlay-mounts, deren Einsatz durch Container
Die AusfĂŒhrung des Befehls man mount ist der beste Weg, um mehr ĂŒber bind- und overlay-mounts zu erfahren, die Entwicklern und Systemadministratoren die Möglichkeit geben, ein Dateisystem unter einem Pfad zu erstellen und es dann Anwendungen unter einem anderen zur VerfĂŒgung zu stellen. FĂŒr eingebettete Systeme bedeutet dies, Dateien in /var auf einem nur lesbaren Flash-Laufwerk zu speichern, jedoch lĂ€sst sich ein gebundener oder ĂŒberlagerter Mount fĂŒr den Pfad aus tmpfs in /var Beim Laden ermöglicht es den Anwendungen, dort Notizen (scrawl) zu hinterlassen. Beim nĂ€chsten Einschalten gehen die Ănderungen verloren. /var Das Overlay-Mounting schafft eine Verbindung zwischen tmpfs und dem darunter liegenden Dateisystem und erlaubt, scheinbare Ănderungen an bestehenden Dateien in ro-tootf wĂ€hrend ein bind-Mount neue leere tmpfs Verzeichnisse sichtbar machen kann, die als beschreibbar in ro-rootfs Pfaden auftreten. WĂ€hrend overlayfs der richtige (proper) Typ eines Dateisystems ist, ist das bind-Mount im .
Basierend auf der Beschreibung von Overlay- und Bind-Mounting ist es nicht ĂŒberraschend, dass sie aktiv verwenden. Lassen Sie uns beobachten, was passiert, wenn wir um einen Container zu starten, wobei wir das Tool mountsnoop ab bcc.
Aufruf system-nspawn startet den Container wÀhrend des Betriebs mountsnoop.py.
Schauen wir uns an, was passiert ist:
Start mountsnoop WÀhrend des "Ladens" des Containers zeigt es, dass die Laufzeitumgebung des Containers stark vom Bind-Mount abhÀngig ist (nur der Anfang einer umfangreichen Ausgabe wird angezeigt).
Hier systemd-nspawn stellt ausgewĂ€hlte Dateien aus procfs und sysfs dem Host im Container als Pfade in dessen rootfs. Neben MS_BIND Flags, die eine bindende Montage festlegen, sowie einige andere Flags im montierten System definieren die Beziehung zwischen Ănderungen im Namespace des Hosts und des Containers. Beispielsweise kann eine bindende Montage Ănderungen entweder in den Container durchlassen oder sie je nach Aufruf verbergen. /proc und /sys Im Container können Ănderungen entweder durchgelassen oder verborgen werden, abhĂ€ngig von dem Aufruf.
Fazit
Das VerstĂ€ndnis der internen Funktionsweise von Linux kann wie eine unĂŒberwindbare Aufgabe erscheinen, da der Kernel selbst eine riesige Menge an Code enthĂ€lt, ganz zu schweigen von den Anwendungen im Benutzerspeicher und den Systemaufruf-Interfaces in C-Bibliotheken wie glibc.Eine Möglichkeit, Fortschritte zu erzielen, besteht darin, den Quellcode eines bestimmten Kernelsubsystems mit dem Fokus auf das VerstĂ€ndnis der Systemaufrufe und der Header, die an den Benutzerspeicher gerichtet sind, sowie grundlegender interner Schnittstellen des Kernels zu lesen, zum Beispiel die Tabelle. file_operationsDateioperationen folgen dem Prinzip âAlles ist eine Dateiâ, daher ist der Umgang mit ihnen besonders angenehm. Die Quellcodes des Kernels in C befinden sich im obersten Verzeichnis. fs/ stellen eine Implementierung von virtuellen Dateisystemen dar, die eine Schicht bereitstellen, die eine breite und relativ einfache KompatibilitĂ€t mit populĂ€ren Dateisystemen und SpeichergerĂ€ten gewĂ€hrleistet. Das Einbinden durch Binding und Overlay ĂŒber die NamensrĂ€ume von Linux ist die Magie von VFS, die die Erstellung von Containern und schreibgeschĂŒtzten Root-Dateisystemen ermöglicht. In Kombination mit der Analyse des Quellcodes, dem eBPF-Kernel-Tool und seiner Schnittstelle. bcc
macht die Untersuchung des Kernels einfacher als je zuvor.
Freunde, teilen Sie uns mit, ob dieser Artikel fĂŒr Sie hilfreich war. Vielleicht haben Sie Kommentare oder Anmerkungen? Und diejenigen, die am Kurs âLinux-Administratorâ interessiert sind, laden wir ein zu , der am 18. April stattfindet.
Quelle: habr.com
