Hej alle sammen, vi deler anden del af publikationen "Virtuelle filsystemer i Linux: hvorfor er de nødvendige, og hvordan fungerer de?" Du kan læse første del . Lad os minde dig om, at denne serie af publikationer er timet til at falde sammen med lanceringen af en ny stream på kurset , som starter meget snart.
Sådan overvåger du VFS ved hjælp af eBPF- og bcc-værktøjer
Den nemmeste måde at forstå, hvordan kernen fungerer på filer sysfs er at se det i praksis, og den nemmeste måde at se ARM64 på er at bruge eBPF. eBPF (forkortelse for Berkeley Packet Filter) består af en virtuel maskine, der kører ind , som privilegerede brugere kan anmode om (query) fra kommandolinjen. Kernekilderne fortæller læseren, hvad kernen kan; at køre eBPF-værktøjerne på et indlæst system viser, hvad kernen rent faktisk gør.
Heldigvis er det ret nemt at komme i gang med at bruge eBPF ved hjælp af værktøjer , som er tilgængelige som pakker fra den generelle distribution og dokumenteret i detaljer . Værktøjer bcc er Python-scripts med små indsættelser af C-kode, hvilket betyder, at enhver, der er fortrolig med begge sprog, nemt kan ændre dem. I bcc/tools Der er 80 Python-scripts, hvilket betyder, at en udvikler eller systemadministrator højst sandsynligt vil være i stand til at vælge noget, der passer til at løse problemet.
For at få mindst en overfladisk idé om, hvad VFS'er udfører på et kørende system, prøv vfscount eller vfsstat. Dette vil vise, lad os sige, at dusinvis af opkald vfs_open() og "hans venner" sker bogstaveligt talt hvert sekund.
vfsstat.pyer et Python-script med C-kodeindsættelser, der blot tæller VFS-funktionskald.
Lad os give et mere trivielt eksempel og se, hvad der sker, når vi indsætter et USB-flashdrev i en computer, og systemet registrerer det.
Ved hjælp af eBPF kan du se, hvad der sker i
/sysnår et USB-flashdrev er isat. Et enkelt og komplekst eksempel er vist her.
I eksemplet vist ovenfor, bcc инструмент udskriver en meddelelse, når kommandoen køres sysfs_create_files(). Det ser vi sysfs_create_files() blev lanceret vha kworker stream som svar på det faktum, at flashdrevet blev indsat, men hvilken fil blev oprettet? Det andet eksempel viser styrken af eBPF. Her trace.py Udskriver en kerne-backtrace (-K option) og navnet på den fil, der blev oprettet sysfs_create_files(). Enkelt sætningsindsættelse er C-kode, der inkluderer en let genkendelig formatstreng leveret af Python-scriptet, der kører LLVM just-in-time compiler. Den kompilerer denne linje og udfører den i en virtuel maskine inde i kernen. Fuld funktions signatur sysfs_create_files () skal gengives i den anden kommando, så formatstrengen kan referere til en af parametrene. Fejl i dette stykke C-kode resulterer i genkendelige fejl fra C-kompileren. For eksempel, hvis parameteren -l er udeladt, vil du se "Kunnede ikke kompilere BPF-tekst." Udviklere, der er fortrolige med C og Python, vil finde værktøjerne bcc let at udvide og ændre.
Når USB-drevet er indsat, vil kerne-backtrace vise, at PID 7711 er en tråd kworkersom oprettede filen «events» в sysfs. I overensstemmelse hermed er opkaldet fra sysfs_remove_files() vil vise, at fjernelse af drevet resulterede i, at filen blev slettet events, hvilket svarer til det generelle koncept for referencetælling. Samtidig ses sysfs_create_link () med eBPF, mens du indsætter USB-drevet, vil vise, at der er oprettet mindst 48 symbolske links.
Så hvad er meningen med begivenhedsfilen? Brug Til søgning , viser, hvad det forårsager disk_add_events (), og enten "media_change"Eller "eject_request" kan optages i en begivenhedsfil. Her informerer kernebloklaget brugerområdet om, at en "disk" er dukket op og skubbet ud. Bemærk, hvor informativ denne undersøgelsesmetode er ved at indsætte et USB-drev sammenlignet med at forsøge at finde ud af, hvordan tingene fungerer udelukkende fra kilden.
Skrivebeskyttede rodfilsystemer aktiverer indlejrede enheder
Selvfølgelig er der ingen, der slukker for serveren eller deres computer ved at trække stikket ud af stikkontakten. Men hvorfor? Dette skyldes, at monterede filsystemer på fysiske lagerenheder kan have forsinket skrivning, og de datastrukturer, der registrerer deres tilstand, er muligvis ikke synkroniseret med skrivninger til lagringen. Når dette sker, skal systemejere vente til næste opstart for at starte værktøjet. fsck filesystem-recovery og i værste fald miste data.
Vi ved dog alle, at mange IoT-enheder, såvel som routere, termostater og biler, nu kører Linux. Mange af disse enheder har en lille eller ingen brugergrænseflade, og der er ingen måde at slukke dem "rent". Forestil dig at starte en bil med et dødt batteri, når strømmen til styreenheden er hele tiden hopper op og ned. Hvordan er det, at systemet starter uden en lang fsckhvornår begynder motoren endelig at køre? Og svaret er enkelt. Indlejrede enheder er afhængige af rodfilsystemet (forkortet ro-rootfs (skrivebeskyttet rodfilsystem)).
ro-rootfs tilbyder mange fordele, der er mindre indlysende end autenticitet. En fordel er, at malware ikke kan skrive til /usr eller /lib, hvis ingen Linux-proces kan skrive der. En anden er, at et stort set uforanderligt filsystem er afgørende for feltunderstøttelse af fjerntliggende enheder, da supportpersonale er afhængige af lokale systemer, der nominelt er identiske med feltsystemerne. Den måske vigtigste (men også mest lumske) fordel er, at ro-rootfs tvinger udviklere til at beslutte, hvilke systemobjekter, der vil være uforanderlige på systemets designstadium. At arbejde med ro-rootfs kan være akavet og smertefuldt, da const-variabler ofte er i programmeringssprog, men deres fordele retfærdiggør nemt den ekstra overhead.
skabelse rootfs Skrivebeskyttet kræver noget ekstra indsats for indlejrede udviklere, og det er her VFS kommer ind i billedet. Linux kræver, at filer er i /var var skrivbare, og desuden vil mange populære applikationer, der kører indlejrede systemer, forsøge at oprette konfiguration dot-files в $HOME. En løsning til konfigurationsfiler i hjemmemappen er normalt at prægenerere og indbygge dem i rootfs. Til /var En mulig fremgangsmåde er at montere den på en separat skrivbar partition, mens / monteret skrivebeskyttet. Et andet populært alternativ er at bruge binde- eller overlejringsbeslag.
Sammenhængbare og stabelbare holdere, deres brug af containere
Kommandoudførelse man mount er den bedste måde at lære om bindbare og overlejrbare monteringer, som giver udviklere og systemadministratorer mulighed for at oprette et filsystem på én sti og derefter udsætte det for applikationer i en anden. For indlejrede systemer betyder dette muligheden for at gemme filer i /var på et skrivebeskyttet flashdrev, men en overlejrings- eller linkbar monteringssti fra tmpfs в /var når den indlæses, vil det tillade programmer at skrive noter der (scrawl). Næste gang du slår ændringerne til /var vil gå tabt. Et overlægsbeslag skaber en forening mellem tmpfs og det underliggende filsystem og giver dig mulighed for at foretage tilsyneladende ændringer af eksisterende filer i ro-tootf hvorimod et bindbart beslag kan gøre nye tomme tmpfs mapper synlige som skrivbare i ro-rootfs måder. Mens overlayfs dette er den rigtige (proper) filsystemtype, bindbar montering er implementeret i .
Baseret på beskrivelsen af overlejringen og det sammenkoblede beslag er ingen overrasket over det de bruges aktivt. Lad os se, hvad der sker, når vi bruger for at køre beholderen ved hjælp af værktøjet mountsnoop fra bcc.
opkald system-nspawn starter beholderen, mens den kører mountsnoop.py.
Lad os se, hvad der skete:
Запуск mountsnoop mens containeren "starter" viser, at containerens køretid er meget afhængig af monteringen, der er linket (kun begyndelsen af det lange output vises).
Her systemd-nspawn leverer udvalgte filer i procfs и sysfs vært til container som stier til den rootfs... Udover MS_BIND flag, der opsætter bindingsmonteringen, definerer nogle andre flag på monteringen forholdet mellem ændringer af værts- og containernavneområderne. For eksempel kan en sammenkædet montering enten springe ændringer til /proc и /sys ind i containeren, eller skjul dem afhængigt af opkaldet.
Konklusion
At forstå Linux' indre funktioner kan virke som en umulig opgave, da kernen selv indeholder en enorm mængde kode, når man ser bort fra Linux-brugerpladsapplikationer og systemopkaldsgrænseflader i C-biblioteker som f.eks. glibc. En måde at gøre fremskridt på er at læse kildekoden for et kerneundersystem med vægt på at forstå systemkald og brugerrumsheadere samt de vigtigste interne kernegrænseflader, såsom tabel file_operations. Filhandlinger giver "alt er en fil"-princippet, hvilket gør dem særligt behagelige at administrere. C-kernens kildefiler i mappen på øverste niveau fs/ præsentere en implementering af virtuelle filsystemer, som er et indpakningslag, der giver bred og relativt enkel kompatibilitet mellem populære filsystemer og lagerenheder. Linkning og overlejringsmontering via Linux-navneområder er magien ved VFS, der gør det muligt at oprette skrivebeskyttede containere og root-filsystemer. Kombineret med en undersøgelse af kildekoden, eBPF-kerneværktøjet og dets grænseflade bcc
gør kerneudforskning nemmere end nogensinde før.
Venner, skriv, var denne artikel nyttig for dig? Måske har du nogle kommentarer eller bemærkninger? Og de, der er interesserede i Linux Administrator-kurset er inviteret til , som finder sted den 18. april.
Kilde: www.habr.com