Virtuelle Dateisystemer an LinuxFirwat gi se gebraucht a wéi funktionéieren se? Deel 2

Moien alleguer, mir deelen den zweeten Deel vun der Publikatioun "Virtuell Dateisystemer an LinuxFirwat gi se gebraucht a wéi funktionéieren se? Den éischten Deel kann gelies ginn hei. Loosst eis Iech drun erënneren datt dës Serie vu Publikatiounen Zäit ass fir mam Start vun engem neie Stream um Cours zesummen ze kommen "Administrateur Linux», déi ganz geschwënn ufänkt.

Wéi iwwerwaacht VFS mat eBPF a bcc Tools

Deen einfachste Wee fir ze verstoen wéi de Kernel op Dateien funktionnéiert sysfs ass et an der Praxis ze gesinn, an deen einfachste Wee fir ARM64 ze kucken ass eBPF ze benotzen. eBPF (kuerz fir Berkeley Packet Filter) besteet aus enger virtueller Maschinn déi an Kär, déi privilegiéiert Benotzer kënnen ufroen (query) vun der Kommandozeil. D'Kernelquelle soen dem Lieser wat de Kernel ka maachen; d'eBPF Tools op engem geluedene System lafen weist wat de Kernel tatsächlech mécht.

Glécklech, unzefänken eBPF ze benotzen ass ganz einfach mat der Hëllef vun Tools BCC, déi als Packagen aus der allgemenger Verdeelung verfügbar sinn Linux an am Detail dokumentéiert Bernard Gregg. Tools bcc si Python Scripte mat klengen Insertiounen vum C Code, dat heescht datt jiddereen dee mat béide Sprooche vertraut ka se einfach änneren. IN bcc/tools Et ginn 80 Python Scripten, dat heescht, datt héchstwahrscheinlech en Entwéckler oder System Administrateur fäheg sinn eppes gëeegent fir de Problem ze léisen wielen.
Fir op d'mannst eng iwwerflächlech Iddi ze kréien iwwer wéi eng Aarbecht VFSs op engem lafende System maachen, probéiert vfscount oder vfsstat. Dëst wäert weisen, loosst eis soen, datt Dosende vun Uruff vfs_open() an "seng Frënn" geschéien wuertwiertlech all zweet.

vfsstat.py ass e Python Skript mat C Code Inserts déi einfach VFS Funktioun Uruff zielen.

Loosst eis e méi trivial Beispill ginn a kucken wat geschitt wa mir en USB Flash Drive an e Computer setzen an de System et erkennt.

Mat eBPF kënnt Dir gesinn wat geschitt an /syswann en USB Flash Drive agefouert gëtt. En einfacht a komplext Beispill gëtt hei gewisen.

Am Beispill hei uewen gewisen, bcc Instrument trace.py dréckt e Message wann de Kommando leeft sysfs_create_files(). Mir gesinn dat sysfs_create_files() gouf lancéiert benotzt kworker Stream als Äntwert op d'Tatsaach datt de Flash Drive agefouert gouf, awer wéi eng Datei gouf erstallt? Dat zweet Beispill weist d'Kraaft vun eBPF. Hei trace.py Dréckt e Kernel Backtrace (-K Optioun) an den Numm vun der Datei déi erstallt gouf sysfs_create_files(). Eenzeg Ausso Insertion ass C Code deen eng liicht erkennbar Formatstring enthält, déi vum Python Skript geliwwert gëtt, deen LLVM leeft just-in-time Compiler. Et kompiléiert dës Zeil an féiert se an enger virtueller Maschinn am Kernel aus. Voll Funktioun Ënnerschrëft sysfs_create_files () muss am zweete Kommando reproduzéiert ginn, sou datt d'Formatstring op ee vun de Parameteren bezéie kann. Feeler an dësem Stéck C Code resultéieren zu erkennbaren Feeler vum C Compiler. Zum Beispill, wann de -l Parameter ewech gelooss gëtt, gesitt Dir "Feiled to compile BPF Text." Entwéckler, déi mat C a Python vertraut sinn, fannen d'Tools bcc einfach ze vergréisseren an z'änneren.

Wann den USB Drive agebaut ass, weist de Kernel Backtrace datt PID 7711 e Fuedem ass kworkerdéi d'Datei erstallt huet «events» в sysfs. Deementspriechend den Uruff vun sysfs_remove_files() wäert weisen datt d'Ewechhuele vum Drive zu der Datei geläscht huet events, wat dem allgemenge Konzept vun der Referenzzielung entsprécht. Zur selwechter Zäit kucken sysfs_create_link () mat eBPF beim Asetzen vum USB Drive weist datt op d'mannst 48 symbolesch Linken erstallt goufen.

Also wat ass de Punkt vun der Eventdatei? Benotzung cscope Fir Sich __device_add_disk(), weist wat et verursaacht disk_add_events (), an entweder "media_change", oder "eject_request" kann an engem Event Fichier opgeholl ginn. Hei informéiert d'Kernelblockschicht de Benotzerraum datt eng "Disk" erschéngt an ausgestouss ass. Notéiert wéi informativ dës Fuerschungsmethod ass andeems Dir en USB Drive setzt, am Verglach mam Versuch erauszefannen wéi d'Saachen reng aus der Quell funktionnéieren.

Read-only Root Dateisystemer aktivéieren embedded Geräter

Natierlech schalt keen de Server oder hire Computer aus, andeems de Stecker aus der Socket zitt. Mee firwat? Dëst ass well montéiert Dateisystemer op physesch Späichergeräter verlagert Schreiwe kënnen hunn, an d'Datestrukturen, déi hiren Zoustand ophuelen, kënnen net mat Schreiwen op d'Späichere synchroniséiert ginn. Wann dat passéiert, musse Systembesëtzer bis den nächsten Boot waarden fir den Utility ze starten. fsck filesystem-recovery an, am schlëmmste Fall, Verléierer Donnéeën.

Mir all wëssen awer, datt vill IoT-Geräter, souwéi Routeren, Thermostaten an Autoen, elo op ... lafen. LinuxVill vun dësen Apparater hunn praktesch keng Benotzeruewerfläch, an et gëtt keng Méiglechkeet, se propper auszeschalten. Stellt Iech vir, Dir start en Auto mat enger eideler Batterie, wann de Stroum zum Steiergerät ausgeschalt gëtt. Linux stänneg op an erof sprangen. Wéi ass et, datt de System Stiwwelen ouni laang fsckwéini fänkt de motor endlech un? An d'Äntwert ass einfach. Embedded Geräter vertrauen op de Root Dateisystem nëmme fir ze liesen (ofgekierzt ro-rootfs (read-nëmme root Dateisystem)).

ro-rootfs bitt vill Virdeeler déi manner offensichtlech sinn wéi Authentizitéit. Ee Virdeel ass datt Malware net schreiwe kann /usr oder /lib, wann kee Prozess Linux kann net drop schreiwen. Eng aner ass, datt e gréisstendeels onverännerlecht Dateisystem entscheedend ass fir den Support vu Ferngeräter am Feld, well den Supportpersonal lokal Systemer benotzt, déi nominell identesch mat de Systemer virun Ort sinn. De vläicht wichtegsten (awer och heimtückeschsten) Virdeel ass, datt ro-rootfs d'Entwéckler forcéiert ze entscheeden, wéi eng Systemobjekter fréi am Systemdesign onverännerlech sinn. D'Aarbecht mat ro-rootfs kann onpraktesch a penibel sinn, wéi et dacks de Fall ass mat const Variablen a Programméiersproochen, awer seng Virdeeler iwwerweien däitlech den zousätzlechen Overhead.

Kreatioun rootfs D'Read-only-Funktionalitéit erfuerdert e puer extra Ustrengungen fir Embedded-Entwéckler, an hei kënnt VFS an d'Spill. Linux verlaangt, datt Dateien an /var schrëftlech waren, an zousätzlech, vill populär Applikatiounen datt embedded Systemer lafen wäert probéieren Configuratioun ze schafen dot-files в $HOME. Eng Léisung fir Konfiguratiounsdateien am Heemverzeechnes ass normalerweis fir se viraus ze generéieren an ze bauen rootfs. fir /var Eng méiglech Approche ass et op enger separater schreiwenbarer Partition ze montéieren, wärend / montéiert nëmmen liesen. Eng aner populär Alternativ ass d'Benotzung vu Bind- oder Overlay Mounts.

Linkbar a stackbar Mounts, hir Notzung vu Container

Kommando Ausféierung man mount ass de beschte Wee fir iwwer bindbar an iwwerlagerbare Mounts ze léieren, déi Entwéckler a Systemadministrateuren d'Fäegkeet ginn e Dateiesystem op engem Wee ze kreéieren an et dann un Uwendungen an engem aneren auszesetzen. Fir embedded Systemer heescht dat d'Fäegkeet fir Dateien ze späicheren /var op engem liesen-nëmmen Flash fueren, mee en overlay oder linkable Mount Wee vun tmpfs в /var wann Luede, et erlaabt Uwendungen Notizen do ze schreiwen (scrawl). Déi nächst Kéier Dir d'Ännerungen op /var wäert verluer goen. Eng Iwwerlagerung schaaft eng Gewerkschaft tëscht tmpfs an de Basisdaten Dateiesystem an erlaabt Iech scheinbar Ännerungen un existente Dateien ze maachen ro-tootf wärend e bindbare Mount kann nei eidel maachen tmpfs Classeure siichtbar als schreiwen an ro-rootfs Weeër. Während overlayfs dat ass déi richteg (proper) Dateisystemtyp, bindbar Mount ass implementéiert an VFS Nummraum.

Baséierend op d'Beschreiwung vun der Iwwerlagerung a verlinkbare Montage, ass keen iwwerrascht datt Linux Container si sinn aktiv benotzt. Loosst eis kucken wat geschitt wa mir benotzen systemd-nspawn fir de Container mam Tool ze lafen mountsnoop от bcc.

Rufft system-nspawn fänkt de Container beim Lafen un mountsnoop.py.

Loosst eis kucken wat geschitt ass:

Lancéiere mountsnoop wärend de Container "boott" weist datt d'Runtime vum Container héich ofhängeg ass vum Mount dat verlinkt ass (Nëmmen den Ufank vun der laanger Ausgang gëtt gewisen).

et ass systemd-nspawn stellt ausgewielte Dateien an procfs и sysfs Host zu Container als Weeër derzou rootfs... Donieft MS_BIND Fändel deen de verbindleche Mount opstellt, e puer aner Fändelen um Mount definéieren d'Relatioun tëscht Ännerunge vum Host a Containernummraim. Zum Beispill, e verlinkte Mount kann entweder Ännerungen iwwersprangen /proc и /sys an de Container, oder verstoppt se ofhängeg vum Uruff.

Konklusioun

D'intern Struktur verstoen Linux kann onméiglech ausgesinn, well de Kernel selwer eng enorm Quantitéit u Code enthält, ouni d'Userspace-Applikatiounen ze benotzen. Linux an Systemruff-Interfaces a C-Bibliothéiken wéi z. B. glibc. Ee Wee fir Fortschrëtter ze maachen ass de Quellcode vun engem Kernel-Subsystem ze liesen, mat engem Akzent op d'Verstoe vu Systemruffen a Benotzerraum-Header, souwéi d'Haaptintern Kernel-Interfaces, wéi Tabell file_operations. Dateioperatioune bidden de "Alles ass e Fichier" Prinzip, wat se besonnesch agreabel mécht ze managen. C Kernel Quelldateien am Top-Level Verzeichnis fs/ representéiert eng Implementatioun vu virtuelle Dateisystemer, déi eng Wrapper-Layer sinn, déi eng breet a relativ einfach Kompatibilitéit tëscht populäre Dateisystemer a Späichermedien ubitt. Montage mat Verknëppung an Iwwerlagerung iwwer Namespaces Linux — ass d'Magie vu VFS, déi et erméiglecht, Container a read-only Root-Dateisystemer ze kreéieren. Kombinéiert mat enger Studie vum Quellcode, dem eBPF Kernel Tool a senger Interface bcc
mécht Kär Exploratioun méi einfach wéi jee.

Frënn, loosst mech wëssen, ob dësen Artikel Iech hëllefräich war. Vläicht hutt Dir Kommentarer oder Virschléi? A fir déi, déi un dem "Administrateur"-Cours interesséiert sinn, Linux„, mir invitéieren Iech op Porte Ouverte, déi den 18. Abrëll stattfënnt.

Éischten Deel.

Source: will.com