Hallo jiddereen, mir deele mat Iech den zweeten Deel vun der Publikatioun "Virtuell Dateiesystemer am Linux: firwat si se gebraucht a wéi funktionnéieren se?" Dir kënnt den éischten Deel liesen . 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 , 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 , 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 , déi als Packagen aus der allgemenger Verdeelung verfügbar sinn an am Detail dokumentéiert . 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.pyass 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 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 Fir Sich , 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.
Wéi och ëmmer, mir wëssen all datt vill IoT Apparater, souwéi Router, Thermostaten an Autoen, elo Linux lafen. Vill vun dësen Apparater hu wéineg bis keng User-Interface, an et gëtt kee Wee fir se "propper" auszeschalten. Stellt Iech vir en Auto mat enger dout Batterie unzefänken wann d'Kraaft un d'Kontrolleenheet ass 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 (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, wa kee Linux Prozess do schreiwen kann. En aneren ass datt e gréisstendeels onverännert Dateiesystem kritesch ass fir Feldunterstëtzung vu Ferngeräter, well Supportpersonal vertrauen op lokal Systemer déi nominell identesch mat den Feldsystemer sinn. Vläicht ass de wichtegsten (awer och am meeschte verréckten) Virdeel datt ro-rootfs Entwéckler forcéiere fir ze entscheeden wéi eng Systemobjekter an der Designstadium vum System onverännerbar sinn. Mat Ro-Rootfs schaffen ka schweier a schmerzhaf sinn, well Const Variablen dacks a Programméierungssprooche sinn, awer hir Virdeeler justifiéieren einfach déi zousätzlech Overhead.
Kreatioun rootfs Lies-nëmmen erfuerdert e bëssen extra Effort fir embedded Entwéckler, an dat ass wou VFS an d'Bild kënnt. Linux erfuerdert 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 .
Baséierend op d'Beschreiwung vun der Iwwerlagerung a verlinkbare Montage, ass keen iwwerrascht datt si sinn aktiv benotzt. Loosst eis kucken wat geschitt wa mir benotzen 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éi bannenzeg Aarbecht vu Linux ze verstoen kann wéi eng onméiglech Aufgab schéngen, well de Kernel selwer eng rieseg Quantitéit vu Code enthält, andeems Linux Benotzerraumapplikatiounen a Systemruff-Interfaces a C Bibliothéiken ofgesi ginn, wéi z. 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/ presentéieren eng Implementatioun vu virtuelle Dateiesystemer, déi eng Wrapperschicht sinn déi breet a relativ einfach Kompatibilitéit tëscht populäre Dateiesystemer a Späicherapparater ubitt. Verknüpfung an Iwwerlagermontage iwwer Linux Nummraim ass d'Magie vu VFS, déi nëmme Liesbehälter a Root Dateiesystemer méiglech mécht. Kombinéiert mat enger Untersuchung vum Quellcode, dem eBPF Kärinstrument a senger Interface bcc
mécht Kär Exploratioun méi einfach wéi jee.
Frënn, schreiwen, war dësen Artikel nëtzlech fir Iech? Hutt Dir vläicht Kommentaren oder Bemierkungen? An déi, déi un de Linux Administrator Cours interesséiert sinn, sinn invitéiert , déi den 18. Abrëll stattfënnt.
Source: will.com