Hallo elkenien, wy diele mei jo it twadde diel fan 'e publikaasje "Virtuele bestânsystemen yn Linux: wêrom binne se nedich en hoe wurkje se?" Jo kinne it earste diel lêze . Lit ús jo herinnerje dat dizze searje publikaasjes op tiid is om gear te fallen mei de lansearring fan in nije stream op 'e kursus , dy't hiel gau begjint.
Hoe kinne jo VFS kontrolearje mei eBPF- en bcc-ark
De maklikste manier om te begripen hoe't de kernel wurket op bestannen sysfs is om it yn 'e praktyk te sjen, en de maklikste manier om ARM64 te besjen is eBPF te brûken. eBPF (koart foar Berkeley Packet Filter) bestiet út in firtuele masine dy't yn rint , hokker befoarrjochte brûkers kinne oanfreegje (query) fan 'e kommandorigel. De kearnboarnen fertelle de lêzer wat de kearn dwaan kin; it útfieren fan de eBPF-ark op in laden systeem lit sjen wat de kernel eins docht.
Gelokkich is it begjinnen fan eBPF frij maklik mei help fan ark , dy't beskikber binne as pakketten fan 'e algemiene distribúsje en dokumintearre yn detail . Tools bcc binne Python-skripts mei lytse ynfoegingen fan C-koade, wat betsjut dat elkenien dy't fertroud is mei beide talen se maklik feroarje kin. YN bcc/tools D'r binne 80 Python-skripts, wat betsjut dat wierskynlik in ûntwikkelder of systeembehearder wat geskikt kin kieze foar it oplossen fan it probleem.
Om op syn minst in oerflakkich idee te krijen fan wat wurk VFS's dogge op in rinnend systeem, besykje vfscount of vfsstat. Dit sil sjen litte, lit ús sizze, dat tsientallen oproppen vfs_open() en "syn freonen" barre letterlik elke sekonde.
vfsstat.pyis in Python-skript mei C-koade-ynfoegingen dy't gewoan VFS-funksjeoproppen telt.
Litte wy in mear triviale foarbyld jaan en sjen wat der bart as wy in USB-flashdrive yn in kompjûter ynfoegje en it systeem detekt.
Mei eBPF kinne jo sjen wat der yn bart
/sysas in USB flash drive wurdt ynfoege. In ienfâldich en kompleks foarbyld wurdt hjir werjûn.
Yn it hjirboppe werjûn foarbyld, bcc ynstrumint print in berjocht as it kommando wurdt útfierd sysfs_create_files(). Wy sjogge dat sysfs_create_files() waard lansearre mei help kworker stream yn reaksje op it feit dat de flash drive waard ynfoege, mar hokker triem is makke? It twadde foarbyld lit de krêft fan eBPF sjen. Hjir trace.py drukt in kernel-backtrace (-K opsje) en de namme fan it bestân dat is makke sysfs_create_files(). Ynfoegje fan ienige ferklearring is C-koade dy't in maklik werkenbere opmaakstring omfettet levere troch it Python-skript dat LLVM rint just-in-time kompilator. It kompilearret dizze line en fiert it út yn in firtuele masine binnen de kernel. Folsleine funksje hântekening sysfs_create_files () moat wurde reprodusearre yn it twadde kommando sadat de opmaak tekenrige kin ferwize nei ien fan de parameters. Flaters yn dit stik C-koade resultearje yn werkenbere flaters fan 'e C-kompiler. Bygelyks, as de parameter -l is weilitten, sille jo "BPF-tekst kompilearje mislearre." Untwikkelders dy't bekend binne mei C en Python sille de ark fine bcc maklik te wreidzjen en te feroarjen.
As it USB-stasjon is ynfoege, sil de kernel-backtrace sjen litte dat PID 7711 in thread is kworkerdy't it bestân makke «events» в sysfs. Dêrtroch is de oprop fan sysfs_remove_files() sil sjen litte dat it fuortheljen fan it stasjon resultearre yn it wiskjen fan de triem events, wat oerienkomt mei it algemiene begryp fan referinsjeteljen. Tagelyk, besjen sysfs_create_link () mei eBPF wylst jo it USB-stasjon ynfoegje sil sjen litte dat op syn minst 48 symboalyske keppelings binne makke.
Dus wat is it punt fan it barrensbestân? Gebrûk Foar sykjen , lit sjen wat it feroarsaket disk_add_events (),en of "media_change", of "eject_request" kin wurde opnommen yn in evenemint triem. Hjiryn ynformearret de kernelbloklaach brûkersromte dat in "skiif" is ferskynd en útstutsen. Tink derom hoe ynformatyf dizze ûndersyksmetoade is troch it ynfoegjen fan in USB-stasjon, fergelike mei besykje út te finen hoe't dingen puur út 'e boarne wurkje.
Allinnich-lêzen root-bestânsystemen ynskeakelje ynbêde apparaten
Fansels makket gjinien de tsjinner of har kompjûter út troch de stekker út 'e socket te lûken. Wêrom? Dit komt om't monteare bestânsystemen op fysike opslachapparaten skriuwwurken hawwe kinne, en de gegevensstruktueren dy't har steat opnimme meie net syngronisearre wurde mei skriuwingen nei de opslach. As dit bart, moatte systeemeigners wachtsje oant de folgjende boot om it hulpprogramma te starten. fsck filesystem-recovery en, yn it slimste gefal, gegevens ferlieze.
Wy witte lykwols allegear dat in protte IoT-apparaten, lykas routers, thermostaten en auto's, no Linux rinne. In protte fan dizze apparaten hawwe in bytsje oant gjin brûkersynterface, en d'r is gjin manier om se "skjin" út te skeakeljen. Stel jo foar dat jo in auto begjinne mei in deade batterij as de macht nei de kontrôle ienheid is hieltyd op en del springe. Hoe is it dat it systeem boots sûnder in lange fsckwannear begjint de motor einlings te rinnen? En it antwurd is ienfâldich. Ynbêde apparaten fertrouwe op it rootbestânsysteem (ôfkoarte ro-rootfs (allinich-lês-root triemsysteem)).
ro-rootfs biede in protte foardielen dy't minder fanselssprekkend binne as autentisiteit. Ien foardiel is dat malware net nei skriuwe kin /usr of /lib, as gjin Linux-proses dêr kin skriuwe. In oar is dat in foar it grutste part ûnferoarlik bestânsysteem kritysk is foar fjildstipe fan apparaten op ôfstân, om't stipepersoniel fertrout op lokale systemen dy't nominaal identyk binne mei de fjildsystemen. Miskien is it wichtichste (mar ek meast ferrifeljende) foardiel dat ro-rootfs ûntwikkelders twingt om te besluten hokker systeemobjekten ûnferoarlik sille wêze yn it ûntwerpstadium fan it systeem. Wurkje mei ro-rootfs kin ûnhandich en pynlik wêze, om't const fariabelen faak binne yn programmeartalen, mar har foardielen rjochtfeardigje maklik de ekstra overhead.
skepping rootfs Allinnich lêzen fereasket wat ekstra ynspannings foar ynbêde ûntwikkelders, en dit is wêr VFS yn 'e foto komt. Linux fereasket dat bestannen yn binne /var wiene skriuwber, en boppedat, in protte populêre applikaasjes dy't rinne ynbêde systemen sille besykje te meitsjen konfiguraasje dot-files в $HOME. Ien oplossing foar konfiguraasjebestannen yn 'e thúsmap is normaal om se foar te generearjen en yn te bouwen rootfs. foar /var Ien mooglike oanpak is te mount it op in aparte skriuwbere partition, wylst / mounted allinne-lês. In oar populêr alternatyf is it brûken fan bind- of overlay-mounts.
Keppelbere en stapelbere mounts, har gebrûk troch konteners
It útfieren fan in kommando man mount is de bêste manier om te learen oer bindbere en oerlaadbere mounts, dy't ûntwikkelders en systeembehearders de mooglikheid jouwe om in bestânsysteem op ien paad te meitsjen en it dan bleatstelle oan applikaasjes yn in oar. Foar ynbêde systemen betsjut dit de mooglikheid om bestannen yn te bewarjen /var op in read-allinnich flash drive, mar in overlay of linkable mount paad fan tmpfs в /var by it laden sil it applikaasjes tastean om dêr notysjes te skriuwen (scrawl). De folgjende kear as jo de feroarings ynskeakelje nei /var sil ferlern gean. In overlay mount skept in uny tusken tmpfs en it ûnderlizzende bestânsysteem en kinne jo skynbere wizigingen meitsje oan besteande bestannen yn ro-tootf wylst in bindbere berch nijen leech meitsje kin tmpfs mappen sichtber as skriuwber yn ro-rootfs manieren. Wylst overlayfs dit is de goede (proper) triemsysteemtype, bindbere berch wurdt ymplementearre yn .
Op grûn fan de beskriuwing fan de overlay en linkable mount, gjinien is ferrast dat se wurde aktyf brûkt. Litte wy sjen wat der bart as wy brûke om de kontener út te fieren mei it ark mountsnoop от bcc.
Challenge system-nspawn begjint de kontener wylst it rint mountsnoop.py.
Litte wy sjen wat der bard is:
Te rinnen mountsnoop wylst de kontener "opstart" lit sjen dat de kontener syn runtime is tige ôfhinklik fan de berch wurdt keppele (Allinne it begjin fan 'e lange útfier wurdt werjûn).
it is systemd-nspawn jout selektearre triemmen yn procfs и sysfs host nei kontener as paden nei it rootfs... Neist MS_BIND flagge dy't stelt de binende berch, guon oare flaggen op de berch definiearje de relaasje tusken feroarings oan de host en container nammeromten. Bygelyks, in keppele berch kin wizigingen oerslaan nei /proc и /sys yn 'e kontener, of ferbergje se ôfhinklik fan de oprop.
konklúzje
It begripen fan 'e ynderlike wurking fan Linux kin lykje as in ûnmooglike taak, om't de kernel sels in enoarme hoemannichte koade befettet, it ferlitten fan Linux-brûkersromteapplikaasjes en systeemoprop-ynterfaces yn C-biblioteken lykas glibc. Ien manier om foarútgong te meitsjen is de boarnekoade fan ien kernel-subsysteem te lêzen, mei in klam op it begripen fan systeemoproppen en brûkersromte-headers, lykas de wichtichste ynterne kernel-ynterfaces, lykas tabel file_operations. Bestânsoperaasjes jouwe it prinsipe "alles is in bestân", wêrtroch't se benammen noflik binne om te behearjen. C kernel boarne triemmen yn de top-nivo map fs/ presintearje in ymplemintaasje fan firtuele triem systemen, dat binne in wrapper laach dat jout brede en relatyf ienfâldige komptabiliteit tusken populêre triem systemen en opslach apparaten. Keppeling en montage fan overlay fia Linux-nammeromten is de magy fan VFS dy't it meitsjen fan allinich-lêskonteners en root-bestânsystemen mooglik makket. Kombinearre mei in ûndersyk fan 'e boarne koade, de eBPF kearn ark en syn ynterface bcc
it meitsjen fan kearnferkenning makliker as ea.
Freonen, skriuw, wie dit artikel nuttich foar jo? Hawwe jo miskien opmerkings of opmerkings? En dyjingen dy't ynteressearre binne yn 'e kursus Linux Administrator wurde útnoege foar , dat sil plakfine op 18 april.
Boarne: www.habr.com